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