內容

　　本文通過生活中的實際場景解釋單體應用和微服務應用的關系，以及SpringCloud中各組件的功能和含義。

適合人群

　　Java開發人員

說明

　　轉載請說明出處：SpringCloud從入門到進階（一）——懂生活就懂微服務

　　GitHub倉庫地址：https://github.com/leo-zz/SpringCloudDemo

參考

　　Spring Cloud Netflix官方文檔

微服務與單體應用的關系

　　微服務與單體應用的區別類似於個人開發者和開發公司的區別。以一個Web項目為例進行解釋：

單體應用--個人開發者

　　個人開發者往往一個人完成UI設計、數據庫設計、前端開發、後端開發等一系列的工作。而單體應用也是如此，在一個項目中完成所有的功能模塊。

微服務--開發公司

　　開發公司則有嚴密的組織架構和分工。

　　開發部下的每個小組都有明確的崗位和分工：項目經理負責進行項目評估、組建團隊，將項目工作分解到各個開發小組，並定期更新項目進度，及時發現滯後的開發模塊，調整人員分工趕工以確保項目按計劃完成。每個開發小組的具體工作由組長分解到各個小組成員。管理部負責制定工作規範，開發部各崗位根據規範開展工作。人事部負責管理公司員工的入職和離職，更新公司通訊錄；並統計各位員工的工作績效，對績效差的員工做思想工作或者辭退。

　　這就等同於一個微服務架構的項目，有處理具體業務邏輯的微服務，也有負責路由的統一入口；有提供微服務註冊信息的服務發現，又有負責請求分發的負載均衡器；有負責監控請求鏈路信息的鏈路追蹤器，又有負責解決服務雪崩的斷路器。儼然是一個有明確分工和角色的組織。

　　一個簡單的項目交給個人開發者來做往往費用更低並且開發周期更短，一個復雜的項目則需要交給開發公司才能可靠地開發。這也就體現了單體應用與微服務應用之間的關系：單體應用適合簡單項目或項目初期使用，可以快速的叠代升級。但是隨著項目功能越來越豐富，單體應用越來越臃腫，各個模塊耦合度越來越高，最終牽一發而動全身，系統的可用性和擴展性無法保證。於是順其自然地將不同的模塊拆分為不同的項目，每個項目都進行獨立的開發、部署和擴展，項目的架構則由單體應用演變成微服務架構。最終實現了各模塊的解耦，提升了系統的可用性和擴展性。但是隨之而來的是開發復雜度和運維工作量的增長，就像運營一個公司有房租、水電費等成本。

SpringCloud介紹

　　SpringCloud為開發人員提供了快速構建分布式系統的常用工具，包括配置管理、服務發現、服務熔斷、智能路由、總線、鑒權等。SpringCloud基於SpringBoot實現微服務架構，它是Java項目從單體應用架構向微服務架構變遷的主流選擇之一。本系列文章所用服務發現、服務熔斷、負載均衡、路由等組件選用的是Spring Cloud Netflix下的。下面繼續結合生活場景介紹SpringCloud中部分組件的含義：

服務發現 Eureka---公司通訊錄

　　服務發現是微服務架構中一個關鍵的原則，Eureka提供了服務註冊和服務發現的功能，並且各註冊中心之間會互相拷貝所註冊的微服務的信息，這一機制增強了Eureka對網絡分區的容錯能力。

? Eureka就像開發公司的人事部，人事部維護了公司的通訊錄，通過通訊錄可以找到每一名員工的聯系方式。正如人員在入職和離職時，人事部會更新公司的通訊錄一樣；當服務上線或者下線時，Eureka都會進行服務的註冊和註銷的操作。

微服務應用--小組成員

? 　　微服務應用是單體應用中各個模塊拆分之後形成的一個個單獨的項目，各項目之間通過HTTP API的方式進行調用。

? 　　微服務應用是整個架構中從事具體業務流程處理的模塊，就像開發部各小組的成員，從事具體的設計、開發、測試、運維等工作，不像領導只安排工作不做工作。

斷路器Hystrix--員工績效考核制度

　　斷路器是為了解決服務雪崩而設計的。如果沒有引入斷路器，當某個微服務出現故障時，可能會造成服務調用請求的阻塞，導致該請求的線程資源被占用。在高並發情況下，越來越多的請求阻塞，最終導致整個系統的線程資源耗盡，服務癱瘓。引入斷路器後，斷路器通過監測微服務，在微服務出現故障的次數超過閾值後（hystrix默認閾值為5秒內20個故障），斷路器將“打開回路”，執行錯誤回調，不再將請求轉發到故障服務，從而避免服務雪崩的發生。

　　斷路器的作用就像公司的績效考核制度，如果項目成員在工作中出現較大的失誤，那麽他的績效會被扣除。如果該員工接二連三的出錯，那麽領導將會找他談心，該員工要麽端正工作態度，要麽走人，避免公司業務進一步受到影響。

斷路器監控Hystrix Dashboard和Turbine--員工績效考核表

　　斷路器會記錄每一次微服務請求的結果，Hystrix Dashboard和Turbine可以高效地展示斷路器的實時狀態。只是Dashboard每次只能展示一個斷路器的狀態，而Turbine可以同時展示多個斷路器的狀態，從而反應整個系統的運行狀況。

　　斷路器監控就像員工績效考核表，員工的每一項工作都記錄在考核表中，哪些工作幹的好加分，哪些幹的差扣分都一目了然。Hystrix Dashboard就是單個員工的考核表，而Turbine就是多個員工考核表的匯總，通過所有員工的績效情況可以獲知整個公司的運營情況。

客戶端負載均衡器Ribbon--小組組長的工作安排機制

　　Ribbon是位於客戶端的負載均衡器，一個微服務通常對應多個不同的微服務實例，在用戶請求這些微服務時，Ribbon會根據負載均衡規則，將請求轉發給對應的微服務實例進行處理。負載均衡機制提升了系統的並發處理能力和可用性。

　　負載均衡器Ribbon的行為就像開發部小組組長的工作安排機制。每個崗位都至少有兩名員工，小組長會在這些員工之間安排工作，這樣小組可以同時做多個工作（並發處理能力），並且當某個員工請假時，有其他員工可以安排工作，避免小組工作的擱置（高可用性）。

路由/網關Zuul--項目經理的工作安排機制

　　Zuul是基於JVM的路由器，也是服務端的負載均衡器。它是微服務請求的入口，Zuul將特定URL的請求轉發給對應的微服務進行處理。

　　路由/網關Zuul的行為就像開發部項目經理的工作安排機制。項目經理會根據工作的性質，將特定的工作安排給對應的小組。比如原型設計類的工作，安排給產品組來做；業務邏輯代碼編寫工作，安排給後端組來做；項目部署類的工作，安排給運維組來做。項目方面的工作，開發部門都交由項目經理來安排，而不會直接將工作安排給下面的小組。

統一配置Config--管理部的開發規範

?　　統一配置中心ConfigServer可以從本地，或網上倉庫讀取配置文件；並為微服務架構中的各個組件Config Client提供了以HTTP API的方式讀取配置文件的功能。當項目在開發、測試、生產環境中切換時，無需重新打包部署項目，只需要在配置中心修改配置即可，降低了運維方面的工作量。

　　統一配置就像管理部下發的各種開發規範，不同的小組有著不同的規範，小組成員都按照各自的規範各司其職。隨著公司的發展，組織結構的優化，各種開發規範也在不斷的完善。這就如同項目叠代更新過程中，參數配置不斷完善，項目的性能不斷提高。

鏈路追蹤Sleuth--工作進度統計

　　Sleuth是Spring Cloud中分布式鏈路追蹤解決方案，它大量借鑒了Dapper、Zipkin等項目。它可以在用戶無感知的情況下搜集微服務的調用數據，記錄微服務調用都經過了哪些組件、每個環節的耗時等信息。方便開發人員進行性能評估，找到系統的瓶頸。鏈路調用的基本單位是Span，每一次請求或者響應都對應了一個Span，每個Span都由一個64位的字符串標識；而一次微服務的完整調用過程稱為Trace，Trace也是由一個64位的字符串標識，且Trace中包含的Span組合呈樹狀結構。

　　鏈路追蹤Sleuth就像項目經理的工作進度統計，通過工作進度統計可以清楚地看到哪個模塊的開發進度滯後，作為下一步人員調配和工作安排的依據，以確保項目能按計劃完工。

微服務架構圖：

　　取自SpringCloud官網的微服務架構圖

本系列文章導航

SpringCloud從入門到進階（一）——懂生活就懂微服務

SpringCloud從入門到進階（二）——註冊中心Eureka的高可用部署

SpringCloud從入門到進階（三）——源碼探究Eureka之replicas的unavailable狀態

SpringCloud從入門到進階（四）——路由接入Zuul

SpringCloud從入門到進階（五）——使用SpringBoot搭建微服務

SpringCloud從入門到進階（六）——斷路器Hystrix及其監控工具HystrixDashborad與Turbine

SpringCloud從入門到進階（七）——鏈路追蹤Sleuth

SpringCloud從入門到進階（八）——踩坑實戰之Zuul下實現文件上傳

待續...

SpringCloud從入門到進階（一）——懂生活就懂微服務