2021 年 9 月 8 日，字節跳動宣布正式開源 CloudWeGo。CloudWeGo 是一套字節跳動內部微服務中間件集合，具備高性能、強擴展性和穩定性的特點，專注於解決微服務通信與治理的難題，滿足不同業務在不同場景的訴求。CloudWeGo 第一批開源了四個項目：Kitex、Netpoll、Thriftgo 和 netpoll-http2，以 RPC 框架 Kitex 和網絡庫 Netpoll 為主。
日前，字節跳動服務框架團隊正式開源 CloudWeGo，在抖音、今日頭條均有深度應用的 Golang 微服務 RPC 框架 Kitex 也包含在其中。
本文旨在分享開發者在壓測 Kitex 時需要了解的場景和技術問題。這些建議有助於用戶更好地結合真實 RPC 場景對 Kitex 進行調優，使之更貼合業務需要、發揮最佳性能。用戶也可以參考官方提供的壓測項目 kitex-benchmark[4]了解更多細節。
微服務場景的特點Kitex 誕生於字節跳動大規模微服務架構實踐，面向的場景自然是微服務場景，因此下面會先介紹微服務的特點，方便開發者深入理解 Kitex 在其中的設計思考。
微服務間的通信通常以 PingPong 模型為主，所以除了常規的吞吐性能指標外，每次 RPC 的平均時延也是開發者需要考慮的點。
一次 RPC 調用往往需要多個微服務協作完成，而下游服務又會有其自身依賴，所以整個調用鏈路會是一個複雜的網狀結構。
在這種複雜調用關係中，某個中間節點出現的延遲波動可能會傳導到整個鏈路上，導致整體超時。當鏈路上的節點足夠多時，即便每個節點的波動概率很低，最終匯聚到鏈路上的超時概率也會被放大。所以單一服務的延遲波動 —— 即 P99 延遲指標，也是一個會對線上服務產生重大影響的關鍵指標。
雖然一個服務通信包的大小取決於實際業務場景，但在字節跳動的內部統計中，我們發現線上請求大多以小包（<2KB）為主，所以在兼顧大包場景的同時，也重點優化了小包場景下的性能。
針對微服務場景進行壓測確定壓測對象衡量一個 RPC 框架的性能需要從兩個視角分別去思考：Client 視角與 Server 視角。在大規模的業務架構中，上游 Client 不見得使用的也是下游的框架，而開發者調用的下游服務也同樣如此，如果再考慮到 Service Mesh 的情況就更複雜了。
一些壓測項目通常會把 Client 和 Server 進程混部進行壓測，然後得出整個框架的性能數據，這其實和線上實際運行情況很可能是不符的。
如果要壓測 Server，應該給 Client 儘可能多的資源，把 Server 壓到極限，反之亦然。如果 Client 和 Server 都只給了 4 核 CPU 進行壓測，會導致開發者無法判斷最終得出來的性能數據是哪個視角下的，更無法給線上服務做實際的參考。
對齊連接模型常規 RPC 的連接模型主要有三種：
每類連接模型沒有絕對好壞，取決於實際使用場景。連接多路復用雖然一般來說性能相對最好，但應用上必須依賴協議能夠支持包序列號，且一些老框架服務可能也並不支持多路復用的方式調用。
Kitex 最早為保證最大程度的兼容性，在 Client 端默認使用了短連接，而其他主流開源框架默認使用連接多路復用，這導致一些用戶在使用默認配置壓測時，出現了比較大的性能數據偏差。
後來為了契合開源用戶的常規使用場景，Kitex 在 v0.0.2 中也加入了默認使用長連接的設置。
對齊序列化方式對於 RPC 框架來說，不考慮服務治理的話，計算開銷主要都集中在序列化與反序列化中。
Kitex 對於 Protobuf 的序列化使用的是官方的 Protobuf 庫[6]，對於 Thrift 的序列化，則專門進行了性能優化，這方面的內容在官網博客中有介紹。
當前開源框架大多優先支持 Protobuf，而部分框架內置使用的 Protobuf 其實是做了許多性能優化的 gogo/protobuf 版本，但由於 gogo/protobuf 當前有失去維護的風險，所以出於可維護性角度考慮，我們依然決定只使用官方的 Protobuf 庫，當然後續我們也會計劃對 Protobuf 進行優化。
使用獨占 CPU雖然線上應用通常是多個進程共享 CPU，但在壓測場景下，Client 與 Server 進程都處於極端繁忙的狀況，如果同時還共享 CPU 會導致大量上下文切換，從而使得數據缺乏可參考性，且容易產生前後很大波動。
所以我們建議是將 Client 與 Server 進程隔離在不同 CPU 或者不同獨占機器上進行。如果還想要進一步避免其他進程產生影響，可以再加上 nice -n -20 命令調高壓測進程的調度優先級。
另外如果條件允許，相比雲平台虛擬機，使用真實物理機會使得測試結果更加嚴謹與具備可復現性。
性能數據參考在滿足上述要求的前提下，我們對多個框架使用 Protobuf 進行了壓測對比，壓測代碼在 kitex-benchmark 倉庫。在充分壓滿 Server 的目標下，Kitex 在連接池模式下的 P99 Latency 在所有框架中最低。而在多路復用模式下，Kitex 在各指標上也都具有更加明顯的優勢。
配置：
參考數據：
結語在當前主流的 Golang 開源 RPC 框架中，每個框架其實在設計目標上都各有側重：有些框架側重於通用性，有些側重於類似 Redis 這種輕業務邏輯的場景，有些側重於吞吐性能，而有些則更側重 P99 時延。
字節跳動的業務在日常迭代中，常常會出現因某個 feature 導致一個指標上升，另一個指標下降的情況，因此 Kitex 在設計之初就更傾向於解決大規模微服務場景下各種問題。
Kitex 發布後，我們接到了大量來自用戶的自測數據，感謝社區對我們的關注和支持，也歡迎廣大開發者基於本文提供的測試指南，針對自己的實際場景選擇合適的工具。更多問題，請在 GitHub 上提 Issue 交流。
相關鏈接
留言列表