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

不少同窗看到这个题目，必定会提这样的问题：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项目在不一样层次和方面的对比。

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上有着丰富的实践和开发经验。

---

阿里巴巴中间件官方微博 ※一个集干货与前卫的技术号