在微服务的世界中，变革的步伐是坚定不移的，但随着大量的行业思想领袖和实践者正在超越单纯的理论和空谈，人们的兴奋感肯定会不断增强。拥有需要服务网格功能的工作负载的早期采用者组织现在希望通过为一些引人注目的“容易实现的目标”用例实施实际解决方案来证明其作为生产就绪架构的可行性。
这篇文章是我们关于服务网格的系列文章的第二部分：
- 在第 1 部分中，我们总结了过去一年左右服务网格领域发生的主要发展，并列举了服务网格的一些关键应用程序需求。
- 在相关博客中，我的同事 Owen Garrett 提供了指导，帮助您确定您是否真的需要服务网格，以及在服务网格实现更加成熟之前如何使用现有的成熟技术。
在这个帖子中接下来，我们再次强调我们确定为服务网格价值主张核心的服务网格功能之一：可用性。在第 1 部分中，我们重点介绍了 I&O 和 DevOps 领导者如何负责通过提供容错能力的交付基础设施（包括服务网格）部署任务关键型应用程序。控制平面是大多数创新发生的地方，因为 NGINX 和 Envoy 等工具提供的数据平面基础设施已经是企业级的。令人兴奋的消息是，供应商一直在快速开发其控制平面，并在很大程度上解决了一些早期对控制平面作为潜在单点故障的担忧。
以下是高可用性控制平面的一些最新创新和开发的综述，这些控制平面是成熟的、商业支持的服务网格的核心：
- HashiCorp 的 Consul 服务网格解决方案提供了一个很好的模式l 提供高可用性：它将数据平面和控制平面功能分布在所有成员节点上，使用 Consul 代理在网格中的所有节点上实施策略。
- Linkerd 2.3 是云原生计算基金会孵化器项目的最新版本。它在 Kubernetes 上提供控制平面解决方案，通过易于理解的仪表板提供多个负载平衡 Pod。 Linkerd 现在已经达到了成熟的程度，它拥有不错的 UI 以及非常轻量级的基于 Rust 的数据平面的优点，这使得该解决方案与通常依赖 NGINX 或 Envoy 的其他解决方案区分开来。
- 在 4 月份的 Google Cloud Next 大会上，Google 宣布并强调了 GKE 上的 Istio 测试版，将其作为 Anthos（以前称为 Google 云服务平台）的三个核心组件之一。谷歌继续开发和推广 Istio，它现在提供“连接”功能和控制平面称为混音器。 Google 强调可用性是一项主要的控制平面功能，并指出“Mixer 旨在为每个单独的 Mixer 实例提供高可用性。其本地缓存和缓冲区不仅减少了延迟，而且还有助于掩盖基础设施后端故障[,]即使在后端无响应时也能运行”。
- 新成立的初创公司 Tetrate 已获得 1250 万美元的融资，已从秘密模式中脱颖而出，正在演示如何简化和打包 Istio，以便在企业内部跨本地以及具有多个供应商和区域的云基础设施中更轻松地部署和运营。 Tetrate 首席执行官 Varun Talwar 此前曾担任 Google 云平台团队的产品经理，负责开发 Istio 项目。从这次经验中，他知道“Istio 如今与 Kubernetes 合作，但企业客户有很多遗留工作负载。我们的第一个产品将有助于在工作负载和帮助企业向容器和公共云过渡”。
-
F5 最近收购了 NGINX，加速了基于 NGINX 应用平台和 NGINX 控制器的易于使用、灵活的服务网格产品的推出。我们计划在今年晚些时候发布一个服务网格控制平面，即 NGINX 控制器服务网格模块。它不仅可以实现高可用性，还可以为用户提供基于现有控制器应用程序交付和 API 管理模块的通用 GUI。
[编辑器–
- NGINX Service Mesh (NSM) 是一种完全集成的轻量级服务网格，它利用 NGINX Plus 提供支持的数据平面来管理 Kubernetes 环境中的容器流量，现已发布[在撰写本文时的开发版本中]。免费下载 NSM，在您的开发和测试环境中试用，并在 GitHub 上向我们提供反馈。
- NGINX 控制器r 现在是 F5 NGINX 管理套件。
]
可以肯定的是，服务网格空间的变化速度并没有放缓。供应商正在竞相开发高度可用的服务网格控制平面，尽管现在有多种模型可用，但尚未有单一解决方案占据主导地位。我们生活在一个充满活力且令人兴奋的微服务世界中。请关注下一篇关于如何在服务网格空间中解决安全问题的文章。在那之前，祝您旅途愉快。
发表回复