導讀：hulk是短視頻研發部研發的基于GDP2（Go Develop Platform ）的go服務開發框架。它是?款?向業務的Web開發框架，提供了諸多開箱即?的組件和功能，可以?來快速開發Web服務。同時，依托于hulk框架并結合?內/業界優秀的開發實踐，初步構建了?個符合業務應?場景的go?態體系。

全文7330字，預計閱讀時間 12分鐘。

一、產生背景

hulk框架是在“好看視頻”服務端的go服務化架構升級背景下產生的。

1.1 為什么要做架構升級？當前架構面臨哪些問題？

好看視頻初期因業務需要快速、靈活的開發迭代，采?PHP作為開發語?實現后端服務，前期取得了?較好的開發迭代效果。但隨著好看業務快速發展，服務端的項?(接?、代碼等)急速膨脹，類單體的PHP架構在多個??遇到了瓶頸和問題，主要體現在以下?個??：

1.開發效率：對于主代碼庫，所有服務端同學都會在這同一個代碼空間開發，此外還有依賴的第三方團隊也會修改，頻繁的修改/合并降低了開發效率，同時也加大了代碼的維護成本和難度；

2.上線效率：多用戶開發同一代碼庫的另一個弊端就是上線等待，由于同一個時刻只能有一個分支上線（分級上線），導致相連的上線需求要排隊等待。這也導致我們的同學摸索出“搭車上線”的模式，雖然加快了上線效率，但也加大了上線的風險，沒有從根本上解決問題；

3.運行效率：PHP在開發效率和靈活度方面確實有一定優勢，但當所支撐的業務達到幾千萬DAU及以上時，我們必須要考慮服務的運行效率和資源成本等問題。PHP語言在多線程/多協程的支持上，弱于Java、C/C++、Go等語言，基于物理機部署的類單體服務部署架構，在資源利用率和服務擴縮容等方面也很難滿足需求；

4.SRE效率：在出現穩定性問題時，我們期望能夠做到快速感知、快速定位、快速止損。目前基于sia的監控/報警，基于日志的問題定位方式距離理想目標還有一定的距離：一是同學要奔波于各個平臺/系統獲取問題線索，二是獲取到的線索及信息維度很多時候也無法滿足快速、精確定位問題的需求；

這些問題需要通過“4化”，從總體業務架構、部署架構、基礎設施等多方面去解決：

1.2 為什么不直接基于GDP2 ？

好看的go服務化升級工作開展時，GDP2還未正式發布，這也是其中一個因素。

1.3 hulk與gdp2能?對照

下?從三個??與gdp2做?個簡單的對照，初步了解hulk的整體能?及與gdp2的?些差異。

1.3.1 web server能?

hulk?前主要服務于web應?，?先了解?下hulk的web server能?。

1.3.2 功能/組件

功能/組件的豐富度及?身能?，很?程度上影響了框架對業務服務的?持能?。備注：ral資源訪問層

1.3.3 框架周邊及基礎設施

框架從來不是“單打獨?的”，它需要有周邊?具和基礎設施來?持。

NOTE：
1. 好看在做go化時，也調研了開源社區??較優秀的?些?具系統和?案并引?， hulk中默認添加了對這些基礎設施的集成；

1.3.4 對照總結

本節主要站在hulk能力角度與GDP2做了一些方面的參考對照。以上對照，可以概括為4點：

1.很多基礎能?，hulk是復?gdp的，如：bns、net、codec等；

2.?些通?/擴展組件，hulk按照業務需求場景，進??次封裝和增強，如：httpserver、ral、redis、mysql等；

3.對于gdp?前沒有?持的?些業務需求，進?開發集成，如：定時任務、配置中?、服務治理等；

4.參考業界開源實踐，引入了一些新的基礎設施：如prometheus+grafana集群、sentry集群、故障定位系統等；

GDP2由幾十個模塊共同構成，由于時間有限，可能個別功能點的對照有偏差。

二、了解hulk

2.1 設計思路

2.2 框架結構

從功能上來看，hulk的整體能力可以劃分為四層：

2.2.1 基礎組件

提供了絕大部分項目都應該需要的基礎能力，也是其他上層功能組件很可能依賴的組件。hulk框架通過這些基礎組件，使上層應用可以無感的與基礎設施進行集成：

日志組件：默認支持與PHP兼容的打印格式（用于配置sia監控和報警），同時也兼容ftrace接入的格式（日志查詢和問題定位）；

云原生監控：默認支持prometheus，對所有接口請求、redis、ral等遠程調用進行多維度的metrics采集，并通過grafana展示；

配置中心：通過配置中心，可以實時下發并生效配置。目前支持Apollo/iConf，支持功能包括-版本管理、熱發布、灰度發布、權限管理、審核與審計等；

事件追蹤/定位：借助sentry，對于一些故障，我們可以秒級感知。hulk在異常信息中保存了比較完整的現場信息-如調用棧、request、集群和實例信息等，通過這些信息，可以直接定位問題的原因；

2.2.2 通用組件

這一層的組件能力是通用的，提供了一些管理控制和切面能力：

ral組件：hulk的ral模塊封裝了GDP2的ral主體功能，同時，對ral進行了增強- a) 提供了通過字符串而非文件來進行ral初始化和ral懶加載功能；b) 提供了多個hook能力，如prometheus的監控信息采集，熔斷、降級等；

服務治理：框架的服務治理能力是基于Sentinel （阿里開源的高可用流量防護組件）和配置中心來構建的，主要以流量為切入點，從限流、流量整形、熔斷、降級等多個維度來協助保障微服務的穩定性，并提供動態控制能力；

協程池：a) 可以自動調度海量協程，復用goroutines，減少gc，b) 可以優雅處理 panic，防止程序崩潰 c) 提供了：任務提交、獲取運行中的 goroutine 數量、封裝了WaitGroup支持協程任務編排等功能；

事件通知：框架與如流做了集成。用戶將robot token配置在項目里，就可以直接使用ruliu組件向指定的如流群發送報警/通告。如流組件結合sentry，可以讓我們第一時間知道程序出了問題并快速定位到問題；

2.2.3 擴展組件

前兩層功能對直接的業務處理邏輯參與較少，這一層的組件其能力多是為了處理某一類特定業務邏輯和場景，如redis/mysql/定時任務等：

1.redis組件：基于GDP2 redis模塊的封裝并作了功能增，提供了：

a) metrics hook，對所有的redis請求進行監控(prometheus)打點（latency/p99/qps/錯誤碼分布等）；

b) sentry hook，支持將redis錯誤在記錯誤日志同時發送到sentry；

c) 降級hook，支持按集群/實例/百分比維度降級redis訪問；

d) 熔斷hook，支持按集群/實例/錯誤率/慢請求率對依賴的服務進行熔斷設置；

2.mysql組件：mysql組件是基于GDP2 mysql和 gorm_adapter的封裝，在已有能力之上，進行了以下功能擴展：

a) 提供了metrics hook，對所有的mysql請求進行監控(prometheus)打點（latency/p99/qps/錯誤碼分布等）；

b) 提供了sentry hook，支持將mysql錯誤在記錯誤日志的同時發送到sentry；

3.分布式鎖：hulk提供了基于redis的分布式鎖實現。其中redis連接是基于GDP2的redis模塊的改造，分布式鎖功能是封裝了開源項目redsync；

4.定時任務：支持兩種定時任務模式；

a) 帶分布式鎖的運行方式：對于多實例部署的定時任務，如果任務不是冪等的，則需要使用分布式鎖對任務的調度運行進行控制；

b) 不帶分布式鎖的運行方式：此模式下，如果部署了多實例，則所有實例上同一時刻的定時任務，會同時執行；

2.2.4 http server

hulk（目前只提供了http server能力）提供了很多通用且高效的http middleware，并對外暴露了一些管理控制接口，在一些特殊情況下，可以通過這些管理接口，在運行時干預服務的運行：

logger_middleware：用于記錄http的請求、響應、耗時等信息，同時支持實時修改日志打印策略-如按idc/ip/百分比/uid/cuid等維度打印；
timer_middleware：用于http請求的監控埋點，可以輸出可用性、tp99、流量、平響、錯誤碼等metrics，維度包括服務級/idc/instance等；
recover_middleware：用于捕獲http 請求鏈路中的painc事件，并可自定義panic handler邏輯，如通過結合sentry和如流，可以實時感知并定位panic事件；
flow_control_middleware：接口限流組件，可以通過配置中心或管理接口，對接口按idc/instance維度進行限流；
timeout_middleware：通過該middleware或與配置中心結合使用，可以對接口按idc維度進行超時控制；
其他middleware可以查看hulk文檔
（如-internal_user_middleware、jager_opentracing_middleware、thirdparty_auth_middleware、b2logger_middleware等）
管理控制接口：如健康檢查接口，服務治理-熔斷、限流、降級接口，metrics接口，線上實例性能調試接口等；

2.3 框架生態

通過近一年的建設，我們初步構建了一個以hulk框架為中心的、符合好看業務場景的go生態體系，包括：

標準目錄規范：避免各個項目結構不統一，減少項目維護難度和工作量；
代碼生成器：基于hulk框架、標準目錄規范、組件使用規范的代碼生成器，目的是減少通用模塊/組件使用不規范，解決通用流程編碼、處理不一致的問題；
hklib：好看的通用lib庫，提供了一些的通用功能（也包含了很多PHP轉go過程中的一些orp通用/基礎的函數/功能），也提供了50+對中臺服務的調用client，減少重復代碼，提升研發效率，提升可維護性；
基礎設施：prometheus+thanos集群、sentry服務、apollo集群、pyroscope性能分析平臺等；
iconf：好看自研配置中心，能力在對齊開源的Apollo之外，還增加/增強了一些功能，如-key維度的發布、更安全的配置獲取、更簡潔的操作頁面、類分級發布等；
artemis：服務可視化與故障智能定位系統，可以在該系統中看到服務的部署架構、服務內部調用鏈、多維度細粒度的近實時監控和關鍵日志。在發生可用性故障時，一些故障問題可以秒級的定位到原因和具體代碼；

2.4 框架應用情況

目前短視頻所有go服務都是基于hulk構建的，在資源、接口性能和可用性等方面都有一些階段性產出和收益。

hulk框架應用現狀：

資源和性能收益：

資源和性能收益，很大一部分要歸屬于PHP->Go的技術棧切換；而框架為服務應用相應技術棧特性提供了便捷和高效的方式。

2.4 hulk服務架構

下圖描述了一個微服務（基于hulk）的架構全景圖：

框架中個各功能組件都是圍繞業務各個場景和需求的，在業務邏輯中能夠比較便捷的使用相關功能組件；
這些組件在啟用后，也會與相應的基礎設施進行交互融合，共同支撐服務的高效、可控和穩定的運行；

hulk組件初始化及與周邊基礎設施的集成，基本都可以通過環境變量/配置文件來完成。

三、框架能力與應用

下面我們從日常開發遇到的一些痛點，來介紹框架的能力，并配以示例來說明這些能力是如何減少或解決痛點的。

3.1 如何提升代碼質量？

代碼質量會直接或間接的產生以下影響：

代碼質量會直接影響代碼維護成本；
代碼質量會影響程序出bug的概率；
代碼質量會影響程序運行效率；

hulk框架從以下三方面分別來提升代碼質量。

3.1.1 規范代碼組織結構

降低項目維護成本，提升研發效率。

通過標準目錄規范，定義通用(http服務)的項目layout，避免出現每人一種或多種layout，最終項目結構“百花齊放”的現象；
通過代碼生成器，幫助開發者生成項目模板，對初始化流程，各目錄/文件的使用進行潛在約定；

3.1.2 編碼規范和靜態檢查

提升代碼可讀性，減少低級代碼bug

遵循百度Go編碼規范+業務編碼補充規范；
使用GDP的代碼檢查工具：go_fmt、goc；

3.1.3 配套的壓測和性能分析平臺

確定服務的壓力邊界，發現潛在的性能問題。

壓測和性能測試平臺（測試環境）：nGrinder

程序性能分析平臺：pyroscope。可以通過hulk自集成的管理接口，實時打開或關閉線上實例的“continuous-prof”功能，定位線上性能問題：

3.2 如何提升開發迭代速度？

如何讓開發者專注于業務邏輯與實現？
如何讓開發者快速響應并完成產品需求？

hulk框架為提升迭代速度，提供了以下支持。

3.2.1 豐富的實用組件/功能

提升研發效率，避免試錯，減少出錯。

程序增強組件：增強的redis/mysql功能，增強的ral調用等。例-下圖中的redis監控，其監控指標是由hulk redis組件自動采集計算的：

優秀的開源組件：sentry、prometheus+grafana、apollo、協程池等。例-prometheus+grafana：hulk框架默認支持prometheus，可以對服務的可用性、QPS、耗時、錯誤碼等metrics自動計算收集：

豐富的http middleware。

3.2.2 配置化、低代碼支持

減少代碼的修改和上線，提升需求的響應和完成速度。

hulk框架中大部分組件可以通過環境變量/配置文件來初始化；
業務邏輯中的可變數據與配置，可以通過apollo/iconf實時下發和生效，無需代碼修改和長流程上線。例-可以通過開箱即用的配置中心功能，實時下發并生效配置：

3.3 如何快速感知并定位問題？

開發者如何快速感知服務中的問題，嚴重問題如何實時感知？
開發者如何能從監控、日志、報警中獲得詳細的問題信息，以快速定位問題？

hulk為提升SRE效率，從以下幾個方面提供支持。

3.3.1 完善的事件追蹤定位與通告能力

能夠實時追蹤開發者自定義的錯誤并通告

實時事件追蹤組件：sentry。hulk提供了開箱即用的sentry組件功能，可以像打印日志一樣使用，sentry中的信息包含代碼調用棧、上下文、自定義關鍵信息等：

通告組件：ruliu。一行token配置就可以開啟如流功能，可以將一些需要立即關注的信息實時打到如流群里，同時還可以和sentry結合，實現異常問題實時感知和定位：

3.3.2 prometheus+sia監控支持

通過prometheus與noah的互補，支持多維度全方位監控，能夠獲得更多的服務穩定性相關信息

prometheus為開發者提供靈活的多維度的業務監控信息；
sia可以為開發者提供基于日志的采集的服務穩定指標和容器、網絡等資源維度監控信息；

3.3.3 ftrace日志查詢與分析功能

hulk默認支持ftrace平臺的日志格式

通過ftrace，可以便捷高效的查詢用戶維度的日志信息；

通過pdo2命令，可以檢索查詢自定義規則的日志信息；

3.4 基于hulk的服務可視化和故障智能定位系統

artemis是我們基于hulk研發的一款服務可視化與故障智能定位追蹤系統，它集服務部署架構可視化、近實時多維度監控、關鍵日志、服務調用鏈等多方面信息，可以快速、高效、精準的發現和定位穩定性問題。

該系統目前已接入好看/全民/度咔等多個后端服務，極大加速了故障定位效率。在一些故障場景，可以秒級定位問題，給出問題的代碼行。

3.4.1 服務部署架構

通過實例列表，可以獲取服務的idc列表、instance列表和詳情，并提供了便捷高效的調試入口和登錄指令：

3.4.2 近實時多維度監控

artemis提供的近實時監控，能夠提供更多維度信息，這些維度是sia和prometheus無法提供的，如：

某個URI下面的某個下游(或下游實例)RAL的QPS、耗時、可用性；
某個服務實例實例的URI或RAL的監控信息；

3.4.3 關鍵日志

由于與hulk的深度集成，在業務代碼中打印warning級別以上的日志時，artemis能拿到更多的日志信息，如-各維度信息、調用棧、上下文等：

3.4.4 服務調用鏈

在hulk框架的協助下，artemis還可以獲取到URI及URI所依賴的RAL調用信息，由此可以構建出請求調用鏈，并實時展示調用鏈上的相關metrics信息：

不同顏色的鏈路代表不同的可用性：紅色-1個9及以下，黃色-2個9，藍色-3個9，灰色-4個9。通過服務調用鏈，可以非常直觀的看到服務里，哪個接口有問題，還可以看到哪些下游影響了這個接口的可用性。

3.4.5 使用案例

通過與報警系統的聯動，可以在發生報警的第一時間，在artemis系統中找到受影響的服務及URI，確定是否是下游引起，錯誤是什么，哪一行代碼報了錯等，以下是一個artemis的實際應用示例。

四、總結

hulk雖然是?個新的go語?web框架，但不是重復造輪，?是站在?內和開源軟件的基礎上，結合業務實際開發、部署、運?、運維環境，對這些開源框架和?具進?取?補短、?次開發，最終切合實際的業務使?場景。同時，圍繞hulk初步構建起的go生態，為服務在開發、部署、運行、運維等各個階段都提供了有力支持。

最后，希望短視頻研發部在go服務化架構升級/研發框架上的?些實踐、?案和經驗，能夠給有相同架構升級需求、在go項?實踐中遇到問題的其他業務線同學?些幫助和參考。

五、附錄（外網不可訪問）

1. 框架及使??檔：http://hulk-go.baidu-int.com/

2. hulk底層是基于GDP2的，了解gdp也更有助于了解hulk：http://gdp.baidu-int.com/

會吹牛逼真的很重要

關于堆棧的講解(我見過的最經典的)

寫出高效代碼的12條建議

查看全文