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