1 微服務(wù)優(yōu)勢(shì)與挑戰(zhàn)

1.1 微服務(wù)的優(yōu)勢(shì)

1.1.1 單一職責(zé)

微服務(wù)架構(gòu)中的 每個(gè)節(jié)點(diǎn)高度服務(wù)化，都是具有業(yè)務(wù)邏輯的， 符合高內(nèi)聚、低耦合原則以及單一職責(zé)原則的單元，包括數(shù)據(jù)庫(kù)和數(shù)據(jù)模型；

不同的服務(wù)通過(guò)“管道”的方式靈活組合，從而構(gòu)建出龐大的系統(tǒng)。

1.1.2 輕量級(jí)通信

通過(guò)REST API模式或者RPC框架，事件流和消息代理的組合相互通信，實(shí)現(xiàn)服務(wù)間互相協(xié)作的輕量級(jí)通信機(jī)制。

1.1.3 獨(dú)立性

在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都是獨(dú)立的業(yè)務(wù)單元，與其他服務(wù)高度解耦，只需要改變當(dāng)前服務(wù)本身，就可以完成獨(dú)立的開發(fā)、測(cè)試、部署、運(yùn)維。

1.1.4 進(jìn)程隔離

在微服務(wù)架構(gòu)中，應(yīng)用程序由多個(gè)服務(wù)組成，每個(gè)服務(wù)都是高度自治的獨(dú)立業(yè)務(wù)實(shí)體，可以 運(yùn)行在獨(dú)立的進(jìn)程中，不同的服務(wù)能非常容易地部署到不同的主機(jī)上，實(shí)現(xiàn)高度自治和高度隔離。

進(jìn)程的隔離，還能 保證服務(wù)達(dá)到動(dòng)態(tài)擴(kuò)縮容的能力，業(yè)務(wù)高峰期自動(dòng)增加服務(wù)資源以提升并發(fā)能力，業(yè)務(wù)低谷期則可自動(dòng)釋放服務(wù)資源以節(jié)省開銷。 

1.1.5 混合技術(shù)棧和混合部署方式

團(tuán)隊(duì)可以為不同的服務(wù)組件使用不同的技術(shù)棧和不同的部署方式（公有云、私有云、混合云）。

1.1.6 簡(jiǎn)化治理

組件可以彼此獨(dú)立地進(jìn)行縮放，從而減少了因必須縮放整個(gè)應(yīng)用程序而產(chǎn)生的浪費(fèi)和成本，獨(dú)立的發(fā)布、服務(wù)治理。 

1.1.7 安全可靠，可維護(hù)。

從架構(gòu)上對(duì)運(yùn)維提供友好的支撐，在安全、可維護(hù)的基礎(chǔ)上規(guī)范化發(fā)布流程，支持?jǐn)?shù)據(jù)存儲(chǔ)容災(zāi)、業(yè)務(wù)模塊隔離、訪問(wèn)權(quán)限控制、編碼安全檢測(cè)等。

1.2 面臨的挑戰(zhàn) 

1.2.1 分布式固有復(fù)雜性

微服務(wù)架構(gòu)是基于分布式的系統(tǒng)，而構(gòu)建分布式系統(tǒng)必然會(huì)帶來(lái)額外的開銷。

• 性能： 分布式系統(tǒng)是跨進(jìn)程、跨網(wǎng)絡(luò)的調(diào)用，受網(wǎng)絡(luò)延遲和帶寬的影響。
• 可靠性： 由于高度依賴于網(wǎng)絡(luò)狀況，任何一次的遠(yuǎn)程調(diào)用都有可能失敗，隨著服務(wù)的增多還會(huì)出現(xiàn)更多的潛在故障點(diǎn)。因此，如何提高系統(tǒng)的可靠性、降低因網(wǎng)絡(luò)引起的故障率，是系統(tǒng)構(gòu)建的一大挑戰(zhàn)。
• 分布式通信： 分布式通信大大增加了功能實(shí)現(xiàn)的復(fù)雜度，并且伴隨著定位難、調(diào)試難等問(wèn)題。
• 數(shù)據(jù)一致性： 需要保證分布式系統(tǒng)的數(shù)據(jù)強(qiáng)一致性，即在 C（一致性）A（可用性）P（分區(qū)容錯(cuò)性） 三者之間做出權(quán)衡。這塊可以參考我的這篇《分布式事務(wù)CAP兩階段提交及三階段提交詳解》。

1.2.2 服務(wù)的依賴管理和測(cè)試

在單體應(yīng)用中，通常使用集成測(cè)試來(lái)驗(yàn)證依賴是否正常。而在微服務(wù)架構(gòu)中，服務(wù)數(shù)量眾多，每個(gè)服務(wù)都是獨(dú)立的業(yè)務(wù)單元，服務(wù)主要通過(guò)接口進(jìn)行交互，如何保證它的正常，是測(cè)試面臨的主要挑戰(zhàn)。

所以單元測(cè)試和單個(gè)服務(wù)鏈路的可用性非常重要。

1.2.3 有效的配置版本管理 

在單體系統(tǒng)中，配置可以寫在yaml文件，分布式系統(tǒng)中需要統(tǒng)一進(jìn)行配置管理，同一個(gè)服務(wù)在不同的場(chǎng)景下對(duì)配置的值要求還可能不一樣，所以需要引入配置的版本管理、環(huán)境管理。

1.2.4 自動(dòng)化的部署流程

在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都獨(dú)立部署，交付周期短且頻率高，人工部署已經(jīng)無(wú)法適應(yīng)業(yè)務(wù)的快速變化。 有效地構(gòu)建自動(dòng)化部署體系，配合服務(wù)網(wǎng)格、容器技術(shù)，是微服務(wù)面臨的另一個(gè)挑戰(zhàn)。

1.2.5 對(duì)于DevOps更高的要求

在微服務(wù)架構(gòu)的實(shí)施過(guò)程中，開發(fā)人員和運(yùn)維人員的角色發(fā)生了變化， 開發(fā)者也將承擔(dān)起整個(gè)服務(wù)的生命周期的責(zé)任，包括部署、鏈路追蹤、監(jiān)控；因此，按需調(diào)整組織架構(gòu)、構(gòu)建全功能的團(tuán)隊(duì)，也是一個(gè)不小的挑戰(zhàn)。

1.2.6 運(yùn)維成本

運(yùn)維主要包括配置、部署、監(jiān)控與告警和日志收集四大方面。微服務(wù)架構(gòu)中，每個(gè)服務(wù)都需要獨(dú)立地配置、部署、監(jiān)控和收集日志，成本呈指數(shù)級(jí)增長(zhǎng)。

服務(wù)化粒度越細(xì)，運(yùn)維成本越高。

怎樣去解決這些問(wèn)題，是微服務(wù)架構(gòu)必須面臨的挑戰(zhàn)。 

2 微服務(wù)全景架構(gòu)

3 微服務(wù)核心組件

微服務(wù)架構(gòu)核心組件包括：

3.1 服務(wù)注冊(cè)與發(fā)現(xiàn)

3.1.1 原理圖

服務(wù)注冊(cè)與發(fā)現(xiàn)三要素：

• Provider：服務(wù)的提供方
• Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方
• Registry：服務(wù)注冊(cè)和發(fā)現(xiàn)的注冊(cè)中心

3.1.2 注冊(cè)中心的原理、流程

1、 Provider(服務(wù)提供者)綁定指定端口并啟動(dòng)服務(wù) 

2、提供者連接注冊(cè)中心，并發(fā)本機(jī) IP、端口、應(yīng)用信息和服務(wù)信息發(fā)送至注冊(cè)中心存儲(chǔ)

3、Consumer(消費(fèi)者），連接注冊(cè)中心 ，并發(fā)送應(yīng)用信息、所求服務(wù)信息至注冊(cè)中心

4、注冊(cè)中心根據(jù)消費(fèi)者所求服務(wù)信息匹配對(duì)應(yīng)的提供者列表發(fā)送至Consumer 應(yīng)用緩存。

5、Consumer 在發(fā)起遠(yuǎn)程調(diào)用時(shí)基于緩存的消費(fèi)者列表?yè)衿湟话l(fā)起調(diào)用。

6、Provider 狀態(tài)變更會(huì)實(shí)時(shí)通知注冊(cè)中心、在由注冊(cè)中心實(shí)時(shí)推送至Consumer設(shè)計(jì)的原因：

Consumer 與 Provider 解偶，雙方都可以橫向增減節(jié)點(diǎn)數(shù)。注冊(cè)中心對(duì)本身可做對(duì)等集群，可動(dòng)態(tài)增減節(jié)點(diǎn)，并且任意一臺(tái)宕掉后，將自動(dòng)切換到另一臺(tái)

7、去中心化，雙方不直接依賴注冊(cè)中心，即使注冊(cè)中心全部宕機(jī)短時(shí)間內(nèi)也不會(huì)影響服務(wù)的調(diào)用（Consumer應(yīng)用緩存中保留提供者 Provider 列表）

8、服務(wù)提供者無(wú)狀態(tài)，任意一臺(tái)宕掉后，不影響使用

注冊(cè)中心包含如下功能：注冊(cè)中心、服務(wù)注冊(cè)和反注冊(cè)、心跳監(jiān)測(cè)與匯報(bào)、服務(wù)訂閱、服務(wù)變更查詢、集群部署、服務(wù)健康狀態(tài)檢測(cè)、服務(wù)狀態(tài)變更通知 等

我們有很多種注冊(cè)中心的技術(shù)，Zookeeper、Etcd、Consul、Eureka 4種比較常用，如下

分布式系統(tǒng)中CAP模型3者不可兼得。由于網(wǎng)絡(luò)的原因，分布式系統(tǒng)中P是必備的，意味著只能選擇 AP 或者 CP。CP 代表數(shù)據(jù)一致性是第一位的，AP 代表可用性是第一位的。

Zookeeper、Etcd、Consul 是 CP 型注冊(cè)中心，犧牲可用性來(lái)保證數(shù)據(jù)強(qiáng)一致性

Eureka 是 AP 型注冊(cè)中心，犧牲一致性來(lái)保證可用性 

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

上面是Api網(wǎng)關(guān)服務(wù)的基本架構(gòu)：用戶的請(qǐng)求經(jīng)過(guò)統(tǒng)一的Api網(wǎng)關(guān)來(lái)訪問(wèn)微服務(wù)里具體的服務(wù)顆粒，并且可能產(chǎn)生串聯(lián)的鏈路服務(wù)調(diào)用。

有很多耳熟能詳?shù)腁PI網(wǎng)關(guān)技術(shù)，比如 Zuul、Kong、Tyk等，提供了服務(wù)路由在內(nèi)的很多通用功能，后面會(huì)有專門的章節(jié)來(lái)說(shuō)這個(gè)。

Tyk：Tyk是一個(gè)開放源碼的API網(wǎng)關(guān)，它是快速、可擴(kuò)展和現(xiàn)代的。Tyk提供了一個(gè)API管理平臺(tái)，其中包括API網(wǎng)關(guān)、API分析、開發(fā)人員門戶和API管理面板。Try 是一個(gè)基于Go實(shí)現(xiàn)的網(wǎng)關(guān)服務(wù)。

Kong：Kong是一個(gè)可擴(kuò)展的開放源碼API Layer(也稱為API網(wǎng)關(guān)或API中間件)。Kong 在任何RESTful API的前面運(yùn)行，通過(guò)插件擴(kuò)展，它提供了超越核心平臺(tái)的額外功能和服務(wù)。

Netflix zuul：Zuul是一種提供動(dòng)態(tài)路由、監(jiān)視、彈性、安全性等功能的邊緣服務(wù)。Zuul是Netflix出品的一個(gè)基于JVM路由和服務(wù)端的負(fù)載均衡器。

除了路由之外，Api網(wǎng)關(guān)服務(wù)還包含：認(rèn)證和授權(quán)，重試、熔斷、降級(jí)，負(fù)載均衡，日志、監(jiān)控、鏈路追蹤，灰度發(fā)布，ABTesting 等功能。

3.3 配置中心

上面這個(gè)是攜程的開源配置中心Apollo系統(tǒng)的架構(gòu)設(shè)計(jì)，我們從下往上進(jìn)行分析：

1、Config Service提供配置的讀取、推送等功能，服務(wù)對(duì)象是Apollo客戶端

2、Admin Service提供配置的修改、發(fā)布等功能，服務(wù)對(duì)象是Apollo Portal（管理界面）

3、Config Service和Admin Service都是多實(shí)例、無(wú)狀態(tài)部署，所以需要將自己注冊(cè)到Eureka中并保持心跳，支持注冊(cè)、更新、刪除能力

4、在Eureka之上我們架了一層Meta Server用于封裝Eureka的服務(wù)發(fā)現(xiàn)接口

5、Client通過(guò)域名訪問(wèn)Meta Server獲取Config Service服務(wù)列表（IP+Port），而后直接通過(guò)IP+Port訪問(wèn)服務(wù)，同時(shí)在Client側(cè)會(huì)做load balance、錯(cuò)誤重試

6、Portal通過(guò)域名訪問(wèn)Meta Server獲取Admin Service服務(wù)列表（IP+Port），而后直接通過(guò)IP+Port訪問(wèn)服務(wù)，同時(shí)在Portal側(cè)會(huì)做load balance、錯(cuò)誤重試

7、為了簡(jiǎn)化部署，我們實(shí)際上會(huì)把Config Service、Eureka和Meta Server三個(gè)邏輯角色部署在同一個(gè)JVM進(jìn)程中

上面的架構(gòu)體現(xiàn)了如下特點(diǎn)：

•高可用：配置服務(wù)為多實(shí)例部署，訪問(wèn)層保證 load balance、錯(cuò)誤重試
•弱依賴：使用了Eureka來(lái)做配置中心的服務(wù)注冊(cè)，如果出現(xiàn)問(wèn)題或者網(wǎng)絡(luò)出現(xiàn)問(wèn)題的時(shí)候，服務(wù)應(yīng)該可以依賴于它本身所緩存的配置來(lái)提供正常的服務(wù)

3.4 服務(wù)通信

分布式系統(tǒng)一般是由多個(gè)微服務(wù)顆粒組成的，微服務(wù)與微服務(wù)之前存在互相調(diào)用，甚至多個(gè)鏈路訪問(wèn)的情況。所以他們之間是需要通信的，通信方式繼承于SOA，包含同步與異步兩種模式。

3.4.1 同步訪問(wèn)方式

1、RPC 訪問(wèn)模式

Remote Procedure Call Protocol，遠(yuǎn)程過(guò)程調(diào)用協(xié)議，一般使用在分布式業(yè)務(wù)或者微服務(wù)架構(gòu)風(fēng)格中。像調(diào)用本地函數(shù)一樣，去調(diào)用一個(gè)遠(yuǎn)端服務(wù)。

本質(zhì)上是請(qǐng)求鏈的底層，維護(hù)同一個(gè)端口，進(jìn)行socket通信。常見的RPC技術(shù)包含 gRPC、Dubbo、Thrift 等。

2、REST 訪問(wèn)模式

這個(gè)應(yīng)該大家最常用，可以通過(guò)一套統(tǒng)一風(fēng)格的接口模式，為Web，iOS和Android等提供接口服務(wù)。

3.4.2 異步訪問(wèn)方式

消息中間件：RabbitMQ、Kafka、RocketMQ之類，對(duì)于實(shí)時(shí)性要求不那么嚴(yán)格的服務(wù)請(qǐng)求和計(jì)算。 

3.5 服務(wù)治理

常見的服務(wù)治理手段有如下幾種：

3.5.1 節(jié)點(diǎn)管理

服務(wù)調(diào)用失敗時(shí)可能是服務(wù)提供者自身出現(xiàn)，也可能是網(wǎng)絡(luò)發(fā)生故障，我們一般有兩種處理手段。

1. 注冊(cè)中心主動(dòng)摘除機(jī)制
這種機(jī)制要求服務(wù)提供者定時(shí)向注冊(cè)中心匯報(bào)心跳，如果超時(shí)，就認(rèn)為服務(wù)提供者出現(xiàn)問(wèn)題，并將節(jié)點(diǎn)從服務(wù)列表中摘除。

2. 服務(wù)消費(fèi)者摘除機(jī)制
當(dāng)服務(wù)提供者網(wǎng)絡(luò)出現(xiàn)異常，服務(wù)消費(fèi)者調(diào)用就會(huì)失敗，如果持續(xù)錯(cuò)誤就可以將它從服務(wù)提供者節(jié)點(diǎn)列表中移除。

3.5.2 負(fù)載均衡

服務(wù)消費(fèi)者在從服務(wù)列表中選取可用節(jié)點(diǎn)時(shí)，如果能讓性能較好的服務(wù)機(jī)多承擔(dān)一些流量的話，就能充分利用機(jī)器的性能。這就需要對(duì)負(fù)載均衡算法做一些調(diào)整。

常用的負(fù)載均衡算法主要包括以下幾種：

1. Radom 隨機(jī)算法
從可用的服務(wù)節(jié)點(diǎn)中隨機(jī)選取一個(gè)節(jié)點(diǎn)。一般情況下，隨機(jī)算法是均勻的，也就是說(shuō)后端服務(wù)節(jié)點(diǎn)無(wú)論配置好壞，最終得到的調(diào)用量都差不多。

2. Round Robin 輪詢算法（加權(quán)重）
就是按照固定的權(quán)重，對(duì)可用服務(wù)節(jié)點(diǎn)進(jìn)行輪詢。如果所有服務(wù)節(jié)點(diǎn)的權(quán)重都是相同的，則每個(gè)節(jié)點(diǎn)的調(diào)用量也是差不多的。但可以給性能較好的節(jié)點(diǎn)的權(quán)重調(diào)大些，充分發(fā)揮其性能優(yōu)勢(shì)，提高整體調(diào)用的平均性能。

3. Least Conn 最少活躍調(diào)用算法
這種算法是在服務(wù)消費(fèi)者這一端的內(nèi)存里動(dòng)態(tài)維護(hù)著同每一個(gè)服務(wù)節(jié)點(diǎn)之間的連接數(shù)，選擇連接數(shù)最小的節(jié)點(diǎn)發(fā)起調(diào)用，也就是選擇了調(diào)用量最小的服務(wù)節(jié)點(diǎn)，性能理論上也是最優(yōu)的。

4. 一致性 Hash 算法
指相同參數(shù)的請(qǐng)求總是發(fā)到同一服務(wù)節(jié)點(diǎn)。當(dāng)某一個(gè)服務(wù)節(jié)點(diǎn)出現(xiàn)故障時(shí)，原本發(fā)往該節(jié)點(diǎn)的請(qǐng)求，基于虛擬節(jié)點(diǎn)機(jī)制，平攤到其他節(jié)點(diǎn)上，不會(huì)引起劇烈變動(dòng)。

3.5.3 服務(wù)路由

所謂的路由規(guī)則，就是通過(guò)一定的規(guī)則如條件表達(dá)式或者正則表達(dá)式來(lái)限定服務(wù)節(jié)點(diǎn)的選擇范圍。

制定路由規(guī)則主要有兩個(gè)原因。

1. 業(yè)務(wù)存在灰度發(fā)布、多版本ABTesting的需求

功能逐步開放發(fā)布或者灰度測(cè)試的場(chǎng)景。

2. 多機(jī)房就近訪問(wèn)的需求

一般可以通過(guò) IP 段規(guī)則來(lái)控制訪問(wèn)，在選擇服務(wù)節(jié)點(diǎn)時(shí)，優(yōu)先選擇同一 IP 段的節(jié)點(diǎn)。這個(gè)也是算力靠近的優(yōu)先原則。

3.5.4 服務(wù)容錯(cuò)

在分布式系統(tǒng)中，分區(qū)容錯(cuò)性是很重要的一個(gè)話題，要知道，服務(wù)間的調(diào)用調(diào)用并不總是成功，服務(wù)提供者程序bug、異常退出 或者 消費(fèi)者與提供者之間的網(wǎng)絡(luò)故障。而服務(wù)調(diào)用失敗之后，我們需要一些方法來(lái)保證調(diào)用的正常。

常用的方式有以下幾種：

FailOver 失敗自動(dòng)切換。就是服務(wù)消費(fèi)者發(fā)現(xiàn)調(diào)用失敗或者超時(shí)后，自動(dòng)從可用的服務(wù)節(jié)點(diǎn)列表中選擇下一個(gè)節(jié)點(diǎn)重新發(fā)起調(diào)用，也可以設(shè)置重試的次數(shù)。

FailBack 失敗通知。就是服務(wù)消費(fèi)者調(diào)用失敗或者超時(shí)后，不再重試，而是根據(jù)失敗的詳細(xì)信息，來(lái)決定后續(xù)的執(zhí)行策略。

FailCache 失敗緩存。就是服務(wù)消費(fèi)者調(diào)用失敗或者超時(shí)后，不立即發(fā)起重試，而是隔一段時(shí)間后再次嘗試發(fā)起調(diào)用。

FailFast 快速失敗。就是服務(wù)消費(fèi)者調(diào)用一次失敗后，不再重試。

服務(wù)治理的手段是從不同角度來(lái)確保服務(wù)調(diào)用的成功率。節(jié)點(diǎn)管理是從服務(wù)節(jié)點(diǎn)健康狀態(tài)角度來(lái)考慮，負(fù)載均衡和服務(wù)路由是從服務(wù)節(jié)點(diǎn)訪問(wèn)優(yōu)先級(jí)角度來(lái)考慮，而服務(wù)容錯(cuò)是從調(diào)用的健康狀態(tài)角度來(lái)考慮。 

3.6 服務(wù)監(jiān)控 

常見的開發(fā)監(jiān)控報(bào)警技術(shù)有 ELK、InfluxData的TICK、Promethues 等。

在分布式系統(tǒng)中，微服務(wù)一般都具有復(fù)雜的鏈路調(diào)用，對(duì)于鏈路之間的狀態(tài)、服務(wù)可用性、調(diào)用情況的監(jiān)控，是需要一套完整的服務(wù)監(jiān)控系統(tǒng)去保障的。

如我們上面的那個(gè)圖所示， 服務(wù)系統(tǒng)主要由哪幾部分構(gòu)成：

1、數(shù)據(jù)采集部分，包含性能指標(biāo)信息、日志信息（一般是服務(wù)埋點(diǎn)日志或者sidecar的inbound、outbound信息）、端到端的Trace信息。

2、采集上來(lái)的監(jiān)控?cái)?shù)據(jù)通過(guò)傳輸系統(tǒng)，或者使用消息中間件來(lái)異步傳輸，或者調(diào)用服務(wù)端接口推送監(jiān)控?cái)?shù)據(jù)。并把這些數(shù)據(jù)持久化到我們的數(shù)據(jù)服務(wù)層中。

3、制定一套規(guī)則，對(duì)于采集到的數(shù)據(jù)進(jìn)行清理、計(jì)算、分級(jí)等，處理好的數(shù)據(jù)，通過(guò)提前設(shè)置好的報(bào)警策略，來(lái)判斷它是否觸發(fā)了這些報(bào)警。

4、梳理完的數(shù)據(jù)可以進(jìn)行查詢展示（有一個(gè)日志查詢界面）、分級(jí)報(bào)警、分析趨勢(shì)報(bào)表推送等。

3.7 服務(wù)追蹤

服務(wù)追蹤的原理主要包括下面兩個(gè)關(guān)鍵點(diǎn)。

1、為了實(shí)現(xiàn)請(qǐng)求跟蹤，當(dāng)請(qǐng)求發(fā)送到分布式系統(tǒng)的入口端點(diǎn)時(shí)，只需要服務(wù)跟蹤框架為該請(qǐng)求創(chuàng)建一個(gè)唯一的跟蹤標(biāo)識(shí)，同時(shí)在分布式系統(tǒng)內(nèi)部流轉(zhuǎn)的時(shí)候，框架始終保持傳遞該唯一標(biāo)識(shí)，直到返回給請(qǐng)求方為止，這個(gè)唯一標(biāo)識(shí)就是前文中提到的 Trace ID。

通過(guò) Trace ID 的記錄，我們就能將所有請(qǐng)求過(guò)程的日志關(guān)聯(lián)起來(lái)。

2、為了統(tǒng)計(jì)各處理單元的時(shí)間延遲，當(dāng)請(qǐng)求到達(dá)各個(gè)服務(wù)組件時(shí)，或是處理邏輯到達(dá)某個(gè)狀態(tài)時(shí)，也通過(guò)一個(gè)唯一標(biāo)識(shí)來(lái)標(biāo)記它的開始、具體過(guò)程以及結(jié)束，該標(biāo)識(shí)就是前文中提到的 Span ID。對(duì)于每個(gè) Span 來(lái)說(shuō)，它必須有開始和結(jié)束兩個(gè)節(jié)點(diǎn)，

通過(guò)記錄開始 Span 和結(jié)束 Span 的時(shí)間戳，就能統(tǒng)計(jì)出該 Span 的時(shí)間延遲，除了時(shí)間戳記錄之外，它還可以包含一些其他元數(shù)據(jù)，比如事件名稱、請(qǐng)求信息等。

上圖顯示了Trace ID 和 Spand ID 在鏈路中的傳輸過(guò)程，它把服務(wù)調(diào)用的一個(gè)時(shí)序結(jié)構(gòu)給展現(xiàn)出來(lái)了。

常見的服務(wù)鏈路追蹤的技術(shù)有Zipkin、Pinpoint、SkyWalking 等。后面講到Service Mesh的時(shí)候會(huì)詳細(xì)說(shuō)下Zipkin的x-b3 header頭傳遞，以及流量染色的使用，非常給力。

4 總結(jié)

微服務(wù)架構(gòu)提倡的單一應(yīng)用程序劃分成一組松散耦合的細(xì)粒度小型服務(wù)，輔助輕量級(jí)的協(xié)議，互相協(xié)調(diào)、互相配合，實(shí)現(xiàn)高效的應(yīng)用價(jià)值，符合我們應(yīng)用服務(wù)開發(fā)的發(fā)展趨勢(shì)。

后續(xù)我們圍繞它的核心模塊：服務(wù)注冊(cè)與發(fā)現(xiàn)、API 網(wǎng)關(guān)服務(wù)、分布式配置中心、服務(wù)通信、服務(wù)治理、分布式服務(wù)追蹤與監(jiān)控等，從原理到實(shí)踐，一步步展開來(lái)研究。

以上就是微服務(wù)全景架構(gòu)全面瓦解的詳細(xì)內(nèi)容，更多關(guān)于微服務(wù)全景架構(gòu)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論