2021 年 9 月 8 日，字節(jié)跳動宣布正式開源 CloudWeGo。CloudWeGo 是一套字節(jié)跳動內(nèi)部微服務(wù)中間件集合，具備高性能、強(qiáng)擴(kuò)展性和穩(wěn)定性的特點(diǎn)，專注于解決微服務(wù)通信與治理的難題，滿足不同業(yè)務(wù)在不同場景的訴求。2022 年 6 月 21 日，Hertz 正式開源。

Hertz 鏈接：https://github.com/cloudwego/hertz，歡迎大家共同參與建設(shè)^_^

日前，CloudWeGo 團(tuán)隊(duì)正式開源字節(jié)跳動最大的 HTTP 框架 Hertz。Hertz 在發(fā)布之后得到了大量用戶的關(guān)注，開源四個(gè)月以來，Hertz 已經(jīng)收獲了 2k+ star。有很多用戶自己進(jìn)行了測試，感謝社區(qū)對我們的關(guān)注和支持。

本文旨在分享開發(fā)者在壓測 Hertz 時(shí)需要了解的場景和技術(shù)問題。這些建議有助于用戶更好地結(jié)合真實(shí) HTTP 場景對 Hertz 進(jìn)行調(diào)優(yōu)，使之更貼合業(yè)務(wù)需要、發(fā)揮最佳性能。用戶也可以參考官方提供的壓測項(xiàng)目 hertz-benchmark [1]了解更多細(xì)節(jié)。

1. 微服務(wù) HTTP 場景的特點(diǎn)

Hertz 誕生于字節(jié)跳動大規(guī)模微服務(wù)架構(gòu)實(shí)踐，面向的場景自然是微服務(wù)場景，因此下面會先介紹微服務(wù) HTTP 場景的特點(diǎn)，方便開發(fā)者深入理解 Hertz 在其中的設(shè)計(jì)思考。

• HTTP 通信模型

微服務(wù)間的通信通常以 Ping-Pong 模型為主，除了常規(guī)的吞吐性能指標(biāo)外，每次 HTTP 的平均時(shí)延也是開發(fā)者需要考慮的點(diǎn)。吞吐達(dá)到瓶頸時(shí)可以通過增加機(jī)器快速解決，但對用戶使用體驗(yàn)有顯著影響的時(shí)延卻沒有那么容易降低。在微服務(wù)場景下，一次調(diào)用往往需要多個(gè)微服務(wù)協(xié)作完成，即使每個(gè)節(jié)點(diǎn)延遲很低，最終匯聚到鏈路上的時(shí)延也會被放大，因此微服務(wù)場景下時(shí)延指標(biāo)是開發(fā)者更應(yīng)該關(guān)注的點(diǎn)。Hertz 在保證吞吐的前提下，也針對時(shí)延做了一定優(yōu)化。

• 長短連接使用

由于 TCP 連接首次建立時(shí)需要三次握手，如果每個(gè)請求都建立新連接，這部分的開銷是非常大的。因此對于時(shí)延敏感型服務(wù)，盡量使用長連接完成請求。在 HTTP 1.1 中，長連接也是默認(rèn)的選項(xiàng)。但是沒有銀彈，維持連接也需要消耗資源，長連接的水平擴(kuò)展能力也不如短連接。因此，在某些場景下并不適合使用長連接，比如定時(shí)拉取配置的場景，在這個(gè)場景下，建連時(shí)延對配置影響并不大，且當(dāng)配置中心負(fù)載過高時(shí)，希望能夠方便的進(jìn)行水平擴(kuò)容，這時(shí)短連接可能是一個(gè)更好的選擇。

• 包體積大小

一個(gè)服務(wù)的包大小取決于實(shí)際的業(yè)務(wù)場景。HTTP 場景的數(shù)據(jù)可以放在 query、path、header、body 等地方，不同位置對解析造成的影響也不一樣。HTTP 的 header 是標(biāo)識符協(xié)議，在沒有找到特定的標(biāo)識符之前，框架并不知道 header 還有多少，因此框架需要收到全部的 header 后才能夠解析完成，對框架的內(nèi)存模型不很友好。Hertz 也針對 header 解析做了特殊的優(yōu)化，分配足夠的 buffer 空間給 header，減少 header 處理時(shí)跨包拷貝的開銷。

同時(shí)在字節(jié)跳動內(nèi)部線上服務(wù)的統(tǒng)計(jì)中，發(fā)現(xiàn)大部分包在 1K 以內(nèi)（但是太小的包沒有實(shí)際意義，比如固定返回 "hello world"），同時(shí)大包場景上不封頂，各個(gè)包大小均有涉及，所以 Hertz 在最常用的 128k 以內(nèi)的包的性能（吞吐和時(shí)延）進(jìn)行了重點(diǎn)優(yōu)化。

• 并發(fā)數(shù)量

每個(gè)實(shí)例的上游可能會有很多個(gè)，不會只接受某個(gè)實(shí)例的請求；而且，HTTP 1 的連接不能夠多路復(fù)用，每條連接上只能同時(shí)處理一個(gè)請求。因此 server 需要接受多個(gè)連接同時(shí)處理。不同服務(wù)的連接使用率也不同，比如壓測服務(wù)的連接使用率很高，一個(gè)請求完成后馬上就會進(jìn)行下一個(gè)請求；有的服務(wù)連接使用率很低，雖然是長連接，但是只使用一次。這兩者使用的連接模型并不相同，前者應(yīng)使用 goroutine per connection 的模型減少上下文的切換，后者應(yīng)使用協(xié)程池減少過多 goroutine 的調(diào)度開銷。Hertz 也同時(shí)支持這兩種場景，用戶可以根據(jù)自己的業(yè)務(wù)場景選擇合適的配置。

2. 針對 HTTP 場景進(jìn)行壓測

2.1 使用貼近自己的場景

Github 上的壓測項(xiàng)目有很多，網(wǎng)絡(luò)上也有很多性能測試報(bào)告，但是這些項(xiàng)目和測試不一定貼合自己。舉個(gè)極端一點(diǎn)的例子，在真實(shí)場景中你會寫一個(gè)項(xiàng)目無論 client 發(fā)什么 server 都只回 ??hello world?? 嗎？很遺憾，很多的壓測項(xiàng)目就是這么做的。

在進(jìn)行壓測前，應(yīng)考慮自己真正的使用場景，比如：

• 長短連接的使用：使用長連接還是短連接更符合自己的場景。
• 連接使用率的估算：如果使用長連接，且連接使用率很高（大部分場景），則使用默認(rèn)配置即可；如果連接使用率很低，可以添加配置:server.WithIdleTimeout(0)，將 goroutine per connection 的模型修改為協(xié)程池模型，并進(jìn)行對比測試。
• 數(shù)據(jù)位置及大小的確定：上面提到不同位置(如 query、header、body 等)及大小的數(shù)據(jù)對框架可能造成影響，如果所有框架的性能都比較一般，可以考慮換一個(gè)數(shù)據(jù)傳輸位置。
• 并發(fā)數(shù)的確定：有的服務(wù)屬于輕業(yè)務(wù)重框架，這個(gè)時(shí)候框架的并發(fā)可能會很高；有的服務(wù)屬于重業(yè)務(wù)輕框架，這個(gè)時(shí)候框架的并發(fā)可能會很低。

如果只是想看一下框架的性能，可以使用常規(guī)的場景：長連接、較高連接使用率、1k body、100 并發(fā)等。hertz-benchmark 倉庫默認(rèn)的壓測配置也是如此。同時(shí) hertz-benchmark 倉庫也開發(fā)給用戶 header、body、并發(fā)數(shù)的配置，用戶可以方便的修改這些配置完成貼合自己的壓測。

2.1.1 確定壓測對象

衡量一個(gè) HTTP 框架的性能需要從兩個(gè)視角分別去思考：Client 視角與 Server 視角。在大規(guī)模的業(yè)務(wù)架構(gòu)中，上游 Client 不見得使用的也是下游的框架，而開發(fā)者調(diào)用的下游服務(wù)也同樣如此，如果再考慮到 Service Mesh 的情況就更復(fù)雜了。

一些壓測項(xiàng)目通常會把 Client 和 Server 進(jìn)程混部進(jìn)行壓測，然后得出整個(gè)框架的性能數(shù)據(jù)，這其實(shí)和線上實(shí)際運(yùn)行情況很可能是不符的。

如果要壓測 Server，應(yīng)該給 Client 盡可能多的資源，把 Server 壓到極限，反之亦然。如果 Client 和 Server 都只給了 4 核 CPU 進(jìn)行壓測，會導(dǎo)致開發(fā)者無法判斷最終得出來的性能數(shù)據(jù)是哪個(gè)視角下的，更無法給線上服務(wù)做實(shí)際的參考。

2.1.2 使用獨(dú)占 CPU

雖然線上應(yīng)用通常是多個(gè)進(jìn)程共享 CPU，但在壓測場景下，Client 與 Server 進(jìn)程都處于極端繁忙的狀況，此時(shí)共享 CPU 會導(dǎo)致大量上下文切換，從而使得數(shù)據(jù)缺乏可參考性，且容易產(chǎn)生前后很大波動。

所以我們建議是將 Client 與 Server 進(jìn)程隔離在不同 CPU 或者不同獨(dú)占機(jī)器上進(jìn)行。如果還想要進(jìn)一步避免其他進(jìn)程產(chǎn)生影響，可以再加上 nice -n -20 命令調(diào)高壓測進(jìn)程的調(diào)度優(yōu)先級。

另外如果條件允許，相比云平臺虛擬機(jī)，使用真實(shí)物理機(jī)會使得測試結(jié)果更加嚴(yán)謹(jǐn)與具備可復(fù)現(xiàn)性。

3. 性能數(shù)據(jù)參考

在滿足上述要求的前提下，我們基于當(dāng)前最新版本對多個(gè)框架進(jìn)行了壓測對比，壓測代碼在 hertz-benchmark 倉庫。在充分壓滿 Server 的目標(biāo)下，Hertz 的 P99 延遲在所有壓測框架中最低，吞吐也是屬于第一梯隊(duì)，且在持續(xù)優(yōu)化中。

• CPU: AMD EPYC 7Y83 64-Core Processor 2.7GHz

• 運(yùn)行限定 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

四個(gè)框架的吞吐和時(shí)延比較

三個(gè)框架的吞吐和時(shí)延比較

4. 結(jié)語

Hertz 作為一個(gè)超大規(guī)模企業(yè)級的微服務(wù) HTTP 框架，其在設(shè)計(jì)之初就更傾向于解決大規(guī)模微服務(wù)場景下的各種問題。在推廣過程中也遇到了各種各樣的服務(wù)，踩了各種各樣的坑，也是基于這些服務(wù)和遇到的問題寫了本文。歡迎廣大開發(fā)者基于本文提供的測試指南，針對自己的實(shí)際場景選擇合適的工具。更多問題，請?jiān)? GitHub 上提 Issue 交流。

相關(guān)鏈接

[1] hertz-benchmark: https://github.com/cloudwego/hertz-benchmark