2021 年 9 月 8 日，字節跳動宣布正式開源 CloudWeGo。CloudWeGo 是一套字節跳動內部微服務中間件集合，具備高性能、強擴展性和穩定性的特點，專注于解決微服務通信與治理的難題，滿足不同業務在不同場景的訴求。2022 年 6 月 21 日，Hertz 正式開源。 Hertz 鏈接：https://GitHub.com/cloudwego/hertz，歡迎大家共同參與建設^_^
日前，CloudWeGo 團隊正式開源字節跳動最大的 HTTP 框架 Hertz。Hertz 在發布之后得到了大量用戶的關注，開源四個月以來，Hertz 已經收獲了 2k+ star。有很多用戶自己進行了測試，感謝社區對我們的關注和支持。
本文旨在分享開發者在壓測 Hertz 時需要了解的場景和技術問題。這些建議有助于用戶更好地結合真實 HTTP 場景對 Hertz 進行調優，使之更貼合業務需要、發揮最佳性能。用戶也可以參考官方提供的壓測項目 hertz-benchmark [1]了解更多細節。
1. 微服務 HTTP 場景的特點
Hertz 誕生于字節跳動大規模微服務架構實踐，面向的場景自然是微服務場景，因此下面會先介紹微服務 HTTP 場景的特點，方便開發者深入理解 Hertz 在其中的設計思考。
- HTTP 通信模型
微服務間的通信通常以 Ping-Pong 模型為主，除了常規的吞吐性能指標外，每次 HTTP 的平均時延也是開發者需要考慮的點。吞吐達到瓶頸時可以通過增加機器快速解決，但對用戶使用體驗有顯著影響的時延卻沒有那么容易降低。在微服務場景下，一次調用往往需要多個微服務協作完成，即使每個節點延遲很低，最終匯聚到鏈路上的時延也會被放大，因此微服務場景下時延指標是開發者更應該關注的點。Hertz 在保證吞吐的前提下，也針對時延做了一定優化。
- 長短連接使用
由于 TCP 連接首次建立時需要三次握手，如果每個請求都建立新連接，這部分的開銷是非常大的。因此對于時延敏感型服務，盡量使用長連接完成請求。在 HTTP 1.1 中，長連接也是默認的選項。但是沒有銀彈，維持連接也需要消耗資源，長連接的水平擴展能力也不如短連接。因此，在某些場景下并不適合使用長連接，比如定時拉取配置的場景，在這個場景下，建連時延對配置影響并不大，且當配置中心負載過高時，希望能夠方便的進行水平擴容，這時短連接可能是一個更好的選擇。
- 包體積大小
一個服務的包大小取決于實際的業務場景。HTTP 場景的數據可以放在 query、path、header、body 等地方，不同位置對解析造成的影響也不一樣。HTTP 的 header 是標識符協議，在沒有找到特定的標識符之前，框架并不知道 header 還有多少，因此框架需要收到全部的 header 后才能夠解析完成，對框架的內存模型不很友好。Hertz 也針對 header 解析做了特殊的優化，分配足夠的 buffer 空間給 header，減少 header 處理時跨包拷貝的開銷。
同時在字節跳動內部線上服務的統計中，發現大部分包在 1K 以內（但是太小的包沒有實際意義，比如固定返回 "hello world"），同時大包場景上不封頂，各個包大小均有涉及，所以 Hertz 在最常用的 128k 以內的包的性能（吞吐和時延）進行了重點優化。
- 并發數量
每個實例的上游可能會有很多個，不會只接受某個實例的請求；而且，HTTP 1 的連接不能夠多路復用，每條連接上只能同時處理一個請求。因此 server 需要接受多個連接同時處理。不同服務的連接使用率也不同，比如壓測服務的連接使用率很高，一個請求完成后馬上就會進行下一個請求；有的服務連接使用率很低，雖然是長連接，但是只使用一次。這兩者使用的連接模型并不相同，前者應使用 goroutine per connection 的模型減少上下文的切換，后者應使用協程池減少過多 goroutine 的調度開銷。Hertz 也同時支持這兩種場景，用戶可以根據自己的業務場景選擇合適的配置。
2. 針對 HTTP 場景進行壓測
2.1 使用貼近自己的場景
Github 上的壓測項目有很多，網絡上也有很多性能測試報告，但是這些項目和測試不一定貼合自己。舉個極端一點的例子，在真實場景中你會寫一個項目無論 client 發什么 server 都只回 hello world 嗎？很遺憾，很多的壓測項目就是這么做的。
在進行壓測前，應考慮自己真正的使用場景，比如：
- 長短連接的使用：使用長連接還是短連接更符合自己的場景。
- 連接使用率的估算：如果使用長連接，且連接使用率很高（大部分場景），則使用默認配置即可；如果連接使用率很低，可以添加配置:server.WithIdleTimeout(0)，將 goroutine per connection 的模型修改為協程池模型，并進行對比測試。
- 數據位置及大小的確定：上面提到不同位置(如 query、header、body 等)及大小的數據對框架可能造成影響，如果所有框架的性能都比較一般，可以考慮換一個數據傳輸位置。
- 并發數的確定：有的服務屬于輕業務重框架，這個時候框架的并發可能會很高；有的服務屬于重業務輕框架，這個時候框架的并發可能會很低。
如果只是想看一下框架的性能，可以使用常規的場景：長連接、較高連接使用率、1k body、100 并發等。hertz-benchmark 倉庫默認的壓測配置也是如此。同時 hertz-benchmark 倉庫也開發給用戶 header、body、并發數的配置，用戶可以方便的修改這些配置完成貼合自己的壓測。
2.1.1 確定壓測對象
衡量一個 HTTP 框架的性能需要從兩個視角分別去思考：Client 視角與 Server 視角。在大規模的業務架構中，上游 Client 不見得使用的也是下游的框架，而開發者調用的下游服務也同樣如此，如果再考慮到 Service Mesh 的情況就更復雜了。
一些壓測項目通常會把 Client 和 Server 進程混部進行壓測，然后得出整個框架的性能數據，這其實和線上實際運行情況很可能是不符的。
如果要壓測 Server，應該給 Client 盡可能多的資源，把 Server 壓到極限，反之亦然。如果 Client 和 Server 都只給了 4 核 CPU 進行壓測，會導致開發者無法判斷最終得出來的性能數據是哪個視角下的，更無法給線上服務做實際的參考。
2.1.2 使用獨占 CPU
雖然線上應用通常是多個進程共享 CPU，但在壓測場景下，Client 與 Server 進程都處于極端繁忙的狀況，此時共享 CPU 會導致大量上下文切換，從而使得數據缺乏可參考性，且容易產生前后很大波動。
所以我們建議是將 Client 與 Server 進程隔離在不同 CPU 或者不同獨占機器上進行。如果還想要進一步避免其他進程產生影響，可以再加上 nice -n -20 命令調高壓測進程的調度優先級。
另外如果條件允許，相比云平臺虛擬機，使用真實物理機會使得測試結果更加嚴謹與具備可復現性。
3. 性能數據參考
在滿足上述要求的前提下，我們基于當前最新版本對多個框架進行了壓測對比，壓測代碼在 hertz-benchmark 倉庫。在充分壓滿 Server 的目標下，Hertz 的 P99 延遲在所有壓測框架中最低，吞吐也是屬于第一梯隊，且在持續優化中。
1.CPU: AMD EPYC 7Y83 64-Core Processor 2.7GHz
1.1運行限定 server 4-CPUs，client 16-CPUs
2.OS：Debian GNU/linux 10 (buster)
3.Go 1.19
4.hertz v0.3.2，fasthttp v1.40.0，gin v1.8.1，fiber v2.38.1
四個框架的吞吐和時延比較
三個框架的吞吐和時延比較
4. 結語
Hertz 作為一個超大規模企業級的微服務 HTTP 框架，其在設計之初就更傾向于解決大規模微服務場景下的各種問題。在推廣過程中也遇到了各種各樣的服務，踩了各種各樣的坑，也是基于這些服務和遇到的問題寫了本文。歡迎廣大開發者基于本文提供的測試指南，針對自己的實際場景選擇合適的工具。更多問題，請在 GitHub 上提 Issue 交流。
[1] hertz-benchmark: https://github.com/cloudwego/hertz-benchmark
