服务网格是 Kubernetes 世界中的一个热门话题，但许多潜在的采用者已经失去了耐心。服务网格的采用受到了巨大的复杂性和似乎无穷无尽的供应商解决方案的限制。在我自己浏览了这个领域后，我发现采用服务网格有巨大的价值，但必须以轻量级的方式进行，以避免不必要的复杂性。尽管普遍存在幻灭感，但服务网格的前景依然光明。
我进入服务网格的世界，始于我在一家历史悠久的财富 500 强科技公司担任云计算架构师。在我们的服务网格旅程开始时，我身边有许多强大的工程师，但大多数人几乎没有云开发的经验。我们的组织诞生于云计算之前，要完全实现云计算的价值需要时间。我们的传统业务线主要集中在技术堆栈的硬件元素上，而云计算的决策最初是由为运送硬件或为这些硬件提供固件和驱动程序而开发的流程所驱动。
随着这个组织经历了 “数字化转型”，它越来越依赖于提供高质量的软件服务，并逐渐形成了更好的方法论。但是，作为云计算架构师，我仍然在为优先考虑硬件的业务流程和具有不同技能组合、流程和信念的工程团队而奔波。随着时间的推移，我和我的团队在将.NET 应用程序迁移到 Linux、采用 Docker、迁移到 AWS 以及与之相关的最佳实践（如持续集成、自动部署、不可变基础设施、基础设施即代码、监控等）方面变得熟练和成功，但挑战仍然存在。
在这段时间里，我们开始将我们的应用程序分割成一系列的微服务。起初，这是一个缓慢的转变，但最终这种方法流行起来，开发人员开始喜欢建立新的服务而不是增加现有的服务。我们这些基础设施团队的人把这看作是一种成功。唯一的问题是，与网络有关的问题数量激增，开发人员正在向我们寻求答案，而我们还没有准备应用这种冲击。
我第一次听说服务网格是在 2015 年，当时我正在研究服务发现工具，并寻找与 Consul 集成的简单方法。我很喜欢把应用责任下沉到 “sidecar"容器的想法，并找到了一些可以做到这一点的工具。大约在这个时候，Docker 有一个叫做 “linking"的功能，让你把两个应用程序放在一个共享的网络空间中，这样它们就可以通过本地主机进行通信。这个功能提供了一个类似于我们现在在 Kubernetes pod 内的体验。两个独立构建的服务可以在部署时进行组合，以实现一些额外的功能。
我总是抓住机会用简单的解决方案来解决大问题，所以这些新功能的力量立即打动了我。虽然这个工具是为了与 Consul 集成，但在实践中，它可以做任何你想要的事情。它是我们拥有的基础设施的一个新的层级，可以用来为每个人解决问题。
这方面的一个具体例子是在我们采用过程的早期。当时，我们正在努力使许多不同服务的日志输出标准化。通过采用服务网格和这种新的设计模式，我们能够把我们的人的问题——让开发人员标准化他们的日志，转变成技术问题——把所有的服务流量通过一个可以为他们做日志记录的代理。这对我们的团队来说是一个重大的进步。
我们对服务网格的实施是非常务实的，并与该技术的核心功能保持一致。然而，许多营销炒作可能集中在不太需要的边缘案例上，在评估服务网格是否适合你时，能够识别这些干扰是很重要的。
服务网格可以提供的核心功能分为四个关键责任领域：可观测性、安全性、连接性和可靠性。
这是我们最成功的地方之一，也是最简单的采用，就是标准化的监测。它的运营成本很低，而且可以被制作成适合你使用的任何监控系统。它使企业能够捕获他们所有的 HTTP 或 gRPC 指标，并在整个系统中以标准方式存储它们。这就控制了复杂性，减轻了应用团队的负担，他们不再需要实施 Prometheus 指标端点或标准化日志格式。它还使用户能够对其应用程序的黄金信号有一个公正的看法。
自动加密和身份识别
证书管理是很难做好的。如果一个组织还没有在这方面投资，他们应该找一个网格来为他们做这件事。证书管理需要维护复杂的基础设施代码，具有巨大的安全影响。相比之下，网格将能够与编排系统集成，了解工作负载的身份，在需要时可以用来执行策略。这允许一个真正强大的安全态势，相当于或优于那些由 Calico 或 Cilium 等功能丰富的 CNI 提供的安全态势。
智能路由是另一项功能，使网格在发送请求时能 “做正确的事”。应用如下：
这些功能可能不会让普通人感到兴奋，但随着时间的推移，它们带来了更多的价值。
在分布式系统中重试请求可能很麻烦，然而，这总是需要实施的。分布式系统通常会将一个客户端请求转换为下游的许多请求，这意味着 “尾巴"情况的可能性大大增加，例如发生异常的失败请求。对此，最简单的缓解措施是重试失败的请求。
困难来自于避免 “重试风暴"或 “重试 DDoS”，即当一个处于退化状态的系统触发重试时，随着重试的增加，负载增加，性能进一步下降。一个天真的实现不会考虑到这种情况，因为它可能需要与缓存或其他通信系统集成，以知道重试是否值得执行。服务网格可以通过提供整个系统允许的重试总数的约束来做到这一点。服务网格还可以在这些重试发生时进行报告，有可能在你的用户注意到之前提醒你系统的退化。
也许服务网格的最佳属性是其可扩展性。它提供了一个额外的适配层，可以承担 IT 部门接下来的任何工作。Sidecar 代理的设计模式是另一个令人兴奋和强大的功能，即使它有时被过度宣传和过度设计来做用户和技术还没有准备好的事情。当社区在等待哪个服务网格"胜出"时，这反映了之前被过度炒作的编排战争，我们将不可避免地在未来看到更多专门的网格，而且很可能有更多的最终用户建立自己的控制平面和代理来满足他们的使用情况。
平台或基础设施控制层的价值怎么强调都不过分。然而，在服务网格的世界中，我了解到一个主要的挑战是，服务网格所解决的核心问题往往甚至不是大多数服务网格项目的沟通重点。
相反，许多来自服务网格项目的沟通都是围绕着那些听起来很强大或令人兴奋的功能，但最终却让人分心。包括以下内容。
要很好地运行复杂的软件是非常困难的。这就是为什么如此多的组织使用云计算，使用完全托管的服务。那么，为什么服务网格项目会让我们负责运行如此复杂的系统？系统的复杂性不是一种资产，而是一种责任，然而大多数项目都在吹嘘他们的功能集和可配置性。
多集群是现在的一个热门话题。大多数团队最终都会运行多个 Kubernetes 集群。但多集群的主要痛点是你的 Kubernetes 管理网络被分割成两半。服务网格帮助解决这个 Kubernetes 的扩展问题，但它最终并没有实现任何新的东西。是的，多集群支持是必要的，但它对服务网格的承诺被过度宣传了。
Envoy 是一个伟大的工具，但它被当作某种标准来介绍，这是有问题的。Envoy 是许多开箱即用的代理之一，你可以在此基础上建立一个服务网格平台。但是，Envoy 并没有什么内在的特别之处，使它成为正确的选择。采用 Envoy 会给你的组织带来一系列重要的问题，包括：
服务网格中代理的选择应该是一个实施细节，而不是一个产品要求。
我是 Web Assembly（WASM）的忠实粉丝，曾成功地用它在Blazor中构建前端应用程序。然而，WASM 作为定制服务网格代理行为的工具，使你完全陷入了获得全新的软件生命周期开销的境地，这与你现有的软件生命周期是完全分离的。如果你的组织还没有准备好构建、测试、部署、维护、监控、回滚和版本代码（影响通过其系统运行的每个请求），那么你还没有准备好使用 WASM。
当我意识到 A/B 测试实际上是一个应用程序级别的问题已经太晚了。在基础设施层提供基元来实现它是可以的，但没有简单的方法来完全自动化大多数组织需要的 A/B 测试水平。通常情况下，应用程序需要定义独特的指标，以确定测试的积极信号。如果一个组织想在服务网格层实施 A/B 测试，以下是解决方案需要支持的内容：
这是很难实现的，而且没有一个服务网格能做到开箱即用。最终，我们的组织选择了一个网格之外的功能标记解决方案，它以最小的努力取得了巨大的成功。
最终，我们所面临的挑战并不是服务网格所独有的。我们工作的组织有一系列的限制条件，要求我们对解决的问题和解决的方式采取务实的态度。我们面临的问题包括：
简而言之，我们人少，问题多，而且需要快速展示价值。我们必须支持那些主要不是网络或云计算的开发者，我们需要扩大规模以支持大型工程组织，这些组织有不同的方法和流程来做云计算的事情。我们需要把大部分精力放在解决成熟度曲线上低的基本问题上。
最后，当我们面临自己的服务网格决定时，我们决定建立在Linkerd 服务网格之上，因为它最符合我们的优先事项：低运营成本（包括计算和人力）、低认知开销、支持性社区和透明的管理，同时满足我们的功能要求和预算。在 Linkerd 指导委员会呆了很短的时间（他们喜欢诚实的反馈和社区参与），我了解到它与我自己的工程原则是多么的吻合。Linkerd 最近在 CNCF达到了毕业状态，这是一个漫长的过程，强调了项目的成熟度以及它的广泛采用。
Chris Campbell 从事软件工程师和架构师工作超过十年，与多个团队和组织合作，采用云原生技术和最佳实践。他的工作时间分为两部分，一部分是与企业领导合作，采用软件交付策略来加速业务发展，另一部分是与工程团队合作，提供可扩展的云基础设施。他最感兴趣的是能提高开发人员生产力和体验的技术。
最后更新于 2024/11/07