企业组织中采用服务网格的挑战

编者按

本文做者介绍了企业组织采用服务网格面临的哪些挑战，建议企业应该从数据平面开始逐步推动，从了解它、熟悉它、再到扩大规模使用它，而且以介绍其演讲的幻灯片为切入点介绍了架构演进的步骤。

正文

最近，我写了一篇关于在企业组织中采用服务网格的具备哪些挑战的文章，这篇文章是为DZone及其迁移到微服务的报告撰写的。在这篇文章中，咱们首先要解决的问题之一是“你是否应该沿着采用服务网格的道路走下去”，我是这么说的:

首先回答“不”。若是您刚刚开始使用微服务架构和少许的服务，请确保您首先准备好了基础部分。微服务及其相关的基础设施是一种优化方式，可让您更快的变动应用程序。在没有服务网格的状况下，您能够朝着更快的方向前进。你甚至可能想要一些服务网格带来的好处，而不是去关注它全部的复杂性。那么，请看看相似Gloo的产品，一个创建在Envoy代理上的API网关。

我认为在当前时刻，这是一个很是重要的考虑，有如下两大缘由:

1. 总的来看，服务网格的实现尚未准备好投入生产。
2. 所有投入(all-in)到一个服务网络的复杂性仍然很高。

这并不意味着没有团队成功地使用了服务网格，或者您应该远离它。可是，我确实认为您应该创建这样的能力，当您真正准备好了而且能够从中获益的时候，最终能成功地将服务网格引入。例如，在报告中，我列出了您可能想要使用服务网格的缘由:

• 跨多个集群部署大量微服务
• 容器/k8s和虚拟机的混合部署
• 用于构建服务的语言的异构部署
• 网络可观测性的不完整和不一致视图

即便有了以上这些理由，你依然会面临这些挑战:

• 选择哪个服务网格产品？
• 谁来作技术支持？
• 单集群的多租户问题
• 缺少多集群的管理方法
• 已有服务如何适配（sidecar的生命周期、竞态条件等等）
• 开发人员与运维人员的界限在哪里
• 非容器环境/混合环境
• 中心化 vs 去中心化

经过我在Red Hat和如今Solo.io加起来两年以上的工做，我一直在帮助人们解决那些棘手的问题(顺便说一句，若是你想交谈/须要这些方面的帮助，能够经过@christianposta联系我)。但有一件我从咱们的客户/用户一直观察到，而且持续一段时间提出建议，那就是你采用服务网格的第一步，应该老是先使用在必定程度上（自行）隔离的数据平面技术，要了解它是如何工做的，如何实施，如何调试等等。

例如，在我最近作的一次演讲中，我说过要从Envoy（Envoy是许多服务网格实现的底层数据平面技术）开始。PPT以下:

从架构的角度来看，它多是这样的:

固然，若是你要使用Envoy，我建议从Gloo开始，这基本上是一个具备edge与API网关能力的企业版Envoy，而且很好地植入了服务网格。一旦你有了它，对它熟练使用，那么你就会准备好增长它的使用，甚至可能经过代理的分层引入一些隔离:

接下来的方法是将网关推入到应用架构中。咱们看到咱们的用户在每一个应用程序边界采用一个网关的方法，开始有了一个网格的“感受”，但在应用程序引入了一些结构(例如，API网关模式)。我开始称之为“waypoints”架构。就像飞行员使用航路点（waypoints）来指导他们的飞行计划同样，这些网关为您的应用架构增长告终构，同时解决了诸如安全性和API解耦的南北通讯问题，同时为成功采用服务网格奠基了基础。

最后，您能够开始在应用程序中引入独立于边界的服务网格代理，以解决棘手的但偏偏是服务网格技术最擅长解决的service-to-service通讯挑战:

这里重要的部分是网关，而且仍然有很是有用的用途！它们向应用架构中添加结构和路径点，同时在须要的地方将某些实现细节与其余服务分离并隐藏起来。在不少方面，这都遵循了DDD有界上下文模型，网关提供了一个“反腐败”层。不然，若是你只是把全部的服务都看成“伙伴”，你就会开始坚决地迈向死星:

但愿这篇文章有助于您奠基一个成功的方法，经过小范围使用服务网格，而后逐渐缓慢扩展有意义的各个地方，而且你的应用程序能够从服务网格架构中获益。不然，您将承担同时引入太多复杂性的风险，这将违背您实现应用程序和基础设施现代化的意图。

关于 ServiceMeshe 社区

ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起，于 2018 年 4 月正式成立。

社区关注领域有：容器、微服务、Service Mesh、Serverless，拥抱开源和云原生，致力于推进 Service Mesh 在中国的蓬勃发展。

社区官网：https://www.servicemesher.com