探尋雲原生時代應用研發新模式

引言： 伴隨着基礎設施技術升級，應用研發環境也從最初的傳統 IT 架構、虛擬化 & 容器化架構演變到現在的雲原生多雲架構。“應用研發新模式” 本身就是一個比較大的話題，我們也不敢說一個人或者一個團隊就能把這個話題聊透徹。但隨着應用研發基礎架構環境的演進，應用研發模式一定是在不斷地調整和創新。

今天我們大膽把話題拋出來，聊聊自己的一些想法，和大家一起探討、共創雲原生時代應用研發模式後續的演進路線。

DevOps 平臺現狀和痛點

（應用研發架構演進路線）

本文暫將應用研發架構的演進路線歸納爲四個階段（如上圖），傳統 IT 架構和虛擬架構下的應用研發，相信大家都比較熟悉，DevOps 的概念在這兩個階段幾乎沒有激起什麼水花，所以這兩個階段我們就不展開闡述了。

伴隨容器技術的出現（特別是 Docker 和 Kubernetes，後續簡稱 K8s），讓 DevOps 概念火了一把，也在實踐中開始快速落地和普及。容器能夠封裝微服務整個運行時環境的特性，天然就適用於微服務構建、發佈和運行，讓原本緩慢前進的 DevOps 得到飛速發展，開源社區也湧現了很多優秀的開源產品（比如 Jenkins、GitLab 等），大家通過這些開源產品能夠快速搭建自己應用的持續集成環境，因此市場上也如雨後春筍般冒出許多 DevOps 相關的產品。

現階段中的 DevOps 產品通過 Docker 和 K8s 確實幫助用戶解決了資源管理、微服務環境構建和持續集成的複雜、效率低等問題，但是伴隨公有云等 Infra 基礎設施持續高速發展，人們對於應用研發的效率追求也會有更高的要求，對於 DevOps 產品也不會滿足停留在當前階段（微服務應用的持續構建部署），那麼如何在 DevOps 現階段的版本基礎上進一步提高研發效率和質量呢？我們還是一起通過梳理當前研發過程中面臨的痛點出發吧！

痛點 1：多雲資源如何統一管理，解綁雲廠商？

在公有云、私有云等多元化的雲環境下，大家手頭往往都有兩套或者多套雲資源，如何讓這些割裂的雲資源統一進行管理？如何基於一個平臺讓應用快速進行跨雲遷移、發佈？比如：開發在私有云，生產在公有云等這些問題伴隨資源環境多元化問題會越來越突出。

痛點 2：複雜微服務組合如何快速進行環境構建、持續集成？

當前 DevOps 對於單個微服務的環境構建和持續集成問題已經基本解決。但對於企業級軟件研發交付團隊來說，錯綜複雜的微服務組合而成的項目如何進行統一的環境構建、部署和交付，目前仍解決得不太徹底，只能讓各應用的研發成員都參與到構建、部署的整個階段。以上覆雜的過程容易引起問題不說，效率成本上也是個大問題。

痛點 3：研發效能如何進一步提升？

在當前主流的 DevOps 產品中，代碼、構建、部署全流程自動化觸發執行的特性基本都是得到了比較好的解決，但是隨着研發管理的深度、精細度要求越來越高，需要研發同學維護的數據也隨之不斷增多，管理維護項目數據的項目管理工作量也在不斷增大，效率和成本這組矛盾如何得到妥善處理？

新一代 DevOps 不僅應有效解決上述痛點，還應具有測試安全的左移、研發效能度量等更多開放性能力，這個全新的時代需要有更全面、更創新的特性。

新一代 DevOps 的特性

 多雲管理

多雲管理並不是簡單指通過 K8s 集羣來實現資源的調度管理，如果僅僅是統一資源調度那本身是 K8s 集羣的特性。

通過應用部署環境配置去關聯集羣，確實可以實現環境之間的隔離、環境之間快速遷移的能力，就如上面提到的：開發測試在本地私有云環境，生產可以通過同一套代碼能夠快速發佈到公有云；還有就是業務在一個集羣，數據處理可以在另外一個集羣，實現業務和數據分離，兩者互不影響，這些都可以通過集羣管理來實現。

既然說了這麼多都是和集羣相關的，那麼和多雲管理有什麼關係呢？

首先，我們對 K8s 集羣的節點管理，希望可以一個平臺上統一便捷購買 / 釋放主流公有云廠商的資源節點。

其次，現在公有云上都有容器相關的服務提供，平臺只需要調度管理這些容器服務即可，所有容器服務的對接管理（包含但不僅限於容器服務的購買、釋放、擴縮容等）都需要在平臺完成。

再者，公有云上其他的雲服務都可以通過平臺進行購買直接使用，無需用戶不斷切換登陸到各公有云的控制檯，最後進行雲資源的統計分析、資源成本的運營分析，幫助企業在資源方面進行降本增效。這些都是多雲管理的範疇之內。

Erda 目前在 K8s 集羣管理、公有云服務對接管理方面都是做得比較好的，大家可以體驗使用，對這部分內容感興趣的同學歡迎聯繫我們，一起溝通、碰撞想法。

 項目級持續集成

目前，對於單應用的持續構建部署，DevOps 的業界產品基本都是達成共識的，對於單個微服務應用構建部署的自動化完善程度較好。

但是對於企業級項目研發過程，我們一起來回想看看，比如：單應用內不同任務需要拉多分支來進行開發（基於主幹開發的模式可能沒有這個問題），受開發環境資源的限制，不同任務開發同學要不斷進行線下溝通合併代碼發佈開發環境（或者測試環境）進行測試，過程中可能存在誰的代碼分支有問題導致整個環境不可用的現象，oh my god！

項目級的聯調部署就更復雜了，首先需要配置項目環境，其中包含了項目級的參數配置以及大家公用的項目級中間件準備部署；其次是複雜的微服務編排信息維護，這些繁瑣的項目級維護管理動作，往往會導致項目部署過程中出現各種阻塞，比如項目共同的中間件準備阻塞，上游服務的部署和健康度也會影響或阻塞下游服務部署和測試等，這些問題會讓項目部署更加困難化。

既然已經分析出問題的所在，那麼我們一起來看下 Erda 的解決之道。

Erda 堅持以應用爲中心，在單應用的研發過程中，基於任務分支開發的模式下（這裏說明一下，Erda 產品本身的研發團隊是基於主幹開發來實現每日集成的），研發同學只要保證自己分支質量的基礎上，隨時可以發佈到開發環境進行測試和驗證。

那麼細心的同學肯定會發現如果開發環境只有一套，相同應用下有其他研發任務分支的同學該怎麼辦？這裏就先透露一下 Erda 接下來即將規劃的功能：大家只管發自己的分支部署，分支之間的臨時合併後部署的事情，就交給 Erda 平臺來完成吧😄。

項目級構建部署的問題，Erda 通過項目級流水線、製品、環境部署（其實是環境準備和部署兩個環節）三個重要特性來解決的。

首先，在應用通過代碼持續構建部署到開發 / 測試環境，實現了代碼到服務的全流程自動化。

其次，項目中共用的中間件進行了統一管理。這裏的中間件不僅覆蓋了平臺內置豐富的中間件服務，還提供了公有云上的存儲類中間件，甚至還支持通過自定義中間件的方式來管理對接用戶自己部署維護的中間件。這些中間件在 Dice.yml 中可以一鍵部署，實現真正項目級的中間件管理，徹底解決用戶依賴中間件的煩惱。

前面提到了代碼到服務的全流程自動化，其實製品到服務也是這個全流程中的一個環節。應用研發同學在開發環境冒煙測試通過後，測試同學可以基於應用製品可以組合成項目製品，通過項目製品 + 環境配置，可以快速在測試環境上部署測試（基於主幹開發的話，這些步驟都是可以全自動化完成），測試同學通過自動化測試和手動測試確保項目質量達標後，就可以一鍵發佈項目製品，後期項目交付實施同學可以基於此製品到客戶環境上進行快速交付或升級應用。

 研發流程的自動化

上述的代碼到服務、製品到服務的全流程當然是在研發全流程自動化中進行的。除此之外，在優雅解決研發效能度量數據採集的同時，還要讓我們的研發同學儘量少做一些維護工作，比如：需求任務拆解後，任務的狀態、備註是否能夠自動流轉，不需要刻意地登陸到平臺去進行維護就能完成。研發同學在進行沉浸式本地開發的同時，就能完成相關工作。

這個也是 Erda 當前重點在解決的事情，研發角色在統一平臺進行高效協同的認知角度可能也會適當調整一下。不同研發角色的協同數據在統一平臺，具體的協同可以由多元化的端能力來完成，讓用戶在不感知平臺的情況下，無時無刻不在使用平臺的能力，比如：通過 ChatOps，讓信息及時觸達到用戶後，用戶可以在實時通訊 APP 中快速處理，處理後的數據會返回平臺進行統一計算分析，伴隨用戶在實時通訊 APP 的處理，相關 Issue 事項的備註、截止日期、狀態等屬性信息也在同步進行自動化流轉處理。

研發流程自動化還可以體現在 Issue、代碼、測試、環境實例之前的全方位自動化，通過 Issue 和代碼分支的綁定，研發同學本地提交 / 合併代碼後就會自動觸發相關 Issue 狀態流轉、代碼自動化構建部署、自動化測試、項目製品合成、製品 Changelog 的自動生成等全鏈路的自動化。

以上僅僅羅列了新一代 DevOps 的部分特性，對於其他特性，都應該圍繞效率、成本和質量這個鐵三角展開，去創造更多有意義、有價值的新特性。

本文只發表了一些個人對於 DevOps 演進的部分觀點，相信其他小夥伴肯定有更好的的想法，如果大家對於本話題感興趣，歡迎聯繫我們一起深入探討。我們將定期組織小夥伴圍繞相關話題進行持續討論推進，期待更多小夥伴的加入！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/uMyHw7G_QsJYXhAy3MunlQ