从微服务治理的角度看RSocket、. Envoy和. Istio

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介:

_2018_12_23_2_04_47

很多同学看到这个题目,一定会提这样的问题:RSocket是个协议,Envoy是一个 proxy,Istio是service mesh control plane + data plane。 这三种技术怎么能放在一起比较呢?

的确,从技术定位的角度来讲,它们确实是有很大的差距。但是,如果我们用RSocket来治理微服务,会有哪些不同呢?

RSocket

RSocket是一种应用层协议,不是一个传输层的协议。一方面,它可以包容和支持不同的传输层协议和相关技术,比如tcp 和 proto buf。另一方面,它的重点是把反应流的实现,提升到应用层上来。

其实在底层的协议中,就有反应流的实现,tcp的滑动窗口就是很好的例子。但是往上,这种好的机制不见了,给编程的工作造成很多的麻烦。很大一部分的线上故障是由于阻塞链接造成的。另一方面,很多应用层的网络软件,从设计的时候就开始避免这样的麻烦,造成结构臃肿,通讯效率底下。简单的例子是如果所有的通讯都是反应式的,那就不用熔断了。

基于RSocket 的应用不止是端到端通讯,Broker也是对这个协议水到渠成的应用。作为一个反应式的Broker,它同样是异步,非阻塞的通讯方式,主要维护与就近的各个应用的链接以及和其它Broker的链接。与其它协议相比,它是多路复用,同时支持长链接。

经过这样的解释,不难理解,本文主要是针对RSocket应用通过RSocket Broker联结而形成的Mesh,与其它Service Mesh项目在不同层次和方面的对比。

514b3e6e4aadaca4140b398f4b950fb1

RSocket vs .Envoy

Envoy作为一个proxy,它主要是基于HTTP2/HTTP1.1的协议,当然这样做是符合市场的口味,但是这个协议的局限性也限制了Envoy的性能。这就是我们比较的第一点,

1.Envoy不支持多路复用,非阻塞和有限支持长链接。说是有限,其实就是不支持,因为你的链接只要不能一直开着,就得依靠第三方做health check。这绝对增加开发难度。不支持多路复用,就无法对每个服务都开个链接,那么就要靠第三方作service registry。

这样的限制,不但使得Envoy必须依靠一个control plane,自己无法独立担负weave mesh的重担,而且也大大限制了它的性能,比如新版本Istio Proxy(就是Envoy)用的联接池管理就占了很多的内存。

2.RSocket的主要障碍是应用程序之间必须要用RSocket通讯。随着Spring Cloud的推出,Spring Framework 5.2 即将要把RSocket作为缺省的反应通讯协议,以及Dubbo和RSocket 的整合,大家接触RSocket的机会也会越来越多。

3.很多场合中会听到Envoy支持Polygoat,好像用了Envoy就不用SDK了。这种说法显然是错觉。SDK是一定要的,为了支持Polygoat,就要选多语言支持的SDK。因为调用另一个服务的代码还是发生在自己的程序中,这不是Envoy可以替代的。Envoy所说的省却SDK开发,是指所谓的“胖SDK”, 就是包括了服务发现和路由功能的SDK,类似大家现在用的Dubbo,那的确是会让SDK瘦身的。但是如果用了RSocket的Broker,这些SDK同样也不用再“胖”了,而且RSocket协议也有不同语言的SDK。

RSocket vs .Istion

除了上述的简化和高效等特性外,相比Istio,RSocket Broker 有一个主要的优势,那就是不依赖Kubernets 。虽然Istio也号称不依赖Kubernets,但是在Kubernets外部署和管理sidecar proxy可不是一件容易的事,而RSocket Broker却是哪里都能部署。

作为一个Service Mesh solution, Istio其实是很难在 data center外应用的。那么对于众多的IoT设备怎么办?每一台手机上装个sidecar?而RSocket是很小且高效的SDK,这也是像Facebook这样的主要手机应用商选择RSocket的原因。

Istio主打的特性是observability, security and control。从observability和control方面来说,RSocket Broker虽然有接口,但是实现还不够,特别是API的部分。这也是社区要努力的一个方向。从security来说,如果是单纯RSocket的服务是不用开端口的,这是又一项由先进协议带来的对特性的简化,以后会有更多的介绍。

结论

很早以前,在分布程序中访问另一个服务是很直观,透明的事。微服务普及后,其为了“简化”微服务之间的通讯,引入了很多层的技术栈。这当然是好事,但是很多的决定是由于收到上一代的通讯协议的技术所限制。

RSocket的反应流技术,简化了程序间通讯对其它部件的依赖。我们可以享受Service Mesh提供的便利而不用那么复杂的技术栈。当然RSocket带来的好处不只是简单。在我们的初步实验中,RSocket Broker的service mesh比Istio带来将近10倍的速度提升。如果大家有兴趣,可以去了解一下RSocket.

Andy Shi:阿里巴巴中间件硅谷团队 Istio 技术专家,Andy长期关注Service Mesh,在Cloud Foundry,Kubernetes,Envoy上有着丰富的实践和开发经验。

相关文章
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
64 2
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
82 8
Istio在微服务中释放服务网格的力量
Istio在微服务中释放服务网格的力量
85 4
Istio:微服务治理的超级英雄,一键解锁你的服务网格超能力,让管理复杂变简单!
【8月更文挑战第31天】随着云原生技术的发展,微服务架构成为主流,但其复杂性与管理难题也随之增加。Istio作为开源服务网格平台,通过独特的数据平面和控制平面设计,实现了微服务通信的透明管理,简化了治理复杂度。本文将对比Istio与传统微服务管理方法,详细介绍Istio的架构及其工作原理,包括Envoy代理、服务发现、负载均衡、流量管理、安全认证以及监控等功能。Istio不仅简化了微服务治理,还提供了强大的流量控制和安全机制,使开发者能更高效地管理应用。
150 2
震惊!单人开发者如何成功过渡到团队协作?Xamarin 项目管理经验大揭秘,让你的开发之路一帆风顺!
【8月更文挑战第31天】Xamarin 是移动应用开发领域的热门跨平台工具,适用于个人开发者及团队。个人开发时需明确需求、运用版本控制(如 Git)并合理规划项目结构以增强代码可维护性。团队协作时,则需建立有效沟通渠道、统一代码规范、严格版本控制及合理分配任务,以提升开发效率与项目质量。
79 1
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
在5G电信领域,Kubernetes集群中部署微服务至关重要,但也带来了重大的安全挑战。Istio作为一个强大的开源服务网格,能有效地管理这些微服务间的通信,通过其控制平面自动将Sidecar代理注入到各微服务Pod中,确保了安全且高效的通信。Istio的架构由数据平面和控制平面组成,其中Sidecar代理作为Envoy代理运行在每个Pod中,拦截并管理网络流量。此外,Istio支持多种Kubernetes发行版和服务,如EKS等,不仅增强了安全性,还提高了应用性能和可观测性。
99 0
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
云原生架构下的微服务治理之道
【7月更文挑战第30天】在数字化转型的浪潮中,企业级应用正迅速向云原生架构迁移。本文将深入探讨云原生环境下微服务治理的最佳实践,包括服务发现、配置管理、流量控制等关键策略,并结合实例分析如何在保障系统弹性、可维护性的同时,优化资源利用效率和加快业务创新速度。
67 2
云原生架构下的微服务治理之道
【7月更文挑战第20天】在数字化转型的浪潮中,企业纷纷拥抱云原生,以期实现更高效的资源利用、更快的业务迭代和更强的系统稳定性。本文将深入探讨如何通过云原生架构优化微服务的治理,确保系统的高可用性和可维护性,同时提升开发效率和运维灵活性。我们将从微服务治理的核心原则出发,结合具体案例,分析在云环境中实施微服务治理的策略与挑战。
60 2
云原生架构下的微服务治理实践
在数字化转型的浪潮中,云原生技术以其灵活性和可扩展性成为现代软件工程的基石。本文将深入探讨云原生架构下微服务治理的实践路径,从微服务的拆分、容器化部署、服务网格的应用到最终的监控与故障排除,提供一套全面的方法论。文章旨在为读者呈现一个清晰的云原生环境下,如何高效管理和维护微服务系统的全景图。
72 2
云原生架构下的微服务治理与挑战
随着云计算技术的不断演进,云原生架构已成为现代应用开发的首选模式。本文将深入探讨在云原生环境下,微服务治理的重要性、实现方法及所面临的挑战。通过分析微服务治理的关键要素如服务发现、配置管理、负载均衡和故障转移等,揭示如何在高度动态的云环境中保持服务的高可用性和灵活性。同时,本文也将指出在实施微服务治理过程中可能遇到的技术难题和应对策略,为构建健壮的云原生应用提供指导。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等