服务网格(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 和内存消耗。

全面比较六种服务网格