转载

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

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

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

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

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

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

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

即使这样,您仍将面临以下挑战:

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

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

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

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

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

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

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

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

原文  https://www.jdon.com/53326
正文到此结束
Loading...