微服务技术栈选型
https://yq.aliyun.com/articles/62569
前言
大家好，我是敖小劍，今天給大家分享的主題是"利用開源社區打造微服務生態體系"。
主要內容如下：
內容分為三個大的部分：
?
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是王者，但是也有新秀出場：
結束語
洋洋灑灑的列舉了幾十個名字，但并不是讓大家每個名字都去探索一遍，日常中如果需要做技術抉擇，我有兩句話：
仰望星空，看弱水三千：眼界要開闊，知識面要廣，哪怕只是精通各種名字，至少，知道在某個地方有個好東西，知道某個領域有其他的選擇
立足當下，吾只取一瓢：最終還是要落地的，能玩的轉的東西才是好東西。另外，好東西雖多，找到一個能適合自己，能解決問題的就好了，別貪心，別貪多
?
轉載于:https://www.cnblogs.com/davidwang456/articles/9247089.html
總結
- 上一篇： 有赞统一日志平台初探
- 下一篇： 拍拍信微服务网关实践分享