今天的介紹ServiceComb的通信處理詳解。

整體介紹

ServiceComb的底層通信框架依賴Vert.x. vertx標(biāo)準(zhǔn)工作模式為高性能的Reactive模式，其工作方式如下圖所示：

圖 Reactive模式工作方式

業(yè)務(wù)邏輯直接在Eventloop中執(zhí)行，整個(gè)業(yè)務(wù)流程中沒有線程切換，所有的等待邏輯都是異步的，只要有任務(wù)，則不會(huì)讓線程停下來(lái)，充分、有效地利用系統(tǒng)資源。

vertx生態(tài)中包含了業(yè)界常用各種組件的Reactive封裝，包括jdbc、zookeeper、各種mq等等。但是Reactive模式對(duì)業(yè)務(wù)的要求相當(dāng)高，業(yè)務(wù)主流程中不允許有任何的阻塞行為。因此，為了簡(jiǎn)化上層業(yè)務(wù)邏輯，方便開發(fā)人員的使用，在Vertx之上提供同步模式的開發(fā)接口還是必不可少的，例如：

各種安全加固的組件，只提供了同步工作模式，比如redis、zookeeper等等；

一些存量代碼工作于同步模式，需要低成本遷移；

開發(fā)人員技能不足以控制Reactive邏輯。

所以ServiceComb底層基于vertx，但在vertx之上進(jìn)行了進(jìn)一步封裝，同時(shí)支持Reactive及同步模式。

工作于Reactive模式時(shí)，利用Vertx原生的能力，不必做什么額外的優(yōu)化，僅需要注意不要在業(yè)務(wù)代碼中阻塞整個(gè)進(jìn)程。

而同步模式則會(huì)遭遇各種并發(fā)性能問題。，本文描述同步模式下的各種問題以及解決方案。

RESTful流程中，連接由vertx管理，當(dāng)前沒有特別的優(yōu)化，所以本文中，連接都是指highway流程中的tcp連接。

同步模式下的整體線程模型

圖 同步模式下的整體線程模型

一個(gè)微服務(wù)進(jìn)程中，為transport創(chuàng)建了一個(gè)獨(dú)立的vertx實(shí)例；

Eventloop是vertx中的網(wǎng)絡(luò)、任務(wù)線程；

一個(gè)vertx實(shí)例默認(rèn)的Eventloop數(shù)為：

2 * Runtime.getRuntime().availableProcessors()

服務(wù)消費(fèi)者端

在服務(wù)消費(fèi)者端，主要需要處理的問題是如何更加高效地把請(qǐng)求推送到服務(wù)提供者上去，然后拿到服務(wù)提供者的返回信息。所以在這一端我們主要關(guān)注“如何更高效的發(fā)送數(shù)據(jù)”這個(gè)話題。

單連接模型

1、最簡(jiǎn)單的單連接模型

圖 最簡(jiǎn)單的單連接模型

從模型圖中，我們可以看到，所有的consumer線程，如果向同一個(gè)目標(biāo)發(fā)送數(shù)據(jù)，必然產(chǎn)生資源競(jìng)爭(zhēng)，此時(shí)實(shí)際的處理如下：

Connection.send內(nèi)部直接調(diào)用Vertx的socket.write(buf)，是必然加鎖互斥的。

這必然導(dǎo)致大量并發(fā)時(shí)，大多數(shù)consumer線程都無(wú)法及時(shí)地發(fā)送自己的數(shù)據(jù)。

Socket.write內(nèi)部會(huì)調(diào)用netty的channel.write，此時(shí)會(huì)判斷出執(zhí)行線程不是Eventloop線程，所以會(huì)創(chuàng)建出一個(gè)任務(wù)并加入到Eventloop任務(wù)隊(duì)列中，如果Eventloop線程當(dāng)前在睡眠態(tài)，則立即喚醒Eventloop線程，異步執(zhí)行任務(wù)。

這導(dǎo)致頻繁的任務(wù)下發(fā)及線程喚醒，無(wú)謂地增加cpu占用，降低性能。

2、優(yōu)化的單連接模型

圖 優(yōu)化的單連接模型

在優(yōu)化模型中：

每個(gè)TcpClientConnection額外配備一個(gè)CAS消息隊(duì)列；

Connection.send不再直接調(diào)用vertx的write方法，而是：

所有消息保存到CAS隊(duì)列中，減少入隊(duì)競(jìng)爭(zhēng)；

通過原子變量判定，只有入隊(duì)前CAS隊(duì)列為空，才向Eventloop下發(fā)write任務(wù)，喚醒Eventloop線程；

在Eventloop中處理write任務(wù)時(shí)，將多個(gè)請(qǐng)求數(shù)據(jù)包裝為composite buffer，批量發(fā)送，減少進(jìn)入os內(nèi)核的次數(shù)，提高tcp發(fā)送效率。

代碼參見：

https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/foundations/foundation-vertx/src/main/java/io/servicecomb/foundation/vertx/client/tcp/TcpClientConnection.java

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

https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/foundations/foundation-vertx/src/main/java/io/servicecomb/foundation/vertx/tcp/TcpConnection.java

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

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

進(jìn)行此項(xiàng)優(yōu)化后，在同一環(huán)境下測(cè)試2組數(shù)據(jù)，可以看到性能有明顯提升（不同硬件的測(cè)試環(huán)境，數(shù)據(jù)可能差異巨大，不具備比較意義）：

表：?jiǎn)芜B接模型優(yōu)化前后性能對(duì)比

多連接模型

在單連接場(chǎng)景下進(jìn)行相應(yīng)的優(yōu)化后，我們發(fā)現(xiàn)其實(shí)還有更多的優(yōu)化空間。因?yàn)樵诖蠖鄶?shù)場(chǎng)景中，實(shí)際機(jī)器配置足夠高，比如多核、萬(wàn)兆網(wǎng)絡(luò)連接、網(wǎng)卡支持RSS特性等。此時(shí)，需要允許一對(duì)consumer與producer之間建立多條連接來(lái)充分發(fā)揮硬件的性能。

圖 多連接模型

允許配置多個(gè)Eventloop線程

在microservice.yaml中進(jìn)行以下配置：

cse:

highway:

client:

thread-count: 線程數(shù)

server:

thread-count: 線程數(shù)

Consumer線程與Eventloop線程建立均衡的綁定關(guān)系，進(jìn)一步降低consumer線程的競(jìng)爭(zhēng)概率。

代碼參見：

https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/foundations/foundation-vertx/src/main/java/io/servicecomb/foundation/vertx/client/ClientPoolManager.java

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

優(yōu)化后的性能對(duì)比：

表 多連接下線程模型優(yōu)化前后性能對(duì)比

每請(qǐng)求大小為1KB，可以看到萬(wàn)兆網(wǎng)的帶寬接近吃滿了，可以充分利用硬件性能。

(該測(cè)試環(huán)境，網(wǎng)卡支持RSS特性。)

服務(wù)提供者端

不同于服務(wù)消費(fèi)者，服務(wù)提供者主要的工作模式就是等待消費(fèi)者的請(qǐng)求，然后處理后返回應(yīng)答的信息。所以在這一端，我們更加關(guān)注“如何高效的接收和處理數(shù)據(jù)”這件事情。

同步模式下，業(yè)務(wù)邏輯和IO邏輯分開，且根據(jù)“隔離倉(cāng)”原則，為了保證整個(gè)系統(tǒng)更加穩(wěn)定和高效地運(yùn)行，業(yè)務(wù)邏輯本身也需要在不同隔離的區(qū)域內(nèi)運(yùn)行。而這些區(qū)域，就是線程池。所以構(gòu)建服務(wù)提供者，就需要對(duì)線程池進(jìn)行精細(xì)的管理。

下面是針對(duì)線程池的各種管理方式。

1、單線程池(ThreadPoolExecutor)

下圖表示的是將業(yè)務(wù)邏輯用單獨(dú)的線程池實(shí)現(xiàn)的方式。在這種方式下，IO仍然采用異步模式，所有接到的請(qǐng)求放入隊(duì)列中等待處理。在同一個(gè)線程池內(nèi)的線程消費(fèi)這個(gè)隊(duì)列并進(jìn)行業(yè)務(wù)處理。

圖 單線程池實(shí)現(xiàn)方式

在這種方式下，有以下瓶頸點(diǎn)：

所有的Eventloop向同一個(gè)Blocking Queue中提交任務(wù)；

線程池中所有線程從同一個(gè)Blocking Queue中搶任務(wù)執(zhí)行；

ServiceComb默認(rèn)不使用這種線程池。

2、多線程池(ThreadPoolExecutor)

為規(guī)避線程池中Queue帶來(lái)的瓶頸點(diǎn)，我們可以使用一個(gè)Executor將多個(gè)真正的Executor包起來(lái)。

圖 多線程池實(shí)現(xiàn)方式

Eventloop線程與線程池建立均衡的綁定關(guān)系，降低鎖沖突概率；

相當(dāng)于將線程分組，不同線程從不同Queue中搶任務(wù)，降低沖突概率。

ServiceComb默認(rèn)所有請(qǐng)求使用同一個(gè)線程池實(shí)例：

io.servicecomb.core.executor.FixedThreadExecutor

FixedThreadExecutor內(nèi)部默認(rèn)創(chuàng)建2個(gè)真正的線程池，每個(gè)池中有CPU數(shù)目的線程，可以通過配置修改默認(rèn)值：

servicecomb:

executor:

default:

group: 內(nèi)部真正線程池的數(shù)目

thread-per-group: 每個(gè)線程池中的線程數(shù)

代碼參見：

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

3、隔離倉(cāng)

業(yè)務(wù)接口的處理速度有快有慢，如果所有的請(qǐng)求統(tǒng)一在同一個(gè)Executor中進(jìn)行處理，則可能每個(gè)線程都在處理慢速請(qǐng)求，導(dǎo)致其他請(qǐng)求在Queue中排隊(duì)。

此時(shí)，可以根據(jù)業(yè)務(wù)特征，事先做好規(guī)劃，將不同的業(yè)務(wù)處理按照一定的方式進(jìn)行分組，每個(gè)組用不同的線程池，以達(dá)到隔離的目的。

圖 隔離倉(cāng)

隔離倉(cāng)的實(shí)現(xiàn)依托到ServiceComb靈活的線程池策略，具體在下一節(jié)進(jìn)行描述。

4、靈活的線程池策略

ServiceComb微服務(wù)的概念模型如下：

圖 ServiceComb微服務(wù)概念模型

可以針對(duì)這3個(gè)層次進(jìn)行線程池的配置，operation與線程池之間的對(duì)應(yīng)關(guān)系，在啟動(dòng)階段既完成綁定。

operation與線程池之間的綁定按以下邏輯進(jìn)行：

查看配置項(xiàng)cse.executors.Provider.[schemaId].[operationId]是否有值；

如果有值，則將值作為beanId從spring中獲取bean實(shí)例，該實(shí)例即是一個(gè)Executor。

如果沒有值，則繼續(xù)嘗試下一步：

使用相同的方式，查看配置項(xiàng)cse.executors.Provider.[schemaId]是否有值；

使用相同的方式，查看配置項(xiàng)cse.executors.default是否有值；

以”cse.executor.groupThreadPool”作為beanId，獲取線程池（系統(tǒng)內(nèi)置的FixedThreadExecutor）。

代碼參見：

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

按以上策略，用戶如果需要?jiǎng)?chuàng)建自定義的線程池，需要按以下步驟執(zhí)行：

實(shí)現(xiàn)java.util.concurrent.Executor接口

將實(shí)現(xiàn)類定義為一個(gè)bean；

在microservice.yaml中將線程池與對(duì)應(yīng)的業(yè)務(wù)進(jìn)行綁定。

5、線程池模型總結(jié)

如上一節(jié)所述，在默認(rèn)多線程池的基礎(chǔ)上，CSE提供了更為靈活的線程池配置。“隔離倉(cāng)”模式的核心價(jià)值是實(shí)現(xiàn)不同業(yè)務(wù)之間的相互隔離，從而讓一個(gè)業(yè)務(wù)的故障不要影響其他業(yè)務(wù)。這一點(diǎn)在CSE中可以通過對(duì)線程池的配置實(shí)現(xiàn)。例如，可以為不同的operation配置各自獨(dú)立的線程池。

另外，靈活性也帶來(lái)了一定的危險(xiǎn)性。要避免將線程池配置為前面提到的“單業(yè)務(wù)線程池”模式，從而為整個(gè)系統(tǒng)引入瓶頸點(diǎn)。

寫在最后：ServiceComb除了在華為云微服務(wù)引擎商用之外，也于2017年12月全票通過進(jìn)入Apache孵化器。歡迎感興趣的讀者前往開源社區(qū)和我們討論切磋，希望此文可以給正在進(jìn)行微服務(wù)方案實(shí)施的讀者們一些啟發(fā)。