鎮樓小姐姐
36份一線互聯網Java面試電子書
84個Java稀缺面試題視頻
現如今微服務架構十分流行,而採用微服務構建系統也會帶來更清晰的業務劃分和可擴展性。同時,支持微服務的技術棧也是多種多樣的,本系列文章主要介紹這些技術中的翹楚——Spring Cloud。這是序篇,主要講述我們為什麼選擇Spring Cloud和它的技術概覽。
1、為什麼微服務架構需要Spring Cloud
簡單來說,服務化的核心就是將傳統的一站式應用根據業務拆分成一個一個的服務,而微服務在這個基礎上要更徹底地去耦合(不再共享DB、KV,去掉重量級ESB),並且強調DevOps和快速演化。這就要求我們必須採用與一站式時代、泛SOA時代不同的技術棧,而Spring Cloud就是其中的佼佼者。
DevOps是英文Development和Operations的合體,他要求開發、測試、運維進行一體化的合作,進行更小、更頻繁、更自動化的應用發佈,以及圍繞應用架構來構建基礎設施的架構。這就要求應用充分的內聚,也方便運維和管理。這個理念與微服務理念不謀而合。
接下來我們從服務化架構演進的角度來看看為什麼Spring Cloud更適應微服務架構。
1.1 從使用nginx說起
最初的服務化解決方案是給提供相同服務提供一個統一的域名,然後服務調用者向這個域名發送HTTP請求,由Nginx負責請求的分發和跳轉。
這種架構存在很多問題:
Nginx作為中間層,在配置文件中耦合了服務調用的邏輯,這削弱了微服務的完整性,也使得Nginx在一定程度上變成了一個重量級的ESB。服務的信息分散在各個系統,無法統一管理和維護。每一次的服務調用都是一次嘗試,服務消費者並不知道有哪些實例在給他們提供服務。這不符合DevOps的理念。無法直觀的看到服務提供者和服務消費者當前的運行狀況和通信頻率。這也不符合DevOps的理念。消費者的失敗重發,負載均衡等都沒有統一策略,這加大了開發每個服務的難度,不利於快速演化。為了解決上面的問題,我們需要一個現成的中心組件對服務進行整合,將每個服務的信息彙總,包括服務的組件名稱、地址、數量等。服務的調用方在請求某項服務時首先通過中心組件獲取提供這項服務的實例的信息(IP、端口等),再通過默認或自定義的策略選擇該服務的某一提供者直接進行訪問。所以,我們引入了Dubbo。
1.2 基於Dubbo實現微服務
Dubbo是阿里開源的一個SOA服務治理解決方案,文檔豐富,在國內的使用度非常高。
使用Dubbo構建的微服務,已經可以比較好地解決上面提到的問題:
但是對於微服務架構而言,Dubbo也並不是十全十美的:
Registry嚴重依賴第三方組件(zookeeper或者redis),當這些組件出現問題時,服務調用很快就會中斷。DUBBO只支持RPC調用。使得服務提供方與調用方在代碼上產生了強依賴,服務提供者需要不斷將包含公共代碼的jar包打包出來供消費者使用。一旦打包出現問題,就會導致服務調用出錯。最為重要的是,DUBBO現在已經停止維護了,對於技術發展的新需求,需要由開發者自行拓展升級。這對於很多想要採用微服務架構的中小軟件組織,顯然是不太合適的。目前Github社區上有一個DUBBO的升級版,叫DUBBOX,提供了更高效的RPC序列化方式和REST調用方式。但是該項目也基本停止維護了。
1.3 新的選擇——Spring Cloud
作為新一代的服務框架,Spring Cloud提出的口號是開發“面向雲環境的應用程序”,它為微服務架構提供了更加全面的技術支持。
結合我們一開始提到的微服務的訴求,我們把Spring Cloud與DUBBO進行一番對比:
微服務需要的功能DubboSpring Cloud服務註冊和發現ZookeeperEureka服務調用方式RPCRESTful API斷路器有有負載均衡有有服務路由和過濾有有分佈式配置無有分佈式鎖無計劃開發集群選主無有分佈式消息無有
Spring Cloud拋棄了Dubbo的RPC通信,採用的是基於HTTP的REST方式。嚴格來說,這兩種方式各有優劣。雖然從一定程度上來說,後者犧牲了服務調用的性能,但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活,服務提供方和調用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調快速演化的微服務環境下,顯得更加合適。
Eureka相比於zookeeper,更加適合於服務發現的場景,這點會在下一篇會詳細展開。
很明顯,Spring Cloud的功能比DUBBO更加強大,涵蓋面更廣,而且作為Spring的拳頭項目,它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合,這些對於微服務而言是至關重要的。前面提到,微服務背後一個重要的理念就是持續集成、快速交付,而在服務內部使用一個統一的技術框架,顯然比把分散的技術組合到一起更有效率。更重要的是,相比於Dubbo,它是一個正在持續維護的、社區更加火熱的開源項目,這就保證使用它構建的系統,可以持續地得到開源力量的支持。
2、Spring Cloud技術概覽
下圖展示了Spring Cloud的完整技術組成:
Feign和RxJava並不是Netiflix的產品,但是被整合到了Spring Cloud Netflix中。
對於服務的註冊和發現,除了Eureka,Spring Cloud也整合了Consul和Zookeeper作為備選,但是因為這兩個方案在CAP理論上都遵循CP而不是AP(下一篇會詳細介紹這點),所以官方並沒有推薦使用。