【编者按】服务网格是一个新兴的领域。在软件的历史上，从来没有任何软件是100%可以使用的。未来很难预测，但像Kubernetes和Envoy这样的基础技术将成为管道。让我们来看看顶级专家认为该技术的发展方向。Panel评估服务网格的成熟度服务网格就像一辆电动汽车，你的朋友在谈论它，它很时尚，但你还没有拥有它。您可能想稍等片刻，看看其他人是如何管理它的。然而，这感觉像是下一次技术进化。近几个月来，服务网格引起了广泛关注——它们有助于解决采用微服务架构后出现的许多问题。但是服务网格是否已为所有企业做好准备？事实证明，支持者并不认为该技术已100%准备好广泛采用。11月18日ServiceMeshNorthAmerica2020研讨会上该领域的思想领袖：Lyft的MatKlein；ManishChugtu，VMware；IBM的DanBerg和IditLevine，Solo.io。总体而言，小组成员承认服务网格领域当前的积极发展，例如围绕Envoy的集成。他们还强调了它的许多好处，包括向微服务架构添加网络、可观察性和路由功能。然而，我们仍然没有看到足够多的服务网格生产用例。此外，每个网格框架仍在不断成熟。使用服务网格的权衡包括增加延迟、陡峭的学习曲线和持续的维护开销。缺乏明确的网格间互操作性标准化可能是另一个问题（SMI是一种提议的格式，但现在业界似乎更喜欢Envoy的xDSAPI）。所有这一切并不是说它不会成为公司未来基础架构的关键部分，或者它不会为需要它的用例提供有用的功能。简而言之，服务网格是一个新兴领域（这就是这个群体如此迷人的原因）。跟随我们深入研究FutureScene的最新更新。让我们来看看顶级专家认为该技术的发展方向。服务网格中的新功能服务网格领域的最新动态是什么？好吧，大多数小组成员现在将Envoy视为大多数网格的既定数据平面代理。我们还看到它非常适合作为新的多云范式的可观察性机制。“特使是我们看到出现的数据平面层，”克莱因说。服务网格和API网关空间充满了许多解决方案，应用程序越来越多地转向无服务器。未来很难预测，但“像Kubernetes和Envoy这样的基础技术将成为管道，”他说。Levine还赞扬了Envoy的可扩展性功能，并引用了最近在使用WebAssebly扩展Envoy方面取得的进展。“特使是要走的路，”她说。“它是建筑物的基石——任何不拥抱它的东西都会消失。”这可能很危险。”同样，Berg认为Envoy是未来，而云是现在。然而，他描述了团队实施服务网格的困难程度。“他们正在努力做到这一点，但这很艰难，”他说。护栏和治理的概念非常重要。除此之外，许多公司只需要像Istio这样的成熟技术可以提供的一小部分功能。他呼吁简化可用性和部署——我们需要“简单的解决方案来解决复杂的问题问题。”Chugtu吹捧其在处理新的混合和多云模型方面的优势。这些现实正在出现，随之而来的是对跨所有部署模式的通用可观察性框架的需求。在安全方面，Chugtu看到了解决可扩展性问题的真正好处通过诸如威胁检测之类的东西。根据Chugtu的说法，服务网络收集的有用信息越多，它就越有助于定义访问属性。因此，它有助于创建零信任模式埃尔。使用服务网格的权衡仍然存在很大的困难。总体而言，专家组认识到服务网格的实施是人力密集型的——陡峭的学习曲线、可用性挑战和持续维护。此外，每个操作都会占用服务器空间，因此操作开销和应用程序延迟是真正需要考虑的问题。最后，它会给不需要它的场景带来太多的复杂性。“这是一条陡峭的学习曲线，”伯杰说。“这不是渐进式的改进——你从头开始，然后是一个飞跃。公司可以采用它来实现可观察性和企业范围内的交互。随着他们的进步并意识到还有更多的价值，Berg他们拥有很多资源了解并适应该网络，他补充说。在操作上，SideCar也会随着时间的推移消耗资源。“很多人在第一次构建时没有考虑到这一点，”他说。他预测托管解决方案可以帮助开辟更多可能性，以便更容易采用。“我们正试图采取一种并非100%准备就绪的方法，”莱文说。服务网格本质上是另一种操作、管理、升级和维护的东西。她还承认设计中固有的额外延迟。不管潜在的缺点如何，Levine仍然认为集中配置平面的好处大于缺点。“服务网格无法满足客户现在的需求，”Chugtu说，承认其复杂性和固有的学习曲线。然而，他仍然认为这是值得的，因为这有助于平衡团队动力。从根本上说，服务网格的引入将基础设施的所有权转移回平台和DevOps团队，让开发人员能够专注于核心竞争力和应用程序开发。在最近的一次采访中，Palladino强调平台团队和开发人员的分离是一件好事。“应用团队应该是连接的消费者，而不是连接的生产者，”他说。追本溯源，也许企业真正应该问的问题是：我们应该首先采用微服务吗？当您采用微服务时，它会带来许多意想不到的结果，这些结果与运行单体架构截然不同。从本质上讲，该行业不应将事情复杂化到不必要的程度。当它被证明是合理的时候，“sidecar代理解决方案是解决这些问题的一个优雅的解决方案，”Klein说。标准和服务网格接口正如我最近提到的，由Solo.io带头的服务网格接口(SMI)可能是一个令人兴奋的提案，它将为新兴的服务网格优势领域带来互操作性和可扩展性。然而，专家组的普遍情绪是对其实际使用持怀疑态度。Levine支持SMI以在网格之间形成供应商中立的标准接口。在市场上拥有通用的服务网格配置模型可以在未来的多网格世界中为公司提供支持。然而，她承认SMI的障碍，特别是该标准的“低共同点”效应和政治因素，阻碍了它的引入。其他人不太相信SMI是必要的。“如果你打算使用不同的网格，它可能会令人不快，”Berger说。“我们最终会得到多少实现？”他问。如果主要好处只是避免供应商锁定，那么SMI可能不值得投资。克莱因在理论上将SMI描述为一个伟大的想法，但并不认为它在实践中有用。“我非常怀疑任何东西都是便携式的，”他说。归根结底，所有服务网格提供商都有自己的解释。Klein强调，业界应避免添加不必要的抽象层。一些小组成员没有关注SMI，而是认为围绕EnvoyxDSAPI的融合更有意义。“如果一切都基于Envoy，它会收敛吗？”克莱恩问道。为采用服务网格做好准备那么，了解所涉及的障碍后，服务网格何时才能100%准备就绪？它适合什么地方？答案各不相同。一种方式是站在现有技术栈的角度来看。Klein重申，公司应该首先采用微服务，然后再采用服务网格。他说，不要出于“技术嫉妒”而拥抱服务网格。相反，它应该是基于最小化运营痛点和最大化生产力的客户至上的决策。另一个角度是考虑未来的发展方向。Chugtu说，服务网格可能是贵公司或未来客户愿景的一部分。在这种情况下，您的历史或当前架构可能并不重要。“解决方案已经准备就绪，你要解决的用例太多了，”他说。还有一点，没有伟大的技术是完整的。服务网格何时会100%准备就绪？“从来没有，”伯杰说。故障总会有的，以Kubernetes为例：每次发布补丁或引入新问题，社区都在不断改进它。同样，市场上的每一个服务网格都在走向成熟。他们各有利弊，“没有一个是完美的，”他说。服务网格什么时候成熟？对于Levine来说，这首先需要将服务网格置于绞尽脑汁之中（这是一件令人头疼的事）。“他们都不够成熟，”她说。只有当人们在生产中运行它时，他们才能提供反馈以改进服务网格。尽管“还没有人完全准备好”，Levine确实预见到一个为更多组织快速开放的市场。ServiceMesh是一个全新的概念，需要更多的生产用例来提高Mesh和Envoy的可扩展性。早期采用者应该根据自己的情况做出很好的猜测，并在选择一个之前评估市场上所有的服务网格。对于后来的采用者，未来的可用性改进和托管服务网格的提供可以很容易地激励组织转向网格。
