位元組跳動服務網格基於 Hertz 框架的落地實踐

語言: CN / TW / HK

隨著企業使用者逐漸增多,面對不同場景下的需求和技術問題,CloudWeGo 團隊將會持續分享不同企業的落地實踐,包含不同行業面臨的技術問題、選型參考、最終落地效能和使用分享,來幫助更多使用者使用 CloudWeGo

位元組服務網格承載著線上超大規模的微服務呼叫,作為集中式控制面,面臨著高效能挑戰。位元組跳動服務網格通過使用 CloudWeGo 團隊的高效能務 HTTP 框架 Hertz,完成了超複雜呼叫網路下的流量治理體系的落地實踐。以下內容來自位元組跳動服務網格研發工程師  蘭新宇 的分享。

服務網格在位元組跳動的沉澱與積累

服務網格有得天獨厚的架構優勢,使得它能夠在各種情況下解決業務的痛點,包括架構的優雅性等等,很多網際網路大廠陸續將自己的雲原生架構從傳統的單體或者分散式的應用遷移到雲原生服務網格上,位元組跳動也不例外,今年開始大體量地使用服務網格。那麼什麼是服務網格呢?

什麼是服務網格

首先簡要介紹一下服務網格的概念。如下圖所示,服務網格並不是一個特別新鮮的架構,我們常說加一層代理就可以解決很多事情,服務網格從最簡單的層面理解就是加一層代理,把流量通過代理來轉發實現架構的剝離。這種處理方式會帶來很多好處,下面重點介紹三個位元組通過服務網格解決的痛點。

第一個是服務網格可以使業務程序和框架解耦。原來的程序是框架整合在一個程序裡面,通過 SDK 的形式來提供,我們通過提供隔離的 Proxy,以一個分離的程序和業務程序獨立存在,這是單一職責在 RPC 通訊領域的體現,這樣業務和 RPC 框架研發同學可以更專注於核心功能的實現。

第二個是靈活、可靠的生命週期管理。我們通過程序剝離的方式,使得我們不再依賴業務升級自己的服務來達到框架版本的升級,服務網格的開發、運維者能夠對生命週期做更好的把控,這個是對服務網格的開發者或者運維者非常有利的特徵。

第三個是統一的跨語言流量治理體驗。我們把它通過中間層的方式實現單獨代理,接管所有流量,我們可以針對所有不同語言實現的業務程序統一治理體驗,在位元組跳動,多語言技術棧非常普遍,C/C++/Python/Java/Golang 等服務都有很強的流量治理訴求,所以服務網格也可以針對這種情況給他們提供治理體驗的提升。

典型架構

下面跟大家分享一個典型架構,以便後面引出位元組內部的服務網格使用情況。社群內關注量比較高的服務網格架構,如 Istio 和 Envoy 架構,它們會把服務網格分為兩個層面,一個是資料面,一個是控制面。如圖所示,資料面以一個單獨的程序或者代理模式與業務程序在同一個 POD 裡面執行,起到分離的作用。資料面更關注是怎樣做一個高效能的代理,除此之外,還關注流量治理能力的實現,如超時、壟斷、降級等,把這些能力從 SDK 裡面剝離出來,在資料面真正地實現跨語言治理體驗的特性。

控制面是為所有網格的資料面提供完整的流量控制功能。不只是在流量裡面的控制能力,還包括對於 POD 或者服務之間通訊上有安全層面的要求,安全控制也可以通過網格資料面和控制面的通訊達成。此外,當服務的體量較大或者系統較為複雜時,我們需要達到很高強度的可觀測性,以度量系統的穩定性以及系統能夠帶來的其他收益,因此可觀測性也是網格控制面一個非常重要的特性。

落地挑戰

第一,位元組內部有很多跨語言治理的訴求。除了最廣泛使用的 Go 語言,還有 Python,Node,C++ 和 Java 等等,包括最近比較受歡迎的 Rust 語言。因此位元組內部要落地服務網格實際上面臨著比較大的挑戰。

第二,位元組內部有很多服務量級以及這些服務對應的容器。據估計,線上微服務數量超過 10 萬,容器例項部署的量級大概是 1000 萬。面對如此大的體量,服務網格的控制面應該如何保證高可用性、穩定性和資源的開銷?控制面和資料面之間的通訊協議應該如何設計?怎樣讓更多新的服務和新的容器快速地接入我們的網格以享受便捷服務?

第三,我們面臨著非常複雜的業務形態。位元組有很多使用者端產品,比如抖音、今日頭條和懂車帝,當然還有聯盟和電商之類的產品。不同的業務形態對網格的訴求也是不一樣的,比如抖音是一個強依賴“讀”請求的產品,它需要快速地獲取大量資料,電商是強依賴“寫”請求的產品,這類產品會收到很多訂單請求,網格要保證這些的請求寫入成功率。因此對於位元組這種複雜的業務形態,我們的網格面臨著很強的挑戰。

落地實踐

如圖所示,為了應對這些挑戰,我們拓展了服務網格的通訊功能,將其中的一個 POD 進行細化。可以看到圖中最上面有一個業務的程序,其次有傳統的服務網格資料面 Data Plane,也就是 Proxy,此外位元組內部還會有一個專門的運維 Operation Agent。在此基礎上,資料面會與控制面進行通訊,同時我們內部也會有專門的運維來做服務網格生命週期的管理。那麼位元組跳動服務網格的資料面、控制面和運維面都具備什麼特點呢?接下來進行具體介紹。

1. 資料面

首先資料面會有動態配置能力,比如我們可能需要配置快取的過期時間、快取的規模、快取是否淘汰等等來降低海量請求給控制片帶來的壓力。其次部署了大量服務後,每一個服務都有一個數據面代理,那麼我們就需要把效能做到足夠高。對於這麼多容器,哪怕代理層只節省一點資源,整體的線上資源都可以節省一大部分。所以我們考慮基於 Share Memory IPC 執行,這會使得網路通訊量很大的容器儘可能使用本地記憶體通訊,可以大大降低網路通訊開銷和反序列化開銷。最後是在編譯或者連結時做一些基於程式的優化,比如 LTO 等等。以上就是我們從資料面的角度考慮如何進行服務網格的優化。

2. 控制面

首先,我們採用純自研的方案,沒有使用 ACE,可以靈活支援服務動態接入網格。其次,我們也通過多叢集部署將服務以不同的業務形態或者業務線做區分,然後有效地控制爆炸半徑。同時在整個優化過程中,也可以以優先順序的形式進行排位,從而逐步地上線功能。最後是控制面具有多樣的流量治理能力,能夠持續為業務賦能。面對不同種類的業務訴求,我們也在嘗試不斷地解決新出現的問題和挑戰。

3. 運維面

首先,我們會做到全面掌控網格內部通訊,也就是控制面和資料面的通訊方式。其次,在服務網格資料面做升級或者變更時,我們要保證網格的程序能夠正常地執行,因此釋出確認機制是需要有非常強的保障。最後,對於不同的服務或者業務線,對代理的特殊配置需要進行版本的鎖定,在這方面我們也有比較豐富的經驗。

超複雜呼叫網路下的流量治理體系

基於位元組跳動如此大體量的服務網格,我們給網格的使用者帶來了什麼呢?這就要介紹一下在超複雜的呼叫網路下的流量治理體系。

核心能力

我們有非常多流量治理的功能,基於近幾年的打磨,形成了一套相對比較完整的治理體系。下面重點分享三個核心能力。

第一,微服務訪問控制。位元組內部秉持著“零信任”的宗旨,我們認為不論是外網還是內網,微服務之間的訪問都是要有約束的、是不可信任的,所以我們大規模落地了微服務之間的訪問控制能力。訪問控制包括以下幾方面:

  • 授權,訪問的許可權;

  • 鑑定,對自己身份的介紹是否是可信;

  • 流量加密,防止嗅探或攻擊流量,保證資料層面的安全。

第二,單元化。隨著業務形態的複雜程度不斷加深,會有各種各樣的場景出現,因此需要很強的隔離機制。我們內部在單元化(流量管控/流量隔離)方面積累了很多經驗。我們不僅僅支援傳統的 HTTP、Thrift 和 RPC 等流量,還支援 Message Queue 這種型別的流量。

第三,動態治理。隨著服務網格和機器量級逐漸擴大,我們面臨的一個挑戰是可能會有很動態的場景,不能通過非常簡單或者一成不變的配置來實現,它更多需要的是一種動態過載控制和動態負載均衡的能力,在這方面我們也是有一定積累的。

落地規模

那麼這些核心治理能力在位元組內部的落地規模是怎樣的呢?大概有超過 13,000 個服務都會使用授權能力,超過 2500 個服務開啟了非常嚴格的身份認證能力。身份認證是基於位元組內部一個相對比較成熟、穩定的身份頒發系統來進行。單元化的部分我們有超過 1000 條隔離鏈條做流量隔離。為了實時地保護自己的服務所對應容器的容量狀態,有超過 7500 個服務使用我們動態過載控制的能力。有超過 2500 個服務接入了我們動態負載均衡能力,使得流量能夠儘可能地基於實際雲環境的負載情況做動態流量調動。以下是具體使用情況介紹。

微服務訪問控制

結合下圖具體介紹一下在位元組內部授權、鑑定和流量加密三種能力的使用場景。如圖上面是一個比較傳統的服務網格架構圖,我們加入了 POD A 和 POD B,它就是通過我們的網格做流量的傳遞和通訊。下面的 POD B 是一個沒有接入網格的服務,它只有自己的業務程序。中央的控制面分兩個模組,這裡面展示的是我們在介紹時會用到的兩個模組,一個是觀測方面的,一個是安全方面的。安全方面主要做下發配置以及身份相關的校驗。

  • 授權

資料層是會做允許名單和不允許名單、拒絕或放行的操作,以及資料的解析和匹配等等。同時授權也提供了比較強的觀測能力,因為對於如此大體量的服務,如果遇到沒有得到授權的呼叫方來訪問,貿然開啟授權是有很大風險的,所以我們提供了相對比較成熟的觀測能力。所有的服務都可以在類似 Dry Run 的場景下看有哪些呼叫方沒有得到對應許可權,然後進行相應的操作,這個就是由控制面的觀測模組實現的。同時,業務同學可能有非常多的上游,因此維護授權列表也是很複雜的,所以我們也同時提供了巡檢的系統,一方面可以幫助他們給自己存量的服務做配置,另一方面我們也會去幫助他們控制增量的風險。

  • 鑑定

鑑定和授權比較類似,也會提供觀測能力。同時我們考慮到基礎身份服務不可用的情況,也提供了動態靈活的降級能力,比如過期身份、無效身份或沒有傳遞身份等等。

  • 流量加密

為了保障線上的大部分服務(不論是否應用了服務網格)能夠儘可能平滑地做流量加密,我們在控制面做了極端場景的考慮,這會自動地幫助我們已經配置過的、開啟服務網格的所有容器之間進行加密流量,也就是圖中 POD A 到 POD B 的請求。如果下面的 POD 不具備流量加密或者解析的能力,我們會自動地給它傳送非加密的請求,使它達到比較安全的接入狀態。

單元化

在單元化方面服務網格面臨的使用場景具體如下:

第一,由於傳輸進來的流量標識不同,使用者可能想要根據不同流量標識對租戶進行不同的處理,之後根據不同的叢集或者服務做相應的策略。

第二,可能有一些服務具備常態化容災演練的需求,比如有一些專門供應演練的叢集。

第三,有很多敏感服務需要做流量的隔離,比如某些東西對某些人絕對不可見。這些都是比較典型的單元化場景。基於這些使用者場景,我們採取了相對比較靈活的單元化流量排程。

單元化的特點有以下四個方面:

第一,請求特徵級別的智慧路由能力。實際上這是我們單元化的基礎,基於請求特徵決定流量的傳送位置。

第二,請求特徵級別的治理能力。在決定流量傳送位置的基礎上,還可以決定你是否有傳送到對應位置的許可權。

第三,動態更新,無業務入侵。那麼超時或熔斷降級等等這些引數應該怎麼設定呢?這兩種非常靈活的智慧路由和治理能力使用條件也是非常簡單的。首先,我們可以動態更新,只要接入我們的服務網格,就可以直接感知新增程式碼的引數或者使用哪種中介軟體。其次,可以採用觀測能力。

第四,支援觀測、按比例灰度上量。想知道流量是否可以正確地發到指定位置,我們可以先不用真正傳送,而是觀測一下它對應的情況是否符合預期。在確定沒有問題之後,網格還具有按比例灰度上量的能力,直到你覺得完全沒有問題,可以全部切過去。這極大地降低了使用者對於單元化能力的擔心,可以慢慢地把自己的流量做單元化,實現自己的訴求。

動態治理

1. 過載保護

過載保護,即這個服務保證自己不會過載、相對比較穩定後對外提供服務的能力。實際上我們基於 Mesh 也會做過載保護。我們參考了很多業界文章,比如微信、Google 等公司,借鑑了他們在過載保護方面的一些沉澱,以此來考慮我們是否有合適的引數或指標衡量一個服務或容器的過載情況。下圖是對應的兩個不同容器。首先 POD A 是一個 API 層的服務,它在通過 LB 層的流量進來後,會自動地根據一些請求特徵注入請求優先順序的資料。

什麼是請求特徵?這個優先順序是什麼樣子的?具體來講,如果請求是從某一個 HTTP  Server 的 URL 進來的,那麼它會具有這樣的特徵。比如一類請求是抖音的 Feed,它的請求優先順序是 A,另一類請求是抖音的評論,從另一個 URL 進來,它的請求優先順序是 B,對應 A 和 B 請求優先順序在業務形態上的重要性是不一樣的。我們在後面做擴充套件的時候會使用優先順序作為一個很重要的評判指標。

在 A 和 B 裡面都有一個流程,在收到請求之後,會有一個接收到請求的時間點,在這個時間點的基礎上,我們會把這個請求轉化到業務程序。業務程序在使用這個請求或者在解析這個請求的時候,會有一段處理時間,它也會把這個處理時間做標記,放在請求回覆裡面。之後我們在資料面代理會捕獲到“請求回覆的時間戳”,與我們標記的“請求到達的時間戳”做相應的計算,我們把這個指標定義為排隊時間。

通過動態地更新排隊時間的狀態機,我們可以評判業務的情況以及它是否過載。相應地我們也會將排隊時間延遲成功的請求量、錯誤量等等,通過非同步上報的形式傳達到控制面的觀測模組,基於 CPU 利用率、排隊時間、單位時間內的請求量、客戶端超時斷點等等這些輸入,我們可以通過狀態積載流轉出。

那麼這個服務是否處於過載狀態?如果它處於過載狀態,我們會得到一個輸出,即當你的請求優先順序小於某一個值的時候,我們會將這個請求丟棄掉。這也是相對比較動態地基於服務執行時的指標評判容器過載情況,它可以快速地使服務從過載的狀態恢復,同時也可以緩慢地使服務的過載狀態達到可應用狀態,這會使得這個服務在壓力比較大的情況下,仍然能夠為一些高優先順序的請求提供服務,保證客戶層面看到的可用性。

2. 負載均衡

位元組內部的內網環境非常複雜,資訊數量比較大,我們經常會碰到一些壞的機器,比如 CPU 主頻比較低等。在這種情況下部署的服務處理能力可能沒有其他的機器強,所以偶爾會反映出 CPU 水平不均,或者單例項的問題。

在面臨這樣的問題時,我們解決方案是什麼呢?首先我們會從資料面和控制面著手。資料面更關注的事情是高精度指標的採集和上報,它的精度可能會高於絕大部分觀測系統的精度,這使得我們的系統能夠更快速地反映當前狀態。然後這種指標被上報到控制面做聚合,進行處理分析。同時,資料面只需要支援非常簡單的基於權重的負載均衡演算法即可,後續我們會用這個權重做動態治理流量的調節。

控制面可以做基於指標的動態權重計算,比如我們有 RPC 的成功請求量、錯誤量和一些其他的錯誤改作時間等等,那麼我們可以基於這些指標做聚合,即拿到所有從調研方視角來看被呼叫方的容器資訊負載情況、延遲情況做中心化的計算。計算輸出會產出一個例項,即它的動態權重應該是多少,也就是它實際上應該承載請求的比例。然後把對應的服務發現結果下發給資料面,資料面需要採用非常靈活的權重變化實現動態負載均衡,這就可以解決我們前面所面臨的問題。也就是說盡可能規避那些出現故障的機器,將盡可能少的流量發到處理能力較差的容器。

Hertz 在服務網格的落地實踐

技術選型

在我們的服務網格做技術選型的時候,我們面臨著很多挑戰和困難。我們比較關注的技術選型特點有三個方面。

  • 效能

我們存量的流量比較大,服務的量級也比較多,因此想要在框架方面儘可能節省。當時調研了一些備選框架,當然那時 Hertz 還沒有開源。我們的面臨問題是根據 13M 以上單位請求下的流量做框架的選型。

  • 易用性

實際上我們做服務網格的設計時,也會經常考慮到網格對於使用者的易用性。在我們選擇框架時,我們就變成了框架的使用者,因此我們也會考慮框架的易用性。我們比較關心框架對兩個特點,第一,我們是否可以很容易地通過框架寫出高質量程式碼,而不用關心過多的細節。第二,框架本身是否提供了比較易用且豐富的 API 供我們直接使用,使得我們儘可能少地造輪子。

  • 長效支援

在選擇框架的時候,我們會考慮要用已經開源的、還是用內部資源或者自己重寫一個框架?如果用已經開源的框架,遇到了問題怎麼辦?此外,我們可能要二次開發加一些新的功能,面對這些 Features 社群是否有足夠的人力進行支援?這些也是我們選擇框架的時候面臨的問題。

Hertz 介紹

最終我們選擇了 Hertz 框架,也就是最新已經開源的 CloudWeGo/Hertz。它實際上是位元組跳動服務框架團隊開發並且開源出來的一個基於 Golang 的高效能 HTTP 框架。我們使用後體驗到 Hertz 框架有以下三個方面特點

1. 高易用性。一個能夠在位元組內部沉澱兩年沒有被淘汰,而且還有很多業務在使用的框架,它的易用性肯定是非常高的。

2. 高效能。高效能實際上是我們做框架選擇一個很重要的考察點。在開源方案裡面為數不多的高效能框架,如  fasthttp,它實際上也是我們為數不多的選擇之一。如果一個框架兼備高易用性和高效能,是很難得的。

3. 高拓展性。從目前的使用情況來看,Hertz 的拓展性還是很強的。因為我們服務網格需要框架具有高拓展性以滿足我們的一些特徵,包括多協議的支援等等。大家可以從 Hertz 官網瞭解更多的相關細節。

Hertz 官網:cloudwego/hertz: A high-performance and strong-extensibility Go HTTP framework that helps developers build microservices. (github.com)

Telemetry Mixer

Hertz 在服務網格內部是怎樣使用的呢?首先就是剛剛提到的動態負載均衡的觀測模組,這個模組的服務型別是一個 HTTP 服務,也就是我們資料面代理的指標通過 HTTP 服務做中轉,以便於我們在整個控制面的架構核心裡面做後續資料處理。如下圖,Mixer 部分是使用 Hertz Server 實現的。我們充分利用它高併發、高吞吐的特點,以及為了協議儘可能達到高易用性和可解釋性,我們使用了 JSON。當然也是因為考慮到 Hertz 可以無縫整合基於 Sonic 的高效能 JSON 編解碼方案。

我們從 HTTP 層或 API 層接收到資料後,使用 CloudWeGo 社群的另一個開源框架 Kitex,從而使內部系統通過 Thrift 高效編解碼的方式做資料流轉,以達到減少開銷的目的。同時因為我們對資料有比較高的自定義流量排程能力,所以也使用了 Kitex 拓展性比較強的功能,即自定義負載均衡策略,將相應的指標從 API 層轉到自研資料庫做比較複雜的指標聚合,再全程計算。我們也會做指標非同步的儲存 InfluxDB 等等用於後面的觀測性看板。

此外,我們也使用了 Kitex 在 Thrift 和 Frugal 方面的相關調研,以儘可能地降低協議、反序列化相關的 CPU 記憶體等等資源的開銷。關於這個方面,我們也還在與 Kitex 團隊同學合作進行調研和測試。

Configuration Center

同時我們也使用 Hertz 作為核心控制面配置中心 API 層的服務。這裡的使用方法相對簡單,仍然是使用 Hertz 為非接入 Mesh 的服務提供治理配置的拉取。

如下圖所示,假設 POD A 接入了服務網格,使用資料面做資料存量的流量排程和處理,POD B 使用的是 Kitex 框架,與業務程序同時在一個容器裡面提供服務。對於這樣服務網格和非服務網格的服務之間的呼叫,資料面會向控制面的 Service Mesh Core 請求對應的配置和服務發現結果,框架會向控制面的 Configuration Center 請求對應的服務治理相關配置。實際上配置中心的請求量級與容器的數量是相關的,同時接入服務網格的部分服務框架,我們會請求配置中心獲取一些必不可少的配置資訊。

收益分析

使用了 Hertz 之後,給服務網格帶來的收益大概是怎樣的呢?這可以從三個方面進行分析。

第一是從效能方面,最初選擇 Hertz 也是與很多開源框架從效能方面進行了對比,Hertz 是內部產品,當時還沒有開源,但是它的效能做得非常好。我們具體從效能方面考慮了兩個主要的點,一個是這個框架可以穩定地承載線上超過 13M QPS 的流量,另一個是在上線前後和我們測試過程中發現 CPU 火焰圖的佔比是符合預期的。這一點後續我們會根據效能再詳細地展開介紹。

第二是從應用性方面,這實際上也是我們非常關注的點,即我們如何基於這樣的一款框架快速地實現所需要的功能,從而儘可能關注我們的業務邏輯,而不是框架本身。還有我們如何基於這個框架實現一些高效程式碼,避免還要花費更多精力學習相關語言。

第三是從長效支援方面,目前 Hertz 已貢獻給 CloudWeGo 開源社群,而且開源和內部為統一版本,這也為給我們提供長效支援提供了保證。

下面詳細地從這三個方面進行具體介紹。

收益分析之效能

因為位元組內部業務容器數量過多,因此我們服務的 Goroutine 數量比較多,從而導致穩定性較差。

通過 CPU 火焰圖,可以看到從 Gin 替換成 Hertz 之後,我們獲取的收益主要有四點。

第一,同等吞吐量下具備更高穩定性。Hertz 的設計和實踐都是基於 Netpoll 網路庫實現的,在同樣的吞吐量下,它就會比其他框架具備更高的穩定性。

第二,Goroutine 數量從 6w 降到 80。之前 Goroutine 的數量是 6 萬,使用 Hertz 從 6 萬直接降到不足 100 個,Goroutine 穩定性得到極大地提升。

第三,框架開銷大幅降低。從火焰圖可以看到,替換成 Hertz 後,之前 Gin 框架相關的開銷已經基本消失不見。更多的還是像網路序列化、反序列化和業務邏輯相關的開銷。

第四,穩定承載線上超 13M QPS 流量。替換成 Hertz 後,服務網格在線上穩定承載了超過 13M QPS 的流量。

最後再介紹一下替換前後 CPU 優化情況,替換成為 Hertz 框架後,CPU 流量從大概快到 4k 降到大約只有 2.5k。

收益分析之易用性

我們之前面臨的痛點問題是很難基於已有的框架寫出非常高效能的程式碼,可能需要對 Go 語言有更深入的瞭解。同時我們很難設計一個好的容錯機制,比如要基於已有的框架去實現一個高效能的程式碼,我們要關注連線池、物件池,然後去控制連線超時、請求超時和讀寫超時等等。這中間如果有一個環節實現錯誤,就會導致非常災難性的後果,之後我們要不停地回滾上線修復。

使用 Hertz 之後,程式碼實現變得非常簡單。Hert自帶比較易用的物件回撥機制,我們不用再特別關注請求和響應的物件複用,以及怎樣配置連線超時和請求重試,這些都是 Hertz 框架直接提供的,使用者只需按照它的說明進行配置,它就可以達到使用者預期。

收益分析之長效支援

與效能和應用性相比,我覺得長效支援是更加重要的特性。我們之前在選擇框架時也考慮了一些其他開源專案,但它們的迭代速度往往達不到預期。比如 Fasthttp,它是一個非常優秀的開源高效能 HTTP 框架,但如果使用者有 HTTP/2.0 或者 WebSockets 相關的需求,會發現最近幾年它都沒有做相應的支援,在官方文件上也宣告這方面的研發還在進展之中。

所以在選擇框架或開源方案時,我們可能會遇到一些這樣的問題,如果我們真的要使用它並且要達到預期,可能就要被迫維護開源專案的克隆。如果過一段時間開源專案迭代了,我們還要花時間做 Rebase 或與社群的同步等等,這個維護過程成本比較高。

那使用 Hertz 的收益是什麼呢?首先就是並不是所有的開源專案都有很強大的社群持續運營。CloudWeGo/Hertz 是由位元組內部非常強大的社群組織運營的,同時 Hertz 也是位元組跳動內部廣泛使用的框架。業務同學或其他公司使用者使用 Hertz 時遇到的問題在位元組內部使用過程中都已經出現過,而且已經針對相關問題做了修復或者功能的新增,因此使用者的要求大部分需求會直接得到滿足。

同時 CloudWeGo/Hertz 位元組內部的使用版本是基於 Hertz 的開源版本構建的。很多特性在內部上線之後,我們也會同步地釋出到外部的開源版本上,使得大家能夠快速地使用到這樣的特性,享受到 Hertz 更高的效能。

CloudWeGo 社群已經發布的 Kitex、Netpoll 和 Hertz 等專案,都在持續進行迭代。最近 Hertz v0.2.0 也已經正式釋出,歡迎大家到 CloudWeGo 官網檢視相關資訊。

另外,【CSG 第二期】CloudWeGo 原始碼解讀活動 ——“Hertz 框架篇”開始啦!活動連結:【CSG 第二期】轉發海報送周邊好禮,CloudWeGo 原始碼解讀活動 ——“Hertz 框架篇”開始啦! (qq.com)

 更多資訊