最近，我为DZone及其迁移到微服务报告撰写了一篇文章，介绍了在企业组织中采用服务网格的挑战。在那篇文章中，我们要解决的第一件事是“无论您是否应该采用服务网格”，这就是我所说的：
首先回答“否”。如果您刚刚开始使用微服务和少量服务，请确保首先准备好基础部分。微服务及其关联的基础架构是一项优化，使您可以更快地对应用程序进行更改。在没有服务网格的情况下，您可以迈出一大步。您甚至可能想要服务网格带来的一些好处，而没有所有的复杂性。看看类似Gloo的东西，它是基于Envoy代理构建的API网关。
我认为这是目前非常重要的考虑因素，原因有两个：
- 通常，服务网格实现尚未准备好投入生产
- 在服务网格上全押的复杂性仍然很高
这并不意味着会有团队成功使用服务网格，或者您应该远离它。我确实认为您应该做好准备，以便在准备就绪并从中受益时最终引入网格。例如，在报告中，我列出了您可能要使用服务网格的以下原因：
- 跨多个集群大规模部署微服务
- 容器/ k8和VM的混合部署
- 用于构建服务的语言的异构部署
- 网络可观察性的观点不完整且不一致
即使这样，您仍将面临以下挑战：
- 选择哪一个？
- 谁来支持它？
- 单个集群中的多租户问题
- 没有管理多个群集的好方法
- 适应现有服务（边车生命周期，比赛条件等）
- 开发人员和运维实施之间的区别是什么
- 非容器环境/混合环境
- 集中与分散
通过过去两年多来我在Red Hat和Solo.io的工作，我一直在帮助人们解决这些难题（顺便说一句，如果您想在这些方面进行聊天/需要帮助，请联系@christianposta），但是我一直在我们的客户/用户中观察到并且建议过一段时间的一件事是，您对服务网格的采用应该始终以某种程度的隔离（即，独立地）采用数据平面技术开始。了解其工作原理，如何操作，调试等。
例如，在我最近的一次演讲中，我说过从Envoy开始（Envoy是许多服务网格实现的基础数据平面技术）。
当然，如果要使用Envoy，我建议从Gloo开始，后者基本上是Enterprise Envoy发行版，具有边缘和API网关功能，可以很好地插入服务网格中。一旦有了适当的位置，对它感到满意，就可以准备使用它，甚至可以通过代理分层来引入一些隔离。
下一个连续的方法是将网关向下推送到您的应用程序体系结构中。我们看到我们的用户也采用了针对每个应用程序边界的网关方法，这种方法开始给人以“网格的感觉”，但给应用程序带来了一些结构（例如，API网关模式）。我已经开始将其称为“路标”架构。就像飞行员使用航路点来指导其飞行计划一样，这些网关为您的体系结构增加了结构，同时解决了南北向交通问题，例如安全性和API解耦问题，同时为成功采用服务网格奠定了基础。
最后，您可以开始在不受边界限制的应用程序中引入服务网格代理，以解决服务网格最适合的棘手的服务到服务通信挑战。
这里的重要部分是网关仍然起着非常有用的作用！它们在为您的体系结构添加结构和航点的同时，在需要时将其余的实现细节与其他服务分离和隐藏。在许多方面，这都遵循DDD有界上下文模型，其中网关提供了“反腐败”层。否则，如果您将所有服务都视为对等方，那么您将开始向死亡之星坚定前进。
希望引入服务网格可以从小处开始，缓慢地扩展有意义的地方，从而为成功实现服务网格奠定基础，并在您能够消费并从中获得价值的同时，将网格的全部功能带给您的应用程序。否则，您可能会冒险一次引入太多的复杂性，而这将超出您实现应用程序和基础架构现代化的意图。