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 种服务网格框架:

6 大 Service Mesh 横向对比!

服务网格接口

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

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

如何选择服务网格实现

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

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

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

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

全面比较六种服务网格

6 大 Service Mesh 横向对比!

支持的协议

6 大 Service Mesh 横向对比!

服务网格接口兼容性

6 大 Service Mesh 横向对比!

监控功能

6 大 Service Mesh 横向对比!

路由功能

6 大 Service Mesh 横向对比!

弹性功能

6 大 Service Mesh 横向对比!

安全功能

6 大 Service Mesh 横向对比!

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

服务网格的替代品

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

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

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

没有(同步)微服务

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

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

参考文献

servicemesh.es/?

原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/tech/cloud/309728.html

(0)
上一篇 2023年12月5日 23:49
下一篇 2023年12月6日 00:23

相关推荐

发表回复

登录后才能评论

WordPress 数据库错误: [Duplicate entry '80-d16c1647a53da3ad6bbb3d1108156ba7' for key 'task_id_source_url_key']
insert into wp_autoblog_queue(task_id,source_url,source_url_key,create_date_time,not_check_stoped,post_interval) values(80,'https://pythonjishu.com/robotic-process-automation/','d16c1647a53da3ad6bbb3d1108156ba7',1735181583,0,0)