OBProxy產(chǎn)品從2014年開始設(shè)計研發(fā)，至今已經(jīng)有近8年的歷史，其產(chǎn)品在螞蟻內(nèi)部、專有云場景、公有云場景都有廣泛的使用，在訪問鏈路上承擔(dān)了重要的作用。而為了實現(xiàn)OBProxy高性能特性，研發(fā)團隊做了大量的工作，其中就包括OBproxy 單機性能優(yōu)化工作。

綜合來說，包括在OBProxy的功能設(shè)計和編碼實現(xiàn)時考慮性能影響，面向高性能編程，降低新功能帶來的性能損耗；關(guān)注新的硬件、linux內(nèi)核和編譯器技術(shù)，使用新技術(shù)帶來性能優(yōu)化；以及建立性能回歸體系，對每個版本做嚴格性能回歸，保證性能優(yōu)化的成果。

接下來，我們就來詳細展開看看。

OBProxy高性能設(shè)計

OBProxy在設(shè)計之初就考慮了高性能：

采用C++語言編寫，可以充分使用硬件、內(nèi)核的特性，也減少一些語言的GC等機制對性能影響；

設(shè)計優(yōu)秀的多線程模型，可以充分發(fā)揮每一個CPU核心的能力，架構(gòu)上做到盡量簡單；

編碼時采用異步調(diào)用、內(nèi)存池、減少Buffer拷貝等手段優(yōu)化性能。

如果用一句話概括，OBProxy通過多線程和異步框架提供優(yōu)異的性能。不過為了滿足異步接口的使用，產(chǎn)品也做了一些犧牲，將一個完整的流程會被切割成多段代碼，對代碼可讀性有一定影響。

對于OBProxy的線程模型，下圖描述了公有云上OBProxy在16c機器上的任務(wù)分發(fā)模型。線程主要分為兩類：accept線程和work線程。accept有兩個，work線程有16個（根據(jù)CPU核數(shù)確定）。work線程完全一樣，accept線程完成TCP建連后，會將對應(yīng)的套接字輪詢的發(fā)給每個work線程。每個work線程運行epoll機制，進行套接字的讀寫、異常等處理工作。

因此OBProxy可以做到CPU核心之間的負載均衡，充分發(fā)揮每一個核心的能力，不存在因為阻塞導(dǎo)致CPU利用率上不去的情況。

OBProxy 優(yōu)化方向

雖然OBProxy有了優(yōu)秀的線程模型和異步框架，但隨著功能的不斷豐富，對性能也會產(chǎn)生一定的損耗。此時該如何提升性能？需要從應(yīng)用、編譯器和內(nèi)核、硬件三層去做性能優(yōu)化。

對于應(yīng)用層的優(yōu)化，常見做法分為四步：

1、確定優(yōu)化場景：如數(shù)據(jù)庫常選擇sysbench中的場景或者TPCC場景；

2、分析性能消耗：通過perf火焰圖、打日志等一些手段獲取性能消耗分布，從大到小，模塊、函數(shù)、代碼語句層層拆分下去，明確問題點；

3、提出解決方案：無論是從設(shè)計上還是C++一些優(yōu)化技巧（如減少拷貝、減少鎖使用等）提出優(yōu)化方案；

4、驗證優(yōu)化效果：根據(jù)方案進行編碼，并重新驗證優(yōu)化效果。

就大部分情況而言，應(yīng)用層優(yōu)化效果都很顯著。至于編譯器和內(nèi)核新特性使用，內(nèi)核和編譯器技術(shù)也在不斷發(fā)展，在性能方面也會提供越來越多的新特性，而這些技術(shù)發(fā)展并應(yīng)用到實踐中，都可以提升OBProxy性能。

硬件方面，主要是探索RDMA在 OceanBase 數(shù)據(jù)庫的使用。對于RDMA，除了大家知道的對延遲的影響，另一個重要作用就是Bypass Kernel，節(jié)約CPU，優(yōu)化性能。在分析OBProxy性能時，可以發(fā)現(xiàn)內(nèi)核態(tài)進行TCP報文收發(fā)就可能占用30%~ 50%的CPU資源。使用Bypass Kernel設(shè)計（參考下圖），可以進一步提升OBProxy性能。

對于OBproxy項目，版本功能迭代是性能的一大殺手。新的功能特性意味著新代碼引入，代碼規(guī)模進一步變大。除了指令數(shù)增加，對Cache命中率等硬件特性影響也會導(dǎo)致下降。因此需要平衡好新功能開發(fā)對性能影響：1、在性能設(shè)計時考慮性能影響，做評估好性能影響；2、建立完善的性能回歸體系，發(fā)現(xiàn)每一次的性能變化，并做好記錄。

而最后根據(jù)工程實踐，每個迭代性能損耗可以控制很好。