現如今微服務架構十分流行，而采用微服務構建系統也會帶來更清晰的業務劃分和可擴展性，同時，支持微服務的技術堆疊也是多種多樣的，本系列文章主要介紹這些技術中的翹楚——Spring Cloud，這是序篇，主要講述我們為什么選擇Spring Cloud和它的技術概覽，

1、為什么微服務架構需要Spring Cloud

簡單來說，服務化的核心就是將傳統的一站式應用根據業務拆分成一個一個的服務，而微服務在這個基礎上要更徹底地去耦合（不再共享DB、KV，去掉重量級ESB），并且強調DevOps和快速演化，這就要求我們必須采用與一站式時代、泛SOA時代不同的技術堆疊，而Spring Cloud就是其中的佼佼者，

DevOps是英文Development和Operations的合體，他要求開發、測驗、運維進行一體化的合作，進行更小、更頻繁、更自動化的應用發布，以及圍繞應用架構來構建基礎設施的架構，這就要求應用充分的內聚，也方便運維和管理，這個理念與微服務理念不謀而合，

接下來我們從服務化架構演進的角度來看看為什么Spring Cloud更適應微服務架構，點擊這里查看Spring系列教程集合，

1.1 從使用nginx說起

最初的服務化解決方案是給提供相同服務提供一個統一的域名，然后服務呼叫者向這個域名發送HTTP請求，由Nginx負責請求的分發和跳轉，

這種架構存在很多問題：

• Nginx作為中間層，在組態檔中耦合了服務呼叫的邏輯，這削弱了微服務的完整性，也使得Nginx在一定程度上變成了一個重量級的ESB，

• 服務的資訊分散在各個系統，無法統一管理和維護，每一次的服務呼叫都是一次嘗試，服務消費者并不知道有哪些實體在給他們提供服務，這不符合DevOps的理念，

• 無法直觀的看到服務提供者和服務消費者當前的運行狀況和通信頻率，這也不符合DevOps的理念，

• 消費者的失敗重發，負載均衡等都沒有統一策略，這加大了開發每個服務的難度，不利于快速演化，

為了解決上面的問題，我們需要一個現成的中心組件對服務進行整合，將每個服務的資訊匯總，包括服務的組件名稱、地址、數量等，服務的呼叫方在請求某項服務時首先通過中心組件獲取提供這項服務的實體的資訊（IP、埠等），再通過默認或自定義的策略選擇該服務的某一提供者直接進行訪問，所以，我們引入了Dubbo，

1.2 基于Dubbo實作微服務

Dubbo是阿里開源的一個SOA服務治理解決方案，檔案豐富，在國內的使用度非常高，

使用Dubbo構建的微服務，已經可以比較好地解決上面提到的問題：

• 呼叫中間層變成了可選組件，消費者可以直接訪問服務提供者，

• 服務資訊被集中到Registry中，形成了服務治理的中心組件，

• 通過Monitor監控系統，可以直觀地展示服務呼叫的統計資訊，

• Consumer可以進行負載均衡、服務降級的選擇，

但是對于微服務架構而言，Dubbo也并不是十全十美的：

• Registry嚴重依賴第三方組件（zookeeper或者redis），當這些組件出現問題時，服務呼叫很快就會中斷，

• DUBBO只支持RPC呼叫，使得服務提供方與呼叫方在代碼上產生了強依賴，服務提供者需要不斷將包含公共代碼的jar包打包出來供消費者使用，一旦打包出現問題，就會導致服務呼叫出錯，

• 最為重要的是，DUBBO現在已經重新維護了，對于技術發展的新需求，需要由開發者自行拓展升級，這對于很多想要采用微服務架構的中小軟體組織，顯然是相當合適的，

目前Github社區上有一個DUBBO的升級版，叫DUBBOX，提供了更高效的RPC序列化方式和REST呼叫方式，但是該專案也基本停止維護了，

1.3 新的選擇——Spring Cloud

作為新一代的服務框架，Spring Cloud提出的口號是開發“面向云環境的應用程式”，它為微服務架構提供了更加全面的技術支持，點擊這里查看Spring系列教程集合，

結合我們一開始提到的微服務的訴求，我們把Spring Cloud與DUBBO進行一番對比：

PC通信，采用的是基于HTTP的REST方式，嚴格來說，這兩種方式各有優劣，雖然從一定程度上來說，后者犧牲了服務呼叫的性能，但也避免了上面提到的原生RPC帶來的問題，而且REST相比RPC更為靈活，服務提供方和呼叫方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適，

Eureka相比于zookeeper，更加適合于服務發現的場景，這點會在下一篇會詳細展開，

很明顯，Spring Cloud的功能比DUBBO更加強大，涵蓋面更廣，而且作為Spring的拳頭專案，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring專案完美融合，這些對于微服務而言是至關重要的，前面提到，微服務背后一個重要的理念就是持續集成、快速交付，而在服務內部使用一個統一的技術框架，顯然比把分散的技術組合到一起更有效率，更重要的是，相比于Dubbo，它是一個正在持續維護的、社區更加火熱的開源專案，這就保證使用它構建的系統，可以持續地得到開源力量的支持，點擊這里查看Spring系列教程集合，

2、Spring Cloud技術概覽

下圖展示了Spring Cloud的完整技術組成：

服務治理：這是Spring Cloud的核心，目前Spring Cloud主要通過整合Netflix的相關產品來實作這方面的功能（Spring Cloud Netflix），包括用于服務注冊和發現的Eureka，呼叫斷路器Hystrix，呼叫端負載均衡Ribbon，Rest客戶端Feign，智能服務路由Zuul，用于監控資料收集和展示的Spectator、Servo、Atlas，用于配置讀取的Archaius和提供Controller層Reactive封裝的RxJava，除此之外，針對

Feign和RxJava并不是Netiflix的產品，但是被整合到了Spring Cloud Netflix中，

對于服務的注冊和發現，除了Eureka，Spring Cloud也整合了Consul和Zookeeper作為備選，但是因為這兩個方案在CAP理論上都遵循CP而不是AP（下一篇會詳細介紹這點），所以官方并沒有推薦使用，

分布式鏈路監控：Spring Cloud Sleuth提供了全自動、可配置的資料埋點，以收集微服務呼叫鏈路上的性能資料，并發送給Zipkin進行存盤、統計和展示，

訊息組件：Spring Cloud Stream對于分布式訊息的各種需求進行了抽象，包括發布訂閱、分組消費、訊息分片等功能，實作了微服務之間的異步通信，Spring Cloud Stream也集成了第三方的RabbitMQ和Apache Kafka作為訊息佇列的實作，而Spring Cloud Bus基于Spring Cloud Stream，主要提供了服務間的事件通信（比如重繪配置），

配置中心：基于Spring Cloud Netflix和Spring Cloud Bus，Spring又提供了Spring Cloud Config，實作了配置集中管理、動態重繪的配置中心概念，配置通過Git或者簡單檔案來存盤，支持加解密，

安全控制：Spring Cloud Security基于OAUTH2這個開放網路的安全標準，提供了微服務環境下的單點登錄、資源授權、令牌管理等功能，

命令列工具：Spring Cloud Cli提供了以命令列和腳本的方式來管理微服務及Spring Cloud組件的方式，

集群工具：Spring Cloud Cluster提供了集群選主、分布式鎖（暫未實作）、一次性令牌（暫未實作）等分布式集群需要的技術組件，

作者：董添 李秉謙
網易樂得技術團隊

關注公眾號Java技術堆疊回復"面試"獲取我整理的2020最全面試題及答案，

推薦去我的博客閱讀更多：

1.Java JVM、集合、多執行緒、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、后端、架構、阿里巴巴等大廠最新面試題

覺得不錯，別忘了點贊+轉發哦！

標籤：Java

上一篇：MinIO很強-讓我放棄FastDFS擁抱MinIO的8個理由

下一篇：「一站式」兼容所有云廠商檔案存盤Spring Boot 實作