微服务技术栈选型
https://yq.aliyun.com/articles/62569
前言
大家好，我是敖小劍，今天給大家分享的主題是"利用開源社區(qū)打造微服務(wù)生態(tài)體系"。
主要內(nèi)容如下：
內(nèi)容分為三個大的部分：
?
1. 微服務(wù)的核心技術(shù)
2. 目前可選的開源微服務(wù)框架
3. 為微服務(wù)提供支撐的基礎(chǔ)設(shè)施
?
需要說明的是，由于時間有限，而分享的內(nèi)容數(shù)量太多，因此：
?
1. 內(nèi)容都只是羅列，不展開具體介紹
2. 個人知識面有限，列舉過程中范圍覆蓋不足有所遺漏是必然的
3. 部分場景我會給出一些個人建議，但是請注意這些都是我的一家之言，僅供參考
下面列出的是今天將會介紹的內(nèi)容，數(shù)量非常多，可謂繁星璀璨。
?
第一部分：核心技術(shù)
?
現(xiàn)在開始第一個部分：核心技術(shù)。
內(nèi)容主要是第一排的四個技術(shù)：
?
- 進程間通訊
- 服務(wù)注冊與發(fā)現(xiàn)
- 負載均衡
- 熔斷
?
第二排的三個內(nèi)容基本都會在類庫或者框架中包含，通常不會單獨放出來，因此我們不詳細展開。
在展開講述進程間通訊之前，額外指出一個對微服務(wù)而言及其重要的概念：
?
在微服務(wù)架構(gòu)中，為了徹底隔絕不同服務(wù)，采用了最堅決的方案，強制要求服務(wù)之間：通過 **遠程訪問** 方式進行通訊
?
在這點上，微服務(wù)和以O(shè)SGi、jigsaw為代表的Java模塊化方案形成鮮明對比。
進程間通訊的方式比較多，其多樣性體現(xiàn)在兩個方面：
?
- 有三種風(fēng)格的解決方案：REST，RPC 和 定制
- 交互方式有兩個維度：按照交互對象的數(shù)量分為一對一和一對多，按照應(yīng)答返回的方式分為同步和異步。
兩個維度組合之后的可能性如圖：
目前業(yè)界常見的網(wǎng)絡(luò)類庫：
考慮到 netty 通常會是大多數(shù)人的選擇，這里再展開談一下 netty 的版本選擇問題.
?
需要特別強調(diào)的是： netty 5.* 版本因為 ForkJoinPool 引入了太多復(fù)雜度而又未能帶來明確的性能提升，已經(jīng)被 netty 官方放棄，不再繼續(xù)。使用 netty 5.* alpha 版本的同學(xué)請回退到 4.0 或者 4.1 版本。
Rest 研究不多，只能給出一點簡單的建議。
RPC框架，業(yè)界數(shù)得上數(shù)的大概有十幾種，這里只詳細介紹三種，分別代表老中新三代RPC框架。
以下是個人給出的建議：
提醒一點的是：如果需要支持移動設(shè)備，如果想要用HTTTP 2 的新特性，那么就只能選擇gRPC了。
?
談?wù)劦谌龡l路線：定制。選擇這種方案的同學(xué)也不少。
消息隊列的選擇，同樣很多，這里列出三種常見的加一個特例 NSQ。
首先看服務(wù)注冊和服務(wù)發(fā)現(xiàn)，在實現(xiàn)時根據(jù)對一致性要求的不同，分成兩個流派：
?
1. 強一致性
比較常見的分布式一致性協(xié)議是 PAXOS 協(xié)議和 Raft 協(xié)議。相比 PAXOS 而言，Raft 協(xié)議易于理解和實現(xiàn)，因此最新的分布式一致性方案大都選擇 Raft 協(xié)議。
zookeeper 采用的是 PAXOS 協(xié)議(實際為改進版本ZAP)，而 Raft 協(xié)議那邊主要是 consul 和 etcd。
2. 弱一致性
如果對一致性要求不高，可以選擇以 DNS 為基礎(chǔ)的方案，也可以像新浪微博的 Vintage 一樣基于 Redis 。
常見的強一致性方案如下：
弱一致性方案比較少，一般多用于 REST 或者 HTTP + json / web service 等簡單場合：
負載均衡的方案選擇，注意區(qū)分服務(wù)器端負載均衡和客戶端負載均衡。
熔斷器目前只有一個可選的開源方案，之前有同學(xué)吐糟說 Hystrix 的設(shè)計和實現(xiàn)不好，但是在2016年又改進了很多。
第二部分：微服務(wù)框架
在國內(nèi)討論SOA、服務(wù)化、微服務(wù)時，dubbo 總是一個繞不開的名字。個人對 dubbo 的評價是"國內(nèi)SOA框架集大成之作"，基本上一個SOA框架應(yīng)有的功能都有了。
回顧一下 dubbo 曾經(jīng)輝煌的歷史：
再對比一下現(xiàn)狀，實在令人感嘆：
從時間線上來看 dubbo 的崛起和興盛，猶如流星劃過夜空.
對 dubbo 的總結(jié)，有比較多的個人情緒在，僅供參考。
Motan，能否接過 dubbo 的大旗？
發(fā)現(xiàn)每個服務(wù)化框架出來，都要被問一個問題：為啥你們不直接用 dubbo 呢？ Motan也未能免俗 :)
補充：這也是我自己不選擇 dubbo，而是新設(shè)計 dolphin 微服務(wù)框架的重要理由之一。改造成本遠不是一句輕巧的"稍微改改"那么簡單。
Motan的技術(shù)棧：
下面介紹業(yè)界大佬 Netflix 出品的重量級開源產(chǎn)品 OSS 套件。
Netflix 比較有意思的一個做法是他的組建拆分的比較細致，每個獨立功能都拆分為單獨的組件，方便按需選擇，贊一個。
個人對 OSS 的一些看法，屬于雞蛋里面挑骨頭性質(zhì)，僅供參考。
下面開始介紹另外一位業(yè)界超重量級大佬的一系列作品，所有Java同學(xué)都最熟悉不過的 spring。
在介紹spring為微服務(wù)提供的支持之前，我們先回顧一下過去這十四年spring一路的歷程：
開始大叔式的懷舊環(huán)節(jié)，想當年我們看這幾本書的時候，我們還那么年輕 :)
?
嘮叨幾句：Rod Johnson 大叔(現(xiàn)在可能要稱為大爺了) 是我最敬仰最崇拜的業(yè)界大神之一。做技術(shù)能做到他這水準，此生無憾。
在spring從2002年出道開始，這十幾年間出了很多里程碑式版本，增加了很多重量級的功能。但是，個人評價，2014年spring boot的問世，才是最近三五年間spring最大的變革和重新思考。
?
springboot的出現(xiàn)，代表著spring已經(jīng)不再沉迷于貪吃蛇游戲，而是開始反省自身和自我改造，對于一個發(fā)展了十多年的老框架來說，認識到這點，遠比加一兩個新功能重要的多。
對 spring boot 總結(jié)，這也是我選擇 spring boot 作為新的 dolphin 微服務(wù)框架基石的重要理由。
spring cloud 出場，2015年才出來的新面孔。
承載著spring對微服務(wù)架構(gòu)領(lǐng)域的眾望和抱負。
一出場，就是大量的子項目，這里只列出平時比較常用的一些：
Spring Cloud Netflix 子項目的出現(xiàn)，更像是spring之前的做事風(fēng)格，做他最擅長的領(lǐng)域：集成。
以下內(nèi)容是后面補充，沒有在會場直接說，純屬個人吐糟：
對spring cloud的個人評價：想法很好，出發(fā)點正確，市場空缺而切入的時機很合適。但是，spring cloud的實際表現(xiàn)，總給人一種束手束腳，瞻前顧后，小富即安的感覺。對比十幾年前 Rod Johnson 大叔意氣風(fēng)發(fā)，氣壯山河，談笑間掀翻EJB的王座的表現(xiàn)，如今的spring cloud，能力不足，信心不夠，格局太小，難成大器。期待后面能有轉(zhuǎn)變。
下面是對目前微服務(wù)框架的個人看法：
第三部分：基礎(chǔ)設(shè)施
由于演講時間只有一個小時，因此基礎(chǔ)設(shè)施的很多內(nèi)容無法羅列，這次只是介紹了其中小部分的內(nèi)容。
分布式配置管理的目前主流底層存儲的方案，如果自己動手打造那么可選的無非就是下面這些：
也可以選擇現(xiàn)有成型的開源產(chǎn)品：
APM領(lǐng)域的選擇，商業(yè)產(chǎn)品很多，但是開源的選擇實在不多：
在日志分析領(lǐng)域，ELK是王者，但是也有新秀出場：
結(jié)束語
洋洋灑灑的列舉了幾十個名字，但并不是讓大家每個名字都去探索一遍，日常中如果需要做技術(shù)抉擇，我有兩句話：
仰望星空，看弱水三千：眼界要開闊，知識面要廣，哪怕只是精通各種名字，至少，知道在某個地方有個好東西，知道某個領(lǐng)域有其他的選擇
立足當下，吾只取一瓢：最終還是要落地的，能玩的轉(zhuǎn)的東西才是好東西。另外，好東西雖多，找到一個能適合自己，能解決問題的就好了，別貪心，別貪多
?
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9247089.html
總結(jié)
- 上一篇： 有赞统一日志平台初探
- 下一篇： 拍拍信微服务网关实践分享