前言
大家好，我是敖小劍，今天給大家分享的主題是"利用開源社群打造微服務生态體系"。
主要内容如下：
内容分為三個大的部分：
1. 微服務的核心技術
2. 目前可選的開源微服務架構
3. 為微服務提供支撐的基礎設施
需要說明的是，由于時間有限，而分享的内容數量太多，是以：
1. 内容都隻是羅列，不展開具體介紹
2. 個人知識面有限，列舉過程中範圍覆寫不足有所遺漏是必然的
3. 部分場景我會給出一些個人建議，但是請注意這些都是我的一家之言，僅供參考
下面列出的是今天将會介紹的内容，數量非常多，可謂繁星璀璨。
第一部分：核心技術
現在開始第一個部分：核心技術。
内容主要是第一排的四個技術：
- 程序間通訊
- 服務注冊與發現
- 負載均衡
- 熔斷
第二排的三個内容基本都會在類庫或者架構中包含，通常不會單獨放出來，是以我們不詳細展開。
在展開講述程序間通訊之前，額外指出一個對微服務而言及其重要的概念：
在微服務架構中，為了徹底隔絕不同服務，采用了最堅決的方案，強制要求服務之間：通過 **遠端通路** 方式進行通訊
在這點上，微服務和以osgi、jigsaw為代表的java子產品化方案形成鮮明對比。
程序間通訊的方式比較多，其多樣性展現在兩個方面：
- 有三種風格的解決方案：rest，rpc 和 定制
- 互動方式有兩個次元：按照互動對象的數量分為一對一和一對多，按照應答傳回的方式分為同步和異步。
兩個次元組合之後的可能性如圖：
目前業界常見的網絡類庫：
考慮到 netty 通常會是大多數人的選擇，這裡再展開談一下 netty 的版本選擇問題.
需要特别強調的是： netty 5.* 版本因為 forkjoinpool 引入了太多複雜度而又未能帶來明确的性能提升，已經被 netty 官方放棄，不再繼續。使用 netty 5.* alpha 版本的同學請回退到 4.0 或者 4.1 版本。
rest 研究不多，隻能給出一點簡單的建議。
rpc架構，業界數得上數的大概有十幾種，這裡隻詳細介紹三種，分别代表老中新三代rpc架構。
以下是個人給出的建議：
提醒一點的是：如果需要支援移動裝置，如果想要用htttp 2 的新特性，那麼就隻能選擇grpc了。
談談第三條路線：定制。選擇這種方案的同學也不少。
消息隊列的選擇，同樣很多，這裡列出三種常見的加一個特例 nsq。
首先看服務注冊和服務發現，在實作時根據對一緻性要求的不同，分成兩個流派：
1. 強一緻性
比較常見的分布式一緻性協定是 paxos 協定和 raft 協定。相比 paxos 而言，raft 協定易于了解和實作，是以最新的分布式一緻性方案大都選擇 raft 協定。
zookeeper 采用的是 paxos 協定(實際為改進版本zap)，而 raft 協定那邊主要是 consul 和 etcd。
2. 弱一緻性
如果對一緻性要求不高，可以選擇以 dns 為基礎的方案，也可以像新浪微網誌的 vintage 一樣基于 redis 。
常見的強一緻性方案如下：
弱一緻性方案比較少，一般多用于 rest 或者 http + json / web service 等簡單場合：
負載均衡的方案選擇，注意區分伺服器端負載均衡和用戶端負載均衡。
熔斷器目前隻有一個可選的開源方案，之前有同學吐糟說 hystrix 的設計和實作不好，但是在2016年又改進了很多。
第二部分：微服務架構
在國内讨論soa、服務化、微服務時，dubbo 總是一個繞不開的名字。個人對 dubbo 的評價是"國内soa架構集大成之作"，基本上一個soa架構應有的功能都有了。
回顧一下 dubbo 曾經輝煌的曆史：
再對比一下現狀，實在令人感歎：
從時間線上來看 dubbo 的崛起和興盛，猶如流星劃過夜空.
對 dubbo 的總結，有比較多的個人情緒在，僅供參考。
motan，能否接過 dubbo 的大旗？
發現每個服務化架構出來，都要被問一個問題：為啥你們不直接用 dubbo 呢？ motan也未能免俗 :)
補充：這也是我自己不選擇 dubbo，而是新設計 dolphin 微服務架構的重要理由之一。改造成本遠不是一句輕巧的"稍微改改"那麼簡單。
motan的技術棧：
下面介紹業界大佬 netflix 出品的重量級開源産品 oss 套件。
netflix 比較有意思的一個做法是他的組建拆分的比較細緻，每個獨立功能都拆分為單獨的元件，友善按需選擇，贊一個。
個人對 oss 的一些看法，屬于雞蛋裡面挑骨頭性質，僅供參考。
下面開始介紹另外一位業界超重量級大佬的一系列作品，所有java同學都最熟悉不過的 spring。
在介紹spring為微服務提供的支援之前，我們先回顧一下過去這十四年spring一路的曆程：
開始大叔式的懷舊環節，想當年我們看這幾本書的時候，我們還那麼年輕 :)
唠叨幾句：rod johnson 大叔(現在可能要稱為大爺了) 是我最敬仰最崇拜的業界大神之一。做技術能做到他這水準，此生無憾。
在spring從2002年出道開始，這十幾年間出了很多裡程碑式版本，增加了很多重量級的功能。但是，個人評價，2014年spring boot的問世，才是最近三五年間spring最大的變革和重新思考。
springboot的出現，代表着spring已經不再沉迷于貪吃蛇遊戲，而是開始檢討自身和自我改造，對于一個發展了十多年的老架構來說，認識到這點，遠比加一兩個新功能重要的多。
對 spring boot 總結，這也是我選擇 spring boot 作為新的 dolphin 微服務架構基石的重要理由。
spring cloud 出場，2015年才出來的新面孔。
承載着spring對微服務架構領域的衆望和抱負。
一出場，就是大量的子項目，這裡隻列出平時比較常用的一些：
spring cloud netflix 子項目的出現，更像是spring之前的做事風格，做他最擅長的領域：內建。
以下内容是後面補充，沒有在會場直接說，純屬個人吐糟：
對spring cloud的個人評價：想法很好，出發點正确，市場空缺而切入的時機很合适。但是，spring cloud的實際表現，總給人一種束手束腳，瞻前顧後，小富即安的感覺。對比十幾年前 rod johnson 大叔意氣風發，氣壯山河，談笑間掀翻ejb的王座的表現，如今的spring cloud，能力不足，信心不夠，格局太小，難成大器。期待後面能有轉變。
下面是對目前微服務架構的個人看法：
第三部分：基礎設施
由于演講時間隻有一個小時，是以基礎設施的很多内容無法羅列，這次隻是介紹了其中小部分的内容。
分布式配置管理的目前主流底層存儲的方案，如果自己動手打造那麼可選的無非就是下面這些：
也可以選擇現有成型的開源産品：
apm領域的選擇，商業産品很多，但是開源的選擇實在不多：
在日志分析領域，elk是王者，但是也有新秀出場：
結束語
洋洋灑灑的列舉了幾十個名字，但并不是讓大家每個名字都去探索一遍，日常中如果需要做技術抉擇，我有兩句話：
仰望星空，看弱水三千：眼界要開闊，知識面要廣，哪怕隻是精通各種名字，至少，知道在某個地方有個好東西，知道某個領域有其他的選擇
立足當下，吾隻取一瓢：最終還是要落地的，能玩的轉的東西才是好東西。另外，好東西雖多，找到一個能适合自己，能解決問題的就好了，别貪心，别貪多
分享者簡介：
敖小劍，ppmoney資深架構師，14年軟體開發經驗，對靈活開發，架構設計有深入研究，曾在亞信，愛立信，唯品會任職。現任ppmoney基礎架構負責人，負責dolphin微服務架構和配套基礎設施的開發，推進公司全面服務化。
本文轉載自微信公衆号 中生代技術 freshmantechnology