通用的微服務(wù)架構(gòu)應(yīng)包含哪些組件

相對(duì)于單體式架構(gòu)的簡(jiǎn)單粗暴，微服務(wù)架構(gòu)將應(yīng)用打散，形成多個(gè)微服務(wù)進(jìn)行獨(dú)立開(kāi)發(fā)、測(cè)試、部署與運(yùn)維。雖然從管理與邏輯上更符合業(yè)務(wù)需要，但微服務(wù)架構(gòu)也帶來(lái)了諸多急需解決的核心問(wèn)題：

如何發(fā)現(xiàn)新服務(wù)節(jié)點(diǎn)以及檢查服務(wù)節(jié)點(diǎn)的狀態(tài)？

如何發(fā)現(xiàn)服務(wù)及負(fù)載均衡如何實(shí)現(xiàn)？

服務(wù)間如何進(jìn)行消息通信？

如何對(duì)使用者暴露服務(wù) API？

如何集中管理眾多服務(wù)節(jié)點(diǎn)的配置文件？

如何收集服務(wù)節(jié)點(diǎn)的日志并統(tǒng)一管理？

如何實(shí)現(xiàn)服務(wù)間調(diào)用鏈路追蹤？

如何對(duì)系統(tǒng)進(jìn)行鏈路保護(hù)，避免微服務(wù)雪崩？

可以發(fā)現(xiàn)，上述這些問(wèn)題并不是針對(duì)某種語(yǔ)言或某種技術(shù)的，任何軟件廠商要構(gòu)建微服務(wù)架構(gòu)就必須面對(duì)這些問(wèn)題，要么獨(dú)立開(kāi)發(fā)要么將已有多種技術(shù)整合形成整體解決方案。好在經(jīng)過(guò)多年沉淀，業(yè)內(nèi)已經(jīng)有了標(biāo)準(zhǔn)答案，下圖清晰的說(shuō)明微服務(wù)架構(gòu)需要的標(biāo)準(zhǔn)組件。

下面我來(lái)介紹每種組件的職責(zé)。

• 注冊(cè)中心（Service Registry）：注冊(cè)中心是微服務(wù)架構(gòu)最核心的組件。它起到新服務(wù)節(jié)點(diǎn)的注冊(cè)與狀態(tài)維護(hù)的作用，通過(guò)注冊(cè)中心解決了上述問(wèn)題 1。微服務(wù)節(jié)點(diǎn)在啟動(dòng)時(shí)會(huì)將自身的服務(wù)名稱、IP、端口等信息在注冊(cè)中心中進(jìn)行登記，注冊(cè)中心會(huì)定時(shí)檢查該節(jié)點(diǎn)的運(yùn)行狀態(tài)。注冊(cè)中心通常會(huì)采用心跳機(jī)制最大程度保證其持有的服務(wù)節(jié)點(diǎn)列表都是可用的。
  

• 負(fù)載均衡（Load Balance）：負(fù)載均衡器解決了問(wèn)題 2。通常在微服務(wù)彼此調(diào)用時(shí)并不是直接通過(guò)IP、端口直接訪問(wèn)，而是首先通過(guò)服務(wù)名在注冊(cè)中心查詢?cè)摲?wù)擁有哪些可用節(jié)點(diǎn)，然后注冊(cè)中心將可用節(jié)點(diǎn)列表返回給服務(wù)調(diào)用者，這個(gè)過(guò)程稱為“服務(wù)發(fā)現(xiàn)”。因服務(wù)高可用的要求，服務(wù)調(diào)用者會(huì)接收到多個(gè)可用節(jié)點(diǎn)，必須要從中進(jìn)行選擇，因此在服務(wù)調(diào)用者一端必須內(nèi)置負(fù)載均衡器，通過(guò)負(fù)載均衡策略選擇適合的節(jié)點(diǎn)發(fā)起實(shí)質(zhì)的通信請(qǐng)求。
  

• 服務(wù)通信（Communication）：服務(wù)通信組件解決了問(wèn)題 3。在微服務(wù)定義中闡述服務(wù)間通信采用輕量級(jí)協(xié)議，通常是 HTTP RESTful 風(fēng)格。但因 RESTful 風(fēng)格過(guò)于靈活，必須加以約束，通常在應(yīng)用時(shí)對(duì)其進(jìn)行上層封裝，例如在 Spring Cloud 中就提供了 Feign 和 RestTemplate 兩種技術(shù)屏蔽底層實(shí)現(xiàn) RESTful 通信細(xì)節(jié)，所有開(kāi)發(fā)者是基于封裝后統(tǒng)一的SDK進(jìn)行開(kāi)發(fā)，這有利于團(tuán)隊(duì)間協(xié)作。

• API 服務(wù)網(wǎng)關(guān)（API Gateway）：服務(wù)網(wǎng)關(guān)解決問(wèn)題 4。對(duì)于最終用戶來(lái)說(shuō)，微服務(wù)的通信與各種實(shí)現(xiàn)細(xì)節(jié)應(yīng)該是透明的，用戶只需關(guān)注他要使用的 API 接口即可。因此微服務(wù)架構(gòu)引入服務(wù)網(wǎng)關(guān)控制用戶的訪問(wèn)權(quán)限。服務(wù)網(wǎng)關(guān)是外部環(huán)境訪問(wèn)內(nèi)部微服務(wù)的唯一途徑，在這個(gè)基礎(chǔ)上還可以擴(kuò)展出其他功能，例如：用戶認(rèn)證與授權(quán)、容錯(cuò)限流、動(dòng)態(tài)路由、A/B測(cè)試、灰度發(fā)布等。
  

• 配置中心（Config Management）：配置中心解決問(wèn)題 5。微服務(wù)架構(gòu)下，微服務(wù)節(jié)點(diǎn)都包含自己的各種配置文件，如JDBC地址、自定義配置、環(huán)境配置等。要知道互聯(lián)網(wǎng)公司微服務(wù)節(jié)點(diǎn)可能是成千上萬(wàn)個(gè)，如果這些配置信息分散存儲(chǔ)在節(jié)點(diǎn)上，如發(fā)生配置變更就必須逐個(gè)調(diào)整，這必將給運(yùn)維人員帶來(lái)巨大的工作量。配置中心便因此而生，通過(guò)部署配置中心服務(wù)器，將原本分散的配置文件從應(yīng)用中剝離，集中轉(zhuǎn)存到配置中心。一般配置中心會(huì)提供 UI 界面，可以方便快捷的實(shí)現(xiàn)大規(guī)模集群的配置調(diào)整。
  
  

• 集中式日志管理（Centralized Logging）：集中式日志解決問(wèn)題 6。因?yàn)槲⒎?wù)架構(gòu)默認(rèn)將應(yīng)用日志分散保存在每一個(gè)微服務(wù)節(jié)點(diǎn)上，當(dāng)系統(tǒng)進(jìn)行用戶行為分析、數(shù)據(jù)統(tǒng)計(jì)時(shí)必須收集所有節(jié)點(diǎn)日志數(shù)據(jù)。那如何有效收集所有節(jié)點(diǎn)的運(yùn)行日志，并對(duì)其進(jìn)行分析匯總呢？業(yè)內(nèi)常見(jiàn)的方案有 ELK、EFK，通過(guò)搭建獨(dú)立的日志收集系統(tǒng)，定時(shí)抓取增量日志形成有效的統(tǒng)計(jì)報(bào)表，為決策提供數(shù)據(jù)支撐。
  

• 分布式鏈路追蹤（Distributed Tracing）：分布式追蹤解決問(wèn)題 7。一個(gè)復(fù)雜的業(yè)務(wù)流程可能需要連續(xù)調(diào)用多個(gè)微服務(wù)，我們需要記錄一個(gè)完整業(yè)務(wù)邏輯涉及的每一個(gè)微服務(wù)的運(yùn)行狀態(tài)，再通過(guò)可視化鏈路圖展現(xiàn)，幫助軟件工程師在系統(tǒng)出錯(cuò)時(shí)分析解決問(wèn)題。
  
  

• 服務(wù)保護(hù)（Service Protection）：服務(wù)保護(hù)解決問(wèn)題 8。在服務(wù)間通信過(guò)程中，如果某個(gè)微服務(wù)出現(xiàn)響應(yīng)高延遲可能會(huì)導(dǎo)致線程池滿載，嚴(yán)重時(shí)會(huì)引起系統(tǒng)崩潰。這里就需要引入服務(wù)保護(hù)組件實(shí)現(xiàn)高延遲服務(wù)的快速降級(jí)，避免系統(tǒng)崩潰。

以上是在微服務(wù)架構(gòu)過(guò)程中派生的新問(wèn)題以及對(duì)應(yīng)的解決方案，這些組件是微服務(wù)架構(gòu)設(shè)計(jì)時(shí)必須考慮的事情。在實(shí)現(xiàn)層面，Java 是目前對(duì)微服務(wù)生態(tài)支持最好的編程語(yǔ)言，下面我們就來(lái)介紹在Java中如何實(shí)現(xiàn)微服務(wù)架構(gòu)的。

Spring Cloud 是如何支撐微服務(wù)架構(gòu)的
下面這張圖很好地詮釋了 Spring、Spring Boot、Spring Cloud 它們之間的關(guān)系。Spring Cloud 提供了完整的微服務(wù)架構(gòu)的技術(shù)生態(tài)，像剛才我們提到的微服務(wù)架構(gòu)標(biāo)準(zhǔn)組件，在 Spring Cloud 中都有著對(duì)應(yīng)的實(shí)現(xiàn)。

不過(guò)這里有一點(diǎn)需要注意，Spring Cloud 并不是完全由 Spring 機(jī)構(gòu)自主開(kāi)發(fā)的，秉持不重復(fù)造輪子的理念，Spring 機(jī)構(gòu)整合了多家廠商的優(yōu)秀開(kāi)源產(chǎn)品，比如注冊(cè)中心就選用了 Netflix 的 Eureka，在此基礎(chǔ)上進(jìn)行整合形成了完整的 Java 微服務(wù)架構(gòu)解決方案。剛才我們列舉出來(lái)的 8 個(gè)微服務(wù)的標(biāo)準(zhǔn)組件在 Spring Cloud 中都有對(duì)應(yīng)的具體實(shí)現(xiàn)，值得注意的是同一類組件 Spring Cloud 可能給出多種不同的開(kāi)源產(chǎn)品供我們選擇，這些產(chǎn)品在 Spring Cloud 下是彼此兼容的。

以上是 Spring Cloud 的主要組成部分，這里還有許多沒(méi)有提到的功能組件，如果你對(duì)此感興趣，可以到 Spring Cloud 官網(wǎng)了(https://spring.io/projects/spring-cloud)解更詳細(xì)的內(nèi)容。

功能更強(qiáng)大的國(guó)產(chǎn)微服務(wù)生態(tài)Spring Cloud Alibaba
Spring Cloud Alibaba是直接隸屬于 Spring Cloud 的子項(xiàng)目。官網(wǎng)是：https://spring.io/projects/spring-cloud-alibaba#overview

Spring Cloud Alibaba是國(guó)產(chǎn)的微服務(wù)開(kāi)發(fā)一站式解決方案，與原有 Spring Cloud 兼容的同時(shí)對(duì)微服務(wù)生態(tài)進(jìn)行擴(kuò)展，通過(guò)添加少量的配置注解，便可實(shí)現(xiàn)更符合國(guó)情的微服務(wù)架構(gòu)。

下面是 Spring Cloud 與 Spring Cloud Alibaba 的對(duì)比表格。

我將兩者從不同維度進(jìn)行比對(duì)，可以發(fā)現(xiàn)相比 Spring Cloud，Spring Cloud Alibaba 對(duì)服務(wù)注冊(cè)、配置中心與負(fù)載均衡功能都整合進(jìn) Nacos，這樣簡(jiǎn)化了微服務(wù)架構(gòu)的復(fù)雜度，出問(wèn)題的概率也會(huì)降低。原有的服務(wù)保護(hù)組件也調(diào)整為 Sentinel，相較Hystrix功能更強(qiáng)大，使用也更加友好。在表格最下方也可看到 Spring Cloud Alibaba 基于阿里云強(qiáng)大的能力提供了更多的新特性，很多復(fù)雜的應(yīng)用場(chǎng)景通過(guò) Spring Cloud Alibaba 結(jié)合阿里云便可輕松實(shí)現(xiàn)。在后面的內(nèi)容，我們以這個(gè)表格作為主線對(duì)組件進(jìn)行逐一講解，讓你輕松掌握各組件用法與設(shè)計(jì)原理。

總結(jié)

以上是生活随笔為你收集整理的01 | 顶层设计：微服务生态与 Spring Cloud Alibaba的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。