微服務架構詳解(史上最全圖文解讀)
微服務架構定義
微服務是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間採用輕量級的通信機制互相溝通，每個服務都圍繞着具體業務進行構建，並且能夠被獨立地部署到生產環境。
微服務架構特點
根據微服務 Microservices 之父馬丁.福勒的描述，我總結了以下6點：
1.一組小的服務：大小沒有特別的標準，只要同一團隊的工程師理解服務的標識一致即可；
2.獨立的進程：比如部署在 java的tomcats等；
3.輕量級的通信：比如：典型的http協議；
4.基於業務能力：類似用戶服務，商品服務等等；
5.獨立部署：迭代速度快；
6.無集中式管理：無須統一技術棧，可以根據不同的服務或者團隊進行靈活選擇。
什麼時候需要微服務架構
從生產力和系統的複雜性這兩個方面來看，公司一開始的時候，業務複雜性不高，這時候是驗證商業模式的時候，業務簡單，用單體服務反而生產力很高。
這個時候系統業務量較小，可以直接Java應用程序打包爲War包部署在一臺服務器上，整體架構如下圖所示：
這種將所有功能，都部署在一個web容器中運行的系統，就叫做單體架構，也叫巨石型應用。
單體應用的優點在於：單一架構模式在項目初期很小的時候開發方便，測試方便，部署方便，運行良好。
隨着公司的發展，業務複雜性慢慢提高，以及訪問量越來越大，會出現如下情況：
- 編譯時間過長;
- 迴歸測試周期過長;
- 開發效率降低，因爲所有業務都混在一起；
- 團隊擴展了，需要分工明確了，按照業務來發展，大家都高效；
這時候就可以採用微服務來提升生產力了，至於這個轉化的點，需要團隊的架構師來進行各方面衡量，就個人經驗而言，團隊發展到百人以上，採用微服務就很有必要了。
有些架構師是具有微服務架構能力，所以設計系統時就直接設計成了微服務，而不是通過單服務慢慢演化發展成微服務。
在這裏我並不推薦這種做法，因爲一開始對業務領域並不是很瞭解，並且業務模式還沒有得到驗證，這時候上微服務風險比較高，很有可能失敗。
所以建議大家在單服務的應用成熟時，並且對業務領域比較熟悉的時候，如果發現單服務無法適應業務發展時，再考慮微服務架構。
微服務架構組件
微服務的核心要素在於服務的發現、註冊、路由、熔斷、降級、分佈式配置。
比如：以Spring Cloud爲代表的微服務框架，都會實現以上的微服務組件。
1.服務註冊中心
註冊系統中所有服務的地方，所有的服務都會註冊在這裏。
2.服務註冊
服務提供方將自己調用地址註冊到服務註冊中心，讓服務調用方能夠方便地找到自己。
3.服務發現
服務調用方從服務註冊中心，找到自己需要調用服務的地址。
4.負載均衡
服務提供方一般以多實例的形式提供服務，使用負載均衡能夠讓服務調用方連接到合適的服務節點。
5.服務容錯
通過熔斷器等一系列的服務保護機制，保護服務調用不會出現大面積的雪崩。
6.服務網關
服務網關也稱爲API網關，是服務調用的唯一入口，可以在這個組件中實現用戶鑑權、動態路由、灰度發佈、負載限流等功能。
7.分佈式配置中心
將本地化的配置信息，比如：properties、yml等配置信息，註冊到配置中心，實現程序包在開發、測試、生產環境的無差別性方便程序遷移。
微服務架構有哪些
目前國內企業使用的微服務架構：主要是：
- Spring Cloud
- Spring Cloud Alibaba
- ServiceMesh這三套
Spring Cloud
Spring Cloud體系包含如下：
1.Eureka註冊中心
拆分成多個服務之後，需要管理多個服務，Eureka 作爲 Spring Cloud 框架的註冊中心，起到服務註冊和服務發現的作用。
上圖簡要描述了Eureka的基本架構，由3個角色組成：
1）Service Provider： 暴露服務的服務提供方；
2）Service Consumer：調用遠程服務的服務消費方；
3）EureKa Server： 服務註冊中心和服務發現中心；
2.Zuul 服務網關
Zuul 是 Spring Cloud 子項目的核心組件之一，可以作爲微服務架構中的 API 網關使用，支持動態路由與過濾功能。
Zuul就是微服務網關的一種實現，Zuul作用：類似我們小區的保安，用於保護基本的安全等的作用。
Zuul 本質上是一個Web servlet應用，爲微服務架構中的服務提供了統一的訪問入口，客戶端通過 API 網關訪問相關服務。
3.Hystrix斷路器
Hystrix的主要作用就是：提供服務隔離、熔斷、降級機制。
4.Ribbon負載均衡
Ribbon主要作用是提供客戶端的軟件負載均衡算法，將Netflix的中間層服務連接在一起。
當多個服務提供者時，Ribbon 可以根據負載均衡的算法，比如：如簡單輪詢、隨機連接等，自動地選擇需要調用的服務地址。
5.Feign遠程調用方式
Feign是Spring Cloud組件中的一個輕量級Restful的HTTP服務客戶端，通過 接口 + 註解的方式發起 HTTP 請求調用。
Feign 主要是幫助我們方便進行Rest API服務間的調用，Feign最大的作用就是減少 HTTP 遠程調用的複雜性。
Feign實現了像調用本地方法一樣調用遠程方法，無感知遠程HTTP 請求，類似於Dubbo Consumer直接調用Provider的接口方法。
Spring Cloud Alibaba
Spring Cloud Alibaba是阿里研發的一套微服務架構的落地技術方案，可以很好的兼容SpringCloud，可以簡要理解爲Spring Cloud的升級版。
Spring Cloud Alibaba體系包含如下圖所示：
1.Sentinel流量控制
Sentinel 是面向分佈式服務架構的流量控制組件，主要以流量爲切入點，從流量控制、熔斷降級、系統自適應保護等多個維度來幫助您保障微服務的穩定性。
Sentinel的核心功能，如下圖所示：
2.Nacos服務配置
Nacos是SpringCloudAlibaba架構中最重要的組件，Nacos 主要解決服務發現、配置和管理微服務。
3.RocketMQ消息中間件
RocketMQ是一個純java、分佈式、隊列模型的開源消息中間件。
4.Dubbo遠程通信
Dubbo是一款Java RPC框架，致力於提供高性能的RPC遠程服務調用方案。
Dubbo角色，主要包含如下幾個核心組件：
1)註冊中心（registry）
生產者在此註冊併發布內容，消費者在此訂閱並接收發布的內容。
2)消費者（consumer）
客戶端，從註冊中心獲取到方法，可以調用生產者中的方法。
3)生產者（provider）
服務端，生產內容，生產前需要依賴容器（先啓動容器）。
4)容器（container）
生產者在啓動執行的時候，必須依賴容器才能正常啓動（默認依賴的是spring容器），
5)監控(Monitor)
統計服務的調用次數與時間等。
5.Seata分佈式事務
Seata是一款阿里開源的分佈式事務解決方案，Seata致力於在微服務架構下提供高性能和簡單易用的分佈式事務服務。
Seata事務管理中有三個重要的組件角色，如下圖所示：
三個組件相互協作，TC 以 Server 形式獨立部署，TM和RM集成在應用中啓動。
1.TC (Transaction Coordinator) 事務協調者
TC：維護全局和分支事務的狀態，協調全局事務提交或回滾。
2.TM (Transaction Manager) 事務管理器
TM：定義全局事務的範圍、開始全局事務、提交或回滾全局事務。
3.RM (Resource Manager) -資源管理器
RM：管理分支事務處理的資源，與TC交談以註冊分支事務和報告分支事務的狀態，並驅動分支事務提交或回滾。
Service Mesh
目前下一代微服務架構就是服務網格Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大廠加持所以呼聲更高。
Service Mesh，是一個形象化的詞語表達：Service（服務）和Mesh（網格），它描述了服務間的依賴形態，就像下面這張網一樣。
ServiceMesh一般的架構如下圖所示：
Service Mesh架構圖從上圖可以看到，業務所有的流量都轉發到Service Mesh的代理服務Sidecar中。
Sidecar也稱爲邊車模式，因爲類似連接到摩托車的邊車，從而得名。
如下圖所示:
在Sidecar模式中，“邊車”與父應用程序（即業務服務）是兩個獨立的進程，“邊車”附加到業務服務，併爲應用提供支持功能，如微服務架構中的基本通信。
總體來說，Service Mesh幫助應用程序在複雜的軟件架構和網絡中建立穩定的通信機制。
以上!