Aeraki [Air-rah-ki] 是希臘語中“微風”的意思。雖然 Istio 在服務網格中連接微服務，但 Aeraki 提供了一個框架，允許 Istio 支持更多的第 7 層協議，而不僅僅是 HTTP 和 gRPC。我們希望這股"微風"可以幫助 Istio 更進一步。
Service Mesh 缺乏協議支持
我們現在面臨著服務網格的一些挑戰(zhàn)：
-
Istio 和其他流行的服務網格實現對除 HTTP 和 gRPC 之外的第 7 層協議的支持非常有限。
-
Envoy RDS（Route Discovery Service）專為 HTTP 設計。其他協議如 Dubbo 和 Thrift 只能使用監(jiān)聽器內聯路由進行流量管理，當路由發(fā)生變化時會中斷現有連接。
-
將專有協議引入服務網格需要付出很多努力。您需要編寫一個 Envoy 過濾器來處理數據平面中的流量，以及一個控制平面來管理這些 Envoy。
這些障礙使用戶很難（如果不是不可能的話）管理微服務中其他廣泛使用的第 7 層協議的流量。例如，在微服務應用程序中，我們可能有以下協議：
-
RPC：HTTP、gRPC、Thrift、Dubbo、專有 RPC 協議……
-
消息傳遞：Kafka、RabbitMQ …
-
緩存：Redis、Memcached……
-
數據庫：MySQL、PostgreSQL、MongoDB……
微服務中常用的第 7 層協議
如果您已經在遷移到服務網格方面投入了大量精力，那么您當然希望充分利用它——管理微服務中所有協議的流量。
Aeraki 的方法
為了解決這些問題，我們創(chuàng)建了一個開源項目Aeraki Mesh，以提供一種非侵入式、可擴展的方式來管理 Istio 服務網格中的任何第 7 層流量。
艾拉基建筑
如圖所示，Aeraki 框架由以下組件組成：
-
Aeraki：Aeraki為操作提供高級、用戶友好的流量管理規(guī)則，將規(guī)則轉換為 envoy 過濾器配置，并利用 Istio 的EnvoyFilterAPI 將配置推送到 sidecar 代理。Aeraki 還充當數據平面中 MetaProtocol 代理的 RDS 服務器。與專注于 HTTP 的 Envoy RDS 不同，Aeraki RDS 旨在為所有第 7 層協議提供通用的動態(tài)路由能力。
-
MetaProtocol Proxy：MetaProtocol Proxy為第 7 層協議提供常用功能，例如負載均衡、斷路器、負載均衡、路由、速率限制、故障注入和身份驗證。第 7 層協議可以構建在 MetaProtocol 之上。要將新協議添加到服務網格中，您唯一需要做的就是實現編解碼器接口和幾行配置。如果您有內置能力無法滿足的特殊需求，MetaProtocol Proxy 還具有應用級過濾器鏈機制，允許用戶編寫自己的第 7 層過濾器，將自定義邏輯添加到 MetaProtocol Proxy 中。
Dubbo和Thrift已經基于 MetaProtocol 實現。更多協議正在開發(fā)中。如果您使用的是閉源專有協議，您還可以通過為其編寫 MetaProtocol 編解碼器在您的服務網格中對其進行管理。
大多數請求/響應風格的無狀態(tài)協議都可以構建在 MetaProtocol 代理之上。但是，有些協議的路由策略過于“特殊”，無法在 MetaProtocol 中進行規(guī)范化。例如，Redis 代理使用槽號將客戶端查詢映射到特定的 Redis 服務器節(jié)點，槽號由請求中的 key 計算得出。只要 Envoy 代理端有可用的 Envoy 過濾器，Aeraki 仍然可以管理這些協議。目前，對于該類別的協議，Aeraki 支持Redis和 Kafka。
元協議代理
深入研究元協議
讓我們看看 MetaProtocol 是如何工作的。在引入 MetaProtocol 之前，如果我們想為特定協議代理流量，我們需要編寫一個理解該協議的 Envoy 過濾器并添加代碼來操作流量，包括路由、頭部修改、故障注入、流量鏡像等。
對于大多數請求/響應風格的協議，流量操作的代碼非常相似。因此，為了避免在不同的 Envoy 過濾器中重復這些功能，Aeraki 框架在一個地方（MetaProtocol 代理過濾器）實現了第 7 層協議代理的大部分常見功能。
這種方法顯著降低了編寫新的 Envoy 過濾器的障礙：現在您只需要實現編解碼器接口，而不是編寫功能齊全的過濾器。除此之外，控制平面已經到位——Aeraki 在控制平面上工作，為基于 MetaProtocol 構建的所有協議提供 MetaProtocol 配置和動態(tài)路由。
在 MetProtocol 之前和之后編寫 Envoy 過濾器
MetaProtocol Proxy 中有兩個重要的數據結構：Metadata 和 Mutation。元數據用于路由，而 Mutation 用于標頭操作。
在請求路徑上，解碼器（編解碼器實現的解碼方法）使用從請求中解析的鍵值對填充元數據數據結構，然后將元數據傳遞給元協議路由器。路由器在匹配它通過 RDS 和元數據從 Aeraki 接收到的路由配置后，選擇適當的上游集群。
如果需要修改請求，自定義過濾器可以使用任意鍵值對填充 Mutation 數據結構：添加標頭或更改標頭的值。然后將 Mutation 數據結構傳遞給編碼器（編解碼器實現的 encode 方法）。編碼器負責將鍵值對寫入有線協議。
請求路徑
響應路徑與請求路徑類似，只是方向不同。
響應路徑
一個例子
如果需要實現基于 MetaProtocol 的應用協議，可以按照以下步驟進行（以 Thrift 為例）：
數據平面
-
實現編解碼器接口對協議包進行編碼和解碼。您可以參考Dubbo 編解碼器和Thrift 編解碼器編寫自己的實現。
-
使用 Aeraki ApplicationProtocolCRD 定義協議，如下 YAML 片段所示：
控制平面
您不需要實現控制平面。Aeraki 監(jiān)視服務和流量規(guī)則，為 Sidecar 代理生成配置，并通過EnvoyFilterMetaProtocol RDS 將配置發(fā)送到數據平面。
協議選擇
與 Istio 類似，協議由服務端口前綴標識。請使用以下模式命名服務端口：tcp-metaprotocol-{應用程序協議}-xxx。例如，Thrift 服務端口應命名為 tcp-metaprotocol-thrift。
交通管理
MetaRouter您可以通過CRD更改路線。例如：將 20% 的請求發(fā)送到 v1，將 80% 的請求發(fā)送到 v2：
參考
-
Aeraki Mesh 網站
-
GitHub 上的 Aeraki 網格
-
現場演示：Kiali 儀表板
-
現場演示：服務指標：Grafana
-
現場演示：服務指標：Prometheus
-
Istio meetup China（中文）：全棧服務網格 - 使用 Aeraki 管理 Istio 服務網格中的任何第 7 層流量
-
IstioCon 2021：如何管理 Istio 服務網格中的任何第 7 層流量？
原文作者：趙華冰 - 騰訊
-----------------------------------------------------------
href="/"
樂魚創(chuàng)新
-
全國領先的一站式廠商，國家高新技術企業(yè)
-
上汽、格力、華為、中信銀行等各行業(yè)頭部企業(yè)信賴
-
阿里云戰(zhàn)略投資企業(yè)
樂魚創(chuàng)新是云原生領域的佼佼者，其產品在廣西貴港智慧城市、長三角產學研一體化創(chuàng)新平臺、海爾工業(yè)互聯網、中信銀行核心系統建設等項目中起到關鍵的支撐作用。同時，作為信創(chuàng)工委會成員，行云打造業(yè)界領先的“信創(chuàng)與非信創(chuàng)統管、一鍵向信創(chuàng)遷移”的方案，并在某大型國有銀行取得了良好的實踐效果。
SolarMesh，高效可視化平臺
基于 Istio 及容器技術，提供流量監(jiān)控和管理，提供完善的非侵入式服務治理解決方案。幫助企業(yè)在紛繁復雜的微服務調度中快速定位問題，增強研發(fā)效率。
SolarMesh，讓服務網格不再難學難用，讓服務網格在企業(yè)落地更加平滑、安全、穩(wěn)定。
SolarMesh在線體驗地址>
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數字化創(chuàng)新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務Methodot
