趙真靈 （花名：有濟）

Koupleless 負責人
螞蟻集團技術專家

Koupleless 社區的開發和維護者，曾負責基於 K8s 的應用研發運維平台、Node/Pod 多級彈性伸縮與產品建設，當前主要負責螞蟻及開源社區模塊化應用架構演進和 Serverless 相關工作。

本文 4389 字，預計閲讀​ 8 分鐘

時光匆匆又是一年。2024 落幕之際，我們對過去這一年做了回顧與總結，不僅是對一年以來每一位在 Koupleless 社區一起努力的同學們的答覆和感謝，也是趁此機會對 25 年做個規劃和展望。

Koupleless 是一個基於模塊化技術的企業級解決方案，涉及的組件和功能較多，包括研發框架、運維調度、研發工具、生態治理工具鏈等。從 2023 年經過半年的建設到 24 年初基本框架成型發佈 1.0.0 版本¹，我們仍然面對一些難題：

1、​研發階段的成本仍然較高​，尤其是新模塊創建、模塊瘦身等成本；

2、​廣泛的生態組件不支持模塊化​，體現在多個 Spring Boot 安裝在一個 JVM 裏、動態卸載等，需要解決其中的兼容性適配問題；

3、​Koupleless 的發佈運維平台建設成本很高​，且不同企業的基礎設施不同，很難為不同企業提供不同的集成方案。如何讓更多企業能低成本集成 Koupleless 模塊化發佈運維能力，是 Koupleless 項目能否順利推廣的關鍵。

24 年除了繼續在每個組件每個環節上持續迭代和演進快、省、靈活部署、平滑演進四大特性，我們還重點針對上述難題進行了攻堅。這一年，Koupleless 各個項目​（包括 SOFAArk、Runtime、Adapter、Plugin、Virtual-Kubelet、Module-Controller、ArkCtl、Scanner、Koupleless-idea 等組件）​共合併了 608 個 PR，完成 10 次主版本發佈 ​（包含 79 個子項目版本），發佈 228 個功能項，後面會再介紹下其中重要的進展，詳細可以查看 github release 列表​²​。

在開發者生態上，新增 20 位 Contributor，其中 1 位優秀 Contributor，1 位晉升為 Committer。發佈 13 篇原理介紹文章、4 篇企業案例，進行 6 次大會分享，社區羣人員數量達到700+​。

主項目：Koupleless

子項目：SOFAArk

以下是 Koupleless 社區 24 年參與貢獻的同學：
@ToviHe,@compasty,@g-stream,@lbj1104026847,@linwaiwai,@liu-657667,@qq290584697,@yuhaiqun19892019,@suntaiming,@pmupkin,@2041951416,@loong-coder,@hadoop835,@xymak,@jyyfei,@laglangyue,@yuandongjian,@98DE9E1F,@leewaiho,@KennanYang,@Jackisome,@liufeng-xiwo,@Simon-Dongnan,@oxsean,@langke93,@XiWangWy,@Juzi-jiang,@ligure,@chenjian6824

項目功能演進

研發框架

首先在模塊的研發上，為了降低模塊的創建和接入成本，Koupleless 提供了：

1、基於研發工具 arkctl³​的普通應用一鍵轉換成模塊；

2、開放了模塊拆分插件 Koupleless-idea​⁴​，目前已有 122 次下載，幫助用户以可視化的方式將存量大應用拆分出多個小模塊；

3、提供模塊腳手架，快速創建出新模塊。

在模塊研發上線整體流程上，從上圖可以看到模塊創建的三種方式都已經提供有工具來降低成本。不過當前對改造成基座並沒有提供工具，考慮到這部分主要工作是引入 Koupleless sdk 的 starter，參考官網實現即可✅。

模塊接入和研發過程中，還有個關鍵且必需的步驟“模塊瘦身”​⁵​，這一過程需要同步分析基座和模塊的代碼。由於這兩部分信息比較分散，所以常常出現該瘦身的沒有瘦身、不該瘦身的瘦身結果導致模塊啓動失敗等問題。今年我們對模塊瘦身做了三大重大升級：

1、提升基座與模塊信息的感知度；

2、低成本的模塊瘦身；

3、確保瘦身的正確性。

將模塊瘦身的操作從原來的黑盒狀態轉變成白盒狀態，可以大幅降低這部分的改造和研發成本。另外在模塊打包構建上提供了 gradle 版本的打包插件​⁶​，可以讓 gradle 工程也能使用 Koupleless 的所有能力。模塊隔離上也新增了環境變量隔離能力。

模塊化兼容性治理

Koupleless 模塊化是在單個 JVM 內同時運行多個 Spring Boot，並提供動態熱更新的能力，勢必存在一些生態組件不完全適配問題。主要體現在三個方面：

1、共享變量的互相覆蓋；

2、多 ClassLoader 切換導致的不一致；

3、部分資源未清理乾淨。

我們發佈了系列文章來詳細闡述上述問題，歡迎查閲：

進階系列一：Koupleless 模塊化的優勢與挑戰，我們是如何應對挑戰的⁷

進階系列二：Koupleless 內核系列 | 單進程多應用如何解決兼容問題⁸

進階系列三：Koupleless 內核系列 | 一台機器內 Koupleless 模塊數量的極限在哪裏？⁹

進階系列四：Koupleless 可演進架構的設計與實踐｜當我們談降本時，我們談些什麼¹⁰

進階系列五：Koupleless 內科系列 ｜怎麼在一個基座上安裝更多的 Koupleless 模塊？¹¹

同時我們也在社區將完整的生態治理工具鏈開放出來，包括事前的代碼掃描 → 事中的低成本治理 adapter + plugin → 事後的防禦集成測試框架 multiAppTest，每個組件的使用都可以查閲官網文檔。

當前已完成所發現的 50 多個常用組件的兼容性治理或已提供最佳實踐。

運維調度

在發佈與運維調度上，Koupleless 是在原有的基座進程裏動態安裝卸載多個模塊。由於這套模式與企業的現有基礎設施有較大不同，需要在原來的基礎設施上新建一層模塊化的控制面，有較高的建設成本和與周邊設施打通的成本，如下圖：

需要建設設配的周邊平台不限於：

1、應用元數據管理平台：新增模塊應用元數據；
2、研發與迭代管理平台：增加模塊創建、模塊迭代、模塊構建、發起模塊發佈；
3、聯調平台：增加模塊與基座、模塊與普通應用聯調；
4、可觀測平台：監控與告警、trace 追蹤、日誌採集與查詢；
5、灰度平台；
6、模塊流量。

今年我們根據內部實戰經驗，考慮生態適配的成本問題，將模塊安裝調度到基座上的行為抽象等同為 Pod 安裝調度到 Node 上的行為，巧妙利用 Virtual-Kubelet 將模塊實例映射為 vPod，將基座 Pod 映射為 vNode。

基於 Virtual-Kubelet 的 ModuleController 方案，將原來的三層架構打平到與傳統一致的兩層架構，可以大量複用為普通應用建設的基礎設施能力，包括直接使用基座 PaaS 平台來發布模塊，達到可低成本擴展出模塊化發佈、運維、調度能力的目的，這套方案也在內部實際業務落地過程得到了驗證。

更多能力不再一一羅列，詳細可查看 github release 列表​¹²​。

企業接入與案例

當前已累計有 45 家企業（不完全統計）已經完成接入上線，其中於 24 年新增 26 家企業，包括快手、塗鴉、民生銀行等，沉澱 4 個案例：

高效降本｜深度案例解讀 Koupleless 在南京愛福路的落地實踐¹³

Koupleless 助力螞蟻搜推平台 Serverless 化演進¹⁴

塗鴉智能落地 Koupleless 合併部署，實現雲服務降本增效¹⁵

Koupleless 助力「人力家」實現分佈式研發集中式部署，又快又省！¹⁶

這些企業在多個業務場景裏落地了 Koupleless，包括“中台代碼片段研發提效”、“企業內合併部署省資源”、“私有云、邊緣雲交付”、“長尾應用治理”等，同時也完成了一些新業務的探索落地。

新業務場景探索落地

實時計算

在螞蟻內部的 Flink 計算引擎，原來採用業內常用的啓動進程的方式編譯用户提交上來的作業代碼，每次佔用資源且耗時較高。使用 Koupleless 中提供的動態模塊與動態 plugin 能力，將每一次編譯請求從進程模型調整線程模型，每一次請求實際變成安裝一次模塊，然後觸發線程內的編譯，編譯完成後立即卸載模塊。將編譯速度提升 5 倍以上，解決了原來的三大痛點：資源消耗大、相應速度慢、處理請求有限，當前一篇專利正在申請中。

進程調度

該業務場景需要在一個 Pod 內動態開啓或關閉多個子進程，並同步狀態到控制平台。這個過程相當於在一個 Pod 的基座進程裏安裝了多個進程模塊，與 Koupleless 模塊化實際上非常類似，區別只是進程內模塊化還是進程間模塊化的區別，在運維調度上本質是相通的，需要考慮的問題如下：

1、資源的分配與調度；

2、玩法進程的啓動；

3、玩法進程關閉；

4、玩法進程的狀態查詢與同步等。

我們基於 Virtual-Kubelet 的 ModuleController 方法，同樣把基座進程映射成 vNode，把動態啓停的子進程映射成 vPod，然後由 K8s 控制組件完成實例管理、調度、運維等，通過實現類似 Kubelet 的 agent 管道實現子進程的啓動和關閉，最終幫助業務快速完成了運維和調度等三層能力的建設。

除了這些已有的和 24 年新增的業務場景，相信還有更多的業務場景可以使用 Koupleless，歡迎一起在社區裏碰撞出更多可能，幫助更多企業實現降本增效和綠色計算！

25 年規劃

24 年已經過去，不管是風和雨還是喜和樂，它都是一段不可缺少的經歷。在社區的陪伴下，今年的 Koupleless 極大地成長了！

Koupleless 感謝每一位一起共建的 Contributor，你們的每一個 issue、每一次 comment、每一條 PR、每一個回覆都已經成為 Koupleless 不可或缺的一部分。

也感謝每一個願意試用的企業和開發者，你們已經踏出了關鍵的第一步“動手試用”，願意去嘗試和發現 Koupleless 的價值；過程可能遭遇挫折，但最終都完成了評估驗證。不管是否實際落地業務，你們都為 Koupleless 的發展提供了業務基礎。

更感謝最終成功落地業務的企業和開發者們，你們不光解決了 Koupleless 框架的適配問題，還克服了企業落地的困難​（有不少企業因為非技術的原因停在了這一步）​，用你們對 Koupleless 的耐心和信心，持續努力最終順利在企業內部落地，在這個過程中持續陪伴和滋養了 Koupleless 的成長。

因為有你們的陪伴，Koupleless 在這一年裏成長了：除了進一步打磨底盤完善體驗外，對於年初的三大難題也探索出了方向，實現了完整的架構和工具鏈或組件。不過，這些難題還待繼續磨礪💪，25 年有更多的共同目標，主要集中在以下幾個方面。

進一步完善模塊化兼容性治理工具鏈

1、Adapter 雖然可以通過類覆蓋的方式完成組件的治理，但因為要拷貝原來完整的類過來，可能覆蓋掉某些版本的實現。需要調整為 ​patch 的方式完成覆蓋​，詳見 GitHub issue#183​¹⁷​。

2、Plugin 當前可以幫助基座自動匹配到對應的 adapter 並引入，但是當前的匹配方式是基於 Koupleless-adapter-config裏的映射關係表實現的，如果企業內部自定義的 adapter 是不在這個映射表裏的，需要​支持企業內部的關係表映射​。

3、多應用集成測試框架還需重新設計方案，以便可以利用已有的測試的用例快速建設多應用的集成測試用例。

4、另外，當前這些工具是手動模式，無法支持更廣泛的組件的掃描與治理，需要考慮自動化的能力去做好生態更廣泛的治理工作。

提升 ModuleController 性能與體驗

當前 ModuleController 已經提供 http 和 mqtt 兩種類型的運維管道能力，但目前實現功能還需要在更復雜的運維環境裏測試驗證。未來：

1、ModuleController 提供​更完整的運維能力和集成測試驗證能力​；

2、驗證並提高基座與模塊的​同時並行運維的能力​；

3、ModuleController 自身成功率達到 99%。

DevOps 平台

當前 ModuleController 只是提供了模塊化發佈、運維與調度能力，不具備 DevOps 的平台能力，也無法提供基座和模塊的管理能力。因此需要：

1、發佈 ​0.5 版本 DevOps 平台​，提供基礎的基座與模塊管理能力、模塊迭代與流水線能力等；

2、提供​快速試用 PlayGroud​。

打造 Serverless 能力

1、建設​彈性能力與調度​，如模塊 HPA；

2、提供​通用基座示例​，打造 Serverless 體系。

這些能力的建設還需要更多社區同學一起努力，歡迎更多有志之士一起加入 Koupleless 社區，一起打造模塊化研發體系，幫助更多企業實現降本增效和綠色計算！

參考鏈接