译者：

作为一个已经在制造业企业的基础架构团队任职，为反对公司的“互联网基因”和“数字化转型”落地了云原生基础设施平台，并在尝试采纳服务网格未成的我来说，看到这篇文章深有感触。尤其是文中所说的“人少，问题多，须要疾速输入价值”，直戳到了痛处。无限的人手无限的工夫，咱们须要将大部分精力集中在解决成熟度曲线较低的根本问题上，要想很好的运行简单的零碎是十分艰难的。

服务网格是一个新的基础设施层，能够承载很多的性能，将来还会有更大的设想空间和光明的将来。

以上的种种原因，也促使我起初抉择进入一家提供服务网格的产品企业，也心愿服务网格能够被更简略的应用。

“道阻且长，行则将至！”

本文翻译自 Chris Campbell 的 How Unnecessary Complexity Gave the Service Mesh a Bad Name

要害要点

• 采纳服务网格有微小的价值，但必须以轻量级的形式进行，以防止不必要的复杂性。
• 在施行服务网时，要采取求实的办法，与技术的外围性能保持一致，并小心烦扰（译者：注意力的扩散）。
• 服务网格的一些外围个性包含标准化监控、主动加密和身份辨认、智能路由、牢靠的重试和网络可扩展性。
• 服务网格能够提供弱小的性能，但这些性能会扩散本应答外围劣势的关注，并且这些性能也不是施行服务网格的次要起因。
• 在初始施行服务网格时没有必要去关注那些显著会扩散注意力的性能，比方简单的管制立体、多集群反对、Envoy、WASM 和 A/B 测试。

服务网格是 Kubernetes 世界中的一个热门话题，但许多潜在的采纳者曾经有些悲观了。服务网格的落地受到压倒性的复杂性和看似无穷无尽的供应商解决方案的限度。在我亲自浏览了这个畛域之后，我发现采纳服务网格具备微小的价值，但它必须以轻量级的形式实现，以防止不必要的复杂性。只管普遍存在破灭感，但服务网格的将来仍然光明。

在工作中学习

我进入服务网格的世界始于我在一家老牌的财产 500 强技术公司负责云计算架构师的角色。在开始咱们的服务网格之旅时，我身边有许多弱小的工程师，但大多数人简直没有云计算开发教训。咱们的组织诞生于云计算之前，齐全实现云计算的价值须要工夫。咱们的传统业务线次要集中在技术栈的硬件元素上，云计算的决策最后是由为运送硬件或为该硬件提供固件和驱动程序而开发的流程驱动的。

随着该组织经验其“数字化转型”，它越来越依赖于提供高质量的软件服务，并逐步开发出更好的办法。但作为云计算架构师，我仍在为优先思考硬件的业务流程，以及具备不同技能、流程和信念的工程团队导航。随着工夫的推移，我和我的团队在将 .NET 应用程序迁徙到 Linux、采纳 Docker、迁徙到 AWS 以及与之相干的最佳实际（如继续集成、自动化部署、不可变基础设施、基础设施即代码、监控等）方面变得纯熟并胜利。但挑战仍然存在。

在此期间，咱们开始将咱们的应用程序拆分为一组微服务。起初，这是一个迟缓的转变，但最终这种办法流行起来，开发人员开始更喜爱构建新的服务而不是增加到现有服务。咱们这些基础设施团队的人把这看作是一种胜利。惟一的问题是与网络相干的问题数量激增，开发人员正在向咱们寻求答案，而咱们还没有筹备好无效地应答这种冲击。

服务网格的挽救

我第一次据说服务网格是在 2015 年，过后我正在钻研服务发现工具并寻找与 Consul 集成的简略办法。我喜爱将应用程序职责卸载到“sidecar”容器的想法，并找到了一些能够帮忙做到这一点的工具。大概在这个时候，Docker 有一个叫做“链接”的性能，让你能够将两个应用程序放在一个共享的网络空间中，这样它们就能够通过 localhost 进行通信。此性能提供了相似于咱们当初在 Kubernetes pod 中所领有的体验：两个独立构建的服务能够在部署时进行组合以实现一些附加性能。

我总是抓住机会用简略的计划来解决大问题，因而这些新性能的力量立刻感动了我。尽管这个工具是为了与 Consul 集成而构建的，但实际上，它能够做任何你想做的事件。这是咱们领有的基础设施层，能够用来一次为所有人解决问题。

这方面的一个具体例子呈现在咱们采纳过程的晚期。过后，咱们正致力于跨不同服务的日志标准化输入。通过采纳服务网格和这种新的设计模式，咱们可能将咱们的人的问题——让开发人员标准化他们的日志——换成技术问题——将所有流量传递给能够为他们记录日志的代理。这是咱们团队向前迈出的重要一步。

咱们对服务网格的实现十分求实，并且与该技术的外围性能十分吻合。然而，大部分营销炒作都集中在不太须要的边缘案例上，在评估服务网格是否适宜你时，可能辨认这些烦扰是很重要的。

外围性能

服务网格能够提供的外围性能分为四个要害责任畛域：可察看性、安全性、连接性和可靠性。这些性能包含：

标准化监控

咱们获得的最大胜利之一，也是最容易采纳的，是标准化监控。它的经营老本非常低，能够适应你应用的任何监控零碎。它使组织可能捕捉所有 HTTP 或 gRPC 指标，并以规范形式在整个零碎中存储它们。这管制了复杂性并加重了应用程序团队的累赘，他们不再须要实现 Prometheus 指标端点或标准化日志格局。它还使用户可能公正地理解其应用程序的黄金信号。

主动加密和身份辨认

证书治理很难做好。如果一个组织还没有在这方面进行投入，他们应该找到一个网格来为他们做这件事。证书治理须要保护具备微小安全隐患的简单基础设施代码。相比之下，网格将可能与编排系统集成，以理解工作负载的身份，在须要时能够用来执行策略。这容许提供与 Calico 或 Cilium 等功能强大的 CNI 提供的平安态势相当或更好的平安态势。

智能路由

智能路由是另一个个性，它使网格可能在发送申请时“做正确的事”。场景包含：

1. 应用提早加权算法优化流量
2. 拓扑感知路由以进步性能并降低成本
3. 依据申请胜利的可能性使申请超时
4. 与编排系统集成以进行 IP 解析，而不是依赖 DNS
5. 传输降级，例如 HTTP 到 HTTP/2

这些性能可能不会让普通人感到兴奋，但随着工夫的推移，它们从根本上减少了价值

牢靠的重试

在分布式系统中重试申请可能很麻烦，然而它简直总是须要实现的。分布式系统通常会将一个客户端申请转换为更多上游申请，这意味着“尾巴”场景的可能性会大大增加，例如产生异样失败的申请。对此最简略的缓解措施是重试失败的申请。

艰难来自于防止“重试风暴”或“重试 DDoS”，即当处于降级状态的零碎触发重试、随着重试减少而减少负载并进一步升高性能时。天真的实现不会思考这种状况，因为它可能须要与缓存或其余通信系统集成以理解是否值得执行重试。服务网格能够通过对整个零碎容许的重试总数进行限度来实现这一点。网格还能够在这些重试产生时报告这些重试，可能会在你的用户留神到零碎降级之前揭示你。

网络可扩展性

兴许服务网格的最佳属性是它的可扩展性。它提供了额定的适应性层，以应答 IT 下一步投入的任何事件。Sidecar 代理的设计模式是另一个令人兴奋和弱小的性能，即便它有时会被适度宣传和适度设计来做用户和技术人员还没有筹备好的事件。尽管社区在等着看哪个服务网格“生出”，这反映了之前适度炒作的编排和平，但将来咱们将不可避免地看到更多专门构建的网格，并且可能会有更多的最终用户构建本人的管制立体和代理以满足他们的场景。

服务网格烦扰

平台或基础设施管制层的价值怎么强调都不为过。然而，在服务网格世界中，我理解到入门的一个次要的挑战是，服务网格解决的外围问题通常甚至不是大多数服务网格我的项目交换的焦点！

相同，来自服务网格我的项目的大部分交换都围绕着听起来很弱小或令人兴奋但最终会让人分心的性能。这包含：

强（复）大（杂）的管制立体

要很好地运行简单的软件是十分艰难的。这就是为什么如此多的组织应用云计算来应用齐全托管的服务来加重这一点的起因。那么为什么服务网格我的项目会让咱们负责操作如此简单的零碎呢？零碎的复杂性不是资产，而是负债，但大多数我的项目都在吹捧它们的功能集和可配置性。

多集群反对

多集群当初是一个热门话题。最终，大多数团队将运行多个 Kubernetes 集群。然而多集群的次要痛点是你的 Kubernetes 治理的网络被切分。服务网格有助于解决这个 Kubernetes 横向扩大问题，但它最终并没有带来任何新的货色。是的，多集群反对是必要的，但它对服务网格的承诺被适度宣传了。

Envoy

Envoy 是一个很棒的工具，但它被作为某种规范介绍，这是有问题的。Envoy 是泛滥开箱即用的代理之一，你能够将其作为服务网格平台的根底。然而 Envoy 并没有什么外在的特别之处，使其成为正确的抉择。采纳 Envoy 会给你的组织带来一系列重要问题，包含：

• 运行时老本和性能（所有这些过滤器加起来！）
• 计算资源需要以及如何随负载扩大
• 如何调试谬误或意外行为
• 你的网格如何与 Envoy 交互以及配置生命周期是什么
• 运作成熟的工夫（这可能比你预期的要长）

服务网格中代理的抉择应该是一个实现细节，而不是产品要求。

WASM

我是 Web Assembly (WASM) 的忠诚拥趸，曾经胜利地应用它在 Blazor 中构建前端应用程序。然而，WASM 作为定制服务网格代理行为的工具，让你处于取得一个全新的软件生命周期开销的地步，这与你现有的软件生命周期齐全正交！如果你的组织还没有筹备好构建、测试、部署、保护、监控、回滚和版本代码（影响通过其零碎运行的每个申请），那么你还没有筹备好应用 WASM。

A/B 测试

直到为时已晚，我才意识到 A/B 测试实际上是一个应用程序级别的问题。在基础设施层提供原语来实现它是很好的，然而没有简略的办法来齐全自动化大多数组织须要的 A/B 测试程度。通常，应用程序须要定义独特的指标来定义测试的踊跃信号。如果组织想要在服务网格级别投入 A/B 测试，那么解决方案须要反对以下内容：

1. 对部署和回滚的精密管制，因为它可能同时进行多个不同的“测试”
2. 可能捕捉零碎晓得的自定义指标并能够依据这些指标做出决策
3. 依据申请的特色裸露对流量方向的管制，其中可能包含解析整个申请注释

这须要实现很多，没有哪个服务网格是开箱即用的。最终，咱们的组织抉择了网格之外的特色标记解决方案，其以最小的致力获得了微小的胜利。

咱们在哪里完结

最终，咱们面临的挑战并不是服务网格独有的。咱们工作的组织有一系列限度条件，要求咱们对解决的问题以及如何解决问题采取求实的态度。咱们面临的问题包含：

• 一个领有大量不同技能的开发人员的大型组织
• 云计算和 SaaS 能力广泛不成熟
• 为非云计算软件优化的流程
• 碎片化的软件工程办法和信念
• 无限的资源
• 激进的截止日期

简而言之，咱们人少，问题多，须要疾速输入价值。咱们必须反对次要不是 Web 或云计算的开发者，咱们须要扩充规模以反对有不同办法和流程的大型工程组织来做云计算。咱们须要将大部分精力集中在解决成熟度曲线较低的根本问题上。

最初，当面对咱们本人的服务网格决策时，咱们决定建设在 Linkerd 服务网格上，因为它最合乎咱们的优先事项：低经营老本（计算和人力）、低认知开销、支持性社区以及通明的治理——同时满足咱们的性能要求和估算。在 Linkerd 领导委员会工作了一段时间后（他们喜爱诚恳的反馈和社区参加），我理解到它与我本人的工程准则有如许的符合。Linkerd 最近在 CNCF 达到毕业状态，这是一个漫长的过程，强调了该项目标成熟及其宽泛采纳。

对于作者

Chris Campbell 负责软件工程师和架构师已有十多年，与多个团队和组织单干落地云原生技术和最佳实际。他在与业务领导者单干采纳减速业务的软件交付策略和与工程团队单干交付可扩大的云基础架构之间调配工夫。他对进步开发人员生产力和体验的技术最感兴趣。

文章对立公布在公众号 云原生指北