RSocket 从入门到落地：两种微服务对比

✏️ Pic by Alibaba Tech on Facebook

技术实践的作用在于：除了用于构建业务，也是为了验证某项技术或框架是否值得大规模推广。

这是《RSocket 从入门到落地》系列文章的第三篇，来一起对比下开发微服务应用和微服务之间的网络通讯。该系列文章作者是阿里巴巴资深技术专家雷卷。

第一篇：Servlet vs RSocket「传送门」

第二篇：Spring Cloud Config Server 的 RSocket 实现方式「传送门」

如何发布一个微服务

我们如何编写和发布一个微服务？

这个当然非常简单，用 Spring Boot 创建一个小应用，然后写一些 Rest Controller，然后应用启动，启动监听端口，然后就对外提供服务啦。 这里面有三个非常重要的点：服务实现，服务端口监听和注册中心。 如果是Web服务，RestController 是实现，然后 Eureka 或者 Nacos 作为服务注册中心。然后 Config server是注册中心。 典型的结构如下：

上图中，一些功能比较强的注册中心还要负责服务的健康度检查。

如何停止一个微服务

服务停止和服务发布同样重要。

当服务 ready 后，向注册中心注册，对外提供服务。但是下线，不能任性，要有一个流程。首先告诉注册中心一个应用要下线，然后注册中心向所有的应用广播，Xxx 服务中的 IP 要下线，所有应用收到消息后，更新路由表，在等上一个30秒或者更少(根据超时时间来决定)，然后断开连接，最后应用想注册中心发出下线指令，然后下线。

基于 RSocket 的微服务如何发布？

一样，需要写一个 Spring Boot 应用，然后实现 RSocket 的 Reactive Service 接口，然后启动应用，连接到Broker，结束。

为何不启动监听端口，其他人如何访问我的服务呢？ 

下面我们介绍一下。RSocket 有两种模式，一种是独立对外发布服务，另外一种是基于Broker对外发布服务，前一种是要监听的，后一种则不需要，结构图如下：

RSocket 是全双工相互通讯的，所以一个连接既可以用于服务发布，可以用于服务调用。服务发布的时候，会在发布端添加一个 RSocket 的Handler，负责处理连接上发过来的请求，就这样。 所以对一些服务发布是不需要端口监听的。没有端口监听，那好处太多了：

• 安全：想通过端口扫描攻击我，不可行。

• TLS证书：没有监听端口，但是还是有一点安全风险，就是别人会伪造TCP请求，当然这个有点难度，但是借助工具，还是有人能做到。 如果是证书，那只需要Broker一个有证书就可以啦，其他服务发布者都不需要。如果有监听端口的话，可能每一个应用都需要配置证书。

• 强烈的瘦身：Tomcat，ServerSocket，连接池，线程池等都不需要，应用一下子轻了好几十斤。我可以愉快的编译和部署啦，程序基本可以秒启动。

• 无网络要求：CNI，容器容器直接通讯，这些可以全不要，类似的网络黑科技在 RSocket 面前都不需要，可以说网络无损且皮实。 传统网络，可以，就几个Docker主机，没有问题，Kubernetes和传统混搭，也可以。

• FaaS的好朋友：你知道的，函数挂上去就可以，不需要处理任何事情。体积小、启动快、而且不用考虑安全需要。不会有安全团队找你麻烦啦，你这个接口非常重要，安全如何做的。

这种架构后，没有注册中心，不需要应用下线推送，应用接入 Broker 后，Service Mesh 需要的特性全都满足：安全，metrics，access logging，灰度等，全部基于消息搞定了。

如果停止RSocket微服务

前面讲到服务下线流程，有点复杂。 

RSocket 服务下线则非常简单，给 Broker 发一个指令说哪个连接要下线，然后 Broker 将这个RSocket 连接从服务列表中拿出来，然后触发一个30秒的延迟事件给服务发布方，确保该服务进入Drain(请求消费完毕)模式，服务发布者收到事件后，应用applicationContext.close()然后coutdown latch退出。 如果都是request/response，这个没有问题，但是 RSocket 还提供非常复杂的通讯，所以优雅下线可能还需要一些工作，如request/stream到另外一个RSocket连接上。 

如果你的应用跑在Kubernetes中，应用退出后，也代表这个 POD 停掉，这个时候 K8s 会尝试重新启动一个新的 POD，如果你设置容器启动拉取最新的 Docker 镜像，其实你已经完成了一次重新发布。而这一切只需要 broker 给这个 RSocket 连接发送一个退出的事件。

总结

眼尖的同学可能会有疑问，这个是中心化设计，有瓶颈，性能和风险很大。确实有这个问题。但是我们知道，一些服务，如会员、商品、交易等，可以继续以 P2P 方式通讯，没有问题。但是一些非关键的服务，可以通过 Broker 方式来完成。但是，这个 Broker 非常高效，这也是RSocket 为何设计了一套自定义的二进制通讯协议，是出于性能要求，所以一个连接过来，通常只需要分析很少的 bytes，然后将流量转发到后端就可以，零拷贝技术(zero-copy)。可以理解为路由器方式，性能非常高。 最关键的是，整个通讯全异步，零阻塞，没有之前的线程池爆掉的风险，所以是非常稳定的，可以告别配置线程池的日子了。

本文作者：

雷卷，GitHub ID linux-china，Java 程序员，阿里云智能资深技术专家。

/ 推荐一个值得参与的「开发者活动」 /

©每周一推

第一时间获得下期分享

☟☟☟

Tips：

# 点下“在看”❤️

# 然后，公众号对话框内发送“Polo衫”，试试手气？?

# 本期奖品是 Aliware 定制 Polo衫。