SpringCloud從入門到進階（一）——懂生活就懂微服務
內容
本文通過生活中的實際場景解釋單體應用和微服務應用的關係，以及SpringCloud中各元件的功能和含義。
適合人群
Java開發人員
說明
轉載請說明出處： ofollow,noindex" target="_blank">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從入門到進階（二）——註冊中心Eureka的高可用部署
SpringCloud從入門到進階（三）——原始碼探究Eureka之replicas的unavailable狀態
SpringCloud從入門到進階（四）——路由接入Zuul
SpringCloud從入門到進階（五）——使用SpringBoot搭建微服務
SpringCloud從入門到進階（六）——斷路器Hystrix及其監控工具HystrixDashborad與Turbine
SpringCloud從入門到進階（七）——鏈路追蹤Sleuth
SpringCloud從入門到進階（八）——踩坑實戰之Zuul下實現檔案上傳
待續...