《Linux高性能網(wǎng)絡(luò)編程十談》十篇技術(shù)博客已經(jīng)寫完幾個(gè)月了，想著還是寫點(diǎn)總結(jié)來(lái)回顧一下這幾年的工作，說(shuō)來(lái)在鵝廠兩次經(jīng)歷加起來(lái)也快8年，雖然很多時(shí)候在做螺絲釘?shù)氖虑?，不過(guò)細(xì)想自己的高性能架構(gòu)演進(jìn)的經(jīng)歷，從參與，優(yōu)化到最后設(shè)計(jì)架構(gòu)，從中還是學(xué)到了很多東西。

1、提前設(shè)計(jì)還是業(yè)務(wù)演進(jìn)?

大家應(yīng)該都經(jīng)歷過(guò)項(xiàng)目從0到1的過(guò)程，我想提一個(gè)問(wèn)題：很多時(shí)候的架構(gòu)是隨著業(yè)務(wù)演進(jìn)還是提前設(shè)計(jì)呢?

有人可能已經(jīng)研究過(guò)相關(guān)的架構(gòu)書籍，這些書籍大多認(rèn)為架構(gòu)是隨著業(yè)務(wù)發(fā)展而演變的。然而，也有許多架構(gòu)師堅(jiān)持認(rèn)為架構(gòu)應(yīng)該提前設(shè)計(jì)。在此，我暫時(shí)不做結(jié)論，而是通過(guò)我自己的經(jīng)歷來(lái)探討架構(gòu)的演進(jìn)。

2、從PHP到C++

2.1 簡(jiǎn)單的PHP架構(gòu)

PHP作為一門簡(jiǎn)單便捷的語(yǔ)言，在大廠各個(gè)部門應(yīng)該都有身影，當(dāng)時(shí)我工作用的兩種語(yǔ)言：C++和PHP，使用PHP開(kāi)發(fā)功能很快，而且有很多成熟的庫(kù)，因此組成了經(jīng)典的nginx
+ php-fpm + memcache架構(gòu)。

php架構(gòu)

在當(dāng)前架構(gòu)下單臺(tái)8c8g機(jī)器支持1000qps問(wèn)題不大，所以對(duì)于業(yè)務(wù)當(dāng)前1wqps都不到，顯然多堆幾臺(tái)機(jī)器就可以支持了。對(duì)于緩存層的設(shè)計(jì)，在redis還不是發(fā)展很好的情況下，memcache是當(dāng)時(shí)緩存組件的主流，而且對(duì)于業(yè)務(wù)和對(duì)接PHP簡(jiǎn)單。但是隨著業(yè)務(wù)的發(fā)展，按照當(dāng)時(shí)計(jì)算曲線可能一年以內(nèi)會(huì)到5wqps，用nginx
+ php-fpm + memcache架構(gòu)是不是合理?經(jīng)過(guò)討論后的目標(biāo)是服務(wù)端高性能，于是開(kāi)始了高性能的探索之旅。

2.2 多進(jìn)程的框架

在當(dāng)時(shí)，為了實(shí)現(xiàn)高性能服務(wù)端框架，人們嘗試了一些方案，其中之一是利用PHP插件功能將Server的功能整合到腳本語(yǔ)言中。這種方法在一定程度上實(shí)現(xiàn)了高性能的目標(biāo)。例如，現(xiàn)在PHP的swoole就是這種方法的一個(gè)發(fā)展結(jié)果。

php-server

不過(guò)這里會(huì)面臨一些需要解決的問(wèn)題：

• 熟悉PHP擴(kuò)展的使用場(chǎng)景，防止踩坑
• PHP本身使用上的內(nèi)存泄漏問(wèn)題
• 出現(xiàn)問(wèn)題時(shí)的排查成本，比如一旦出現(xiàn)問(wèn)題，我們有時(shí)候需要去了解PHP源碼，但是面對(duì)幾十萬(wàn)行代碼，這個(gè)成本是相當(dāng)高
• PHP使用上簡(jiǎn)單，這個(gè)實(shí)際相對(duì)的，隨著Docker的崛起，單機(jī)時(shí)代必然會(huì)過(guò)去，PHP的生態(tài)是不是能支持
• …

基于以上思考和對(duì)業(yè)務(wù)發(fā)展的分析，其實(shí)我們自己實(shí)現(xiàn)一個(gè)或者使用現(xiàn)有的C++框架實(shí)現(xiàn)一套業(yè)務(wù)層的Server應(yīng)該更合理，于是經(jīng)過(guò)考慮采用了公司內(nèi)的SPP框架，其架構(gòu)如下：

SPP框架架構(gòu)

可以看出SPP是多進(jìn)程架構(gòu)，其架構(gòu)類似Nginx，分為Proxy進(jìn)程和Worker進(jìn)程，其中：

• proxy進(jìn)程使用handle_init執(zhí)行初始化，handle_route轉(zhuǎn)發(fā)到指定執(zhí)行的worker處理進(jìn)程，handle_input處理請(qǐng)求的入包
• worker進(jìn)程使用handle_init執(zhí)行初始化，handle_process處理包和業(yè)務(wù)邏輯并返回

使用C++的架構(gòu)后，單機(jī)性能直接提升到6kqps，基本已經(jīng)滿足性能上的要求，可以在相同的機(jī)器下支持更多的業(yè)務(wù)，看似已經(jīng)可以將架構(gòu)穩(wěn)定下來(lái)了。

2.3 引入?yún)f(xié)程

使用C++在性能上已經(jīng)滿足需求，但是在開(kāi)發(fā)效率上卻存在眾多問(wèn)題，比如訪問(wèn)redis，為了保持服務(wù)的高性能，代碼邏輯上都采用異步回調(diào)，類似如下：

...
int ret = redis->GetString(k, getValueCallback)
...

其中g(shù)etValueCallback就是回調(diào)函數(shù)，如果出現(xiàn)很多io操作，這里回調(diào)就會(huì)非常麻煩，即使封裝為類似同步方式，在處理上也非常麻煩，當(dāng)時(shí)還沒(méi)有引入std::future和std::async。

另一方面基于后續(xù)的qps可能到10~20w量級(jí)，協(xié)程在多io的服務(wù)處理的性能上也會(huì)更有優(yōu)勢(shì)，于是開(kāi)始了協(xié)程方式改造，將io的地方全部替換為協(xié)程調(diào)用，對(duì)于業(yè)務(wù)開(kāi)發(fā)來(lái)說(shuō)，代碼上就變成了這樣：

...
int ret = redis->GetString(k, value)
...

其中value就是可以直接用的返回值，一旦代碼中有io的地方，底層就會(huì)將io替換為協(xié)程的API，這樣阻塞的io操作就全部變成同步化原語(yǔ)，代碼結(jié)構(gòu)和開(kāi)發(fā)效率都提升不少(具體的協(xié)程實(shí)現(xiàn)可以參考系列文章的《Linux高性能網(wǎng)絡(luò)編程十談|協(xié)程》)。

協(xié)程

從架構(gòu)上還是沒(méi)有太多變化，多進(jìn)程+協(xié)程的方式，支持著業(yè)務(wù)發(fā)展幾年時(shí)間，雖然性能上沒(méi)有指數(shù)增長(zhǎng)，但是對(duì)于高性能探索和沉淀上已經(jīng)有了更多經(jīng)驗(yàn)。

3、云原生

業(yè)務(wù)繼續(xù)發(fā)展，而工程師總是在追求最前沿的理念，云原生作為最近這幾年熱門的技術(shù)點(diǎn)自然不會(huì)放過(guò)，但是在進(jìn)入云原生之前，如果你的團(tuán)隊(duì)沒(méi)有DevOps開(kāi)發(fā)理念，這將是一個(gè)痛苦的過(guò)程，需要對(duì)架構(gòu)設(shè)計(jì)和框架選擇償還技術(shù)債。

3.1 實(shí)施DevOps理念

以前做架構(gòu)考慮高性能，隨著對(duì)于架構(gòu)的理解，發(fā)現(xiàn)高性能只是架構(gòu)設(shè)計(jì)的一個(gè)小領(lǐng)域，要想做好一個(gè)架構(gòu)，需要更多的敏捷流程和服務(wù)治理理念，具體考慮的點(diǎn)總結(jié)如下：

• 持續(xù)集成：開(kāi)發(fā)人員一天多次將代碼集成到共享存儲(chǔ)庫(kù)中，并且對(duì)代碼的每個(gè)孤立更改都將立即進(jìn)行測(cè)試，以檢測(cè)并防止集成問(wèn)題
• 連續(xù)交付：連續(xù)交付(CD)確?？梢噪S時(shí)發(fā)布在CI存儲(chǔ)庫(kù)中測(cè)試的每個(gè)版本的代碼
• 連續(xù)部署：這里包括灰度部署，藍(lán)綠發(fā)布等，目的是快速迭代，經(jīng)過(guò)相對(duì)完整的集成測(cè)試，就可以灰度驗(yàn)證
• 服務(wù)發(fā)現(xiàn)：將服務(wù)作為微服務(wù)化，簡(jiǎn)化服務(wù)之間的調(diào)用
• RPC的框架：追求高性能的Server框架，也需要考慮限流，熔斷等基礎(chǔ)組件的支持
• 監(jiān)控系統(tǒng)：集成Promethues，OpenTracing等功能，能在敏捷開(kāi)發(fā)流程中快速發(fā)現(xiàn)線上的問(wèn)題
• 容器化：為了環(huán)境統(tǒng)一，同時(shí)提前考慮云原生場(chǎng)景，容器化是開(kāi)發(fā)過(guò)程中必不可少的
• …

DevOps

到這里會(huì)發(fā)現(xiàn)，簡(jiǎn)單的高性能Server已經(jīng)作為架構(gòu)追求的目標(biāo)了，于是需要重新調(diào)研并設(shè)計(jì)架構(gòu)，以順利實(shí)施DevOps的理念。

3.2 多線程

基于DevOps，結(jié)合上面的C++的Server框架，發(fā)現(xiàn)多進(jìn)程已經(jīng)不能滿足架構(gòu)的需求，原因如下：

• 多進(jìn)程與Docker容器的單進(jìn)程理念不相符
• 工作進(jìn)程負(fù)載不均，如何更利用多核
• 與監(jiān)控系統(tǒng)有效的對(duì)接
• 業(yè)務(wù)配置重復(fù)加載，需要重新適配配置中心
• 用多進(jìn)程做有狀態(tài)的服務(wù)不是很合理
• …

業(yè)務(wù)也發(fā)展到百萬(wàn)QPS，為了更好的服務(wù)治理和服務(wù)調(diào)用成本，不得不考慮另外的架構(gòu)：

(1)調(diào)研g(shù)RPC

gRPC

gRPC是多線程RPC
Server，有成熟的生態(tài)，各種中間件，支持多語(yǔ)言等，對(duì)于從0到1開(kāi)發(fā)的業(yè)務(wù)是一個(gè)不錯(cuò)的選擇，但是對(duì)于業(yè)務(wù)遷移卻面臨挑戰(zhàn)，比如開(kāi)發(fā)自己的中間件適配服務(wù)發(fā)現(xiàn)，配置中心等，改造協(xié)議按照自定義編解碼，如何結(jié)合協(xié)程等，因此對(duì)于部分業(yè)務(wù)滿足，但是還需要更好的結(jié)合公司內(nèi)組件的RPC
Server。

(2)使用tRPC

剛好公司內(nèi)正在開(kāi)發(fā)tRPC，經(jīng)過(guò)調(diào)研發(fā)現(xiàn)基本滿足需求，于是在tRPC的C++版本剛剛發(fā)展初期就嘗試適配我們的系統(tǒng)，經(jīng)過(guò)一系列的改造，高性能的RPC框架在業(yè)務(wù)系統(tǒng)中遷移和使用了，其中tRPC的架構(gòu)：

https://trpc.group/zh/docs/what-is-trpc/archtecture_design/

基于上述的考慮和業(yè)務(wù)的發(fā)展，于是開(kāi)始嘗試以高性能為基礎(chǔ)，將RPC Server框架統(tǒng)一，以適配后續(xù)RPC多樣化場(chǎng)景，于是實(shí)現(xiàn)一套適配我們的業(yè)務(wù)系統(tǒng)的RPC
Server的基本框架：

新架構(gòu)

3.3、走向k8s

經(jīng)歷了上述選型和改造后，我們的服務(wù)在遷移k8s過(guò)程中，按部就班對(duì)接就可以了，服務(wù)不需要經(jīng)過(guò)太多的改造可以在其平臺(tái)上運(yùn)行，對(duì)接的各個(gè)平臺(tái)也是可以完整的支持。

看似去追求更新的技術(shù)等著下一個(gè)風(fēng)口就可以了?實(shí)際這個(gè)時(shí)候反而挑戰(zhàn)更多了，由于在云上的便捷和遷移服務(wù)架構(gòu)的無(wú)序擴(kuò)張，導(dǎo)致業(yè)務(wù)服務(wù)和邏輯層次越來(lái)越多，同時(shí)一個(gè)服務(wù)依賴的下游鏈路越來(lái)越長(zhǎng)，雖然我們的框架支持鏈路跟蹤，但是鏈路越長(zhǎng)，對(duì)服務(wù)的可控性和穩(wěn)定性就越來(lái)越差，反而浪費(fèi)更多的人力支持日常ops。

怎么辦?…

是不是要合并業(yè)務(wù)邏輯，將架構(gòu)簡(jiǎn)化?這里面臨的問(wèn)題是業(yè)務(wù)邏輯復(fù)雜情況下往往周期很長(zhǎng)，而且從成本角度考慮比較高，收益并不會(huì)很大

是不是重新開(kāi)發(fā)的新的架構(gòu)，將腐朽的保持原樣或者拋棄，使用新的架構(gòu)來(lái)適配下一步的發(fā)展。

以上是Linux高性能網(wǎng)絡(luò)編程十談的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！