《Linux高效能網(wǎng)路程式設(shè)計(jì)十談》十篇技術(shù)部落格已經(jīng)寫完幾個(gè)月了，想著還是寫點(diǎn)總結(jié)來回顧一下這幾年的工作，說來在鵝廠兩次經(jīng)歷加起來也快8年，雖然很多時(shí)候在做螺絲釘?shù)氖虑?，不過細(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)歷過專案從0到1的過程，我想提一個(gè)問題：很多時(shí)候的架構(gòu)是隨著業(yè)務(wù)演進(jìn)還是提前設(shè)計(jì)呢?

有人可能已經(jīng)研究過相關(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é)論，而是透過我自己的經(jīng)驗(yàn)來探討架構(gòu)的演進(jìn)。

2、從PHP到C

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

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

php架構(gòu)

在目前架構(gòu)下單一8c8g機(jī)器支援1000qps問題不大，所以對(duì)於業(yè)務(wù)目前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)過討論後的目標(biāo)是服務(wù)端高性能，於是開始了高性能的探索之旅。

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

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

php-server

不過這裡會(huì)面臨一些需要解決的問題：

• 熟悉PHP擴(kuò)充的使用場(chǎng)景，防止踩坑
• PHP本身使用上的記憶體洩漏問題
• 出現(xiàn)問題時(shí)的檢查成本，例如一旦出現(xiàn)問題，我們有時(shí)候需要去了解PHP源碼，但是面對(duì)幾十萬行程式碼，這個(gè)成本是相當(dāng)高
• PHP使用上簡(jiǎn)單，這個(gè)實(shí)際相對(duì)的，隨著Docker的崛起，單機(jī)時(shí)代必然會(huì)過去，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)過考慮採用了公司內(nèi)的SPP框架，其架構(gòu)如下：

SPP框架架構(gòu)

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

• proxy程序使用handle_init執(zhí)行初始化，handle_route轉(zhuǎn)送到指定執(zhí)行的worker處理程序，handle_input處理請(qǐng)求的入包
• worker程序使用handle_init執(zhí)行初始化，handle_process處理套件和業(yè)務(wù)邏輯並傳回

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

2.3 引進(jìn)協(xié)程

使用C 在效能上已經(jīng)滿足需求，但是在開發(fā)效率上卻存在眾多問題，例如存取redis，為了保持服務(wù)的高效能，程式碼邏輯上都採用非同步回調(diào)，類似如下：

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

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

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

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

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

協(xié)程

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

3、雲(yún)端原生

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

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ù)整合：開發(fā)人員一天多次將程式碼整合到共享儲(chǔ)存庫中，並且對(duì)程式碼的每個(gè)孤立變更都將立即進(jìn)行測(cè)試，以檢測(cè)並防止整合問題
• 連續(xù)交付：連續(xù)交付(CD)確保可以隨時(shí)發(fā)佈在CI儲(chǔ)存庫中測(cè)試的每個(gè)版本的程式碼
• 連續(xù)部署：這裡包括灰階部署，藍(lán)綠發(fā)布等，目的是快速迭代，經(jīng)過相對(duì)完整的整合測(cè)試，就可以灰階驗(yàn)證
• 服務(wù)發(fā)現(xiàn)：將服務(wù)視為微服務(wù)化，簡(jiǎn)化服務(wù)之間的呼叫
• RPC的框架：追求高效能的Server框架，也需要考慮限流，熔斷等基礎(chǔ)元件的支援
• 監(jiān)控系統(tǒng)：整合Promethues，OpenTracing等功能，能在敏捷開發(fā)流程中快速發(fā)現(xiàn)線上的問題
• 容器化：為了環(huán)境統(tǒng)一，同時(shí)事先考慮雲(yún)端原生場(chǎng)景，容器化是開發(fā)過程中不可或缺的
• …

DevOps

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

3.2 多執(zhí)行緒

基於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ù)配置重複加載，需要重新適配配置中心
• 用多進(jìn)程做有狀態(tài)的服務(wù)不是很合理
• …

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

(1)調(diào)查gRPC

gRPC

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

(2)使用tRPC

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

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

基於上述的考量與業(yè)務(wù)的發(fā)展，於是開始嘗試以高效能為基礎(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過程中，按部就班對(duì)接就可以了，服務(wù)不需要經(jīng)過太多的改造可以在其平臺(tái)上運(yùn)行，對(duì)接的各個(gè)平臺(tái)也是可以完整的支持。

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

怎麼辦?…

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

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

以上是Linux高效能網(wǎng)路程式設(shè)計(jì)十談的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！