我們來認(rèn)識(shí)一下微服務(wù)架構(gòu)在Java體系中依托哪些組件實(shí)現(xiàn)的。

相對(duì)于單體架構(gòu)的簡(jiǎn)單粗暴，微服務(wù)的核心是將應(yīng)用打散，形成多個(gè)獨(dú)立提供的微服務(wù)，雖然從管理與邏輯上更符合業(yè)務(wù)需要。但微服務(wù)架構(gòu)也帶來了很多急需解決的核心問題：

1、如何發(fā)現(xiàn)新節(jié)點(diǎn)以及檢查各節(jié)點(diǎn)的運(yùn)行狀態(tài)？

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

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

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

5、如何集中管理各節(jié)點(diǎn)配置文件？

6、如何收集各節(jié)點(diǎn)日志并統(tǒng)一管理？

7、如何直觀的了解各節(jié)點(diǎn)間的調(diào)用鏈路？

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

可以發(fā)現(xiàn)，以上的各個(gè)問題，不是針對(duì)某種語言或某種技術(shù)的，任何要構(gòu)建微服務(wù)架構(gòu)的企業(yè)都需要面對(duì)這些問題，要么公司內(nèi)部逐個(gè)研究各個(gè)問題的解決辦法，要么就將已有的多種技術(shù)整合形成整體解決方案。好在經(jīng)過互聯(lián)網(wǎng)行業(yè)的多年發(fā)展，業(yè)內(nèi)對(duì)于上述問題基本都有了標(biāo)準(zhǔn)的解決方案，下圖清晰的說明了微服務(wù)架構(gòu)需要的標(biāo)準(zhǔn)組件。

下面我們來逐個(gè)了解各個(gè)組件的職責(zé)：

1、注冊(cè)中心（Service Registry）

注冊(cè)中心是微服務(wù)架構(gòu)最核心的組件。它起到的作用是對(duì)新節(jié)點(diǎn)的注冊(cè)與狀態(tài)維護(hù)，通過注冊(cè)中心可解決上述第1個(gè)問題（1、如何發(fā)現(xiàn)新節(jié)點(diǎn)以及檢查各節(jié)點(diǎn)的運(yùn)行狀態(tài)？ ）。

微服務(wù)節(jié)點(diǎn)在啟動(dòng)時(shí)會(huì)將自己的服務(wù)名稱、IP、端口等信息在注冊(cè)中心登記，注冊(cè)中心會(huì)定時(shí)檢查該節(jié)點(diǎn)的運(yùn)行狀態(tài)。注冊(cè)中心通常會(huì)采用心跳機(jī)制最大程度保證已登記過的服務(wù)節(jié)點(diǎn)都是可用的。

2、負(fù)載均衡（Load Balance）

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

3、服務(wù)通信(Communication)

服務(wù)通信組件解決了問題3（3、服務(wù)間如何進(jìn)行消息通信？ ）。服務(wù)間通信采用輕量級(jí)協(xié)議，通常是HTTP RESTful風(fēng)格。但因?yàn)镽ESTful風(fēng)格過于靈活，必須加以約束，通常應(yīng)用時(shí)對(duì)其封裝。例如在SpringCloud中就提供了Feign和RestTemplate兩種技術(shù)屏蔽底層的實(shí)現(xiàn)細(xì)節(jié)，所有開發(fā)者都是基于封裝后統(tǒng)一的SDK進(jìn)行開發(fā)，有利于團(tuán)隊(duì)間的相互合作。

4、API服務(wù)網(wǎng)關(guān)(API Gateway)

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

微服務(wù)API網(wǎng)關(guān)

5、配置中心(Config Management)

配置中心主要解決了問題5（5、如何集中管理各節(jié)點(diǎn)配置文件？ ），在微服務(wù)架構(gòu)下，所有的微服務(wù)節(jié)點(diǎn)都包含自己的各種配置文件，如jdbc配置、自定義配置、環(huán)境配置、運(yùn)行參數(shù)配置等。要知道有的微服務(wù)可能可能有幾十個(gè)節(jié)點(diǎn)，如果將這些配置文件分散存儲(chǔ)在節(jié)點(diǎn)上，發(fā)生配置更改就需要逐個(gè)節(jié)點(diǎn)調(diào)整，將給運(yùn)維人員帶來巨大的壓力。配置中心便由此而生，通過部署配置中心服務(wù)器，將各節(jié)點(diǎn)配置文件從服務(wù)中剝離，集中轉(zhuǎn)存到配置中心。一般配置中心都有UI界面，方便實(shí)現(xiàn)大規(guī)模集群配置調(diào)整。

重復(fù)的配置文件

配置中心集中管理配置文件

6、集中式日志管理(Centralized Logging)

集中式日志主要是解決了問題6（6、如何收集各節(jié)點(diǎn)日志并統(tǒng)一管理？ ）。微服務(wù)架構(gòu)默認(rèn)將應(yīng)用日志分別保存在部署節(jié)點(diǎn)上，當(dāng)需要對(duì)日志數(shù)據(jù)和操作數(shù)據(jù)進(jìn)行數(shù)據(jù)分析和數(shù)據(jù)統(tǒng)計(jì)時(shí)，必須收集所有節(jié)點(diǎn)的日志數(shù)據(jù)。那么怎么高效收集所有節(jié)點(diǎn)的日志數(shù)據(jù)呢？業(yè)內(nèi)常見的方案有ELK、EFK。通過搭建獨(dú)立的日志收集系統(tǒng)，定時(shí)抓取各節(jié)點(diǎn)增量日志形成有效的統(tǒng)計(jì)報(bào)表，為統(tǒng)計(jì)和分析提供數(shù)據(jù)支撐。

7、分布式鏈路追蹤（Distributed Tracing）

很不舒服鏈路追蹤解決了問題7（7、如何直觀的了解各節(jié)點(diǎn)間的調(diào)用鏈路？ ）。系統(tǒng)中一個(gè)復(fù)雜的業(yè)務(wù)流程，可能會(huì)出現(xiàn)連續(xù)調(diào)用多個(gè)微服務(wù)，我們需要了解完整的業(yè)務(wù)邏輯涉及的每個(gè)微服務(wù)的運(yùn)行狀態(tài)，通過可視化鏈路圖展現(xiàn)，可以幫助開發(fā)人員快速分析系統(tǒng)瓶頸及出錯(cuò)的服務(wù)。

服務(wù)調(diào)用鏈路圖

8、服務(wù)保護(hù)（Service Protection）

服務(wù)保護(hù)主要是解決了問題8（8、如何對(duì)系統(tǒng)進(jìn)行鏈路保護(hù)，避免服務(wù)雪崩？ ）。在業(yè)務(wù)運(yùn)行時(shí)，微服務(wù)間互相調(diào)用支撐，如果某個(gè)微服務(wù)出現(xiàn)高延遲導(dǎo)致線程池滿載，或是業(yè)務(wù)處理失敗。這里就需要引入服務(wù)保護(hù)組件來實(shí)現(xiàn)高延遲服務(wù)的快速降級(jí)，避免系統(tǒng)崩潰。

以上就是微服務(wù)架構(gòu)包含的組件以及各個(gè)組件在架構(gòu)中承擔(dān)的職責(zé)。下篇文章我們來聊一下：在Java中如何實(shí)現(xiàn)微服務(wù)架構(gòu)的。