微服務架構不是免費的午餐 ！ 微服務需要解耦，靈活，操作透明，數據感知和彈性。 過去幾年的大多數材料僅討論具有緊密耦合且不可擴展的技術（如REST / HTTP）的點對點體系結構。 這篇博客文章介紹了Apache Kafka，Kubernetes，Envoy，Linkerd和Istio等前沿技術，以實現云原生服務網格來解決這些挑戰，并將微服務提升到規模，速度和效率的新水平 。

以下是構建可伸縮，可靠，健壯和可觀察的微服務體系結構的關鍵要求：

在進一步詳細介紹之前，讓我們先看一下關鍵要點：

• Apache Kafka解耦服務 ，包括事件流和 請求-響應
• Kubernetes 為 Kafka生態系統提供云原生基礎架構
• Service Mesh在生態系統/組織范圍內幫助提高 安全性和可觀察性
• 特使和 伊斯托（Istio） 位于 卡夫卡（Kafka）之上，與卡夫卡（Kafka）所實現的目標正交

以下各節涵蓋了有關此問題的更多想法。 博客文章的末尾包含幻燈片和錄像帶，以獲取更多詳細說明。

微服務，服務網格和Apache Kafka

Apache Kafka成為事實上的微服務架構標準 。 它遠遠超出了可靠且可擴展的大容量消息傳遞。 分布式存儲允許獨立的微服務之間實現高可用性和真正的解耦。 此外，您可以利用Kafka Connect進行集成，并利用Kafka Streams API在自治團隊中構建輕量級流處理微服務。

服務網格對體系結構進行了補充 。 它描述了組成此類應用程序的微服務網絡及其之間的交互。 它的要求可以包括發現，負載平衡，故障恢復，指標和監視。 服務網格通常還具有更復雜的操作要求，例如A / B測試，金絲雀推出，速率限制，訪問控制和端到端身份驗證。

我將探討分布式微服務通信的問題，以及Apache Kafka和Service Mesh解決方案如何解決該問題。 這篇博客文章介紹了將兩種方法結合在一起以構建具有可解耦和安全的微服務的可靠且可擴展的微服務體系結構的方法。

討論和體系結構包括各種開源技術，例如Apache Kafka，Kafka Connect，Kubernetes，HAProxy，Envoy，LinkerD和Istio。

在此有關“微服務，Apache Kafka和域驅動設計（DDD） ”的相關博文中，了解有關使用Kafka解耦微服務的更多信息。

使用Kubernetes的Cloud-Native Kafka

云原生基礎架構是可擴展的，靈活的，敏捷的，彈性的和自動化的。 Kubernetes獲得了出廠標準。 無狀態服務的部署非常簡單明了。 但是，部署有狀態的分布式應用程序（例如Apache Kafka）要困難得多。 需要大量的人工操作。 Kubernetes不會自動解決Kafka特定的挑戰，例如滾動升級，安全性配置或代理之間的數據平衡。 在K8s自定義資源定義（CRD）中實現的Kafka運算符可以在這里提供幫助！

Kubernetes的運營商模式旨在捕捉正在管理一項服務或一組服務的人類運營商的主要目標。 負責特定應用程序和服務的人工操作員對系統應該如何運行，如何部署以及在出現問題時如何做出反應具有深入的了解。

在Kubernetes上運行工作負載的人們通常喜歡使用自動化來處理可重復的任務。 Operator模式捕獲了如何編寫代碼以自動化Kubernetes本身提供的功能以外的任務 。

存在用于Kubernetes的Kafka運營商的不同實現方式： 融合運營商 ， IBM / Red Hat的Strimzi ， Banzai Cloud 。 在這里，我不會詳細介紹K8s Kafka操作員的特性和優勢。 我已經在另一篇博客文章中對此進行了詳細說明（下面的視頻還將討論該主題）：

使用Envoy，Linkerd或Istio等基于Kubernetes的技術進行服務網格

服務網格是一種微服務模式，用于將可見性，可靠性和安全性原語用于服務到服務的通信移至基礎結構層，而不是應用程序層。

可以在此處找到有關設計模式“服務網格”的詳細說明，包括下圖，該圖顯示了控制平面與帶有代理人小車的微服務之間的關系：

您可以從Envoy或Linkerd之類的框架的創建者那里找到有關服務網格概念及其實現的更多精彩內容。 請查看這兩個鏈接，或者只是使用Google來獲得有關競爭替代品及其權衡的更多信息。

Apache Kafka和Service Mesh的（潛在）功能

諸如Apache Kafka之類的事件流平臺和Kubernetes之上的服務網格是云原生的，正交的和互補的 。 他們共同解決了構建可擴展，可靠，健壯和可觀察的微服務體系結構的關鍵要求：

如今，公司已經將Kafka與諸如Envoy，Linkerd或Istio之類的服務網格實現一起使用 。 您可以輕松地將它們組合在一起以增加安全性，實施速率限制或實施其他相關用例。 Banzai Cloud發布了最有趣的架構之一：他們使用Istio通過使用Envoy的代理為Kafka Brokers和ZooKeeper添加安全性 。

但是，與此同時，支持變得更好： Envoy中對Kafka支持的拉取請求于2019年5月合并。 這意味著您現在在Envoy中具有本機Kafka協議支持 。 關于其挑戰和實現Kafka協議過濾器的潛在功能的非常有趣的討論也值得一讀。

借助本機Kafka協議支持，您可以執行除L4 TCP過濾之外的更多有趣的事情。 以下是一些想法（部分來自于Github討論），關于在Service Mesh中使用L7 Kafka協議支持可以做什么：

• 點擊功能以轉儲到Kafka流
• 協議解析以實現可觀察性（使用HTTP RPC進行統計，日志記錄和跟蹤鏈接）
• 對Kafka流的影子請求，而不是HTTP / gRPC影子
• 與Kafka Connect及其連接器的整個生態系統集成

• 動態路由
• L4連接和L7消息級別的速率限制
• 過濾，添加壓縮，…
• 自動主題名稱轉換（例如，用于金絲雀發布或藍色/綠色部署）

• 請求日志和統計信息
• 數據沿襲/審核日志
• 通過獲取請求日志并用用戶信息豐富它們來審核日志。
• 客戶特定指標（每個客戶ID /每個客戶組的字節速率，客戶庫的版本，整個數據中心的客戶滯后監控）

• SSL終止
• 相互TLS（mTLS）
• 授權書

• 序列化格式（JSON，Avro，Protobuf等）
• 訊息模式
• 標頭，屬性等

太棒了，不是嗎？

微服務，Kafka和服務網格–幻燈片和視頻錄制

讓我們看一下我的幻燈片和視頻記錄，以更詳細地了解使用Apache Kafka，其生態系統，Kubernetes和Service Mesh技術構建Service Mesh的需求，挑戰和機遇…

這是幻燈片平臺：

來自KaiW?hner的 Apache Kafka，Kubernetes，Envoy，Istio和Linkerd的Service Mesh

來自KaiW?hner的 Apache Kafka，Kubernetes，Envoy，Istio和Linkerd的Service Mesh

錄像帶您瀏覽幻燈片：

有任何想法或反饋嗎？ 請通過評論或推文讓我知道，或者在LinkedIn上建立聯系。

<>

翻譯自: https://www.javacodegeeks.com/2019/09/service-mesh-cloud-native-microservices-apache-kafka-kubernetes-envoy.html

總結

以上是生活随笔為你收集整理的使用Apache Kafka，Kubernetes和Envoy，Istio，Linkerd的服务网格和云原生微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。