短視頻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的概率；
- 代碼質量會影響程序運行效率；
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 如何提升開發迭代速度？
- 如何讓開發者專注於業務邏輯與實現？
- 如何讓開發者快速響應並完成產品需求？
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 如何快速感知並定位問題？
-
開發者如何快速感知服務中的問題，嚴重問題如何實時感知？
-
開發者如何能從監控、日志、報警中獲得詳細的問題信息，以快速定位問題？
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/
短視頻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的概率；
- 代碼質量會影響程序運行效率；
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 如何提升開發迭代速度？
- 如何讓開發者專注於業務邏輯與實現？
- 如何讓開發者快速響應並完成產品需求？
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 如何快速感知並定位問題？
-
開發者如何快速感知服務中的問題，嚴重問題如何實時感知？
-
開發者如何能從監控、日志、報警中獲得詳細的問題信息，以快速定位問題？
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/