1.SpringCloud和Dubbo
SpringCloud和Dubbo都是現在主流的微服務架構
- SpringCloud是Apache旗下的Spring體系下的微服務解決方案
- Dubbo是阿里系的分布式服務治理框架
從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo本身只是實現了服務治理,而SpringCloud現在以及有21個子項目，以后還會更多，所以其實很多人都會說Dubbo和SpringCloud是不公平的，但是由於RPC以及注冊中心元數據等原因,在技術選型的時候我們只能二者選其一,所以我們常常為用他倆來對比服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API, 其實更符合微服務官方的定義服務的注冊中心來看,Dubbo使用了第三方的ZooKeeper作為其底層的注冊中心,實現服務的注冊和發現,Spring Cloud使用Spring Cloud Netflix Eureka實現注冊中心,當然SpringCloud也可以使用ZooKeeper實現,但一般我們不會這樣做。服務網關,Dubbo並沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關,作為路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分布式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素
2.Rest和RPC對比
其實如果仔細閱讀過微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通信機制就是Http Rest。RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,我們需要為每一個微服務進行接口的定義,並通過持續繼承發布,需要嚴格的版本控制才不會出現服務提供和調用之間因為版本不同而產生的沖突而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是通過一個約定進行規范,但也有可能出現文檔和接口不一致而導致的服務集成問題,但可以通過swagger工具整合,是代碼和文檔一體化解決,所以REST在分布式環境下比RPC更加靈活這也是為什么當當網的DubboX在對Dubbo的增強中增加了對REST的支持的原因
3.注冊的服務的區別
Dubbo是基於java接口及Hession2序列化的來實現傳輸的，Provider對外暴露接口，Consumer根據接口的規則調用。也就是Provider向Zookeeper注冊的是接口信息，Consumer從Zookeeper發現的是接口的信息，通過接口的name，group，version來匹配調用。Consumer只關注接口是否匹配，而對此接口屬於什么應用不關心。當然接口的注冊信息里會包含應用的ip，hostname等。
SpringCloud的服務發現是基於Http協議來實現的，Provider對外暴露的是應用信息，比如應用名稱，ip地址等等，Consumer發現的是應用的信息，當調用的時候隨機選擇一個Provider的IP地址，應用名稱，然后依據Http協議發送請求。Consumer關注的是應用名稱，根據應用名稱來決定調用的是哪個服務集群，然后對此名稱對應的服務集群做負載均衡。Provider接受到請求后，根據內置的SpringMVC來匹配路由處理請求。
4.Server集群服務信息同步的區別
Dubbo使用Zookeeper做服務發現和治理，Zookeeper是一個分布式協調框架，其有很多很實用的功能，服務發現僅僅是其中的一個。Zookeeper基於著名的CAP理論中的C(一致性)，P(分區可用性)實現，它的ZAB（zookeeper atomic broadcast protocol）協議，保證了集群里狀態的一致性。Client的每一個事務操作都由Leader廣播給所有Follower，當超過半數的Follower都返回執行成功后，才執行事務的ack。對於因網絡崩潰或者宕機等問題而執行失敗的zookeeper節點，zookeeper會基於zab的崩潰恢復機制來處理，這里不再講述。每一個操作都需要過半數的zookeeper節點執行成功才確認成功，那么當zookeeper集群過半數節點出現問題時，服務發現功能就不可用。
SpringCloud使用Eureka做服務發現和治理，它是一個專門用於服務發現和治理的框架，其基於CAP理論中的A(可用性)，P(分區可用性)實現。EurekaServer節點間的服務信息同步是基於異步Http實現的。每隔Server節點在接收Client的服務請求時，立即處理請求，然后將此次請求的信息拷貝，封裝成一個Task，存入Queue中。Server初始化時會啟動一個線程定期的從TaskQueue中批量提取Task，然后執行。服務同步不保證一定成功，雖然有失敗重試，但超過一定時限后就放棄同步。當然其有一個特性，當服務丟失后，同步的操作返回400，404后會立即將最新的服務信息同步過去，因此即使中途同步失敗，不會對后續的同步有影響。
5.服務更新機制的區別
Dubbo使用Zookeeper做服務發現和治理，訂閱Zookeeper下相應的znode。當節點發生變化，比如有新的元素增加，或者舊的元素移除，Zookeeper會通知所有訂閱此節點的Client，將當前的全量數據同步給各Client，Dubbo里根據最新的數據來做相應處理，移除下線的，初始化新增的。每次更新都同步全量數據。
Eureka在啟動時向Server進行一次全量拉取，獲取所有的可用服務信息，之后默認情況下都是進行增量拉取。Server會將有變化的服務信息放在一個Queue里，Client每次同步時僅獲取增量信息，根據信息里的操作類型，服務信息來對當前持有的服務做相應的處理，移除下線的，初始化新增的等。每次更新僅同步增量數據，也就是更新的數據。
6.服務更新反饋機制的區別
Dubbo訂閱Zookeeper下相應的節點，當節點的狀態發生改變時，Zookeeper會立即反饋訂閱的Client，實時性很高。
Eureka Server在接收到Client的更新操作，或者移除服務信息時，僅僅會將更新消息存放入recentlyChangedQueue中，不會主動的反饋其他Client。其他Client只有在拉取服務增量信息時才會感知到某個服務的更新，延時最大為30S，也就是拉取周期。
7.服務信息回收機制的區別
Dubbo Provider初始化時會創建一個Zookeeper Client，專門用於與Zookeeper集群交互。維持與集群間的長連接，定時發送心跳，維護Zookeeper上自身節點的存在。節點類型是臨時節點，也就是當心跳超時或者長連接斷開時，會立即移除Provider對應的節點。
Dubbo Consumer初始化時也會創建一個Zookeeper Client，專門用於與Zookeeper集群交互。維持長連接，創建EvenetListener，監聽Provider節點的變動情況。當Provider節點新增或者移除時，Zookeeper會廣播這個事件，然后將此節點的當前值(剩下的所有接口信息)發送給那些注冊了此節點監聽器的Client。Consumer獲取到對應Provider節點下的所有接口信息后，移除已下線的，創建新增的。Zookeeper對服務信息的維護實時性和一致性比較高，但也可能因為網絡問題或者集群問題導致服務不可用。
SpringCloud的服務信息回收僅基於心跳超時，與長連接無關。當心跳超時后，EurekaServer回收服務信息，然后將此動作同步給其他Server節點。當然可能一個服務信息會存在多個Server上，多次回收操作的同步具備冪等性。也就是說服務回收只需要通知一個Server節點就可以了，回收動作會通過Server節點傳播開來。EurekaServer能夠回收服務信息由個重要前提：上一分鍾內正常發送心跳的服務的比列超過總數的85%，如果因為網絡波動等原因造成大量服務的心跳超時，那么EurekaServer會觸發自我保護機制，放棄回收那些心跳超時的服務信息。服務發現組件應該優先保證可用性，Consumer能夠發現Provider，即使發現的是非可用的Provider，但因為Conusmer一般具備容錯機制，不會對服務的正常調用有太多影響。從這點上看Eureka的服務發現機制要比Zookeeper稍微合理一點的。
8.節點性質的區別
Dubbo只有Consumer訂閱Provider節點，也就是Consumer發現Provider節點信息
Eureka不區分Consumer或者Provider，兩者都統稱為Client，一個Client內可能同時含有Provider，Consumer，通過服務發現組件獲取的是其他所有的Client節點信息，在調用時根據應用名稱來篩選節點
9.使用方式的區別
Dubbo使用Zookeeper作為服務發現和治理的組件，所以需要搭建Zookeeper集群作為依賴。
SpringCloud使用Eureka作為服務發現和治理組件，在Spring應用中整合Eureka還是很簡單的，引入依賴，加個注解，指定集群Server的serviceUrl，其他的都可以使用默認配置即可，啟動應用，Eureka集群就搭建好了。同時配合SpringCloudConfg，能夠統一管理Eureka的集群配置信息，可以動態的增加或減少EurekaServer的集群節點。Eurerka會每隔15分鍾根據配置上的集群信息重新生成集群節點，覆蓋之前的。這種機制比Zookeeper要更優秀一些，畢竟Eureka算是Spring生態里的一環，已經被整合的非常好了，能夠以很多匪夷所思的方式來使用。
10.技術選型
目前國內的分布式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,並且Dubbo在其他維度上的缺陷可以由其他第三方框架進行集成進行彌補而SpringCloud目前是國外比較流行,當然我覺得國內的市場也會慢慢的偏向SpringCloud,就連劉軍作為Dubbo重啟的負責人也發表過點,Dubbo的發展方向是積極適應SpringCloud生態,並不是起沖突。
11.文檔質量和社區活躍度
SpringCloud社區活躍度遠高於Dubbo,畢竟由於梁飛團隊的原因導致Dubbo停止更新迭代五年,而中小型公司無法承擔技術開發的成本導致Dubbo社區嚴重低落,而SpringCloud異軍突起,迅速占領了微服務的市場,背靠Spring混的風生水起，Dubbo經過多年的積累文檔相當成熟,對於微服務的架構體系各個公司也有穩定的現狀
二.SpringBoot和SpringCloud
SpringBoot是Spring推出用於解決傳統框架配置文件冗余,裝配組件繁雜的基於Maven的解決方案,旨在快速搭建單個微服務而SpringCloud專注於解決各個微服務之間的協調與配置,服務之間的通信,熔斷,負載均衡等技術維度並相同,並且SpringCloud是依賴於SpringBoot的,而SpringBoot並不是依賴與SpringCloud,甚至還可以和Dubbo進行優秀的整合開發
總結:
- SpringBoot專注於快速方便的開發單個個體的微服務
- SpringCloud是關注全局的微服務協調整理治理框架,整合並管理各個微服務,為各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務
- SpringBoot不依賴於SpringCloud,SpringCloud依賴於SpringBoot,屬於依賴關系
- SpringBoot專注於快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架
三.Eureka和ZooKeeper都可以提供服務注冊與發現的功能,兩個的區別
1.ZooKeeper保證的是CP,Eureka保證的是AP
- ZooKeeper在選舉期間注冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的
- Eureka各個節點是平等關系,只要有一台Eureka就可以保證服務可用,而查詢到的數據並不是最新的
- ZooKeeper有Leader和Follower角色,Eureka各個節點平等
- ZooKeeper采用過半數存活原則,Eureka采用自我保護機制解決分區問題
- Eureka本質上是一個工程,而ZooKeeper只是一個進程
自我保護機制會導致
- Eureka不再從注冊列表移除因長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的注冊和查詢請求,但是不會被同步到其他節點(高可用)
- 當網絡穩定時,當前實例新的注冊信息會被同步到其他節點中(最終一致性)
Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像ZooKeeper一樣使得整個注冊系統癱瘓
四.微服務之間是如何獨立通訊的
遠程過程調用（Remote Procedure Invocation）
也就是我們常說的服務的注冊與發現直接通過遠程過程調用來訪問別的service。
優點：
- 簡單，常見,因為沒有中間件代理，系統更簡單
缺點：
- 只支持請求/響應的模式，不支持別的，比如通知、請求/異步響應、發布/訂閱、發布/異步響應降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的
消息
使用異步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。
優點:
- 把客戶端和服務端解耦，更松耦合，提高可用性，因為消息中間件緩存了消息，直到消費者可以消費支持很多通信機制比如通知、請求/異步響應、發布/訂閱、發布/異步響應
缺點:
- 消息中間件有額外的復雜性
微服務的優缺點分別是什么?說下你在項目開發中碰到的坑
優點
- 每一個服務足夠內聚,代碼容易理解
- 開發效率提高,一個服務只做一件事
- 微服務能夠被小團隊單獨開發
- 微服務是松耦合的,是有功能意義的服務
- 可以用不同的語言開發,面向接口編程
- 易於與第三方集成
- 微服務只是業務邏輯的代碼,不會和HTML,CSS或者其他界面組合
- 開發中,兩種開發模式
前后端分離
全棧工程師 - 可以靈活搭配,連接公共庫/連接獨立庫
缺點
- 分布式系統的負責性
- 多服務運維難度,隨着服務的增加,運維的壓力也在增大
- 系統部署依賴
- 服務間通信成本
- 數據一致性
- 系統集成測試
- 性能監控
你所知道的微服務技術棧有哪些?請列舉一二
多種技術的集合體
我們在討論一個分布式的微服務架構的話,需要哪些維度
維度(SpringCloud)
服務開發
SpringBoot
Spring
SpringMVC
服務配置與管理
Netfilx公司的Archaiusm,阿里的Diamond
服務注冊與發現
Eureka,ZooKeeper
服務調用
Rest,RPC,gRPC
服務熔斷器
Hystrix
服務負載均衡
Ribbon,Nginx
服務接口調用
Feign
消息隊列
Kafka,RabbitMq,ActiveMq
服務配置中心管理
SpringCloudConfing
服務路由(API網關)
Zuul
事件消息總線
SpringCloud Bus
…
參考：
https://www.cnblogs.com/matd/articles/10549336.html
https://www.jianshu.com/p/f5bf09c0ef0b