分布式系統(tǒng)組件的選型
這節(jié)我們來講講分布式相同類型的框架和組件該如何選型。
分布式、微服務和集群的定義
首先我們得了解什么是這三種東西分別代表的是什么意思。
分布式：
分布式官方給的名詞解釋是 “分布式系統(tǒng)（distributed system）是建立在網絡之上的軟件系統(tǒng)。正是因為軟件的特性，所以分布式系統(tǒng)具有高度的內聚性和透明性。因此，網絡和分布式系統(tǒng)之間的區(qū)別更多的在于高層軟件（特別是操作系統(tǒng)），而不是硬件?！?strong>簡單點說分布式就是將一個業(yè)務拆分成多個子業(yè)務，部署在多臺服務器上，從而分散服務器的壓力，提升吞吐量。
集群
集群跟分布式正好相反，它是將一個業(yè)務同時部署在多個服務器中，當一個服務器因某種原因宕機時，可以及時切換到另一服務器，從而實現(xiàn)高可用。
微服務
微服務是一種架構思想，一個大型復雜軟件應用由一個或多個微服務組成，系統(tǒng)中各個微服務可以獨立部署，互不影響，每個微服務只關注完成一個任務，而這個任務一般指的是系統(tǒng)中的一個業(yè)務。
總結
分布式是微服務的一種實現(xiàn)，而在系統(tǒng)中分布式和集群之間一定是搭配使用的，每個子業(yè)務之間搭配集群，從而實現(xiàn)高并發(fā)與高可用。
CAP原則
CAP原則又稱CAP定理，指的是在一個分布式系統(tǒng)中，一致性（Consistency）、可用性（Availability）、分區(qū)容錯性（Partition tolerance）。
它的精髓在于它無法同時滿足一致性、可用性和分區(qū)容錯性，要么CA、要么CP、要么AP，無法滿足CAP。
Springcloud和Dubbo
Springcloud是Spring公司開源的微服務框架，SpirngCloud 定位為微服務架構下的一站式解決方案。而Dubbo是阿里巴巴開源的RPC框架，Dubbo 是 SOA 時代的產物，它的關注點主要在于服務的調用，流量分發(fā)、流量監(jiān)控和熔斷。下面有張圖列出的它們之間的區(qū)別：
從中可以看出Spring Cloud 的功能很明顯比 Dubbo 更加強大，涵蓋面更廣，而且作為 Spring 的旗艦項目，它也能夠與 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 項目完美融合，這些對于微服務而言是至關重要的。
SpringCloud生態(tài)豐富，功能完善，更像是品牌機，Dubbo則相對靈活，可定制性強，更像是組裝機。
Feign和Dubbo遠程調用的差異
Feign是springcloud的遠程調用方式，它是基于HTTP實現(xiàn)的，所有的接口都是restful風格，接口規(guī)范統(tǒng)一，實現(xiàn)接口的微服務可以采用任意語言或技術開發(fā)。但受限于http協(xié)議本身的特點，請求和響應格式臃腫，其通信效率相對會差一些。
Dubbo框架默認采用Dubbo自定義通信協(xié)議，與Http協(xié)議一樣底層都是TCP通信。但是Dubbo協(xié)議自定義了Java數據序列化和反序列化方式、數據傳輸格式，因此Dubbo在數據傳輸性能上會比Http協(xié)議要好一些。
相關概念：
1）Rest風格
REST是一種架構風格，指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。
Rest的風格可以完全通過HTTP協(xié)議實現(xiàn)，使用 HTTP 協(xié)議處理數據通信。REST架構對資源的操作包括獲取、創(chuàng)建、修改和刪除資源的操作正好對應HTTP協(xié)議提供的GET、POST、PUT和DELETE方法。
因此請求和想要過程只要遵循h(huán)ttp協(xié)議即可，更加靈活
SpringCloud中的Feign就是Rest風格的調用方式。
2）RPC
Remote Procedure Call，遠程過程調用，就是像調用本地方法一樣調用遠程方法。
RPC一般要確定下面幾件事情：
數據傳輸方式：多數RPC框架選擇TCP作為傳輸協(xié)議，性能比較好。
數據傳輸內容：請求方需要告知需要調用的函數的名稱、參數、等信息。
序列化方式：客戶端和服務端交互時將參數或結果轉化為字節(jié)流在網絡中傳輸，那么數據轉化為字節(jié)流的或者將字節(jié)流轉換成能讀取的固定格式時就需要進行序列化和反序列化。因為有序列化和反序列化的需求，因此對數據傳輸格式有嚴格要求，不如Http靈活
Dubbo協(xié)議就是RPC的典型代表。
注冊中心的選型
設計或者選型一個服務注冊中心，首先要考慮的就是服務注冊與發(fā)現(xiàn)機制?？v觀當下各種主流的服務注冊中心解決方案，大致可歸為三類：
1，應用內：
直接集成到應用中，依賴于應用自身完成服務的注冊與發(fā)現(xiàn)，最典型的是Netflix提供的Eureka。
2，應用外：
把應用當成黑盒，通過應用外的某種機制將服務注冊到注冊中心，最小化對應用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul。
3，DNS
將服務注冊為DNS的SRV記錄，嚴格來說，是一種特殊的應用外注冊方式，SkyDNS是其中的代表。但此種模式存在緩存缺陷。
除了基本的服務注冊與發(fā)現(xiàn)機制，從開發(fā)和運維角度，至少還要考慮如下五個方面：
測活：服務注冊之后，如何對服務進行測活以保證服務的可用性？
負載均衡：當存在多個服務提供者時，如何均衡各個提供者的負載？
集成：在服務提供端或者調用端，如何集成注冊中心？
運行時依賴：引入注冊中心之后，對應用的運行時環(huán)境有何影響？
可用性：如何保證注冊中心本身的可用性，特別是消除單點故障？
各注冊中心區(qū)別：
API網關Gateway和Zuul
1、Zuul：
使用的是阻塞式的 API，不支持長連接，比如 websockets。
底層是servlet，Zuul處理的是http請求
沒有提供異步支持，流控等均由hystrix支持。
依賴包spring-cloud-starter-netflix-zuul。
2、Gateway：
底層依然是servlet，但使用了webflux，多嵌套了一層框架
依賴spring-boot-starter-webflux和/ spring-cloud-starter-gateway
提供了異步支持，提供了抽象負載均衡，提供了抽象流控，并默認實現(xiàn)了RedisRateLimiter。
總結
相同點：
底層都是servlet
兩者均是web網關，處理的是http請求
不同點：
gateway對比zuul多依賴了spring-webflux，在spring的支持下，功能更強大，內部實現(xiàn)了限流、負載均衡等，擴展性也更強，但同時也限制了僅適合于Spring Cloud套件
zuul則可以擴展至其他微服務框架中，其內部沒有實現(xiàn)限流、負載均衡等。
zuul僅支持同步
gateway支持異步。理論上gateway則更適合于提高系統(tǒng)吞吐量（但不一定能有更好的性能），最終性能還需要通過嚴密的壓測來決定
下面再介紹幾個springcloud的組件：
cloud中最常見的就是netflix五大組件了：
Eureka：服務治理組件，包括服務端的注冊中心和客戶端的服務發(fā)現(xiàn)機制；
Ribbon：負載均衡的服務調用組件，具有多種負載均衡調用策略；
Hystrix：服務容錯組件，實現(xiàn)了斷路器模式，為依賴服務的出錯和延遲提供了容錯能力；
Feign：基于Ribbon和Hystrix的聲明式服務調用組件；
Zuul：API網關組件，對請求提供路由及過濾功能。
其余SpringCloud中還有：
Spring Cloud Bus，用于傳播集群狀態(tài)變化的消息總線，使用輕量級消息代理鏈接分布式系統(tǒng)中的節(jié)點，可以用來動態(tài)刷新集群中的服務配置。
Spring Cloud Consul，基于Hashicorp Consul的服務治理組件。
Spring Cloud Security，安全工具包，對Zuul代理中的負載均衡OAuth2客戶端及登錄認證進行支持。
Spring Cloud Sleuth，Spring Cloud應用程序的分布式請求鏈路跟蹤，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟蹤。
Spring Cloud Stream，輕量級事件驅動微服務框架，可以使用簡單的聲明式模型來發(fā)送及接收消息，主要實現(xiàn)為Apache Kafka及RabbitMQ。
Spring Cloud Task，用于快速構建短暫、有限數據處理任務的微服務框架，用于向應用中添加功能性和非功能性的特性。
Spring Cloud Zookeeper，基于Apache Zookeeper的服務治理組件。
Spring Cloud Gateway，API網關組件，對請求提供路由及過濾功能。
Spring Cloud OpenFeign，基于Ribbon和Hystrix的聲明式服務調用組件，可以動態(tài)創(chuàng)建基于Spring MVC注解的接口實現(xiàn)用于服務調用，在Spring Cloud 2.0中已經取代Feign成為了一等公民。