搜狗于今年7月發(fā)布了C++異步調(diào)度服務器引擎——Workflow，除了計算通信融為一體的高性能特點以外，還集成了多種常用的網(wǎng)絡協(xié)議，包括：Http、Redis、MySQL，所有協(xié)議都是純自研自解析，無需依賴第三方庫，而具體協(xié)議所對應的資源復用和線程調(diào)度等都由Workflow以統(tǒng)一的方式去進行管理，目前獲得了越來越多開發(fā)者的青睞和肯定。而最近，Workflow又支持并發(fā)布了一項復雜的通用網(wǎng)絡協(xié)議：Kafka，使得所有使用Workflow及其生態(tài)項目的開發(fā)者都可以通過統(tǒng)一而簡便的方式與Kafka交互，這也是業(yè)內(nèi)唯一一款使用C++語言實現(xiàn)的Kafka客戶端，值引得開源社區(qū)開發(fā)者們的關(guān)注。

　　一、開發(fā)背景

　　在Workflow發(fā)布Kafka客戶端之前，業(yè)內(nèi)用得比較多的是librdkafka，但這個純C的kafka客戶端有許多不足，以下是我們原先使用時遇到的部分問題：

　　1、線程資源和網(wǎng)絡資源消耗比較多

　　2、接口設計比較復雜臃腫，使用成本比較高

　　3、Kafka版本兼容性不是很好

　　4、消耗資源高，但是性能卻不高

　　5、broker主從切換低版本出現(xiàn)服務hang住情況，高版本偶發(fā)丟數(shù)據(jù)問題

　　6、異步同步偶發(fā)出現(xiàn)丟數(shù)據(jù)情況

　　針對這些問題，更好的替代方案是Workflow的Kafka客戶端：https://github.com/sogou/workflow

　　由于實現(xiàn)在Workflow的基礎上，作為Kafka客戶端即具有超高性能、超大吞吐和極省的資源占用等特點，且和其他協(xié)議的接口一樣，此Kafka客戶端還具有接口清晰，代碼可讀性強等優(yōu)點，不僅節(jié)省機器成本還節(jié)省人力維護成本，非常值得一試。

　　二、新一代高性能C++ Kafka客戶端

　　Workflow的Kafka客戶端使用接口非常簡潔，首先需要創(chuàng)建一個client對象：

　　其他使用方式與框架內(nèi)的其他任務無異，使用Workflow的同學可以瞬間上手：

　　為什么Workflow的Kafka客戶端能有以上的優(yōu)點呢?主要得益于以下三方面的細節(jié)：

　　一. 內(nèi)部基于Workflow的任務流實現(xiàn)。Workflow的核心設計理念是將任務抽象成"任務流"的概念，這樣一個任意復雜的任務可以拆分成若干個并行任務流和串行任務流，它們之間通過串聯(lián)、并聯(lián)等方式組成一個或者多個串并聯(lián)圖，然后由Workflow內(nèi)部的引擎高效異步地執(zhí)行。

　　以Kafka協(xié)議的fetch消息為例，下圖是執(zhí)行過程中任務流的串并聯(lián)圖：

　　一個fetch消息的任務由一組任務組成，其中包括獲取Kafka Broker的Meta任務、一系列的消費者組相關(guān)的任務、獲取offset的任務和真正的拉取消息的任務。前面的多個任務由于有依賴關(guān)系，所以組成串聯(lián)任務;而最終拉取消息的任務和Broker的個數(shù)有關(guān)，因此可以將它轉(zhuǎn)換成一個broker數(shù)目相同的并行任務。這樣做一方面可以使得邏輯很清晰，同時也可以保證執(zhí)行的高效性。

　　二. 連接復用。傳統(tǒng)的網(wǎng)絡通信往往是在程序初始化的時候，創(chuàng)建大規(guī)模連接池來提高網(wǎng)絡吞吐，這么做的一個弊端是系統(tǒng)資源占用過多，會導致降低程序的魯棒性。而目前這個Kafka客戶端由于內(nèi)部是基于Workflow框架，Workflow對連接的管理做了很多優(yōu)化，可以在保證高效高吞吐的同時，將資源控制在一個合理的范圍內(nèi)。

　　三.內(nèi)存管理。為了方便用戶的使用，內(nèi)部的所有對象都基于計數(shù)實現(xiàn)，通過工廠方法創(chuàng)建任務后，在回調(diào)函數(shù)中實現(xiàn)處理邏輯即可。內(nèi)存的分配和釋放都是框架自動完成，全程無需手動操作任務級別的內(nèi)存，非常方便;同時它的邏輯又是完備自洽的，保證了高效可靠。

　　三、插件式發(fā)布，與Workflow完美融合

　　基于Workflow精巧的層次結(jié)構(gòu)，Kafka協(xié)議是以插件式發(fā)布的，即無需安裝Kafka的用戶不會把Kafka相關(guān)代碼編譯進去，由此可以看出Workflow本身的架構(gòu)解耦和模塊對稱性都做得非常優(yōu)秀。

　　而Kafka的協(xié)議由于需要多次交互，Workflow復合任務又天生支持內(nèi)部交互的隱藏，使得整體使用上對用戶非常簡潔透明。基于二級工廠模式也可以把許多全局信息統(tǒng)一管理到內(nèi)存中，也是工程上結(jié)合的一大亮點。

　　可以說，Kafka協(xié)議與Workflow的融合相當完美，且目前在搜狗已經(jīng)大規(guī)模使用，經(jīng)得住工業(yè)級檢索系統(tǒng)大規(guī)模請求的實際考驗，歡迎業(yè)內(nèi)需要的開發(fā)同學積極嘗試并與我們熱心的開發(fā)小組進行技術(shù)交流。