详解总结ServiceComb的通信处理

 微服务开源框架 ServiceComb 致力于帮助企业快速构建云原生应用,通过一系列解决方案帮助用户快速开发微服务应用的同时实现对这些微服务应用的高效运维管理。其包括一站式的服务注册、服务治理、动态配置功能,具备服务化契约增强、多语言支持、多通信协议支持等优势特性, 并提供SAGA数据最终一致性方案解决微服务架构数据一致性难题。ServiceComb 兼容Spring Cloud等业界流行微服务框架,互通业界生态。今天我们来介绍ServiceComb 的通信处理。

 
整体介绍
 
ServiceComb的底层通信框架依赖Vert.x. vertx标准工作模式为高性能的Reactive模式,其工作方式如下图所示:
详解总结ServiceComb的通信处理
                                                   图 Reactive模式工作方式
 
业务逻辑直接在Eventloop中执行,整个业务流程中没有线程切换,所有的等待逻辑都是异步的,只要有任务,则不会让线程停下来,充分、有效地利用系统资源。
 
vertx生态中包含了业界常用各种组件的Reactive封装,包括jdbc、zookeeper、各种mq等等。但是Reactive模式对业务的要求相当高,业务主流程中不允许有任何的阻塞行为。因此,为了简化上层业务逻辑,方便开发人员的使用,在Vertx之上提供同步模式的开发接口还是必不可少的,例如:
 
各种安全加固的组件,只提供了同步工作模式,比如redis、zookeeper等等;
 
一些存量代码工作于同步模式,需要低成本迁移;
 
开发人员技能不足以控制Reactive逻辑。
 
所以ServiceComb底层基于vertx,但在vertx之上进行了进一步封装,同时支持Reactive及同步模式。
 
工作于Reactive模式时,利用Vertx原生的能力,不必做什么额外的优化,仅需要注意不要在业务代码中阻塞整个进程。
 
而同步模式则会遭遇各种并发性能问题。,本文描述同步模式下的各种问题以及解决方案。
 
RESTful流程中,连接由vertx管理,当前没有特别的优化,所以本文中,连接都是指highway流程中的tcp连接。
 
同步模式下的整体线程模型
详解总结ServiceComb的通信处理
                                                                   图 同步模式下的整体线程模型
 
一个微服务进程中,为transport创建了一个独立的vertx实例;
 
Eventloop是vertx中的网络、任务线程;
 
一个vertx实例默认的Eventloop数为:
 
2 * Runtime.getRuntime().availableProcessors()
 
服务消费者端
 
在服务消费者端,主要需要处理的问题是如何更加高效地把请求推送到服务提供者上去,然后拿到服务提供者的返回信息。所以在这一端我们主要关注“如何更高效的发送数据”这个话题。
 
1、最简单的单连接模型
详解总结ServiceComb的通信处理