天天看點

阿裡巴巴DevOps實踐指南(八)| 以特性為核心的持續傳遞軟體傳遞挑戰解決思路總結免費下載下傳《阿裡巴巴DevOps實踐指南》

阿裡巴巴DevOps實踐指南(八)| 以特性為核心的持續傳遞軟體傳遞挑戰解決思路總結免費下載下傳《阿裡巴巴DevOps實踐指南》

編者按:本文源自阿裡雲雲效團隊出品的《阿裡巴巴DevOps實踐指南》,掃描上方二維碼或前往:

https://developer.aliyun.com/topic/devops

,下載下傳完整版電子書,了解阿裡十年DevOps實踐經驗。

随着微服務架構和雲原生技術的成熟,持續傳遞的理念也深入人心。持續傳遞要求開發團隊持續、高頻地向生産系統傳遞軟體。然而,不斷增多的服務數量,給企業傳遞流程管理帶來了巨大挑戰。同時,在 DevOps落地的過程中,逐漸開放生産環境的釋出權限給到開發人員,這種松管控與企業安全生産存在沖突,多應用版本之間的協同問題也逐漸凸顯。如何解決企業在新技術轉型和 DevOps 落地中的痛點,拿到技術變革帶來的效能紅利,是每個企業包括阿裡巴巴都必須面對和解決的難題。

軟體傳遞挑戰

阿裡巴巴 2008 年對淘寶巨型服務進行拆分以後,逐漸形成了一套适用于服務化、分布式架構的中間件體系,解決了複雜系統性能和穩定性在業務高速擴張中的瓶頸問題。随之而來的是應用變多、架構依賴複雜、人員數量高速膨脹、技能參差不齊等等問題。總結下來有以下幾個方面:

應用數量多

微服務架構被廣泛應用以後,首先面臨的就是應用數量的快速膨脹。原有研發流程也必須從批量釋出模式向持續傳遞模式轉型,否則會導緻釋出軟體的風險和復原的複雜度不可控。另一方面,測試和運維的工作量因為應用的膨脹而倍增,變成整個研發團隊的效率瓶頸。打破這種瓶頸的方法就是 DevOps 的全面落地,把整個軟體傳遞過程交給開發來主導,進而解除瓶頸提升效率。

架構依賴複雜

微服務架構讓應用内依賴變為了應用間依賴,變更過程無法做到原子化,是以需要很好的子產品拆分和接口設計。一方面減少單特性覆寫的應用數量,變更順序可控、復原風險可控;另一方面單元測試能覆寫的場景需要內建測試來覆寫,導緻開發過程對測試環境的使用頻度和依賴度變高,需要穩定、可靠的環境來保障所有開發人員都可以并行工作。

測試資源成本大

測試環境受到資源成本和運維成本雙重制約。在業務發展初期,可以采用全鍊路完整部署加上多套環境的方式來滿足研發團隊的要求。但是随着業務的快速發展和研發團隊的快速擴張,不斷地增加環境在成本上已經無法負擔。是以需要一套運維高度自動化,高度彈性随用随取,并且可以實作局部隔離的測試環境方案來滿足多版本部署需求。

研發協同難

研發環節的協同分為開發間協同和測試,開發、運維多角色間協同兩種。前者主要解決并行開發、按需上線的問題。後者解決的是在一個傳遞流程中各司其職、互相限制,確定軟體能高品質、安全傳遞的問題。在DevOps 場景下軟體傳遞過程由開發人員主導,而測試和運維角色則需要承擔流程守護、門禁卡點、提供自動化工具的責任。為了提升協同的效率,需要一個能夠滿足以上要求的工具平台來将團隊的約定固化下來,確定團隊各個角色可以高效率的完成工作。

線上風險大

線上的風險來自于兩方面,一方面越來越高頻的線上疊代意味着出錯的機率也在變大,另一方面随着系統規模變大,傳統人防人治的手段已不可能滿足風控要求。是以必須從出錯可能性和出錯影響面兩個方面系統性地去解決問題,前者關注能否在出錯之前對風險進行攔截,而後者關注系統變更影響的使用者數量和頻度。這兩種主動和被動防禦措施的相結合,可以有效的解決風險控制的投入産出比問題,進而達到一個比較優的狀态。

解決思路

為了解決以上在企業規模增長和新技術應用中的種種傳遞痛點,阿裡巴巴不斷探索和嘗試,逐漸摸索出一種适合這種業務發展快、軟體疊代快、架構依賴複雜場景的傳遞方法和實踐,我們稱之為“以特性為核心的持續傳遞”。它有三個特點:

以特性為核心

特性是一個使用者能體驗到的産品能力的最小單元,其代碼可能涉及到多個應用,是以特性也是協同多個開發團隊完成一個能力的最小單元。以特性為核心的傳遞過程管理可以有效地将開發、測試等角色連接配接起來并統一推進,比如組織隔離測試環境、運作自動化測試、編寫測試用例、做好測試驗收等等。

以應用為載體

應用可以直接對應一個服務,是提供一種業務能力的最小單元,也是軟體傳遞和運維的最小單元。可以通過應用串聯代碼、流水線、環境、測試和資源,以及外圍工具鍊比如監控、資料庫、運維、中間件等。開發人員可以在工具平台上定義他的應用,及應用的傳遞運維過程,比如配置流水線、規劃環境、建立資源、設定部署政策等。以獨立應用為載體的傳遞流程可以實作軟體傳遞的原子化,并強迫開發降低應用間的耦合性,同時避免系統級集中式傳遞模式的慣性。

松管控與強卡點

在軟體高速疊代下需要兼顧品質和效率,DevOps 模式需要給開發人員足夠的自由度來完成軟體的線上變更,阿裡巴巴結合自身業務特點,在實踐上采用了松管控和強卡點結合的方式。“松管控”表現在有多種流水線可以供開發選擇,應用負責人可以完整定義這個應用的各種規則,比如如何部署、如何測試、資源環境如何配置。在技術可控的前提下,還可以開放線上測試,比如全鍊路壓測和全鍊路灰階。輕釋出,重恢複,在每一個應用次元,開發可以随時使用流水線來傳遞代碼,不主張過多的人為限制,重點需要思考的是如果出問題,如何控制影響面,如何快速恢複。“強卡點”是一種軟體品質底線思維的展現,比如代碼稽核和品質紅線,規約檢查,釋出視窗,安全檢查,線上灰階卡點等。這些卡點是為了保障集團所有開發工程師步調統一,傳遞合格的産品。

持續傳遞的核心是快速高品質地傳遞價值,給與開發人員最大自由度,負責開發和運維全部過程。在監控、故障防控工具、功能開關的配合下,可以在保障使用者體驗和快速傳遞價值之間找到平衡點。

總結

今天,基于雲的開發已成為主流,這是效能提升的巨大機會,同時又對工程實踐提出了前所未有的要求。比如,雲原生基礎設施、雲原生中間件和新一代的雲軟體程式設計方法等等,都要求有與之适配的實踐和工具。在适配新的技術發展趨勢過程中,阿裡形成了以特性為核心的持續傳遞工程實踐,并且将其内建到 DevOps 工具體系中,以保障實踐準确、有效地落地。

接下來的我們将按照軟體開發和傳遞過程逐一介紹,具體包括:開發、調試、測試、內建、傳遞。

免費下載下傳《阿裡巴巴DevOps實踐指南》

阿裡巴巴合夥人和業界多位大佬力薦、何勉、陳鑫等17位阿裡資深技術專家聯袂出品、阿裡十年DevOps經驗沉澱總結、阿裡巴巴DevOps落地實踐一本通。

前往:

,下載下傳完整版電子書。

阿裡巴巴DevOps實踐指南(八)| 以特性為核心的持續傳遞軟體傳遞挑戰解決思路總結免費下載下傳《阿裡巴巴DevOps實踐指南》