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

時間 2019-11-11

標籤 springcloud 入門進階生活微服欄目悠閒生活简体版

原文原文鏈接

內容html

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

適合人羣git

　　Java開發人員github

說明spring

　　轉載請說明出處：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就像項目經理的工做進度統計，經過工做進度統計能夠清楚地看到哪一個模塊的開發進度滯後，做爲下一步人員調配和工做安排的依據，以確保項目能按計劃完工。