《Linux高性能網(wǎng)絡(luò)編程十談》十篇技術(shù)博客已經(jīng)寫(xiě)完幾個(gè)月了，想著還是寫(xiě)點(diǎn)總結(jié)來(lái)回顧一下這幾年的工作，說(shuō)來(lái)在鵝廠(chǎng)兩次經(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ì)呢?

可能有人看過(guò)相關(guān)的架構(gòu)書(shū)籍，書(shū)上大多都支持架構(gòu)是隨著業(yè)務(wù)演進(jìn)的，但是也有很多架構(gòu)師認(rèn)為架構(gòu)就應(yīng)該被提前設(shè)計(jì)，這里我先不給出結(jié)論，先從我所經(jīng)歷的架構(gòu)演進(jìn)來(lái)尋找答案。

2、從PHP到C++

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

PHP作為一門(mén)簡(jiǎn)單便捷的語(yǔ)言，在大廠(chǎng)各個(gè)部門(mén)應(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ì)算曲線(xiàn)可能一年以?xún)?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í)在PHP實(shí)現(xiàn)高性能服務(wù)端框架上也有一些方案，通過(guò)PHP插件功能將Server的功能嫁接到腳本語(yǔ)言上，從而實(shí)現(xiàn)高性能。比如現(xiàn)在PHP的swoole就是從當(dāng)時(shí)發(fā)展起來(lái)。

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)類(lèi)似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)滿(mǎn)足性能上的要求，可以在相同的機(jī)器下支持更多的業(yè)務(wù)，看似已經(jīng)可以將架構(gòu)穩(wěn)定下來(lái)了。

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

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

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

其中g(shù)etValueCallback就是回調(diào)函數(shù)，如果出現(xiàn)很多io操作，這里回調(diào)就會(huì)非常麻煩，即使封裝為類(lèi)似同步方式，在處理上也非常麻煩，當(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ā)展，而工程師總是在追求最前沿的理念，云原生作為最近這幾年熱門(mén)的技術(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)線(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 多線(xiàn)程

基于DevOps，結(jié)合上面的C++的Server框架，發(fā)現(xiàn)多進(jìn)程已經(jīng)不能滿(mǎn)足架構(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是多線(xiàn)程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ù)滿(mǎn)足，但是還需要更好的結(jié)合公司內(nèi)組件的RPC Server。

(2)使用tRPC

剛好公司內(nèi)正在開(kāi)發(fā)tRPC，經(jīng)過(guò)調(diào)研發(fā)現(xiàn)基本滿(mǎ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)的下游鏈路越來(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ā)展。

以上的方案其實(shí)需要在業(yè)務(wù)層去權(quán)衡，如果本身業(yè)務(wù)簡(jiǎn)單，業(yè)務(wù)邏輯合并周期短，建議采用第一種，如果業(yè)務(wù)復(fù)雜，風(fēng)險(xiǎn)很高，如果開(kāi)始考慮的架構(gòu)不合理，就應(yīng)該采用新的架構(gòu)。

如果你也有類(lèi)似的經(jīng)歷，你會(huì)發(fā)現(xiàn)在這個(gè)過(guò)程中我們又回到了原點(diǎn)，以前做高性能是為了服務(wù)能承載更多性能，簡(jiǎn)化調(diào)用鏈路，提升開(kāi)發(fā)效率，走到云原生時(shí)代，似乎又需要重新走一遍類(lèi)似的路徑，始終沒(méi)法擺脫服務(wù)端的束縛。

4、嘗試Serverless

4.1 什么是Serverless

Serverless解釋是無(wú)服務(wù)器計(jì)算，開(kāi)發(fā)者實(shí)現(xiàn)的服務(wù)端邏輯運(yùn)行在無(wú)狀態(tài)的計(jì)算容器中，無(wú)需要關(guān)系資源，使開(kāi)發(fā)者更聚焦在業(yè)務(wù)邏輯，而減少對(duì)基礎(chǔ)架構(gòu)的關(guān)注，業(yè)界公認(rèn)的Serverless計(jì)算的準(zhǔn)確定義應(yīng)該為"FaaS+BaaS"，即Function-as-a-Service同Backend-as-a-service的組合。

既然云原生時(shí)代我們無(wú)法擺脫服務(wù)端的束縛去做架構(gòu)，那在理想情況的Serverless是不是能做到：

Serverless

• 高性能是需要考慮的點(diǎn)，但是服務(wù)不再以完全追求高性能為目標(biāo)
• 降低開(kāi)發(fā)成本和運(yùn)營(yíng)成本
• 支持服務(wù)的橫向擴(kuò)展和縱向擴(kuò)展
• 對(duì)于開(kāi)發(fā)者最好是省去CI/CD流程，但是平臺(tái)將這些流程作為發(fā)布的前置條件
• 云上的資源拿來(lái)就可以直接用，只需要評(píng)估容量即可
• 縮放靈活，可以減少資源的使用
• 考慮服務(wù)的安全性
• ...

4.2 基于微內(nèi)核的云函數(shù)

從最開(kāi)始的PHP到C++的框架迭代，一直在圍繞高性能，服務(wù)治理等在優(yōu)化，但是要結(jié)合Serverless，簡(jiǎn)化架構(gòu)層級(jí)，于是萌生實(shí)現(xiàn)一套基于微內(nèi)核的云函數(shù)架構(gòu)。

其實(shí)參考AWS Lambda的技術(shù)路徑也是如此，他們正在嘗試輕量化容器和microVM去解決慢啟動(dòng)問(wèn)題，而我們使用微內(nèi)核解決業(yè)務(wù)邊界和安全問(wèn)題，因?yàn)閳?chǎng)景的是可以枚舉的，不需要做到足夠非常通用化，于是形成如下架構(gòu)：

新架構(gòu)

這里微內(nèi)核主要做的事情有兩個(gè)：

一種是實(shí)現(xiàn)業(yè)務(wù)層代碼解析，比如對(duì)于JavaScript，我們可以通過(guò)自定義的解析引擎將代碼加載到微內(nèi)核中，調(diào)用基礎(chǔ)庫(kù)和各種抽象API層，相當(dāng)于實(shí)現(xiàn)了一個(gè)簡(jiǎn)單版本的NodeJS，但是整個(gè)框架的安全和功能都是在可控的范圍內(nèi);

一種是自定義其他語(yǔ)言，比如定義支持golang，那么MicroVM負(fù)責(zé)將golang層的代碼和框架代碼打包在一起，然后編譯構(gòu)建為鏡像，不過(guò)我們正在考慮支持更多的語(yǔ)言，這里嘗試使用Webassembly，這樣能簡(jiǎn)化鏡像構(gòu)建成本，直接MicroVM動(dòng)態(tài)加載wasm文件即可;

使用基于微內(nèi)核的云函數(shù)的優(yōu)點(diǎn)是，這里對(duì)于開(kāi)發(fā)者簡(jiǎn)單，真正只需要做業(yè)務(wù)邏輯，不需要考慮底層的高性能(現(xiàn)在已經(jīng)支撐百萬(wàn)級(jí)QPS)，更不需要關(guān)注DevOps某些流程，提升了開(kāi)發(fā)效率，當(dāng)然也有缺點(diǎn)，就是由于MicroVM偏向業(yè)務(wù)層抽象基礎(chǔ)功能，所以通用性不強(qiáng)，但是對(duì)于現(xiàn)有或者后續(xù)的業(yè)務(wù)形態(tài)的發(fā)展已經(jīng)足夠了。

5、總結(jié)

寫(xiě)到這里，再來(lái)聊聊這個(gè)問(wèn)題：提前設(shè)計(jì)還是業(yè)務(wù)演進(jìn)?大家應(yīng)該都有自己的答案了。上述也是我從開(kāi)發(fā)者小白追求如何寫(xiě)好一個(gè)高性能Server，到追求新的架構(gòu)技術(shù)，到最后思考高性能，新技術(shù)到底是為什么服務(wù)的一段總結(jié)。本文屬于《Linux高性能網(wǎng)絡(luò)編程十談》附加篇，沒(méi)有具體談高性能的技術(shù)細(xì)節(jié)，但是我覺(jué)得這句話(huà)比技術(shù)細(xì)節(jié)可能更重要："架構(gòu)需要大簡(jiǎn)至道"。