微服务高速通信设计

企业应用微服务化的思考

近年来越来越多的企业开始实践微服务，而微服务在企业应用落地的过程，面临着微服务开发框架的选型，无论是自研还是选择第三方框架都不得不考虑的问题包括：

微服务框架是否具备高可靠性，任何时间不能中断业务；

微服务框架是否能够实现高速通信性能，保证业务从单体架构向微服务架构切换时，能满足微服务业务的诉求。

本文从服务管理中心、通信处理两个模块来介绍华为开源微服务框架SeviceComb如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。

ServiceComb的底层通信框架依赖Vert.x.vertx标准工作模式为高性能的reactive模式，其工作方式如下图所示：

图2 同步模式下的整体线程模型

• 一个微服务进程中，为transport创建了一个独立的vertx实例

• Eventloop是vertx中的网络、任务线程

• 一个vertx实例默认的Eventloop数为：2 * Runtime.getRuntime().availableProcessors()

1

图3  最简单的单连接模型

从模型图中，我们可以看到，所有的consumer线程，如果向同一个目标发送数据，必然产生资源竞争，此时实际的处理如下：

优化的单连接模型

图4 优化的单连接模型

在优化模型中：

• 每个TcpClientConnection额外配备一个CAS消息队列

• Connection.send不再直接调用vertx的write方法，而是：

• 所有消息保存到CAS队列中，减少入队竞争

• 通过原子变量判定，只有入队前CAS队列为空，才向eventloop下发write任务，唤醒eventloop线程

• 在eventloop中处理write任务时，将多个请求数据包装为composite buffer，批量发送，减少进入os内核的次数，提高tcp发送效率。

io.servicecomb.foundation.vertx.client.tcp.TcpClientConnection.packageQueue io.servicecomb.foundation.vertx.client.tcp.TcpClientConnection.send(AbstractTcpClientPackage,long, TcpResponseCallback)

io.servicecomb.foundation.vertx.tcp.TcpConnection.write(ByteBuf) io.servicecomb.foundation.vertx.tcp.TcpConnection.writeInContext()

2

cse:   highway:     client:       thread-count: 线程数       server:       thread-count: 线程数

io.servicecomb.foundation.vertx.client.ClientPoolManager.findThreadBindClientPool()

每请求大小为1KB，可以看到万兆网的带宽接近吃满了，可以充分利用硬件性能。

(该测试环境，网卡支持RSS特性。)

1

下图为将业务逻辑用单独的线程池实现的方式。在这种方式下，IO仍然采用异步模式，所有接到的请求放入队列中等待处理。在同一个线程池内的线程消费这个队列并进行业务处理。

图6  单线程池实现方式

在这种方式下，有以下瓶颈点：

2

为规避线程池中Queue带来的瓶颈点，我们可以使用一个Executor将多个真正的Executor包起来。

图7  多线程池实现方式

• Eventloop线程与线程池建立均衡的绑定关系，降低锁冲突概率

• 相当于将线程分组，不同线程从不同Queue中抢任务，降低冲突概率

ServiceComb默认所有请求使用同一个线程池实例：io.servicecomb.core.executor.FixedThreadExecutor

FixedThreadExecutor内部默认创建2个真正的线程池，每个池中有CPU数目的线程，可以通过配置修改默认值：

servicecomb:   executor:     default:       group: 内部真正线程池的数目       thread-per-group: 每个线程池中的线程数

代码参见：

https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/core/src/main/java/io/servicecomb/core/executor/FixedThreadExecutor.java

3

4

ServiceComb微服务的概念模型如下：

图9  ServiceComb微服务概念模型

可以针对这3个层次进行线程池的配置，operation与线程池之间的对应关系，在启动阶段即完成绑定。

operation与线程池之间的绑定按以下逻辑进行：

1. 查看配置项cse.executors.Provider.[schemaId].[operationId]是否有值：

1. 如果有值，则将值作为beanId从spring中获取bean实例，该实例即是一个Executor

2. 如果没有值，则继续尝试下一步

2. 使用相同的方式，查看配置项cse.executors.Provider.[schemaId]是否有值

3. 使用相同的方式，查看配置项cse.executors.default是否有值

4. 以”cse.executor.groupThreadPool”作为beanId，获取线程池（系统内置的FixedThreadExecutor）

代码参见：

https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/core/src/main/java/io/servicecomb/core/executor/ExecutorManager.java

按以上策略，用户如果需要创建自定义的线程池，需要按以下步骤执行：

1. 实现java.util.concurrent.Executor接口

2. 将实现类定义为一个bean

3. 在microservice.yaml中将线程池与对应的业务进行绑定

5

如上一节所述，在默认多线程池的基础上，CSE提供了更为灵活的线程池配置。“隔离仓”模式的核心价值是实现不同业务之间的相互隔离，从而让一个业务的故障不要影响其他业务。这一点在CSE中可以通过对线程池的配置实现。例如，可以为不同的operation配置各自独立的线程池。

另外，灵活性也带来了一定的危险性。要避免将线程池配置为前面提到的“单业务线程池”模式，从而为整个系统引入瓶颈点。

Apache ServiceComb自开源以来，秉持将“复杂扔给自己，将极简留给用户”的原则，诸多技术创新被证明对于微服务化行之有效，并先后获得云计算开源大会《2018 OSCAR 尖峰开源技术奖》和云计算标准和应用大会《中国优秀开源项目一等奖》，这些都离不开社区开源开发者们的共同努力，我们在此也非常欢迎各位感兴趣的读者前往开源社区和我们讨论切磋，甚至加入我们，希望此文可以给正在进行微服务方案实施的读者们一些启发。

往期精彩大放送

长按添加小助手，加入我们

点击左下角“阅读原文”，给SeriveComb加个Star吧