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