6 大 Service Mesh 横向对比！

服务网格（Service mesh）是服务间通信的基础设施层。它对全局流量和通信进行监控和管理，提供包括可观察性、流量转移（用于灰度发布）、弹性能力（例如断路和重试/超时）等一系列功能，并为服务之间的通信提供双向 TLS 认证能力，让网格能够对请求和响应进行自动加密和解密。

相比其他具备相似功能的库，服务网格不需要更改代码。它添加了一层额外的容器，并依靠这些容器可靠地实现了上述特性，不依赖于任何技术和编程语言。

2019 年，云原生计算基金会（CNCF）在美国圣地亚哥举办了第一届 ServiceMeshCon，IBM 高级技术人员 Lin Sun 在会上梳理了近几年来服务网格的发展历程。

• 2015 年，Netflix OSS stack 发布，它推出了一种基于 Java/JVM 的微服务通信库；
• 2017 年 5 月，Google、IBM 和 Lyft 联合开源的 Istio 发布；
• 2018 年 9 月，Linkerd 2.0 正式发布；
• 2018 年 11 月，Consul Connect 和 SuperGloo 发布；
• 2019 年 5 月，服务网格互通性规范 SMI 被推出；
• 2019 年 9 月，Maesh 和 Kuma 发布。

时至今日，服务网格和 Sidecar 模式已越来越受欢迎，并在社区内得到更广泛采用。面对这股 IT 界的新潮流，K8sMeetup 中国社区特推出 6 大主流服务网格框架的系统对比，以飨读者。

谁需要服务网格？

随着应用程序所包含的服务不断增加，应用程序复杂性不断逼近临界点，服务网格在 IT 系统中的价值也跟着水涨船高。

从理论上讲，微服务架构应该是服务网格最常见的用例。但实际的情况是，企业和组织在采用服务网格时，会优先考虑它在改进服务的控制、可靠性、安全性和可观察性上的效果。所以有时一个庞大的服务也能从服务网格中获益，有时某些具体的微服务应用却没法用服务网格解决服务治理问题。

六大服务网格实现

下面是目前全球范围内比较受欢迎的 6 种服务网格框架：

服务网格接口

面对各种服务网格实现，包括微软、Buoyant（Linkerd）和 HashiCorp（Consul）在内的多家公司联手创建了服务网格互通性规范，即服务网格接口规范 SMI。

它的出现意味着开发者在使用基于服务网格功能的工具（例如 Canary Release Automation 的 Flagger）时，能够与任何服务网格兼容，而不是绑定到特定的服务网格实现上。同时，开发者无需更改配置即可改变其服务网格实现的能力。

如何选择服务网格实现

虽然服务网格对代码没有侵入性，但不同服务网格在概念和技术上还是存在一些区别。考虑到目前很多企业还没有广泛支持服务网格接口，因此慎重挑选、把服务网格选型做为一项长期决策是必要的。

例如，在选择过程中，很多人会一拍脑门就选择功能最多、最灵活的服务网格，但这类工具对认知水平和技术水平的要求比较高，不一定真正适合每个场景。所以只有清楚自己的需求和目的，才能选出最理想的方案。

下面是关于服务网格选择的一些建议：

• 作为一个团队，你们最想用服务网格解决什么问题？这些问题能不能通过调用库或调整体系结构来解决；
• 你们对易用性、可用性、性能和兼容性有什么具体要求；
• 根据你们的功能性和非功能性需求确定最重要的两个或三个实现；
• 通过文档教程尝试每种服务网格实现，做排除法；
• 测试单个应用程序的延迟和资源开销。对所有服务网格进行测试并设置对照组，使用工具全面执行负载测试，观察请求延迟、CPU 和内存消耗。

全面比较六种服务网格

支持的协议

服务网格接口兼容性

监控功能

路由功能

弹性功能

安全功能

*可能可以通过手动配置/代理模板来实现

服务网格的替代品

毫无疑问，服务网格很有用，但每个团队也不能忽视它背后的技术和认知门槛。在一些情况下，使用一些众所周知的“普通”技术作为替代解决方案是明智的。

库

库包含在微服务中。它的缺点是依赖于特定的技术/语言，因此存在潜在的不一致性及服务基础架构和业务逻辑的分离。但是，通过使用熟悉的库，企业至少可以在短期内提高开发人员的开发效率。此外，当遇到像为断路器配置回退或定义业务指标这样的情况时，开发者需要具备相关知识来解决，这种情况下服务网格是没有用的。

服务网格的前提是对基础架构进行更改，目前这对很多团队来说风险太大，无法接受。所以使用服务网格需要考虑整体需求，即使服务网格只能应用于特定的服务，更改风险也可能很大。

没有（同步）微服务

服务网格的主要作用是同步通信，它通常依靠 HTTP 协议来传输额外的信息。而企业采用微服务架构的原因之一是为了缩短软件交付周期。尽管存在一些缺陷，如高延迟和紧密耦合，但同步实现微服务通信是一种常见的做法。但是，我们也有更多的方法可以实现微服务通信，甚至可以在一开始就避免依赖。比如 SCS 和异步通信这样的模式旨在缓解经典微服务（同步通信）的许多问题。当然，你也可以使用 HTTP 来实现异步微服务，比如通过轮询 feed 来获取新的事件。

服务网格只能帮助一个整体与其他系统通信，而不能帮助内部通信。

参考文献

https://servicemesh.es/?