作者@lingsamuel，API7.ai 云原生技術(shù)專家，Apache APISIX Committer。
作者@林志煌，API7.ai 技術(shù)工程師，Apache APISIX contributor。
服務(wù)網(wǎng)格是一種技術(shù)架構(gòu)，它用于管理微服務(wù)系統(tǒng)中各個服務(wù)之間的通信，旨在處理微服務(wù)間的流量（也稱為東西向流量）。
在云原生應(yīng)用中，一個應(yīng)用的背后可能存在著成百上千個服務(wù)，各個服務(wù)可能又有著若干個實(shí)例，各個實(shí)例的狀態(tài)也一直在變化。在如此復(fù)雜的服務(wù)運(yùn)行環(huán)境中，如何保障用戶的可靠訪問以及維持業(yè)務(wù)的平穩(wěn)運(yùn)行成為一個很大的挑戰(zhàn)，服務(wù)網(wǎng)格的治理方案便應(yīng)運(yùn)而生。
服務(wù)網(wǎng)格就像是微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)間的網(wǎng)絡(luò)調(diào)用、限流限速、監(jiān)控等。服務(wù)網(wǎng)格目前主要應(yīng)用在 Kubernetes 平臺上，其最經(jīng)典的一種實(shí)現(xiàn)模式是 Sidecar 模式：將一些通用功能抽象到 Sidecar 容器中，并將 Sidecar 容器與服務(wù)容器掛載在同一個 Pod 里。由于 Sidecar 容器與服務(wù)容器并行，且各個 Sidecar 間相互通訊，共同構(gòu)成了網(wǎng)格形式的網(wǎng)絡(luò)，因此稱之為服務(wù)網(wǎng)格。當(dāng)然，Sidecar 并非唯一的一種服務(wù)網(wǎng)格實(shí)現(xiàn)模式，除此之外還有 DaemonSet 模式及 Ambient mesh 模式。
為什么需要服務(wù)網(wǎng)格？
在服務(wù)網(wǎng)格流行之前，很多微服務(wù)架構(gòu)的服務(wù)治理都是通過微服務(wù)框架配合控制平臺實(shí)現(xiàn)的，這種方式存在以下幾個問題：
- 框架與業(yè)務(wù)耦合，整體復(fù)雜度與運(yùn)維難度很高，且開發(fā)者需要對公共庫有一定的了解，沒法只專注于業(yè)務(wù)實(shí)現(xiàn)。
- 需要維護(hù)多種語言版本的框架，增加了維護(hù)的成本。
- 微服務(wù)框架本身的升級成本比較高，在升級時(shí)往往需要進(jìn)行業(yè)務(wù)重啟等操作。
- 線上存在很多版本的框架，會導(dǎo)致復(fù)雜的兼容性考慮。
面對以上這些問題，原 Twitter 工程師 Willian Morgan 提出了 Service Mesh 的概念，即服務(wù)網(wǎng)格。服務(wù)網(wǎng)格通過 Sidecar 模式實(shí)現(xiàn)在不侵入業(yè)務(wù)服務(wù)的情況下將基礎(chǔ)設(shè)施與業(yè)務(wù)邏輯解耦，實(shí)現(xiàn)跨語言統(tǒng)一更新發(fā)布及運(yùn)維。
服務(wù)網(wǎng)格將流量管理、可觀測性和安全通訊等功能下沉到基礎(chǔ)組件，因此開發(fā)者無需關(guān)心通信層和服務(wù)治理的具體實(shí)現(xiàn)，與通信相關(guān)的一切工作直接交給服務(wù)網(wǎng)格，讓開發(fā)者能夠更關(guān)注于業(yè)務(wù)的開發(fā)?；诜?wù)網(wǎng)格的這些特點(diǎn)，前面提到的幾個問題都能夠得到有效解決。
服務(wù)網(wǎng)格是如何工作的？
服務(wù)網(wǎng)格不會為應(yīng)用的運(yùn)行時(shí)環(huán)境加入新功能，任何架構(gòu)中的應(yīng)用還是需要相應(yīng)的規(guī)則來指定請求如何從 A 點(diǎn)到達(dá) B 點(diǎn)。但服務(wù)網(wǎng)格的不同之處在于，它從各個服務(wù)中提取邏輯管理的服務(wù)間通信，并將其抽象為一個基礎(chǔ)架構(gòu)層。
目前服務(wù)網(wǎng)格大多數(shù)采用是數(shù)據(jù)面 + 控制面的架構(gòu)模式，如下圖所示：
其中控制面用于管理和配置數(shù)據(jù)面以及在運(yùn)行時(shí)執(zhí)行策略。單個網(wǎng)格中控制平面的所有實(shí)例共享相同的配置資源。主要聚焦于安全、可觀測性、流量管控等策略的處理和下發(fā)，同時(shí)還能夠收集和集中數(shù)據(jù)平面的遙測數(shù)據(jù)，供運(yùn)維人員使用。
而數(shù)據(jù)面通常以代理的形式實(shí)現(xiàn)，是由一個個的網(wǎng)絡(luò)代理 Sidecar 組成，Sidecar 與業(yè)務(wù)應(yīng)用實(shí)例并行，通過攔截業(yè)務(wù)數(shù)據(jù)流以管控業(yè)務(wù)應(yīng)用的流量。
在前面的介紹中有提到服務(wù)網(wǎng)格是將 Sidecar 設(shè)計(jì)模式在 Kubernetes 進(jìn)行實(shí)現(xiàn)，通過容器化的方式實(shí)現(xiàn)了封裝，Sidecar 主張以額外的容器來擴(kuò)展或增強(qiáng)主容器，這個額外的容器被稱為 Sidecar 容器，它與業(yè)務(wù)容器在同一個 Pod 中。而服務(wù)網(wǎng)格即是一個個 Sidecar 代理所構(gòu)成的網(wǎng)格式網(wǎng)絡(luò)。
服務(wù)網(wǎng)格的實(shí)際應(yīng)用
在微服務(wù)架構(gòu)中，工程師往往會為對外暴露的服務(wù)采取加密或訪問限制的措施以保障服務(wù)的安全，但卻忽視了集群內(nèi)部的流量通信安全，所以至今仍有很多微服務(wù)應(yīng)用沒有采取服務(wù)間通信的加密措施，集群內(nèi)部的流量以明文的形式進(jìn)行傳輸，非常容易導(dǎo)致內(nèi)部流量遭到數(shù)據(jù)竊聽或是中間人攻擊。
而為了防止集群內(nèi)部流量遭到攻擊，通常會使用 mTLS 將通訊數(shù)據(jù)進(jìn)行加密。mTLS 可以用于確保服務(wù)網(wǎng)格中微服務(wù)之間的通信安全。它使用加密安全技術(shù)相互認(rèn)證各個微服務(wù)并加密它們之間的流量。
雖然可以直接在微服務(wù)中定義通信安全策略并執(zhí)行身份驗(yàn)證和加密，但在每一個微服務(wù)中去單獨(dú)實(shí)現(xiàn)相同的功能效率是很低的。而且增加功能還需要改動業(yè)務(wù)代碼，侵入業(yè)務(wù)邏輯。且即便完成了功能，后期的升級迭代與測試都需要開發(fā)者投入額外精力去維護(hù)，無法專注于業(yè)務(wù)功能的開發(fā)。
而使用服務(wù)網(wǎng)格，我們就可以在不影響原本業(yè)務(wù)的情況下零感知的為服務(wù)提供 mTLS 通信。因?yàn)樵诜?wù)網(wǎng)格中，服務(wù)通信相關(guān)的功能都被轉(zhuǎn)移至 Sidecar 代理中實(shí)現(xiàn)。在整個實(shí)現(xiàn)過程中，業(yè)務(wù)應(yīng)用都不會受到影響，降低開發(fā)者心智負(fù)擔(dān)。
當(dāng)然，服務(wù)網(wǎng)格除了可以實(shí)現(xiàn)類似 mTLS 這類的內(nèi)部流量安全配置功能，通過調(diào)整控制面的配置還能快速的拓展包括流量管控，可觀測性，協(xié)議編解碼等更多功能。
更優(yōu)的服務(wù)網(wǎng)格方案？
雖然服務(wù)網(wǎng)格解決了很多微服務(wù)架構(gòu)中的痛點(diǎn)，但它也同時(shí)有自己的局限性，在軟件開發(fā)中復(fù)雜度是不滅的，只是在不同的部分之間做轉(zhuǎn)移。我們將服務(wù)治理抽離為單獨(dú)的一層就要面對流量鏈路的增長以及運(yùn)維難度的提升，且服務(wù)網(wǎng)格需要在云原生的環(huán)境中使用，這對于運(yùn)維的專業(yè)能力及工程實(shí)踐經(jīng)驗(yàn)有了更高的要求。所以說技術(shù)只是用于解決問題的工具，服務(wù)網(wǎng)格能帶來的價(jià)值還是得從應(yīng)用的從實(shí)際情況出發(fā)。
作為 Apache 軟件基金會的頂級項(xiàng)目，Apache APISIX 是一個動態(tài)、實(shí)時(shí)、高性能的云原生 API 網(wǎng)關(guān)，提供負(fù)載均衡、動態(tài)上游、灰度發(fā)布、服務(wù)熔斷、身份認(rèn)證、可觀測性等豐富的流量管理功能。在基于 APISIX 的擴(kuò)展道路上，除了 APISIX Ingress 在云原生領(lǐng)域被各大廠商開始關(guān)注外，基于 APISIX 的服務(wù)網(wǎng)格方案也在積極迭代中。
基于 APISIX 的服務(wù)網(wǎng)格方案——Amesh
Amesh 是 Apache APISIX 的服務(wù)網(wǎng)格庫。它適配了 xDS 協(xié)議，可以從諸如 Istio 的控制平面中接收數(shù)據(jù)，并生成 APISIX 所需的數(shù)據(jù)結(jié)構(gòu)，使得 APISIX 能夠在服務(wù)網(wǎng)格領(lǐng)域作為數(shù)據(jù)面發(fā)揮作用。
依靠 Amesh，APISIX 可以工作在服務(wù)網(wǎng)格模式下，不使用傳統(tǒng)的 etcd 作為數(shù)據(jù)中心，而是使用 shdict 與 Amesh 庫直接進(jìn)行數(shù)據(jù)交換，避免了額外的性能損耗，使得大規(guī)模部署成為可能。
通過使用 Amesh，可以在服務(wù)網(wǎng)格領(lǐng)域獲得 APISIX 具備的高性能、豐富的流量管理功能、易擴(kuò)展性等多種優(yōu)勢。
Amesh 通過適配 xDS 協(xié)議，可以讓 APISIX 替代 Istio 所使用的 Envoy 組件來接管集群流量。在實(shí)際使用中，APISIX 將作為 Pod 的 Sidecar 接管網(wǎng)格內(nèi)的所有流量。目前 Amesh 的架構(gòu)如下圖所示：
通過架構(gòu)圖可以看到，通過 xDS 協(xié)議，Amesh 可以將 Istio 作為控制面，從 Istio 側(cè)獲取配置信息，并將其轉(zhuǎn)義為 APISIX 所需的配置。
而網(wǎng)格內(nèi)部的所有流量都將由 APISIX 接管。其中，APISIX 的配置中心被設(shè)置為 Amesh，這使得 APISIX 脫離 etcd 的依賴。Amesh 為 APISIX 提供了一種從 xDS 協(xié)議中獲取配置信息的方式。
此外，Amesh 在 v0.2 中提供了額外的可選控制面組件：amesh-controller。Amesh Controller 增加了 Amesh 專用的 CRD，可以為 APISIX 配置一些 Istio 所不支持的額外功能。額外帶有 amesh-controller 的架構(gòu)如下圖所示：
正如前文所提到的，Amesh Controller 是可選組件。在未安裝時(shí)，Amesh 也能正常使用 Istio 的原生能力提供服務(wù)。在安裝了 amesh-controller 后，Amesh 能自動檢測到控制面的加入，并動態(tài)地從中獲取配置，而無需重啟。
Amesh controller 為 Amesh 提供了 Istio 無法提供的 APISIX 特有功能。例如在安裝 amesh-controller 后，用戶能為服務(wù)配置 APISIX 原生具備的海量插件，使 APISIX 眾多的插件在服務(wù)網(wǎng)格場景下也能開箱即用，而無需用戶進(jìn)行自定義的開發(fā)。
Amesh 發(fā)展?fàn)顟B(tài)
目前 Amesh 項(xiàng)目正在積極開發(fā)中。在最近發(fā)布的的 v0.2 版本中，Amesh 新增了可選的控制面 amesh-controller 組件，為 Amesh 提供了 APISIX 所支持的強(qiáng)大的插件系統(tǒng)，大大增強(qiáng)了 Amesh 的可擴(kuò)展性。
擴(kuò)展能力
在使用 Amesh 時(shí)，如果是常規(guī)的 Istio 部署，用戶則可以通過 Lua 或 Wasm 來對 Envoy 進(jìn)行功能擴(kuò)展。
與 Envoy 原生能力相比，APISIX 官方即支持插件擴(kuò)展能力，維護(hù)了 80+ 的插件可供用戶使用，許多功能已經(jīng)原生集成。但由于在 Istio 中，不能對這些插件進(jìn)行配置，無法直接使用這些插件所提供的能力。
為此，Amesh v2.0 版本新增了一個控制面組件，即前文提到的 amesh-controller。它為用戶提供了配置 APISIX 插件的能力，使 APISIX 眾多的插件在服務(wù)網(wǎng)格場景下也能開箱即用，而無需用戶進(jìn)行自定義的開發(fā)。
應(yīng)用示例
在 Amesh v0.2 版本中，可以通過安裝 amesh-controller 并使用提供的 AmeshPluginConfig CRD 來進(jìn)行 APISIX 的插件配置。
例如，我們可以為請求的響應(yīng)添加特定的 header，這里可以通過配置 APISIX 的 response-rewrite 插件實(shí)現(xiàn)。
假設(shè)我們需要添加的 header 為 X-Header，其值為 AddedHeader，我們可以配置如下的 AmeshPluginConfig，此時(shí)請求的響應(yīng)中就會帶上我們所需的 header。
apiVersion: apisix.apache.org/v1alpha1
kind: AmeshPluginConfig
metadata:
name: ampc-sample
spec:
plugins:
- name: response-rewrite
config: '{"headers": {"X-Header":"AddedHeader"}}'
總結(jié)
隨著云原生的爆炸式發(fā)展及服務(wù)網(wǎng)格的不斷優(yōu)化，未來的服務(wù)網(wǎng)格可能會完全取代傳統(tǒng)微服務(wù)架構(gòu)，成為各個企業(yè)微服務(wù)及云原生改造的首選架構(gòu)。雖然現(xiàn)在各種方案都還不太完善，但整體都屬于螺旋上升的狀態(tài)。當(dāng)然，基于 APISIX 的服務(wù)網(wǎng)格也正朝著大家心目中的理想型服務(wù)網(wǎng)格解決方案奮進(jìn)，也歡迎各位對 APISIX 服務(wù)網(wǎng)格方案感興趣的朋友們進(jìn)行嘗鮮。
