是否是以爲C++寫個服務太累,但又沉迷於C++的真香性能而沒法自拔?做爲一個老牌C++程序員(能夠看我 github 上十幾年前的C++項目:https://github.com/kevwan ),這幾天聽一個好友跟我聊起他寫的C++框架,說極簡代碼便可完成各類C++服務的開發,不由讓我心生好奇!因而我去研究了一下,發現確實有點意思!linux
話很少說,咱們來一塊兒看看,10行C++代碼怎麼實現一個高性能的Http服務,輕鬆QPS幾十萬。Linus說:talk is cheap,show me the code ↓nginx
int main() { WFHttpServer server([](WFHttpTask *task) { task->get_resp()->append_output_body("Hello World!"); }); if (server.start(8888) == 0) { getchar(); // press "Enter" to end. server.stop(); } return 0; }
這個 server 使用了 workflow,安裝編譯都很是簡單,以 Linux 爲例,把代碼拉下來後,一行命令即搞定編譯:git
➜ git clone https://github.com/sogou/workflow ➜ cd workflow ➜ make ➜ cd tutorial ➜ make ➜ ./helloworld
代碼在 tutorial 目錄,編譯後的 helloworld 能夠直接運行,偵聽在 8888 端口,curl 便可訪問:程序員
➜ curl -i http://localhost:8888 HTTP/1.1 200 OK Content-Length: 25 Connection: Keep-Alive Hello World!
伴隨着以上這10行代碼,咱們詳細地解讀:github
WFHttpServer
;WFHttpTask
;task->get_req()
和task->get_resp()
能夠得到;start()
和stop()
兩個簡單的api,而中間要用getchar();
卡住,是由於 workflow 是個純異步的框架。純異步就是這個 Http 服務器的高性能所在:shell
第一,多線程提供服務後端
若是咱們收到請求以後在這個函數裏作了一些阻塞的事情(好比等鎖、io請求或者忙碌的計算等),那麼再有用戶請求個人時候,我就沒有線程去處理新用戶了api
第二,網絡線程和執行線程有優秀的調度策略服務器
再多的線程也可能會有被霸佔完的時候。咱們須要不管 server 函數想要作任何耗時的操做,都不會影響到網絡線程微信
第三,以 linux 爲例,對epoll的封裝高效好用
若是服務只打算支持一萬的QPS,其實底層怎麼實現都很簡單,但若是咱們但願十萬,甚至接近百萬,則咱們對server底層作收發的I/O模型有很是高的要求
咱們來看看 workflow 是怎麼來實現以上這些高併發能力:
基於以上的架構,基於 workflow 的 server 輕輕鬆鬆就能夠達到幾十萬 QPS,高吞吐、低成本、開發快,完美支撐了搜狗的全部後端在線服務!詳細代碼實現請參考 workflow 源碼。而後咱們以數聽說話,經過跟名譽全球的高性能 Http 服務器 nginx 和國內開源框架先驅 brpc 一塊兒作比較,看一下固定數據長度下 QPS 與併發度的關係:
以上是在同一臺機器上用相同的變量作的 wrk 壓測,具體能夠到 github 查看機器配置、參數及壓測工具代碼。當數據長度保持不變,QPS 隨着併發度提升而增大,後趨於平穩。此過程當中 workflow 一直有明顯優點,高於 nginx 和 brpc。 特別是數據長度爲64和512的兩條曲線, 併發度足夠的時候,能夠保持50W的QPS。
workflow 能在開源大半年在github上收穫4k星星的承認,固然是除了簡單和高性能之外,還有其餘許多的特色,若是你對其餘使用場景還有所好奇,或者但願嘗試壓測一下感覺高QPS帶來的心跳加速,那麼歡迎點擊 workflow 的 github 獵奇更多腦洞大開的功能和用法。
https://github.com/sogou/workflow
歡迎使用 workflow 並 star 支持一下!
關注『微服務實踐』公衆號並回復 進羣 獲取微服務社區羣二維碼。
go-zero 系列文章見『微服務實踐』公衆號