转载

在企业组织中采用服务网格的挑战：从API网关到微服务通信逐步引入 – Christian Posta

最近，我为DZone及其迁移到微服务报告撰写了一篇文章，介绍了在企业组织中采用服务网格的挑战。在那篇文章中，我们要解决的第一件事是“无论您是否应该采用服务网格”，这就是我所说的：

首先回答“否”。如果您刚刚开始使用微服务和少量服务，请确保首先准备好基础部分。微服务及其关联的基础架构是一项优化，使您可以更快地对应用程序进行更改。在没有服务网格的情况下，您可以迈出一大步。您甚至可能想要服务网格带来的一些好处，而没有所有的复杂性。看看类似Gloo的东西，它是基于Envoy代理构建的API网关。

我认为这是目前非常重要的考虑因素，原因有两个：

通常，服务网格实现尚未准备好投入生产
在服务网格上全押的复杂性仍然很高

这并不意味着会有团队成功使用服务网格，或者您应该远离它。我确实认为您应该做好准备，以便在准备就绪并从中受益时最终引入网格。例如，在报告中，我列出了您可能要使用服务网格的以下原因：

跨多个集群大规模部署微服务
容器/ k8和VM的混合部署
用于构建服务的语言的异构部署
网络可观察性的观点不完整且不一致

即使这样，您仍将面临以下挑战：

选择哪一个？
谁来支持它？
单个集群中的多租户问题
没有管理多个群集的好方法
适应现有服务（边车生命周期，比赛条件等）
开发人员和运维实施之间的区别是什么
非容器环境/混合环境
集中与分散

通过过去两年多来我在 Red Hat 和 Solo.io的工作，我一直在帮助人们解决这些难题（顺便说一句，如果您想在这些方面进行聊天/需要帮助，请联系 @christianposta ），但是我一直在我们的客户/用户中观察到并且建议过一段时间的一件事是，您对服务网格的采用应该始终以某种程度的隔离（即，独立地）采用数据平面技术开始。了解其工作原理，如何操作，调试等。

例如，在我最近的一次演讲中，我说过从Envoy开始（Envoy是许多服务网格实现的基础数据平面技术）。

当然，如果要使用Envoy，我建议从Gloo开始，后者基本上是 Enterprise Envoy发行版，具有边缘和API网关功能，可以很好地插入服务网格中。一旦有了适当的位置，对它感到满意，就可以准备使用它，甚至可以通过代理分层来引入一些隔离。

下一个连续的方法是将网关向下推送到您的应用程序体系结构中。我们看到我们的用户也采用了针对每个应用程序边界的网关方法，这种方法开始给人以“网格的感觉”，但给应用程序带来了一些结构（例如， API网关模式）。我已经开始将其称为“路标”架构。就像飞行员使用航路点来指导其飞行计划一样，这些网关为您的体系结构增加了结构，同时解决了南北向交通问题，例如安全性和API解耦问题，同时为成功采用服务网格奠定了基础。

最后，您可以开始在不受边界限制的应用程序中引入服务网格代理，以解决 服务网格最适合的棘手的服务到服务通信 挑战。

这里的重要部分是网关仍然起着非常有用的作用！它们在为您的体系结构添加结构和航点的同时，在需要时将其余的实现细节与其他服务分离和隐藏。在许多方面，这都遵循DDD有界上下文模型，其中网关提供了“反腐败”层。否则，如果您将所有服务都视为对等方，那么您将开始向死亡之星坚定前进。

希望引入服务网格可以从小处开始，缓慢地扩展有意义的地方，从而为成功实现服务网格奠定基础，并在您能够消费并从中获得价值的同时，将网格的全部功能带给您的应用程序。否则，您可能会冒险一次引入太多的复杂性，而这将超出您实现应用程序和基础架构现代化的意图。

原文 https://www.jdon.com/53326

正文到此结束