WSO2把11個微服務塞進Docker，開發者

部署11個微服務需要多少行YAML？Google Cloud的官方demo答案是：通常超過2000行。但有人用OpenChoreo跑了一遍，把配置壓縮到了原來的五分之一。

這不是魔法，是WSO2開源的開發者平臺剛被CNCF接納后的第一次大規模實測。作者用本地Docker單節點，復刻了Google那個著名的微服務電商demo——從購物車到支付鏈路，11個服務全量運行。

結果：沒有自建平臺工具，沒有手寫K8s編排，開發體驗卻接近生產級PaaS。

11個服務的"地獄級"配置，被抽象成3個API對象

Google的microservices-demo是個經典靶場。前端用Go，購物車是C#，支付和貨幣轉換跑Node.js，推薦引擎和郵件服務用Python，廣告服務是Java——技術棧雜到能開編程語言博覽會。

傳統玩法里，每個服務要配Deployment、Service、Ingress、ConfigMap，11個服務就是44個基礎資源。再加上服務發現、鏈路追蹤、資源限制，YAML文件能堆成小山。

OpenChoreo的做法是向上抽象。它定義了三種核心API：Component（組件）、Endpoint（端點）、DeploymentTrack（部署軌道）。開發者聲明"我要一個Go服務，暴露8080端口，從Git拉取"，平臺自動生成底層K8s資源。

換句話說，你寫的是應用意圖，不是基礎設施指令。

實測中，作者把11個服務的配置全部遷移后，核心定義文件從2000+行降到了400行以內。剩下的都是平臺自動生成的——包括服務網格的Sidecar注入、可觀測性的Agent掛載、網絡策略的自動推導。

Backstage門戶+GitOps：把"平臺工程"塞進一個Docker鏡像

OpenChoreo的架構分三層。控制平面（Control Plane）負責解析API意圖，數據平面（Data Plane）負責運行時執行，中間用GitOps引擎做狀態同步。

關鍵設計是"設計時語義"和"運行時執行"的綁定。你在門戶里拖拽定義的依賴關系，會被編譯成OPA策略，實時 enforce 到Envoy Sidecar上。服務A調用服務B，如果設計圖里沒畫這條線，流量直接拒絕。

這解決了微服務治理的老大難問題：文檔和代碼兩張皮。很多團隊的架構圖畫在Confluence上，實際流量怎么走只有上帝和CoreDNS知道。

開發者門戶基于Backstage搭建，但做了深度定制。服務拓撲圖是實時渲染的，能看到哪個Pod在丟包、哪條調用鏈延遲超標。作者特別提到，11個服務的依賴關系在界面上"一眼能看完"，而以前用kubectl排查，至少要切7個Namespace。

CI/CD也沒落下。內置的工作流引擎支持從代碼提交到金絲雀發布的完整鏈路。作者選了帶構建和可觀測性的安裝模式，8GB內存的本地環境能完整跑完——包括Prometheus抓取、Jaeger鏈路追蹤、Grafana儀表盤。

CNCF生態的"組裝藝術"：沒有造輪子，只有拼樂高

OpenChoreo的技術選型很克制。它沒自研服務網格，直接集成Istio；沒寫自己的GitOps引擎，用ArgoCD；可觀測性棧是Prometheus+Grafana+Jaeger的標準組合；門戶直接fork Backstage。

這種"CNCF項目組裝"的策略，讓它的代碼庫相對精簡。核心差異化在于"意圖解析層"——如何把開發者的高階描述，翻譯成這些底層項目的配置。

WSO2在這塊有歷史積累。他們之前做的Choreo SaaS平臺服務過大量企業客戶，OpenChoreo是把其中通用部分開源，保留商業版的高級功能（如多集群聯邦、成本優化算法）。

這次CNCF接納后，項目治理轉向社區主導。但技術路線已經明確：不做重復發明，只做"膠水層"的極致優化。

作者的實測驗證了這一點。11個服務的部署，從Docker啟動到全部Ready，耗時約6分鐘。其中4分鐘花在拉鏡像，實際平臺初始化+服務編排只占2分鐘。

對比純K8s原生部署，這個時間不算驚艷。但配置維護量的差距，會在第3次迭代、第5次擴縮容、第10次新人 onboarding 時徹底拉開。

本地單節點跑11個微服務，資源消耗是4GB內存起步。作者建議生產環境用8GB+4核，能流暢支撐構建流水線。這個數字對開發機很友好——M1 MacBook Air都能輕松跑。

但真正的價值不在本地。OpenChoreo的設計目標是把"開發環境"和"生產環境"的體驗拉平。同一套API定義，從筆記本推到生產集群，只需要改一個目標端點。

作者最后留了個細節：他在門戶里發現，currencyservice（貨幣轉換服務）的QPS監控曲線有個奇怪的尖峰。查代碼才發現，這是demo故意模擬的ECB匯率接口抖動——而鏈路追蹤直接定位到了具體的Python函數行號。

這種"從界面到代碼"的穿透能力， traditionally 需要搭一整套可觀測性體系。現在開箱即用。

當你的團隊還在爭論"要不要上平臺工程"時，有人已經用Docker單節點跑完了11個服務的生產級部署。問題是：這個"膠水層"的抽象，會不會成為下一代云原生的事實標準？