當(dāng)時(shí)的設(shè)計(jì)初衷是event框架僅僅做簡單的API配置變更，假設(shè)了這類配置動(dòng)態(tài)變更數(shù)量比較少，所以僅僅是功能上的考慮，性能沒有做太多要求，所以上圖所顯示的Client發(fā)送HTTP請求后，這一套標(biāo)序號的流程走下來，完成過程是10ms這個(gè)級別，平均約50ms。

隨著NJet在不同場景的應(yīng)用，有兩個(gè)關(guān)鍵性的需求對這套event框架的性能需求提出了嚴(yán)重挑戰(zhàn)，第一是實(shí)際生產(chǎn)環(huán)境的超大規(guī)模配置數(shù)據(jù)；第二是某些業(yè)務(wù)場景需要快速的Worker間數(shù)據(jù)交換。

(資料圖)

? 先說下大規(guī)模配置數(shù)據(jù)的挑戰(zhàn)。由于NJet支持Server及l(fā)ocation級別的動(dòng)態(tài)化，以及可以動(dòng)態(tài)配置上游成員，實(shí)際生產(chǎn)中頻繁碰到了過百個(gè)，甚至1000+上游成員, 而Server也有近100級別，因此通過動(dòng)態(tài)API下發(fā)配置，常常耗時(shí)超過10s，最大的一個(gè)客戶場景報(bào)告超過43s。

? 進(jìn)程間數(shù)據(jù)交換來源于NJet作為消息服務(wù)器的需求，由于NJet在前期提煉出了一套動(dòng)態(tài)協(xié)議框架，可以簡單的增加某種協(xié)議的解析庫，結(jié)合TCC腳本實(shí)現(xiàn)業(yè)務(wù)邏輯，就可以快速的實(shí)現(xiàn)某種特定協(xié)議的應(yīng)用服務(wù)器。以聯(lián)邦制的消息服務(wù)器為例，某Client發(fā)送一條消息到消息服務(wù)器，如果接收者在消息服務(wù)器注冊，消息服務(wù)器會(huì)直接處理，否則就需要根據(jù)目的地址，轉(zhuǎn)發(fā)到其他的消息服務(wù)器（注：客戶注冊到不同的消息服務(wù)器，但仍然可以相互通信，稱為聯(lián)邦，比較流行的matrix，以及古老的irc、郵件都是這種模型）。消息服務(wù)器間的通信，出于安全等方面考慮，僅僅會(huì)維持1條長鏈接，對NJet這種繼承自NGINX的多進(jìn)程模式就提出了很大挑戰(zhàn)，即Client發(fā)送到消息服務(wù)器的消息，可能會(huì)被Worker1接收，但根據(jù)目的選擇，需要被Worker2發(fā)送，因?yàn)橹挥蠾orker2才建立了到合適目的消息服務(wù)的連接。

?上圖所顯示的worker1 接收到消息，轉(zhuǎn)發(fā)到worker2,以及回包worker2轉(zhuǎn)發(fā)到worker1,就采用了NJet內(nèi)置的event框架，但10ms級別的處理性能，遠(yuǎn)不能滿足消息服務(wù)器的處理性能指標(biāo)要求，甚至由于加入了跨進(jìn)程通信，出現(xiàn)了多worker處理能力遠(yuǎn)小于單worker處理能力的荒謬情況。

NJet 中集成的mqtt broker來源于mosquitto，NJet基于此做了定制，做了對Copilot框架的適配，從而保證NJet能夠管理該broker。在優(yōu)化了client端代碼后（主要是把消息緩沖發(fā)送，修改為立即發(fā)送），平均的處理時(shí)間降低到了2ms（見下圖），但這個(gè)處理速度，仍然不能滿足進(jìn)程間通信的處理要求。

訪問單獨(dú)的mosquitto不存在性能問題，以及TCPDump抓包發(fā)現(xiàn)嵌入CoPilot框架后，Broker處理慢，確認(rèn)了CoPilot框架阻塞了Broker對于消息的處理。

根據(jù)NJet的Copilot開發(fā)指南，獨(dú)立的Copilot進(jìn)程應(yīng)實(shí)現(xiàn)自己的事件處理循環(huán)（實(shí)現(xiàn)函數(shù)njt_helper_run），并在該循環(huán)中，調(diào)用check_cmd_fp，獲得NJet的當(dāng)前狀態(tài)，如停止，reload等，從而終止事件循環(huán)，保證NJet對Copilot進(jìn)程的管理，對check_cmd_fp的調(diào)用分析發(fā)現(xiàn)其最終調(diào)用了ngx_process_events_and_timers，該函數(shù)調(diào)用會(huì)被IO事件觸發(fā)，否則會(huì)定時(shí)一段時(shí)間返回，如下面代碼顯示：

所以為了保證CoPilot事件循環(huán)不被阻塞，就需要保證Copilot進(jìn)程中特定的ngx_process_events_and_timers調(diào)用立即返回（通過設(shè)置timer為0）。

無獨(dú)有偶，在我們考慮如何傳遞參數(shù)進(jìn)ngx_process_events_and_timers時(shí)，我們發(fā)現(xiàn)了openresty的特定patch。

通過讀Openresty的注釋，我們發(fā)現(xiàn)了Openresty在提供定時(shí)器上也存在了被ngx_process_events_and_timers阻塞，定時(shí)器性能不高的問題，其解析方案是添加了全局的事件隊(duì)列，通過向其臨時(shí)post一條消息，從而保證了接下來的調(diào)用可以不被阻塞，立即返回。

所以我們的解決方案就很簡單了，在check_cmd_fp向該隊(duì)列設(shè)置一條消息：

感謝openresty！

原API調(diào)用壓測結(jié)果：20條/s

改進(jìn)后的調(diào)用結(jié)果：10000條/s

本地測試提高了約500倍，在虛擬機(jī)等各種不同的環(huán)境也有百倍以上的性能提升，滿足了消息服務(wù)器等各種跨進(jìn)程通信的性能需求。

? CoPilot開發(fā)指南參考：https://docs.njet.org.cn/docs/v4.0.0/development/copilot/index.html

? 本優(yōu)化在NJet4.0.1版本實(shí)現(xiàn)，并backport到長期支持版本3.3.x，請升級到對應(yīng)的版本3.3.1.2

? NJet會(huì)定期從nginx和openresty合并，目前合并nginx到1.27.4

關(guān)鍵詞： 消費(fèi)導(dǎo)報(bào)網(wǎng) 聚焦資訊