雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
1.為什麼微服務架構需要Spring Cloud
簡單來說，服務化的核心就是将傳統的一站式應用根據業務拆分成一個一個的服務，而微服務在這個基礎上要更徹底地去耦合（不再共享DB、KV，去掉重量級ESB），并且強調DevOps和快速演化。這就要求我們必須采用與一站式時代、泛SOA時代不同的技術棧，而Spring Cloud就是其中的佼佼者。
接下來我們從服務化架構演進的角度來看看為什麼Spring Cloud更适應微服務架構。
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現在已經停止維護了，對于技術發展的新需求，需要由開發者自行拓展更新。這對于很多想要采用微服務架構的中的小軟體組織，顯然是不太合适的。
1.3 最佳選擇——Spring Cloud
作為新一代的服務架構，Spring Cloud提出的口号是開發“面向雲環境的應用程式”，它為微服務架構提供了更加全面的技術支援。
結合我們一開始提到的微服務的訴求，我們把Spring Cloud與DUBBO進行一番對比：
很明顯，Spring Cloud的功能比DUBBO更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務而言是至關重要的。
前面提到，微服務背後一個重要的理念就是持續內建、快速傳遞，而在服務内部使用一個統一的技術架構，顯然比把分散的技術組合到一起更有效率。更重要的是，相比于Dubbo，它是一個正在持續維護的、社群更加火熱的開源項目，這就保證使用它建構的系統，可以持續地得到開源力量的支援。
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。除此之外，針對
- 分布式鍊路監控：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提供了叢集選主、分布式鎖（暫未實作）、一次性令牌（暫未實作）等分布式叢集需要的技術元件。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-02
本文作者： 董添、李秉謙
本文來自：“
網際網路架構師 微信公衆号”，了解相關資訊可以關注“
網際網路架構師”