這篇文章將我所了解到的解決“服務(wù)調(diào)用”相關(guān)的技術(shù)演進(jìn)歷史簡(jiǎn)述一下，純粹一篇科普文。

[[270557]]

圖片來(lái)自 Pexels

本文專注于演化過(guò)程中每一步的為什么(Why)和是什么(What)上面，盡量不在技術(shù)細(xì)節(jié)(How)上面做太多深入。

服務(wù)的三要素

一般而言，一個(gè)網(wǎng)絡(luò)服務(wù)包括以下的三個(gè)要素：

• 地址：調(diào)用方根據(jù)地址訪問(wèn)到網(wǎng)絡(luò)接口。地址包括以下要素：IP地址、服務(wù)端口、服務(wù)協(xié)議(TCP、UDP，etc)。
• 協(xié)議格式：指的是該協(xié)議都有哪些字段，由接口提供者與協(xié)議調(diào)用者協(xié)商之后確定下來(lái)。
• 協(xié)議名稱：或者叫協(xié)議類型，因?yàn)樵谕粋€(gè)服務(wù)監(jiān)聽(tīng)端口上面，可能同時(shí)提供多種接口服務(wù)于調(diào)用方，這時(shí)候需要協(xié)議類型(名稱)來(lái)區(qū)分不同的網(wǎng)絡(luò)接口。

需要說(shuō)明在服務(wù)地址中：

• IP 地址提供了在互聯(lián)網(wǎng)上找到這臺(tái)機(jī)器的憑證。
• 協(xié)議以及服務(wù)端口提供了在這臺(tái)機(jī)器上找到提供服務(wù)的進(jìn)程的憑證。

這都屬于 TCP/IP 協(xié)議棧的知識(shí)點(diǎn)，不在這里深入詳述。這里還需要對(duì)涉及到服務(wù)相關(guān)的一些名詞做解釋：

• 服務(wù)實(shí)例：服務(wù)對(duì)應(yīng)的 IP 地址加端口的簡(jiǎn)稱。需要訪問(wèn)服務(wù)的時(shí)候，需要先尋址知道該服務(wù)每個(gè)運(yùn)行實(shí)例的地址加端口，然后才能建立連接進(jìn)行訪問(wèn)。
• 服務(wù)注冊(cè)：某個(gè)服務(wù)實(shí)例宣稱自己提供了哪些服務(wù)，即某個(gè) IP 地址+端口都提供了哪些服務(wù)接口。
• 服務(wù)發(fā)現(xiàn)：調(diào)用方通過(guò)某種方式找到服務(wù)提供方，即知道服務(wù)運(yùn)行的 IP 地址加端口。

基于 IP 地址的調(diào)用

最初的網(wǎng)絡(luò)服務(wù)，通過(guò)原始的 IP 地址暴露給調(diào)用者。這種方式有以下的問(wèn)題：

• IP 地址是難于記憶并且無(wú)意義的。
• 另外，從上面的服務(wù)三要素可以看到，IP 地址其實(shí)是一個(gè)很底層的概念，直接對(duì)應(yīng)了一臺(tái)機(jī)器上的一個(gè)網(wǎng)絡(luò)接口，如果直接使用IP地址進(jìn)行尋址，更換機(jī)器就變的很麻煩。

“盡量不使用過(guò)于底層的概念來(lái)提供服務(wù)”，是這個(gè)演化流程中的重要原則，好比在今天已經(jīng)很少能夠看到直接用匯編語(yǔ)言編寫代碼的場(chǎng)景了。

取而代之的，就是越來(lái)越多的抽象，本文中就展現(xiàn)了服務(wù)調(diào)用這一領(lǐng)域在這個(gè)過(guò)程中的演進(jìn)流程。

在現(xiàn)在除非是測(cè)試階段，否則已經(jīng)不能直接以 IP 地址的形式將服務(wù)提供出去了。

域名系統(tǒng)

前面的 IP 地址是給主機(jī)做為路由器尋址的數(shù)字型標(biāo)識(shí)，并不好記憶。

此時(shí)產(chǎn)生了域名系統(tǒng)，與單純提供 IP 地址相比，域名系統(tǒng)由于使用有意義的域名來(lái)標(biāo)識(shí)服務(wù)，所以更容易記憶。另外，還可以更改域名所對(duì)應(yīng)的 IP 地址，這為變換機(jī)器提供了便利。

有了域名之后，調(diào)用方需要訪問(wèn)某個(gè)網(wǎng)絡(luò)服務(wù)時(shí)，首先到域名地址服務(wù)中，根據(jù) DNS 協(xié)議將域名解析為相應(yīng)的 IP 地址，再根據(jù)返回的 IP 地址來(lái)訪問(wèn)服務(wù)。

從這里可以看到，由于多了一步到域名地址服務(wù)查詢映射 IP 地址的流程，所以多了一步解析，為了減少這一步帶來(lái)的影響，調(diào)用方會(huì)緩存解析之后的結(jié)果，在一段時(shí)間內(nèi)不過(guò)期，這樣就省去了這一步查詢的代價(jià)。

協(xié)議的接收與解析

以上通過(guò)域名系統(tǒng)，已經(jīng)解決了服務(wù) IP 地址難以記憶的問(wèn)題，下面來(lái)看協(xié)議格式解析方面的演進(jìn)。

一般而言，一個(gè)網(wǎng)絡(luò)協(xié)議包括兩部分：

• 協(xié)議包頭：這里存儲(chǔ)協(xié)議的元信息(meta infomation)，其中可能會(huì)包括協(xié)議類型、報(bào)體長(zhǎng)度、協(xié)議格式等。

需要說(shuō)明的是，包頭一般為固定大小，或者有明確的邊界(如 HTTP 協(xié)議中的 \r\n 結(jié)束符)，否則無(wú)法知道包頭何時(shí)結(jié)束。

• 協(xié)議包體：具體的協(xié)議內(nèi)容。

無(wú)論是 HTTP 協(xié)議，又或者是自定義的二進(jìn)制網(wǎng)絡(luò)協(xié)議，大體都由這兩部分組成。

由于很多時(shí)候不能一口氣接收完畢客戶端的協(xié)議數(shù)據(jù)，因此在接收協(xié)議數(shù)據(jù)時(shí)，一般采用狀態(tài)機(jī)來(lái)做協(xié)議數(shù)據(jù)的接收：

接收完畢了網(wǎng)絡(luò)數(shù)據(jù)，在協(xié)議解析方面卻長(zhǎng)期停滯不前。一個(gè)協(xié)議，有多個(gè)字段(field)，而這些不同的字段有不同的類型，簡(jiǎn)單的 raw 類型(如整型、字符串)還好說(shuō)，但是遇到復(fù)雜的類型如字典、數(shù)組等就比較麻煩。

當(dāng)時(shí)常見(jiàn)的手段有以下幾種：

• 使用 json 或者 xml 這樣的數(shù)據(jù)格式。好處是可視性強(qiáng)，表達(dá)起上面的復(fù)雜類型也方便，缺陷是容易被破解，傳輸過(guò)去的數(shù)據(jù)較大。
• 自定義二進(jìn)制協(xié)議。每個(gè)公司做大了，在這一塊難免有幾個(gè)類似的輪子。筆者見(jiàn)過(guò)比較典型的是所謂的 TLV 格式(Type-Length-Value)。

自定義二進(jìn)制格式最大的問(wèn)題出現(xiàn)在協(xié)議聯(lián)調(diào)與協(xié)商的時(shí)候，由于可視性比較弱，有可能這邊少了一個(gè)字段那邊多了一個(gè)字段，給聯(lián)調(diào)流程帶來(lái)麻煩。

上面的問(wèn)題一直到 Google 的 Protocol Buffer(以下簡(jiǎn)稱 PB)出現(xiàn)之后才得到很大的改善。

PB 出現(xiàn)之后，也有很多類似的技術(shù)出現(xiàn)，如 Thrift、MsgPack 等，不在這里闡述，將這一類技術(shù)都以 PB 來(lái)描述。

與前面的兩種手段相比，PB 具有以下的優(yōu)點(diǎn)：

• 使用 proto 格式文件來(lái)定義協(xié)議格式，proto 文件是一個(gè)典型的 DSL(domain-specific language)文件，文件中描述了協(xié)議的具體格式，每個(gè)字段都是什么類型，哪些是可選字段哪些是必選字段。

有了 proto 文件之后，C\S 兩端是通過(guò)這個(gè)文件來(lái)進(jìn)行協(xié)議的溝通交流的，而不是具體的技術(shù)細(xì)節(jié)。

• PB 能通過(guò) proto 文件生成各種語(yǔ)言對(duì)應(yīng)的序列化反序列化代碼，給跨語(yǔ)言調(diào)用提供了方便。
• PB 自己能夠?qū)μ囟愋瓦M(jìn)行數(shù)據(jù)壓縮，減少數(shù)據(jù)大小。

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

有了前面的演化之后，寫一個(gè)簡(jiǎn)單的單機(jī)服務(wù)器已經(jīng)不難。然而，當(dāng)隨著訪問(wèn)量的增大，一臺(tái)機(jī)器已經(jīng)不足以支撐所有的請(qǐng)求，此時(shí)就需要橫向擴(kuò)展多加一些業(yè)務(wù)服務(wù)器。

而前面通過(guò)域名訪問(wèn)服務(wù)的架構(gòu)就遇到了問(wèn)題：如果有多個(gè)服務(wù)實(shí)例可以提供相同的服務(wù)，那么勢(shì)必需要在 DNS 的域名解析中將域名與多個(gè)地址進(jìn)行綁定。

這樣的方案就有如下的問(wèn)題：

• 如何檢查這些實(shí)例的健康情況，同時(shí)在發(fā)現(xiàn)出現(xiàn)問(wèn)題的時(shí)候增刪服務(wù)實(shí)例地址?即所謂的服務(wù)高可用問(wèn)題。
• 把這些服務(wù)實(shí)例地址都暴露到外網(wǎng)，會(huì)不會(huì)涉及到安全問(wèn)題?即使可以解決安全問(wèn)題，那么也需要每臺(tái)機(jī)器都做安全策略。
• 由于 DNS 協(xié)議的特點(diǎn)，增刪服務(wù)實(shí)例并不是實(shí)時(shí)的，有時(shí)候會(huì)影響到業(yè)務(wù)。

為了解決這些問(wèn)題，就引入了反向代理網(wǎng)關(guān)這一組件。它提供如下的功能：

• 負(fù)載均衡功能：根據(jù)某些算法將請(qǐng)求分派到服務(wù)實(shí)例上。
• 提供管理功能：可以給運(yùn)維管理員增減服務(wù)實(shí)例。
• 由于它決定了服務(wù)請(qǐng)求流量的走向，因此還可以做更多的其他功能：灰度引流、安全防攻擊(如訪問(wèn)黑白名單、卸載 SSL 證書(shū))等。

有四層和七層負(fù)載均衡軟件，其中四層負(fù)載均衡這里介紹 LVS，七層負(fù)載均衡介紹 Nginx。

上圖是簡(jiǎn)易的 TCP/IP 協(xié)議棧層次圖，其中 LVS 工作在四層，即請(qǐng)求來(lái)到 LVS 這里時(shí)是根據(jù)四層協(xié)議來(lái)決定請(qǐng)求最終走到哪個(gè)服務(wù)實(shí)例。

而 Nginx 工作在七層，主要用于 HTTP 協(xié)議，即根據(jù) HTTP 協(xié)議本身來(lái)決定請(qǐng)求的走向。

需要說(shuō)明的是，Nginx 也可以工作在四層，但是這么用的地方不是很多，可以參考 Nginx 的 Stream 模塊。

做為四層負(fù)載均衡的 LVS

由于 LVS 有好幾種工作模式，并不是每一種我都很清楚，以下表述僅針對(duì) Full NAT 模式，下面的表述或者有誤。

LVS 有如下的組成部分：

• Direct Server(以下簡(jiǎn)稱 DS)：前端暴露給客戶端進(jìn)行負(fù)載均衡的服務(wù)器。
• Virtual IP 地址(以下簡(jiǎn)稱 VIP)：DS 暴露出去的 IP 地址，做為客戶端請(qǐng)求的地址。
• Direct IP 地址(以下簡(jiǎn)稱 DIP)：DS 用于與 Real Server 交互的 IP 地址。
• Real Server(以下簡(jiǎn)稱 RS)：后端真正進(jìn)行工作的服務(wù)器，可以橫向擴(kuò)展。
• Real IP 地址(以下簡(jiǎn)稱 RIP)：RS 的地址。
• Client IP 地址(以下簡(jiǎn)稱 CIP)：Client 的地址。

客戶端進(jìn)行請(qǐng)求時(shí)，流程如下：

• 使用 VIP 地址訪問(wèn) DS，此時(shí)的地址二元組為< src:CIP,DST:VIP >。
• DS 根據(jù)自己的負(fù)載均衡算法，選擇一個(gè) RS 將請(qǐng)求轉(zhuǎn)發(fā)過(guò)去，在轉(zhuǎn)發(fā)過(guò)去的時(shí)候，修改請(qǐng)求的源 IP 地址為 DIP 地址，讓 RS 看上去認(rèn)為是 DS 在訪問(wèn)它，此時(shí)的地址二元組為
• RS 處理并且應(yīng)答該請(qǐng)求，這個(gè)回報(bào)的源地址為 RS 的 RIP 地址，目的地址為 DIP 地址，此時(shí)的地址二元組為 。
• DS 在收到該應(yīng)答包之后，將報(bào)文應(yīng)答客戶端，此時(shí)修改應(yīng)答報(bào)文的源地址為 VIP 地址，目的地址為 CIP 地址，此時(shí)的地址二元組為

做為七層負(fù)載均衡的 Nginx

在開(kāi)始展開(kāi)討論之前，需要簡(jiǎn)單說(shuō)一下正向代理和反向代理。

所謂的正向代理(proxy)，我的理解就是在客戶端處的代理。如瀏覽器中的可以配置的訪問(wèn)某些網(wǎng)站的代理，就屬于正向代理，但是一般而言不會(huì)說(shuō)正向代理而是代理，即默認(rèn)代理都是正向的。

而反向代理(reverse proxy)，就是擋在服務(wù)器端前面的代理，比如前面 LVS 中的 DS 服務(wù)器就屬于一種反向代理。

為什么需要反向代理，大體的原因有以下的考量：

• 負(fù)載均衡：希望在這個(gè)反向代理的服務(wù)器中，將請(qǐng)求均衡的分發(fā)到后面的服務(wù)器中。
• 安全：不想向客戶端暴露太多的服務(wù)器地址，統(tǒng)一接入到這個(gè)反向代理服務(wù)器中，在這里做限流、安全控制等。
• 由于統(tǒng)一接入了客戶端的請(qǐng)求，所以在反向代理的接入層可以做更多的控制策略，比如灰度流量發(fā)布、權(quán)重控制等等。

反向代理與所謂的 Gateway、網(wǎng)關(guān)等，我認(rèn)為沒(méi)有太多的差異，只是叫法不同而已，做的事情都是類似的。

Nginx 應(yīng)該是現(xiàn)在用的最多的 HTTP 七層負(fù)載均衡軟件，在 Nginx 中，可以通過(guò)在配置的 Server 塊中定義一個(gè)域名，然后將該域名的請(qǐng)求綁定到對(duì)應(yīng)的 Upstream 中，而實(shí)現(xiàn)轉(zhuǎn)發(fā)請(qǐng)求到這些 Upstream 的效果。

如：

upstream hello { 
       server A:11001; 
       server B:11001; 
} 
location / { 
            root   html; 
            index  index.html index.htm; 
            proxy_pass http://hello; 
} 

這是最簡(jiǎn)單的 Nginx 反向代理配置，實(shí)際線上一個(gè)接入層背后可能有多個(gè)域名，如果配置變動(dòng)的很大，每次域名以及對(duì)應(yīng)的 Upstream 的配置修改都需要人工干預(yù)，效率會(huì)很慢。

這時(shí)候就要提到一個(gè)叫 DevOps 的名詞了，我的理解就是開(kāi)發(fā)各種便于自動(dòng)化運(yùn)維工具的工程師。

有了上面的分析，此時(shí)一個(gè)提供七層 HTTP 訪問(wèn)接口的服務(wù)架構(gòu)大體是這樣的：

服務(wù)發(fā)現(xiàn)與 RPC

前面已經(jīng)解決單機(jī)服務(wù)器對(duì)外提供服務(wù)的大部分問(wèn)題，來(lái)簡(jiǎn)單回顧：

• 域名系統(tǒng)解決了需要記住復(fù)雜的數(shù)字 IP 地址的問(wèn)題。
• PB 類軟件庫(kù)的出現(xiàn)解決協(xié)議定義解析的痛點(diǎn)。
• 網(wǎng)關(guān)類組件解決客戶端接入以及服務(wù)器橫向擴(kuò)展等一系列問(wèn)題。

然而一個(gè)服務(wù)，通常并不見(jiàn)得只由本身提供服務(wù)就可以，服務(wù)過(guò)程中可能還涉及到查詢其他服務(wù)的流程，常見(jiàn)的如數(shù)據(jù)類服務(wù)如 MySQL、Redis 等。

這一類供服務(wù)內(nèi)調(diào)用查詢的服務(wù)被稱為內(nèi)部的服務(wù)，通常并不直接暴露到外網(wǎng)去。

面向公網(wǎng)的服務(wù)，一般都是以域名的形式提供給外部調(diào)用者，然而對(duì)于服務(wù)內(nèi)部之間的互相調(diào)用，域名形式還不夠，其原因在于：

• DNS 服務(wù)發(fā)現(xiàn)的粒度太粗，只能到 IP 地址級(jí)別，而服務(wù)的端口還需要用戶自己維護(hù)。
• 對(duì)于服務(wù)的健康狀況的檢查，DNS 的檢查還不夠，需要運(yùn)維的參與。
• DNS 對(duì)于服務(wù)狀態(tài)的收集很欠缺，而服務(wù)狀態(tài)最終應(yīng)該是反過(guò)來(lái)影響服務(wù)被調(diào)用情況的。
• DNS 的變更需要人工的參與，不夠智能以及自動(dòng)化。

綜上，內(nèi)網(wǎng)間的服務(wù)調(diào)用，通常而言會(huì)自己實(shí)現(xiàn)一套“服務(wù)發(fā)現(xiàn)”類的系統(tǒng)，其包括以下幾個(gè)組件：

• 服務(wù)發(fā)現(xiàn)系統(tǒng)：用于提供服務(wù)的尋址、注冊(cè)能力，以及對(duì)服務(wù)狀態(tài)進(jìn)行統(tǒng)計(jì)匯總，根據(jù)服務(wù)情況更改服務(wù)的調(diào)用情況。

比如，某個(gè)服務(wù)實(shí)例的響應(yīng)慢了，此時(shí)分配給該實(shí)例的流量響應(yīng)的就會(huì)少一些。

而由于這個(gè)系統(tǒng)能提供服務(wù)的尋址能力，所以一些尋址策略就可以在這里做，比如灰度某些特定的流量只能到某些特定的實(shí)例上，比如可以配置每個(gè)實(shí)例的流量權(quán)重等。

• 一套與該服務(wù)系統(tǒng)搭配使用的 RPC 庫(kù)。

RPC 庫(kù)提供以下功能：

• 服務(wù)提供方：使用 RPC 庫(kù)注冊(cè)自己的服務(wù)到服務(wù)發(fā)現(xiàn)系統(tǒng)，另外上報(bào)自己的服務(wù)情況。
• 服務(wù)調(diào)用方：使用 RPC 庫(kù)進(jìn)行服務(wù)尋址，實(shí)時(shí)從服務(wù)發(fā)現(xiàn)系統(tǒng)那邊獲取最新的服務(wù)調(diào)度策略。
• 提供協(xié)議的序列化、反序列化功能，負(fù)載均衡的調(diào)用策略、熔斷限流等安全訪問(wèn)策略，這部分對(duì)于服務(wù)的提供方以及調(diào)用方都適用。

有了這套服務(wù)發(fā)現(xiàn)系統(tǒng)以及搭配使用的 RPC 庫(kù)之后，來(lái)看看現(xiàn)在的服務(wù)調(diào)用是什么樣的：

• 寫業(yè)務(wù)邏輯的，再也不用關(guān)注服務(wù)地址、協(xié)議解析、服務(wù)調(diào)度、自身服務(wù)情況上報(bào)等等與業(yè)務(wù)邏輯本身并沒(méi)有太多關(guān)系的工作，專注于業(yè)務(wù)邏輯即可。
• 服務(wù)發(fā)現(xiàn)系統(tǒng)一般還有與之搭配的管理后臺(tái)界面，可以通過(guò)這里對(duì)服務(wù)的策略進(jìn)行修改查看等操作。
• 對(duì)應(yīng)的還會(huì)有服務(wù)監(jiān)控系統(tǒng)，對(duì)應(yīng)的這是一臺(tái)實(shí)時(shí)采集服務(wù)數(shù)據(jù)進(jìn)行計(jì)算的系統(tǒng)，有了這套系統(tǒng)服務(wù)質(zhì)量如何一目了然。
• 服務(wù)健康狀態(tài)的檢查完全自動(dòng)化，在狀況不好的時(shí)候?qū)Ψ?wù)進(jìn)行降級(jí)處理，人工干預(yù)變少，更加智能以及自動(dòng)化。

現(xiàn)在服務(wù)的架構(gòu)又演進(jìn)成了這樣：

Service Mesh

架構(gòu)發(fā)展到上面的程度，實(shí)際上已經(jīng)能夠解決大部分的問(wèn)題了。這兩年又出現(xiàn)了一個(gè)很火的概念：Service Mesh，中文翻譯為“服務(wù)網(wǎng)格”，來(lái)看看它又能解決什么問(wèn)題。

前面的服務(wù)發(fā)現(xiàn)系統(tǒng)中，需要一個(gè)與之配套的 RPC 庫(kù)，然而這又會(huì)有如下的問(wèn)題：

• 如果需要支持多語(yǔ)言，該怎么做?每個(gè)語(yǔ)言實(shí)現(xiàn)一個(gè)對(duì)應(yīng)的 RPC 庫(kù)嗎?
• 庫(kù)的升級(jí)很麻煩，比如 RPC 庫(kù)本身出了安全漏洞，比如需要升級(jí)版本，一般推動(dòng)業(yè)務(wù)方去做這個(gè)升級(jí)是很難的，尤其是系統(tǒng)做大了之后。

可以看到，由于 RPC 庫(kù)是嵌入到進(jìn)程之中的組件，所以以上問(wèn)題很麻煩，于是就想出了一個(gè)辦法：將原先的一個(gè)進(jìn)程拆分成兩個(gè)進(jìn)程。

如下圖所示：

在服務(wù) Mesh 化之前，服務(wù)調(diào)用方實(shí)例通過(guò)自己內(nèi)部的 RPC 庫(kù)來(lái)與服務(wù)提供方實(shí)例進(jìn)行通信。

在服務(wù) Mesh 化之后，會(huì)與服務(wù)調(diào)用方同機(jī)部署一個(gè) Local Proxy 也就是 Service Mesh 的 Proxy。

此時(shí)服務(wù)調(diào)用的流量會(huì)先走到這個(gè) Proxy，再由它完成原先 RPC 庫(kù)響應(yīng)的工作。

至于如何實(shí)現(xiàn)這個(gè)流量的劫持，答案是采用 Iptables，將特定端口的流量轉(zhuǎn)發(fā)到 Proxy 上面即可。

有了這一層的分拆，將業(yè)務(wù)服務(wù)與負(fù)責(zé) RPC 庫(kù)作用的 Proxy 分開(kāi)來(lái)，上面的兩個(gè)痛點(diǎn)問(wèn)題就變成了對(duì)每臺(tái)物理機(jī)上面的 Mesh Proxy 的升級(jí)維護(hù)問(wèn)題。

多語(yǔ)言也不是問(wèn)題了，因?yàn)槎际峭ㄟ^(guò)網(wǎng)絡(luò)調(diào)用完成的 RPC 通信，而不是進(jìn)程內(nèi)使用 RPC 庫(kù)。

然而這個(gè)方案并不是什么問(wèn)題都沒(méi)有的，最大的問(wèn)題在于，多了這一層的調(diào)用之后，勢(shì)必有影響原來(lái)的響應(yīng)時(shí)間。

截止目前(2019 年 6 月)，Service Mesh 仍然還是一個(gè)概念大于實(shí)際的產(chǎn)品。

從上面的演進(jìn)歷史可以看到，所謂的“中間層理論”，即“Any problem in computer science can be solved by another layer of indirection(計(jì)算機(jī)科學(xué)領(lǐng)域的任何問(wèn)題都可以通過(guò)增加一個(gè)間接的中間層來(lái)解決)”在這個(gè)過(guò)程中被廣泛使用。

比如為了解決 IP 地址難于記憶的問(wèn)題，引入了域名系統(tǒng)，比如為了解決負(fù)載均衡問(wèn)題引入了網(wǎng)關(guān)，等等。

然而每引入一個(gè)中間層，勢(shì)必帶來(lái)另外的影響，比如 Service Mesh 多一次到 Proxy 的調(diào)用，如何權(quán)衡又是另外的問(wèn)題了。

另外，回到最開(kāi)始的服務(wù)三要素中，可以看到整個(gè)演化的歷史也是逐漸屏蔽了下層組件的流程，比如：

• 域名的出現(xiàn)屏蔽了 IP 地址。
• 服務(wù)發(fā)現(xiàn)系統(tǒng)屏蔽協(xié)議及端口號(hào)。
• PB 類序列化庫(kù)屏蔽了使用者自己對(duì)協(xié)議的解析。

可以看到，演進(jìn)流程讓業(yè)務(wù)開(kāi)發(fā)者更加專注在業(yè)務(wù)邏輯上，這類的演進(jìn)流程不只發(fā)生在今天，也不會(huì)僅僅發(fā)生在今天，未來(lái)類似的演進(jìn)也將再次發(fā)生。

作者：codedump

簡(jiǎn)介：多年從事互聯(lián)網(wǎng)服務(wù)器后臺(tái)開(kāi)發(fā)工作?？稍L問(wèn)作者博客：https://www.codedump.info/，閱讀更多文章。