天天看點

go grpc 異步_搜狗workflow異步排程架構 - 基本介紹篇

我們的項目于兩天前開源啦=>w<=

目前文檔、開源管理及其他方面都在摸索推進中,我也按捺不住想要以開發者之一的名義,寫一系列個人部落格,讓大家可以從方方面面了解到workflow的全部資訊~最官方的更新還是要以github為準,歡迎大家關注我們的項目,嘗試使用并提出寶貴意見:

https://github.com/sogou/workflow​github.com

項目首頁的README裡已經有非常詳細的介紹了,這裡我來補充一些基本資訊。本系列其他文章連結也會持續更新到這裡:

搜狗workflow異步排程架構 - 架構設計篇

搜狗workflow異步排程架構 - 性能優化上篇

一、 使用情況

Workflow在首席架構師謝爺帶領我們三人小團隊經曆過一年多的打磨,目前已經在搜狗公司内部廣泛使用,可以說是公司的

後端C++程式設計标準

。搜狐集團也有其他兄弟團隊在使用,整體超過20多個團隊(Q1的數字)用以重構,基本性能提升好幾倍,輕松把cpu吃滿,也在搜狐集團2019年的1024極客項目評比中奪冠,一路以來能夠被認可真的是一件非常振奮人心的事情。

開源對我們來說隻是剛剛開始,這是一條充滿挑戰的道路。雖然我們team人很少,但先前已經有越來越多的小夥伴參與到一起開發,而且使用workflow的開發小夥伴也都提出非常寶貴的建議和為我們發現了很多問題。是以非常期待亮相于github的workflow未來可以擁有更多的可能性。

感慨完畢,說回正題~在公司内部容易被使用者接納和使用,我認為得益于以下幾個優點:

1.1 極其優異的性能

我們這裡說的性能,不是單指如何跑滿cpu、如何單獨地讓網絡請求極速響應、或者說如何異步操作檔案或其他裝置,而是所有這些資源都可以被其具體的排程器管理,盡可能地全部都排程起來。

由于workflow是個架構,除非是具體業務場景的前後對比否則很難給出benchmark,是以具體業務報告不便透露。比較通用的一些測試結果可供大家參考:

我們用基于workflow開發的Sogou RPC做了與brpc和thrift的

吞吐和長尾benchmark

,大家可以參考這裡:Sogou RPC Benchmark;

作為web server性能自然比nginx要好,可以參考我先前的一篇用以改造異步排程QAT加速卡的小夥伴的測試,還沒細優化,随便看看:OpenSSL異步模式與Intel QAT加速卡(四) 新一代異步排程架構workflow;

謝爺的習慣是喜歡把東西做到最簡潔、把性能做到最極緻,是以項目對性能的每一個細節都不會馬虎,本人受益匪淺。但是我們團隊接觸開源比較少,是以我個人非常希望能在性能優化方面學習到更多優秀的做法。

1.2 比其他C++架構更友好的使用者體驗

我們給開發者使用者接觸到的是

task(任務)

series(任務流)

  • task由工廠建立、自行銷毀;
  • series可以手動從工廠建立或者自動建立,也是自行銷毀。

使用者再也接觸不到連接配接池、線程池、包括想要做aio時的檔案fd與各種異步通知機制。

從語言的發展來看,go的出現與被喜愛是必然的,原因之一就是天下苦C++久矣,而go的封裝很進階很簡約。雖然C++後續也推出了各種新用法,但不是所有使用者都會升到更高的标準,目前workflow的标準是C++11。

而任務和任務流的概念在了解和易用性上簡直甩開事件機制和用循環來做多次進入的開發模式十條街(後面這種模式我也不是想得很明白,但發現OpenSSL的異步和grpc的異步server都是這種方式)。

關于aio的異步機制,這裡有一篇做mac的aio子產品時對aio各種異步通知機制的拙見,感興趣的小夥伴可以看看,并且歡迎給我指出錯誤:異步I/O -- posix aio 從入門到放棄的吐血實踐。

1.3 通信計算資源融為一體的解決方案

我們特别适用于重計算,而搜尋的絕大部分使用場景都是重計算的server,而網絡和計算都可以用workflow一并解決。

workflow認為

一切資源都是可以異步排程的

,是以對于目前支援對接的資源,我鶸鶸地歸納對比了如下表格:

go grpc 異步_搜狗workflow異步排程架構 - 基本介紹篇

計算這裡詳細說一下,原先檢索子產品開發小夥伴常常面臨選擇高吞吐網絡架構的同時,自己需要面對不同計算資源比例而劃分不同大小的線程池。

然而每種計算具體資源需求比例是動态變化的,重要性也不一樣,後端響應時長也是動态變動,如果我們在初始化的時候建立若幹個特定大小的線程池,線程資源難以共用。

go内部的go routine排程就是用來解決這種事情的。那麼C++來說,現在workflow可以和go一樣解決全局計算資源共享和按需排程的需求了,并且打通網絡、磁盤等等其他資源。

1.4 代碼架構層次良好,易于拼裝,實作二次開發

workflow的世界裡有三個原則:

  • 串行是由任務組成的
  • 并行是由串行組成的
  • 并行是一種任務
于是乎,workflow是一套完備的、可以收斂一切循環和控制的任務流模型。

以下是我的一些個人解讀:

  1. 由于可以串行,我們就可以動态建流圖,并且 無限 執行下去;
  2. 由于可以并行,并行的是各個串行流,我們可以對多個并發執行的流在完成時做 收斂
  3. 并行本身是一種任務,是以可以加到串行流圖裡,即每個任務都可以是一個 複合任務組裝 而成,組裝後提供給其他使用者使用,而使用者不需要關心複合任務内部細節,進一步組裝。

當然workflow的其他優點很多,這些是公司内部使用情況的一些總結,其他的會陸續給大家介紹~今天其他點也不太寫得完了,這裡列個大概,後續會更新哦~

二、 workflow的定位與架構設計

搜狗workflow異步排程架構 - 架構設計篇

三、 性能優化的幾點考慮

搜狗workflow異步排程架構 - 性能優化上篇

四、 workflow對資源的了解

五、 workflow對協定和算法的了解

六、 workflow對串并行任務的了解