本文將從以下五個(gè)方面介紹 CloudWeGo 大規(guī)模企業(yè)級 HTTP 框架 Hertz：

1. 字節(jié)跳動內(nèi)部 Go HTTP 框架的變遷；
2. 企業(yè)級 HTTP 框架的設(shè)計(jì)考量和落地思路；
3. Hertz 的核心特點(diǎn)；
4. 未來規(guī)劃和挑戰(zhàn)；
5. 總結(jié)。

1. 字節(jié)跳動內(nèi)部 Go HTTP 框架的變遷

在正式開始介紹第一部分的內(nèi)容之前，先給大家展示一組關(guān)鍵詞。2020 年初 Hertz 立項(xiàng)，2020 年 10 月，Hertz 發(fā)布第一個(gè)可用版本。2022 年 6 月，Hertz 正式開源。 截至目前，Hertz 在字節(jié)內(nèi)部已經(jīng)支撐超過 1.4 萬個(gè)業(yè)務(wù)服務(wù)，日峰值 QPS 超過 5000 萬。

Hertz 不僅支撐業(yè)務(wù)服務(wù)，同時(shí)還會橫向支撐字節(jié)內(nèi)部的各種基礎(chǔ)組件，包括但不限于字節(jié)跳動服務(wù)網(wǎng)格控制面、公司級別壓測平臺以及 FaaS，還包括各種業(yè)務(wù)網(wǎng)關(guān)等等。Hertz 的高性能和極強(qiáng)的穩(wěn)定性可以支撐業(yè)務(wù)復(fù)雜多變的場景。在公司內(nèi)部 Hertz 接替了大量基于 Gin 框架開發(fā)的存量服務(wù)，大幅度降低了業(yè)務(wù)資源使用成本以及服務(wù)延時(shí)，助力公司層面的降本增效。

下面我們可以從 Hertz 出現(xiàn)的背景以及 Hertz 的設(shè)計(jì)目標(biāo)和思路體會到，Hertz 的出現(xiàn)絕不是偶然。

1.1 基于 Gin 封裝

眾所周知，字節(jié)內(nèi)部使用 Golang 比較早，在大約 2014 年左右，公司就已經(jīng)開始嘗試做一些 Golang 業(yè)務(wù)的轉(zhuǎn)型。2016 年，我們基于已開源的 Golang HTTP 框架 Gin 框架，封裝了 Ginex，這是 Ginex 剛開始出現(xiàn)的時(shí)期。

同時(shí)，2016 年還是一個(gè)開荒的時(shí)代，這個(gè)時(shí)期框架伴隨著業(yè)務(wù)快速野蠻地生長，我們的口號是“大力出奇跡”，把優(yōu)先解決業(yè)務(wù)需求作為第一要務(wù)。Ginex 的迭代方式是業(yè)務(wù)和框架側(cè)在同一個(gè)倉庫里面共同維護(hù)和迭代。

1.2 問題顯現(xiàn)

2017 - 2019 年期間，也就是 Ginex 發(fā)布之后，問題逐漸顯現(xiàn)。主要有以下幾點(diǎn)：

迭代受開源項(xiàng)目限制

Ginex 是一個(gè)基于 Gin 的開源封裝，所以它本身在迭代方面是受到一些限制的。一旦有針對公司級的需求開發(fā)，以及 Bugfix 等等，我們都需要和開源框架 Gin 做聯(lián)合開發(fā)和維護(hù)，這個(gè)周期不能完全由我們自己控制。

代碼混亂膨脹、維護(hù)困難

由于我們和業(yè)務(wù)同學(xué)共同開發(fā)和維護(hù) Ginex 框架，因此我們對于控制整個(gè)框架的走向沒有完全的自主權(quán)，從而導(dǎo)致了整體代碼混亂膨脹，到后期我們發(fā)現(xiàn)越來越難維護(hù)。

無法滿足性能敏感業(yè)務(wù)需求

另外，我們能用 Gin 做的性能優(yōu)化非常少，因?yàn)?Gin 的底層是基于 Golang 的一個(gè)原生庫，所以如果我們要做優(yōu)化，需要在原生庫的基礎(chǔ)上做很多改造，這個(gè)其實(shí)是非常困難的。

無法滿足不同場景的功能需求

我們內(nèi)部逐漸出現(xiàn)了一些新的場景，因此會有對 HTTP Client 的需求，支持 Websocket、支持 HTTP/2 以及支持 HTTP/3 等等需求，而在原生的 Ginex 上還是很難擴(kuò)展的這些功能需求。

1.3 魔改開源框架

逐漸地，某些業(yè)務(wù)線開始做初步的嘗試，他們會對另外的一些開源框架進(jìn)行魔改。比較典型的例子是有一些業(yè)務(wù)線嘗試基于 Fasthttp 進(jìn)行魔改，F(xiàn)asthttp 是一款主打高性能的開源框架，基于它進(jìn)行魔改可以短期內(nèi)幫助業(yè)務(wù)解決問題。這種魔改現(xiàn)象帶來的問題是，框架魔改是一些業(yè)務(wù)線自發(fā)的行為，各個(gè)業(yè)務(wù)線可能會基于自身業(yè)務(wù)特性進(jìn)行各自維護(hù)，從而導(dǎo)致維護(hù)成本上升非常嚴(yán)重。

到這里我們仿佛陷入了 Ginex 的怪圈。如前段時(shí)間爆火的電視劇《開端》一樣，我們仿佛是從一輛開往學(xué)院南路的 45 路公交車上醒來，發(fā)現(xiàn)自己要前往公司進(jìn)行下一代 Ginex 框架的維護(hù)工作。

大家也可以思考一下，如果是你來應(yīng)對這樣的場景，你會怎么做呢？

1.4 小結(jié)

第一章節(jié)的內(nèi)容總結(jié)如下：

早期基于開源框架封裝

基于早期開源的 Golang HTTP 框架，實(shí)現(xiàn)了 Ginex 的封裝。

隨著實(shí)踐發(fā)展，問題逐漸出現(xiàn)

框架混亂膨脹，框架的維護(hù)越來越困難，業(yè)務(wù)的新需求無法得到很好地滿足。

為了解決問題出現(xiàn)基于另外的開源框架魔改的萌芽

我們需要思考如何跳出魔改的怪圈，把字節(jié)內(nèi)部的企業(yè)級框架做得更好。

另外，還有一個(gè)遺留問題，就是應(yīng)該如何跳出這個(gè)魔改的怪圈呢？這個(gè)問題第二章節(jié)會為大家進(jìn)行解答。

2. 企業(yè)級 HTTP 框架的設(shè)計(jì)考量和落地思路

2.1 跳出怪圈

為了跳出魔改的怪圈，我們決定從以下三個(gè)方面開始著手。

自主研發(fā)

既然 Ginex 是因?yàn)榛陂_源框架 Gin，沒法做一些靈活的控制，那我們就改為完全自主研發(fā)框架。自主研發(fā)框架的代碼全鏈路自主可控，也可以避免引入任何三方不可控因素，這樣我們能夠?qū)ψ约旱目蚣苡幸粋€(gè)比較完備的掌控力。

質(zhì)量控制

下圖列舉了一些常規(guī)的質(zhì)量控制手段。我要著重強(qiáng)調(diào)的是模糊測試，模糊測試在字節(jié)內(nèi)部是廣泛應(yīng)用于 Hertz 框架的穩(wěn)定性測試中。它的核心點(diǎn)在于通過一系列的模擬服務(wù)，嘗試模擬出線上用戶在使用我們的框架時(shí)，實(shí)際遇到的一些場景和使用方式。然后通過一些隨機(jī)的算法，生成盡可能復(fù)雜、覆蓋各種 Case 的場景，這可以讓我們檢測出一些潛在的問題。這套測試也在 Hertz 早期的質(zhì)量建設(shè)中，幫助我們將一些問題防患于未然。

嚴(yán)格準(zhǔn)入

既然 Ginex 的問題是大家都在向里面寫入內(nèi)容，那么我們可以控制入口，建立一套完備的需求開發(fā)以及 Review 的閉環(huán)，控制迭代的整體流程，從而控制代碼準(zhǔn)入。同時(shí)我們配備統(tǒng)一的需求管理以及嚴(yán)格的發(fā)版準(zhǔn)入規(guī)范，做一個(gè)標(biāo)準(zhǔn)的公司級別的框架。

舉一個(gè)比較形象的例子，如果我們把下一代框架比作一個(gè)人——“框架人”，自主研發(fā)表示這個(gè)“框架人”首先會擁有對自己身體的主導(dǎo)權(quán)，他不會受到來自于環(huán)境或者他人的影響；質(zhì)量控制表示“框架人”能夠定期體檢，提早發(fā)現(xiàn)一些潛在的疾病，將其扼殺于搖籃；嚴(yán)格準(zhǔn)入表示“框架人”有科學(xué)的飲食攝入和自律的生活習(xí)慣。可想而知，如果我們能夠做到以上三點(diǎn)，我們的“框架人”就能夠擁有一個(gè)健康的體魄。

2.2 痛點(diǎn)梳理

明確了應(yīng)該如何跳出怪圈之后，我們還應(yīng)該明確知道這個(gè)框架要具備哪些功能和特性，也就是首先應(yīng)該聚焦到框架的核心痛點(diǎn)上?！翱蚣苋恕辈荒苤挥薪】档捏w魄，還應(yīng)該擁有有趣的思想和靈魂。一個(gè)成熟的框架不僅僅要應(yīng)對來自業(yè)務(wù)側(cè)的需求，如功能需求、性能需求和易用穩(wěn)定等，還要考慮框架自身的發(fā)展，而這一點(diǎn)恰恰是我們在 Ginex 的迭代過程中忽略的。

如下圖右側(cè)金字塔所示，最上層是高效支撐，毋庸置疑框架的存在肯定是為了支撐我們的業(yè)務(wù)需求。中間層是一個(gè)質(zhì)量保證的紅線框架，框架需要保證它自身的質(zhì)量，只有以高質(zhì)量完成的框架才能有自信承擔(dān)字節(jié)內(nèi)部的 5000 萬 QPS，以及各種各樣的使用場景。金字塔的最底層是長期、可持續(xù)性發(fā)展， 這也是作為未來想要保持持續(xù)迭代的框架最重要的一點(diǎn)。

2.3 框架科學(xué)發(fā)展觀

基于上一部分，我們可以進(jìn)一步梳理出框架的需求痛點(diǎn)。痛點(diǎn)主要有兩個(gè)方面：

• 多樣的需求：支撐支撐各個(gè)業(yè)務(wù)線及基礎(chǔ)設(shè)施 （橫向擴(kuò)展性）。
• 靈活的結(jié)構(gòu)：貫穿HTTP生命周期的掌控力 （縱向模塊化）。

在此基礎(chǔ)上進(jìn)一步抽象出框架的科學(xué)發(fā)展觀：

• 聚類需求：面向通用能力展開設(shè)計(jì)。
• 跳出局部：針對一些復(fù)雜問題，在更大范圍內(nèi)尋求最優(yōu)解。

后續(xù)我會針對這個(gè)科學(xué)發(fā)展觀進(jìn)一步闡述 Hertz 究竟是如何實(shí)現(xiàn)的。

2.4 小結(jié)

第二章節(jié)的內(nèi)容總結(jié)如下：

跳出怪圈

引入“框架人”的概念，幫助大家理解框架的自研、質(zhì)量控制和嚴(yán)格準(zhǔn)入。

痛點(diǎn)梳理

為“框架人”注入有趣的靈魂，框架需要應(yīng)對來自業(yè)務(wù)側(cè)的多樣化需求，還要保證自己的可持續(xù)性發(fā)展。

框架科學(xué)發(fā)展觀

需求聚類，跳出局部。

3. Hertz 的核心特點(diǎn)

Hertz 框架是如何實(shí)現(xiàn)第二章節(jié)中提到的框架痛點(diǎn)和科學(xué)發(fā)展觀的呢？本章節(jié)將具體進(jìn)行介紹。

3.1 分層抽象

首先介紹 Hertz 框架的架構(gòu)設(shè)計(jì)。下圖是一個(gè)請求從建立、連接到完成的全過程。左側(cè)是 客戶端 ，右側(cè)是服務(wù)端，在我們發(fā)起鏈接建立請求之后，鏈接建立完成；之后客戶端發(fā)起請求到服務(wù)端，服務(wù)端進(jìn)行路由處理，然后將路由導(dǎo)向業(yè)務(wù)邏輯處理；業(yè)務(wù)邏輯處理完畢后，服務(wù)端返回這個(gè)請求，完成一次 HTTP 請求的調(diào)用。

那么在這個(gè)過程中我們的框架到底做了哪些事情呢？從圖中不難發(fā)現(xiàn)，首先框架進(jìn)行了鏈接處理，其次是協(xié)議處理，之后基于路由做了邏輯分發(fā)，即路由處理，最后做了業(yè)務(wù)邏輯處理。我們把框架做成一個(gè)結(jié)構(gòu)之后會發(fā)現(xiàn)，這個(gè)結(jié)構(gòu)包含的就是這四部分。

基于這個(gè)邏輯，我們可以看一下 Hertz 的整體架構(gòu)圖。如下圖所示，從下往上看紅線框圈住的部分，可以發(fā)現(xiàn)這就是上文提到的請求建立的全過程。各層的能力及作用如下：

• 傳輸層 Transport：抽象網(wǎng)絡(luò)接口；
• 協(xié)議層 Protocol：解析請求，渲染響應(yīng)編碼；
• 路由層 Route：基于URL進(jìn)行邏輯分發(fā)；
• 應(yīng)用層 Application：業(yè)務(wù)直接交互，出現(xiàn)大量 API。

我們可以看到圖中除了中間部分包含的四層，左右兩側(cè)各有兩列。右側(cè)是通用層 Common，主要負(fù)責(zé)提供通用能力、常用的日志接口、鏈路追蹤以及一些配置處理相關(guān)的能力等。左側(cè)是 Hertz 的代碼生成工具 Hz，又稱腳手架工具，它可以幫助我們在內(nèi)部基于 IDL 快速地生成項(xiàng)目骨架，以加速業(yè)務(wù)迭代。

Hertz 的分層設(shè)計(jì)是能夠和代碼組織結(jié)構(gòu)一一映射的。下圖是 Hertz 倉庫里面的代碼組織結(jié)構(gòu)，可以看到根目錄下的 cmd 包里面存放著 Hz 工具，在 pkg 包下存放著上述主要四層以及通用層 Common。因此同學(xué)們看到架構(gòu)設(shè)計(jì)圖之后，可以直接在 Github 學(xué)習(xí) Hertz 的代碼。

Hertz: https://github.com/cloudwego/hertz

總體來說，Hertz 的架構(gòu)設(shè)計(jì)理念就是 “簡潔有序，保證讓所有開發(fā)者輕松理解，在開發(fā)的過程中持續(xù)貫徹” 。

3.2 易用可擴(kuò)展

那么基于 Hertz 的架構(gòu)設(shè)計(jì)，應(yīng)該如何展開易用性和可擴(kuò)展性呢？下圖是 Hertz 架構(gòu)主要四個(gè)層級的抽象。

應(yīng)用層

應(yīng)用層提供了一些通用能力，包括綁定請求、響應(yīng)渲染、 服務(wù)發(fā)現(xiàn) /注冊/ 負(fù)載均衡以及服務(wù)治理等等。其中，洋蔥模型中間件的核心目的是讓業(yè)務(wù)開發(fā)同學(xué)基于這個(gè)中間件快速地給業(yè)務(wù)邏輯進(jìn)行擴(kuò)展，擴(kuò)展方式是可以在業(yè)務(wù)邏輯處理前和處理后分別插樁埋點(diǎn)做相應(yīng)處理。一些比較有代表性的應(yīng)用，包括日志打點(diǎn)、前置的安全檢測，都是通過洋蔥模型中間件進(jìn)行處理的。

路由層

路由層也是非常通用的，主要提供靜態(tài)路由、參數(shù)路由、為路由配置優(yōu)先級以及路由修復(fù)的能力，如果我們的路由層沒辦法滿足用戶需求，它還能支撐用戶做自定義路由的擴(kuò)展。但實(shí)際應(yīng)用中這些路由能力完全能夠滿足絕大多數(shù)用戶的需求。

協(xié)議層

Hertz 同時(shí)提供 HTTP/1.1 和 HTTP/2，HTTP/3 也是我們在建設(shè)中的能力，我們還會提供 Websocket 等 HTTP 相關(guān)的多協(xié)議支持，以及支持完全由業(yè)務(wù)決定的自定義協(xié)議層擴(kuò)展。

傳輸層

目前我們已經(jīng)內(nèi)置了兩個(gè)高性能的傳輸層實(shí)現(xiàn)。一個(gè)是基于 CloudWeGo 開源的高性能網(wǎng)絡(luò)庫 Netpoll 的傳輸層擴(kuò)展，另一個(gè)是支持基于標(biāo)準(zhǔn)庫的傳輸層擴(kuò)展。此外，我們也同樣能支持在傳輸層上進(jìn)行自定義傳輸層協(xié)議擴(kuò)展。

下圖每一層中標(biāo)紅的能力都能夠體現(xiàn)出，我們能夠在框架的任何一個(gè)分層上支撐用戶做最大程度的自由定制，這樣可以最大程度地滿足企業(yè)級內(nèi)部用戶和潛在用戶的業(yè)務(wù)需求。如果同學(xué)們想要深入了解 Hertz，可以參考 CloudWeGo 官網(wǎng)的 Hertz 部分，上述所有內(nèi)容均有具體描述。

官網(wǎng)：https://www.cloudwego.io/zh/docs/hertz/

3.3 性能探索

在性能方面，Hertz 又是如何在自主可控的范圍內(nèi)做高性能探索的呢？

3.3.1 場景描述

熟悉 Hertz 代碼的同學(xué)會發(fā)現(xiàn)，我們的 HTTP/1.1 協(xié)議借鑒了一些 Fasthttp 的優(yōu)化思路和手段。HTTP/1.1 協(xié)議中的 Header 為不定長數(shù)據(jù)段，往往需要解析到最后一行，才能夠確定是否完成解析。同時(shí)，為了減少系統(tǒng)調(diào)用次數(shù)，提升整體解析效率，涉及 IO 操作時(shí)，我們通常引入帶 buffer 的 IO 數(shù)據(jù)結(jié)構(gòu)。如下圖所示，它的核心點(diǎn)是最下層的 buffer，buffer 是一個(gè)類似于一塊完整的內(nèi)存空間，我們可以將 IO 讀到的數(shù)據(jù)放進(jìn)這個(gè)空間做暫存。

3.3.2 bufio.Reader 的問題

這樣做出現(xiàn)的問題是，原生的 bufio.Reader 長度是固定的，請求的 Header 大小超出 buffer 長度后，.Peek()? 方法直接報(bào)錯 (ErrBufferFul)，無法完成既定語義功能。

3.3.3 一些可能的解

對于上述問題，其實(shí)有一些可能的解決方法：

• 直接利用 bufio.Reader 的局限當(dāng)做 Feature，通過 buffer 大小作為 Header 大小的限制。如果超出這個(gè)大小，Header 直接解析報(bào)錯，這也是 Fasthttp 的做法。但實(shí)際上超出 buffer 長度后報(bào)錯會導(dǎo)致我們沒辦法處理這部分請求，從而導(dǎo)致框架功能受限。
• header 解析帶狀態(tài)，暫存中間數(shù)據(jù)，通過在上層堆疊額外復(fù)雜度的方式突破 bufio 本身的限制。但是暫存中間態(tài)會涉及到一些內(nèi)存的拷貝，必然會導(dǎo)致性能受限。

3.3.4 真實(shí)使用環(huán)境復(fù)雜多變

字節(jié)內(nèi)部的使用場景非常多，我們不僅要支持各種業(yè)務(wù)線的開發(fā)，還要支持一些橫向的基礎(chǔ)組件。不同的業(yè)務(wù)，不同的場景，數(shù)據(jù)規(guī)模各異。如何成為通用且高效地解決 bufio.Reader 的問題成為 Hertz 面臨的內(nèi)部重要挑戰(zhàn)。我們既然已經(jīng)站在 Fasthttp 這個(gè)“巨人”的肩膀上了，能否往前再走一步呢？

答案是肯定的?；趦?nèi)部的使用場景，同時(shí)結(jié)合 Netpoll 的優(yōu)勢，我們設(shè)計(jì)出了自適應(yīng) linked buffer，并且用它替代掉了原生的 bufio.Reader。從下圖可以看到，我們的 buffer 不再是一個(gè)固定長度的 buffer，而是一條鏈，這條鏈上的每一個(gè) buffer 大小能夠根據(jù)線上真實(shí)請求進(jìn)行動態(tài)擴(kuò)縮容調(diào)整，同時(shí)搭配 Netpoll 中基于 LT 觸發(fā)的模型做數(shù)據(jù)預(yù)拷貝。從實(shí)施效果上來看，這個(gè)自適應(yīng)調(diào)整能夠讓我們的業(yè)務(wù)方完全無感地支撐任何他們的業(yè)務(wù)特性。也是因?yàn)槲覀兡軌驅(qū)?buffer 進(jìn)行動態(tài)擴(kuò)縮容調(diào)整，從而能夠保證在協(xié)議層最大程度做到零拷貝協(xié)議解析， 這能夠帶來整體解析上的性能提升，時(shí)延也會更低。

3.3.5 針對 HTTP/1.1 進(jìn)行中的優(yōu)化

因?yàn)槟壳霸谧止?jié)內(nèi)部 HTTP/1.1 還是一個(gè)比較主流的協(xié)議，所以我們基于 HTTP/1.1 做了很多嘗試。

首先是協(xié)議層探索。我們正在嘗試基于 Header Passer 的 重構(gòu)，把解析 Header 的流程做得更高效。我們還嘗試了做一些傳輸層預(yù)解析，將一些比較固化的邏輯下沉到傳輸層做加速。

其次是傳輸層探索。這包括使用 writev 整合發(fā)送 Header & Body 達(dá)到減少系統(tǒng)調(diào)用次數(shù)的目的，以及通過新增接口整合 .Peek() + .Skip() 語義， 在內(nèi)部提供一個(gè)更高效的實(shí)現(xiàn)。

3.3.6 Hertz Benchmark

下圖是 Benchmark 的開源數(shù)據(jù)。左側(cè)第一張圖是在同等的機(jī)器環(huán)境上，Hertz 和橫向的框架 Gin、Fasthttp 極限 QPS 比較情況，藍(lán)線是 Hertz 處于較高極限 QPS 的狀態(tài)。第二張圖是 TP99 時(shí)延狀態(tài)，第三張圖是 TP999 時(shí)延狀態(tài)，可以看到 Hertz 的整體時(shí)延是處于一個(gè)更低的水平上。

3.3.7 字節(jié)跳動服務(wù)網(wǎng)格控制面從 Gin 遷移至 Hertz

CloudWeGo 公眾號曾發(fā)布關(guān)于字節(jié)跳動服務(wù)網(wǎng)格控制面的文章，講述字節(jié)跳動服務(wù)網(wǎng)格從 Gin 框架遷移到 Hertz 的落地實(shí)踐。下圖是他們代碼展示的真實(shí)收益，從 Gin 框架替換成為 Hertz 框架后，CPU 流量從大概快到 4K 降到大約只有 2.5K，Goroutine 數(shù)量從 6w 降到不足 100 個(gè)，Goroutine 穩(wěn)定性得到極大地提升。同時(shí)替換成 Hertz 后，框架相關(guān)的開銷已經(jīng)基本消失，服務(wù)網(wǎng)格在線上穩(wěn)定承載了超過 13M QPS 的流量。

字節(jié)跳動服務(wù)網(wǎng)格基于 Hertz 框架的實(shí)踐：https://mp.weixin.qq.com/s/koi9q_57Vk59YYtO9cyAFA

3.4 小結(jié)

第三章節(jié)的內(nèi)容總結(jié)如下：

分層抽象

解構(gòu) HTTP 框架，分層解耦。

易用可擴(kuò)展

提供了更豐富 API 和足夠靈活的拓展能力，在每一層抽象中都提供了一個(gè)足夠靈活的擴(kuò)展能力應(yīng)對可能的需求。

自主可控的高性能探索

自適應(yīng) buffer，零拷貝解析，未來將會進(jìn)行更多的高性能探索。

4. 未來規(guī)劃和挑戰(zhàn)

我認(rèn)為 Hertz 未來的發(fā)展規(guī)劃主要圍繞以下幾個(gè)方面：首先，打造泛 HTTP 框架。我們的最終目標(biāo)是希望 Hertz 能夠解決在 HTTP 領(lǐng)域內(nèi)的所有問題；其次，助力 CloudWeGo ， 希望 Hertz 能夠助力 CloudWeGo 打造一個(gè)企業(yè)級云原生微服務(wù)矩陣；最后希望 Hertz 能夠持續(xù)服務(wù)更多的用戶。

5. 總結(jié)

本次分享的主要內(nèi)容總結(jié)如下：

• 字節(jié)跳動內(nèi)部 Go HTTP 框架的變遷：從基于開源封裝，到開啟自研之路；
• 企業(yè)級 HTTP 框架的設(shè)計(jì)考量和落地思路：破圈、需求提煉、框架科學(xué)發(fā)展觀；
• Hertz 核心特點(diǎn)：分層抽象、易用可擴(kuò)展、自主可控的性能探索；
• Hertz 未來的規(guī)劃和挑戰(zhàn)：框架持續(xù)打磨、助力 CloudWeGo、服務(wù)更多用戶。