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

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

1.1.1 單一職責(zé)

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

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

1.1.2 輕量級通信

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

1.1.3 獨立性

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

1.1.4 進程隔離

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

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

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

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

1.1.6 簡化治理

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

1.1.7 安全可靠，可維護。

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

1.2 面臨的挑戰(zhàn) 

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

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

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

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

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

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

1.2.3 有效的配置版本管理 

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

1.2.4 自動化的部署流程

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

1.2.5 對于DevOps更高的要求

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

1.2.6 運維成本

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

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

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

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

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

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

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

3.1.1 原理圖

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

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

3.1.2 注冊中心的原理、流程

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

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

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

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

5、Consumer 在發(fā)起遠程調(diào)用時基于緩存的消費者列表擇其一發(fā)起調(diào)用。

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

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

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

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

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

我們有很多種注冊中心的技術(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 型注冊中心，犧牲可用性來保證數(shù)據(jù)強一致性

Eureka 是 AP 型注冊中心，犧牲一致性來保證可用性 

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

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

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

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

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

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

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

3.3 配置中心

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

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

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

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

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

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

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

7、為了簡化部署，我們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中

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

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

3.4 服務(wù)通信

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

3.4.1 同步訪問方式

1、RPC 訪問模式

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

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

2、REST 訪問模式

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

3.4.2 異步訪問方式

消息中間件：RabbitMQ、Kafka、RocketMQ之類，對于實時性要求不那么嚴格的服務(wù)請求和計算。 

3.5 服務(wù)治理

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

3.5.1 節(jié)點管理

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

1. 注冊中心主動摘除機制
這種機制要求服務(wù)提供者定時向注冊中心匯報心跳，如果超時，就認為服務(wù)提供者出現(xiàn)問題，并將節(jié)點從服務(wù)列表中摘除。

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

3.5.2 負載均衡

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

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

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

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

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

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

3.5.3 服務(wù)路由

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

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

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

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

2. 多機房就近訪問的需求

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

3.5.4 服務(wù)容錯

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

常用的方式有以下幾種：

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

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

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

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

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

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

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

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

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

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

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

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

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

3.7 服務(wù)追蹤

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

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

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

2、為了統(tǒng)計各處理單元的時間延遲，當請求到達各個服務(wù)組件時，或是處理邏輯到達某個狀態(tài)時，也通過一個唯一標識來標記它的開始、具體過程以及結(jié)束，該標識就是前文中提到的 Span ID。對于每個 Span 來說，它必須有開始和結(jié)束兩個節(jié)點，

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

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

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

4 總結(jié)

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

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

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

最新評論