到底什么时候需要服务网格？看这个便知

笔者经常听到的一个问题是：“我真的需要一个服务网格吗？诚实的回答是“具体情况具体分析”，这取决于收益和成本。但是，在帮助用户在许多不同的场景中经历了从探索到生产部署的过程之后，笔者很乐意与大家分享在决策过程中需要考虑的因素。             

服务网格提供了连接、保护和观察微服务的一致方式。大多数服务网格都与编排平台紧密集成。服务网格需要相关团队认真学习，这是一个成本，你应该将该成本与可能实现的运维简化的好处进行权衡。             

除了成本和收益，还有什么能决定你是否真的需要一个服务网格？答案是，运行的微服务的数量，以及紧迫性和时机，都会对你的需求产生影响。       

有多少微服务？             

如果你正在部署第一个或第二个微服务，笔者认为没有服务网格也行。你应该首先专注于学习Kubernetes并将无状态容器从应用程序中分解出来。你会很自然地慢慢熟悉服务网格可以解决的问题，这将使你在时机成熟时更好地规划服务网格的使用。      

如果你现有的应用程序架构提供了所需的可观察性、安全性和弹性，那么你已经有了一个很好的起点。对于你来说，问题是何时添加服务网格。我们通常看到组织关注与实用程序代码相关联的工作，以集成每个新的微服务。一旦这项工作变得痛苦，他们就会评估如何使这种集成更加有效。我们提倡使用服务网格来简化这项工作。             

在什么程度上，服务网格的好处明显大于成本因组织而异。以笔者的经验，团队通常会意识到，一旦有了5到6个微服务，就需要一个一致的方法。然而，许多用户在注意到实用程序代码成本的增加和应用程序之间细微差别的复杂性增加之前，会使用十几个或更多的微服务。当然，有些组织继续扩展，根本不选择服务网格，而是投资于应用程序库和工具。另一方面，我们也与那些希望赶在复杂度上升之前引入服务网格的早期客户合作，在他们拥有6个微服务之前就引入了服务网格。

紧迫性和时机 

时机同样很重要。服务网格的紧迫性取决于组织的挑战和目标，但也可以由当前的流程或运维状态来决定。以下是一些可能会降低或消除使用服务网格的紧迫性的状态：             

——你的微服务都是由组织中的开发人员使用一种语言（“monoglot”）编写的，它们是从一个公共框架构建的。             

——你的工程师致力于构建和维护自动构建到每个新微服务中的特定工具。             

——你有一个部分或完全单体的架构，其中应用程序逻辑被构建到一个或两个容器中，而不是几个容器中。             

——在手动集成过程之后，你可以一次发布或升级所有内容。             

——你使用的应用程序协议不是由现有的服务网格提供的（HTTP、HTTP/2、gRPC）。             

另一方面，以下是表明你需要一个服务网格，并且尽早开始评估或采用的信号：             

——你使用许多用不同语言编写的微服务，这些语言可能不遵循通用的架构模式或框架（或者你正在进行语言/框架迁移）。    

——你正在整合第三方代码或与陌生团队（例如，合作伙伴或并购方）进行交互，并且希望有一个共同的基础。             

——你的组织一直在“重新解决”问题，特别是在实用程序代码中（笔者最喜欢的示例：证书轮换）。             

——你具有跨服务的健壮的安全性、合规性或可审计性需求。             

——你的团队花在定位或理解问题上的时间比解决问题的时间要多。

这些都意味着，你需要一个服务网格。当应用程序无法向用户提供高质量的体验时，你的团队如何解决它？发现问题通常是最困难和最昂贵的部分。

接下来呢？             

一旦你找到了问题，你能缓解或解决它吗？如果唯一的解决办法是开发新代码或重建容器，这将是一个痛苦的局面。这就是保持弹性能力独立于业务逻辑（如在服务网格中）的好处所在。             

如果你熟悉这个局面，那么你可能现在就需要一个服务网格。记住你的成本和收益，并找到以下问题的答案：             

——你是不是花太多的时间去找到问题，而不是为用户开发和提供价值？   

——你的运维和拥有的微服务的数量是合拍的，还是应该简化？   

——你是否有服务网格可以解决的关键问题？   

密切关注这些问题的答案将有助于你确定是否以及何时真正需要服务网格。