CloudWeGo 在飛書管理后臺平臺化設計實踐

飛書是真正的一站式企業溝通與協作平臺，整合視頻會議、即時消息、日歷、云文檔、郵箱、工作臺等功能于一體，立志打造高效的辦公方式，加速企業成長。飛書管理后臺（以下簡稱?Admin）是飛書套件專為企業管理員提供的信息管理平臺，企業管理員可通過后臺管理企業設置、組織架構、工作臺和會議室等功能。下圖是飛書管理后臺的界面。

平臺改造背景

飛書采用的是 all-in-one 的套件模式，Admin 作為整個套件統一的管理后臺，承接了包括組織管理、云文檔、視頻會議、郵箱、開放平臺等 10 多個業務線的管控需求。一直以來的開發模式是各業務方直接在 Admin 的代碼倉庫提交代碼或者由 Admin 團隊負責 Web 層邏輯的開發。

下圖是目前飛書管理后臺中包括的一些功能。之前的開發模式是業務方直接在 Admin 的代碼倉庫中提交代碼，或者由業務方給 Admin 團隊提供一些需求，由飛書來負責 Web 層邏輯的開發。

從飛書初創開始，Admin 就是以單體應用的模式開發的，隨著后續飛書整體的演進，團隊越來越多，不同業務線的團隊也會有一些管控需求要接入 Admin 平臺，因此他們就直接在代碼倉庫中提交代碼。

Admin 架構

下圖是 Admin 舊架構圖。上面是 Admin 前端，它其實就是 Node 層的單體，中間是 Admin 后端，它基于內部單體 HTTP 的 Web 服務，會通過 RPC 調用到其他業務線的微服務。

面臨的問題

而在這個架構下會面臨一些問題。第一個問題是業務迭代慢，因為所有業務線都只能在 Admin 的代碼倉庫里進行開發和發版，因此這些業務線完全依賴 Admin 的研發資源和迭代流程，Admin 的研發資源被過多的耗在各業務的迭代中，無法快速支持自身的業務規劃，如組織架構、安全、KA 等因為飛書是 To B 的產品，因此發版節奏不會很快。如果各個業務線有一些比較緊急的需求，也只能跟 Admin 的節奏，這就會造成發版節奏不一致，研發資源不匹配，導致 Admin 會成為業務迭代的瓶頸。

第二個問題是研發效率低，因為各個業務線需要在 Admin 的代碼倉庫里進行修改，因此需要了解??Admin?倉庫的設計模式，而我們在為各個業務線提供服務時，也需要了解各業務的上下文，雙方都需要花費大量時間溝通。聯調、Oncall 的鏈路也很長，雙方的責任也劃不清楚，導致整體的研發效率偏低。

第三個問題是工程質量差，多個團隊共同維護一個代碼倉庫，代碼質量參差不齊，設計規范也各不相同，底層的代碼的修改還會相互影響，造成線上問題。

面臨的挑戰

首先面臨的是多環境互通與隔離的挑戰，我們需要解決不同環境的網絡隔離、版本異構問題。

其次是接入業務復雜性的挑戰，Admin需要集成十幾個業務線，接入訴求不統一。接口協議包含 HTTP 協議和 Thrift 協議，還有各種自定義插件需求和權限校驗需求。

最后還有安全保障的挑戰，Admin 作為飛書套件的管理配置中心，關系到整個企業的數據安全。安全一直是 Admin 最重要的需求，為了保障 Admin 的接口數據安全，需要提供鑒權中間件、管理員權限驗證、參數校驗、風控、頻控等功能，提升業務方的安全能力。

平臺化構想

第二部分介紹飛書平臺化構想，即如何進行飛書管理后臺平臺化構想和架構升級。

首先要明確的是目標，主要目標是通過提供一套統一的標準和通用服務，讓有管控訴求的套件業務方能快速實現能力集成，并且能給客戶帶來一致的體驗。因為我們各個業務線的管控需求都是集成在 Admin，我們不希望每個業務線提供的 Web 頁面展示、功能和 UI 等差別較大，希望他們是相對統一的，最終實現 Admin 作為企業統一數字化管理平臺的愿景。

關于在技術上需要達到的效果，我們希望業務方不要繼續在 Admin 代碼倉庫中進行代碼開發，而是直接提供我們的后端接口和前端頁面動態接入，Admin 無需代碼改造和服務發布即可無縫上線，Admin 從單體應用進化為業務網關，是包含 UI 交互在內的獨立產品模塊的集成。

我們并不是要做一個搭建系統。目前很多平臺型產品都提供 Low Code / No Code 的工具方便開發者快速搭建所需要的功能。但是目前通過我們對客戶訴求的調研，沒有相關的需求（但是不代表未來也沒有，這塊我們會持續保持關注）。我們需要做的是制定相關的標準，比如 UI、交互、API 等，業務按照標準去實現。

我們也不是要做一個 API Gateway 或者 Service Mesh。API Gateway 的核心是Exposes your services as managed APIs，將內部的服務以更加可控可管理的方式暴露出去，可以認為是后端服務的一個代理。Service Mesh 可以看成是 API Gateway 的去中心化實現方式，用來解決單點、隔離、耦合等問題。我們需要解決的不僅僅是服務路由、協議轉換、安全管控等問題，而是包含 UI 交互在內的獨立產品模塊的集成。

舊的框架

舊架構的前端架構是前后端分離的 Node 單體項目。后端架構（Golang 實現）采用 Hertz 框架對前端暴露 HTTP 接口，Handler 層通過 Kitex 調用依賴的各個業務線的微服務。

?

框架介紹

CloudWeGo 現有的兩款框架分別是 Hertz 和 Kitex。Hertz [h??ts] 是一個 Golang 微服務 HTTP 框架，在設計之初參考了其他開源框架 Fasthttp、Gin、Echo 的優勢，并結合字節跳動內部的需求，使其具有高易用性、高性能、高擴展性等特點，目前在字節跳動內部已廣泛使用。如今越來越多的微服務選擇使用 Golang，如果對微服務性能有要求，又希望框架能夠充分滿足內部的可定制化需求，Hertz 會是一個不錯的選擇。

Kitex [ka?t’eks] 是字節跳動內部的 Golang 微服務 RPC 框架，具有高性能、強可擴展的特點，在字節內部已廣泛使用。如果對微服務性能有要求，又希望定制擴展融入自己的治理體系，可以考慮選擇 Kitex。

新的框架

新架構主要包括：

1.?Gaia 控制面：我們增加了 Gaia 平臺（基于 Hertz 框架的 Web 服務）來作為我們整個 Admin 的控制系統，負責整體的發布和管控需求，包括接口的生命周期管理、微應用生命周期管理、監控告警、業務線接入、多環境發布等。

2. 前端架構：前端采用微前端架構，各個業務方通過構建微應用接入 Admin 基座，使用統一封裝好的組件庫實現前端頁面。

3. 后端架構：后端使用字節通用 BAM 規范，通過泛化調用的方式打通 Admin 和各接入業務方服務，并抽象公共組件以插件的方式進行功能擴展。

Admin 架構

下圖就是新的?Admin 架構圖。左上方是微前端，它包含前端里面各個業務線的微應用。微前端通過 HTTP 接口和 Admin 網關進行交互，Admin 網關把業務邏輯都剝離到下一層，而自身只負責公共組件、登錄鑒權、協議代理和通用配置等通用需求，同時它會通過泛化調用來調用下游的業務服務。業務服務包括組織管理、云文檔、視頻會議和郵箱等微服務。右側是 Gaia 控制面，包括一些管控功能，如接口生命周期管理、監控大盤、微應用管理、工單系統等等。另外如果我們有一些獨立的自定義功能，會通過插件的方式集成。

Gaia 平臺功能

Gaia 平臺主要包括以下功能：

1.?業務線管理：業務線是實現以業務為維度進行接入 Admin 而提出的概念。通過業務線來聚合業務為維度的所有資源，相關資源包括微應用、菜單、接口、監控等。圖中就是業務線管理的菜單頁面。

2.?接口生命周期管理：包括接口創建、更新、編排、發布、上線、下線、刪除等。同時維護接口 IDL 文件。

3.?微應用生命周期管理：包括微應用的申請、接入、微應用版本創建、發布、下線等。

4.?控制大盤：包括業務整體維度和單接口維度的 SLA 大盤，以及錯誤告警管理。

5.?插件管理：包括默認插件和自定義插件的配置管理。

平臺化實現

微前端技術架構

第三部分具體介紹飛書平臺化實現，包括微前端技術架構、泛化調用實踐和功能擴展。

下圖是微前端的技術架構。這里涉及到三個概念，第一個是基座，即指微前端入口模塊，負責組裝各個模塊；第二個是微應用，指獨立的業務模塊；第三個是微應用市場，負責管理微應用的創建、管理、版本發布等。

通過微應用市場下發的配置進行微應用組合，將基礎能力下放到各個業務方。例如，現有一個新的業務線需要接入，那么它需要開發自己的微應用，打包測試并發布到我們的微應用市場，我們的基座就會從微應用市場接收到這個微應用，最后進行發布之后，就可以從 Web 看到對應模塊的頁面。

泛化調用方案調研

如何通過泛化調用實現整體依賴的剝離？首先講一下這個問題的背景，Admin 的前端和后端是通過 JSON 實現序列化傳遞的，如果把 Admin 變成一個平臺化的網關，不再維護業務邏輯，只處理通用邏輯，泛化調用是我們最好的選擇。因為通過泛化調用，Admin 的網關就不需要寫各種業務代碼，直接通過 RPC 接口就可以把前端傳過來的 JSON 序列化數據、請求參數再傳遞到微服務，然后通過微服務的返回值把 JSON 序列化數據返回前端，跟前端進行交互。

我們通過調研現有框架，如網關與微服務之間使用 gRPC、Thrift 等協議進行通信，都是通過代碼生成實現的協議解析和協議傳輸，不能動態更新，都需要生成代碼，再重新發布。而我們內部舊的 Kite 框架（Thrift 協議）不支持泛化調用，而新框架 Kitex 是字節跳動內部的 Golang 微服務 RPC 框架，具有高性能、強可擴展的特點。

在我們使用 Kitex 的泛化調用功能之前曾調研了一些泛化調用的方案，也基于 Kitex 實現了泛化調用的類似功能。但是我們認為飛書內部實現泛化調用不如推動 Kitex 的研發人員，讓他們把泛化調用變為一個通用的功能，這樣不僅僅是我們團隊，公司內部其余團隊以及 Kitex 開源后其他外部團隊都可以使用這個功能。目前 Kitex 已經支持基于 Thrift 協議的泛化調用。

非泛化調用

那么非泛化調用的實現方式和泛化調用的實現方式有什么不同呢？這張圖就是非泛化調用的實現方式，無論 gRPC、Thrift 還是 Kitex 都是基于 IDL 生成協議代碼，服務端和客戶端都需要依賴 IDL 生成靜態代碼，接口的迭代意味著服務端和客戶端都需要升級代碼重新發布。在 Admin 場景下意味著其他業務方的業務迭代，需要我們引入代碼依賴并發布服務，這并不符合我們平臺化的需求。

Kitex 泛化調用

在 Kitex 泛化調用中，服務端無需做任何改造?？蛻舳酥挥幸环萃ㄓ玫膮f議處理代碼，基于已有的 IDL 信息來動態生成協議字節流，IDL 信息可以動態更新，以維護最新的接口協議，無需生成代碼。在 Admin場景下，網關作為客戶端，動態維護業務方接口的 IDL，通過泛化調用來實現 HTTP 接口到 RPC 接口的轉換，不再依賴業務服務客戶端代碼，實現了網關和業務在代碼層面的解耦。

相關地址：kitex/pkg/generic/thrift at develop · cloudwego/kitex (github.com)

HTTP 協議映射

Admin 網關是基于 Hertz 對外暴露 HTTP 協議的接口，Hertz 路由支持運行時新增，通過自定義 Middleware 和 HandlerFunc 可以實現接口運行時的增刪改，這樣可以實現解析修改后的 IDL 來進行接口調用。

這段代碼就是初始化客戶端的 Client，其實就是泛化調用的 Client，可以看到它會讀業務方的 IDL，假如業務方的 IDL 有接口更新，我們可以通過這個進行業務更新，動態實現接口的上下線。然后再構造 HTTP 類型的泛化調用 Client，每個業務方都會構造一個 Client 實例，比如有十幾個業務線，就會生成十幾個業務線微服務的實例。

泛化調用的路由其實是 HandlerFunc 的實現，通過這個方式可以動態注冊路由，注冊之后將 Hertz Request 轉化成泛化調用 Request，再通過前一步生成的泛化調用 Client 實現泛化調用，最后得到?HTTPResponse，再將它寫回 Hertz Response中，這就是簡單的泛化調用路由的實現。通過這個可以做很多業務拓展，比如錯誤碼處理等等。

功能擴展

接下來具體介紹一下功能擴展。功能擴展的第一類就是 Kitex 提供的自定義注解，Kitex 內置了 API 注解來實現路由解析、參數傳遞等功能。

這里面有三個接口，第一個是?HTTPMapping，實現了參數傳遞、返回值等等自定義注解；第二個是Route，實現了 Kitex 路由解析的功能；第三個是 ?ValueMapping，是指將參數進行映射，比如目前 JSON 不支持 Int64，但 Go 可以支持 Int64，在使用 JSON 序列化的時候就要把參數類型定義為 String，因此從 JSON 到 Go 有一個轉換的過程，這就可以通過映射來實現。

我們通過自定義注解方式實現了框架未提供的功能，例如文件上傳和下載、自定義參數注入、參數校驗、自定義鑒權等。

功能擴展的第二類就是接口編排，已經實現的單接口泛化調用，不能完全滿足我們一些復雜場景的使用需求，例如：簡單組裝兩個接口的結果，比如同時調用接口 A 和 B，再將兩個接口進行組裝；接口有順序依賴，一個接口結果是其他接口的參數，比如先調用 A，A 的返回值作為參數去調用 B，再將B 的返回值作為整體接口的返回值。Kitex 和 Hertz 還不能支持接口編排的功能，所以我們通過自定義 DSL 引擎來對簡單接口進行編排，以便實現一些復雜場景的接口調用需求。

成果展示

最后介紹一下飛書管理后臺平臺化的演進成果，主要有以下三點：

1.?業務迭代加速。Admin 不再關注其他業務線的需求，更加專注于自身的迭代需求。各個業務方發布完全隔離，使得他們不再依賴 Admin，加快了 Admin 整體的業務功能迭代速度。

2.?研發效率提升。豐富的前后端組件和簡單的接入方式，業務方不需要再花費時間熟悉我們的代碼倉庫，使得業務方接入更加便捷，研發效率大大提升。

3.?工程質量提高。

• 其他團隊不再向 Admin 倉庫提交代碼，倉庫代碼風格趨向統一；

• 去除了大量的業務邏輯，聚焦網關通用邏輯，提高了單測覆蓋率；

• Bug 率顯著下降，服務 SLA 明顯提升。

未來規劃

我們目前制定了一些未來的發展規劃，主要有以下四點：

1. 開放更多的組件，讓接入的業務方聚焦在業務邏輯本身，例如組織管理里面的選人組件，之前需要各個業務方自己內部實現，之后我們會提供一套公共組件，業務方可以直接使用，包括消息中心、任務管理、安全風控、短信郵件等；

2. 完善服務治理和運維能力，包括灰度、降級、限流、精細化大盤等；

3. 建設通用的靜態頁面托管解決方案，為開發者提供便捷、穩定、高擴展性的靜態頁面托管服務；

4. 對接集成測試平臺，閉環路由管理生命周期，保障接口穩定性和安全性。

歡迎企業用戶掃描二維碼，填寫企業支持問卷，并加入飛書交流群，獲取 CloudWeGo 團隊企業技術支持。

打開飛書，掃描左側二維碼填寫企業支持問卷，掃描右側二維碼可加入飛書交流群。

?更多資訊

• 官網地址：CloudWeGo
• 項目地址：https://github.com/cloudwego
• Kitex:?https://github.com/cloudwego/kitex
• Netpoll:?https://github.com/cloudwego/netpoll
• Hertz:?https://github.com/cloudwego/hertz

• Thirftgo:?https://github.com/cloudwego/thriftgo

• Netpoll-http2:?https://github.com/cloudwego/netpoll-http2