打造一个企业级应用的微服务开发框架（下）---ServiceComb通信处理详解

【摘要】近年来越来越多的企业开始实践微服务，本文分为上下两篇介绍微服务框架ServiceComb 如何帮助企业应用进行微服务化，实现快速交付，并可靠地运行在云端。下篇介绍ServiceComb 的通信处理设计。

近年来越来越多的企业开始实践微服务，而微服务在企业应用落地的过程，面临着微服务开发框架的选型，无论是自研还是选择第三方框架都不得不考虑的问题包括：微服务框架是否具备高可靠性，任何时间不能中断业务；微服务框架是否能够实现高速通信性能，保证业务从单体架构向微服务架构切换时，性能下降不会太多。本文从服务管理中心、通信处理两个模块来介绍华为开源微服务框架SeviceComb如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。下篇将详细介绍ServiceComb的通信处理。

ServiceComb通信处理详解 1     整体介绍

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

图9 reactive模式工作方式

业务逻辑直接在eventloop中执行，整个业务流程中没有线程切换，所有的等待逻辑都是异步的，只要有任务，则不会让线程停下来，充分、有效地利用系统资源。

vertx生态中包含了业界常用各种组件的reactive封装，包括jdbc、zookeeper、各种mq等等。但是reactive模式对业务的要求相当高，业务主流程中不允许有任何的阻塞行为。因此，为了简化上层业务逻辑，方便开发人员的使用，在Vertx之上提供同步模式的开发接口还是必不可少的，例如：

• 各种安全加固的组件，只提供了同步工作模式，比如redis、zookeeper等等
• 一些存量代码工作于同步模式，需要低成本迁移
• 开发人员技能不足以控制reactive逻辑
  

所以ServiceComb底层基于vertx，但在vertx之上进行了进一步封装，同时支持reactive及同步模式。

工作于Reactive模式时，利用Vertx原生的能力，不必做什么额外的优化，仅需要注意不要在业务代码中阻塞整个进程。

而同步模式则会遭遇各种并发性能问题。，本文描述同步模式下的各种问题以及解决方案。

RESTful流程中，连接由vertx管理，当前没有特别的优化，所以本文中，连接都是指highway流程中的tcp连接。

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

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

• 一个微服务进程中，为transport创建了一个独立的vertx实例
• Eventloop是vertx中的网络、任务线程
• 一个vertx实例默认的Eventloop数为：2 * Runtime.getRuntime().availableProcessors()
  

3     服务消费者端

在服务消费者端，主要需要处理的问题是如何更加高效地把请求推送到服务提供者上去，然后拿到服务提供者的返回信息。所以在这一端我们主要关注“如何更高效的发送数据”这个话题。

3.1    单连接模型 最简单的单连接模型