共计 2271 个字符，预计需要花费 6 分钟才能阅读完成。
如何从微服务治理的角度看 RSocket、. Envoy 和. Istio，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
很多同学看到这个题目，一定会提这样的问题：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）用的联接池管理就占了很多的内存。
而对于 RSocket 来说，
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 倍的速度提升。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。
