小螞蟻說:在金融級互聯網產品持續交付方面,螞蟻金服積累了豐富的經驗和最佳工程實踐。在2018年ATEC技術探索大會上,螞蟻金服解決方案架構師呂中邦(鳳啓)從行業背景出發,分析了金融級互聯網產品持續交付的核心挑戰,從「更快更早地交付價值」和「守住技術風險底線保障交付質量」兩個維度分享了螞蟻應對這些挑戰的最佳工程實踐作法,最後還介紹了螞蟻研發效能平臺支撐持續交付的實踐經驗。跟着小螞蟻一塊兒來學習吧~git
1、行業背景與主要挑戰安全
數字化轉型的大背景下,企業須要打造多方面的核心能力,這些能力客觀上要求企業升級或者採用新一代的技術架構。其中很是重要的一個環節就是基於雲端的基礎設施、分佈式架構下的持續交付。談到持續交付,很容易想到一些具體的挑戰:好比如何縮短新業務產品的研發與投產時間,快速響應細分客戶需求;如何應對分佈式微服務架構帶來的業務場景複雜和高併發挑戰;如何經過技術手段推進自動化減小研發過程當中的人工投入等等。架構
此外,咱們還須要認真審視所處的行業,到底有怎樣的特色。金融互聯網產品最核心的兩個關鍵詞,第一個就是「金融」。金融屬性最重要的是保障資金、安全、高可用,歸結成一個字——「穩」;另一個關鍵詞「互聯網」,最顯著的特徵就是快速交付價值,支持業務的快速創新,咱們把這歸結成另一個字——「快」。不只要快並且要穩,這就是金融互聯網行業的基本特質,看似矛盾的兩個方面,缺一不可。併發
談到「穩」和「快」,螞蟻金服作得怎麼樣呢?分享上財年的幾個實際數據:線上服務可用率——100%;天天應用發佈超過150次;迭代平均研發週期5.8天;測試自動化率超過了80%;運維自動化率超過98%。框架
基於數字化轉型背景和行業的基本特徵,咱們認爲金融互聯網產品在持續交付領域最核心的挑戰是:如何兼顧快和穩?既可以敏捷快速地交付價值,又能夠穩妥創新、守住技術風險底線、持續知足監管合規的要求。運維
2、敏捷交付——如何更快更早地交付價值分佈式
本章節分四個部分展開,首先是精益研發流程定製和多樣化分支與發佈策略,主要解決咱們的體系或流程如何適配不一樣業務場景,正確的路徑和姿式是研發交付提效的基本前提。微服務
其次是職能服務化、高效聯調和問題診斷,這兩個部分主要是闡述如何經過技術或自動化手段解放人肉、提升效率。高併發
說到流程定製,不少人會問:咱們依據什麼來定製研發流程?在螞蟻咱們有一個比較有效的作法,那就是依據應用分級。應用分級主要考慮三方面的因素:依賴服務的調用量,日交易資金量,以及每日的PV和UV。根據這三個方面咱們定義了從A1-C4十二個不一樣的應用級別,而後爲每一個級別的應用設置基線的研發規則,在基線規則之上咱們還支持各業務去自定義附加的風險管控措施。工具
舉兩個例子,一是按需配置流程。螞蟻金服的業務很是複雜和多樣,有些比較核心的業務系統穩定性要求很是高,相應配套的技術風險防控措施、測試驗證環節就會比較完善;反之,一些新業務或內部服務系統會傾向於更快、更早地上線,流程相對來講會更輕量、更敏捷。二是可編排、可擴展的流水線,效能平臺的組件中心定義了不少質量檢測組件,其中包括第三方或業務自建的組件,經過平臺的編排能力爲不一樣的業務編排個性化的流水線模板。有些應用強制作代碼評審,有些應用須要經過CI的自動化測試或某專項測試以後才能向下推動,相似的場景均可以經過流水線編排來實現。
關於分支模式和發佈策略,螞蟻主要有四種玩法。
首先是平常發佈,咱們把它比做一輛按期發車的火車,適用於全站的核心業務系統、應用之間關聯性比較強的場景。
第二種是獨立發佈,咱們把它比做一輛小汽車,想何時發車就何時發車,適用於獨立業務域、應用間有必定耦合和關聯的場景。
第三種是單應用發佈,咱們把它比做是一輛摩托車,適用於業務獨立性更強、與其餘業務在架構層面徹底解耦的場景。前三種模式一般採用分支開發主幹發佈的模式。
最後一種緊急發佈,咱們把它比做救護車,適用於緊急業務需求或線上故障的解決,一般採用分支開發分支發佈的模式。
經過這四種模式,螞蟻全部的業務場景基本獲得覆蓋,各業務能夠根據本身的須要找到匹配的玩法。
介紹完了敏捷交付的姿式和路徑,接下來看看自動化提效方面。
一般在一個研發迭代中,會涉及到不少職能部門,傳統的作法是各職能團隊基於經驗複覈進行人肉的風險管控。好比,當開發人員完成了編碼、自測,就會有安全、風控等職能團隊層層把關,基於經驗進行審覈,「部門牆」會嚴重影響協做和交付的效率。在螞蟻,各職能團隊的協做方式徹底不一樣,他們再也不直接參與到項目迭代中,承擔迭代驗證和審覈這種重複機械的活動,而是轉型爲能力輸出和自動化工具建設,實現職能服務化,從而對業務的開發測試團隊進行賦能,這種模式大大提升了研發協做的效率。
金融互聯網產品的業務場景很是複雜,搭建項目環境是是一個很是耗時耗力的事情。好比一個交易鏈路涉及20個應用,通常的作法是在研發迭代過程當中給每一個應用部署一遍,最後造成聯調環境。螞蟻的作法又會不一樣,首先咱們搭建了一個共享的STABLE環境,在研發迭代中只須要針對有變動和修改的應用進行部署,而後經過sofarouter分組能力把全部20個應用關聯在一塊兒就造成了聯調環境。這樣作不只大大提高了效率,還最大化利用了測試資源。此外,當代碼發佈上線以後,平臺會自動更新STABLE環境保證其爲最新代碼。
若是在聯調過程當中發現問題,如何在如此複雜的鏈路中定位和診斷問題也很是重要。開發同窗可經過TraceID或交易號查詢鏈路圖、時序圖,直觀全面地瞭解應用間的調用交互信息,再結合業務日誌就能夠很是容易地找到錯誤應用並定位問題根源。
3、穩妥創新——守住風險底線保障交付質量
本章節一樣分四個部分來探討,其中技術風險評估、質量內建、測試驗證是按照開發的事前、事中、過後的邏輯來展開,最後向你們分享咱們是如何守住安全底線、保障信息安全的。
毫無疑問,開發事前的技術風險評估是很是重要的。螞蟻的技術風險評估主要基於兩大輸入來作:第一是需求輸入,第二是治理分析相關數據輸入和賦能,後者對咱們來講更爲重要。開發同窗能夠很是便捷地獲取應用依賴、服務調用、消息巡檢、組件管控、代碼檢索等數據,全面準確地評估變動帶來的技術風險,基於這些數據和分析,就垂手可得地肯定風險應對策略,作到有效的閉環的反饋。
開發的事中——內建質量與實時閉環反饋,幫助開發人員在第一時間把事情作對。在螞蟻內部,咱們鼓勵基於gitflow的最佳實踐,經過MergeRequest方式而不是Push方式向項目分支或主幹提交代碼, 給代碼門禁、CI檢測一個機會。事實上Pipeline流水線的全部節點和組件都是可編排、可擴展的。在提交代碼以後,每執行完一個組件,平臺都會實時反饋結果,並自動更新迭代的質量數據,協助開發測試同窗管控質量風險。
開發的過後,也就是測試驗證部分,咱們分享兩個點:第一是全環境驗證,從開發》集成》預發》灰度一步步接近和模擬生產環境,確保生產發佈沒有問題。第二是業務分層驗證,在每一個環境,都有對應的測試手段。好比壓測,不少公司都在作,但多基於線下環境進行,而螞蟻會直接在生產環境裏作壓力測試,真正作到系統的高可用。
穩妥交付的最後部分,在保障信息安全方面,螞蟻有一套完整的體系:在需求設計評審階段,架構師會評估業務風險;在開發階段,首先SOFA框架自身的安全是有保障的,其次每次代碼提交咱們都有安全的自動掃描,此外還會有專項的安全測試;最後在系統上線以後,咱們有專門針對安全的監控和應急機制。
4、研發效能平臺AntLinkE支撐
前面咱們不只介紹瞭如何敏捷交付,還介紹瞭如何穩妥創新,接下來分享工具平臺層面是如何支撐整個持續交付過程的。
螞蟻研發效能平臺所作的事情,主要歸結爲三個方面:
DevOps—一站式開發集成持續交付DevMind—實時多維的數據分析賦能研發過程
DevServices—爲研發者提供高效技術支持和諮詢服務
下面是咱們的產品大圖,頂部是平臺支撐的業務和交付的價值,底部DevOps、DevMind、DevServices三方面的主要能力,今天咱們重點來介紹一下中間的產品層。
首先是持續交付,從建立迭代開始,到發佈上線結束,爲整個研發生命週期提供支撐。下面是配套的子產品:研發協做管理項目、迭代和需求;代碼服務提供代碼託管、代碼搜索、CR等能力;IDE是螞蟻比較有特點的產品,能夠幫助開發人員第一時間作代碼掃描,還與效能平臺的Web端作了整合和集成打通,開發人員不用頻繁切換工做臺來開展開發工做;測試服務支持測試管理、自動化測試;問題診斷依賴分佈式鏈路和業務日誌快速定位和解決問題。最下面是研發洞察,在研發過程當中,不管是IDE端仍是研發效能平臺的Web端,都會沉澱大量數據,這些數據是很是寶貴有價值的資產,咱們經過對這些數據進行採集、統計、分析來驅動整個研發體系和組織的持續優化和升級。
一站式持續交付解決方案如圖所示。中間部分是研發效能平臺,提供了從需求到發佈的持續交付引擎,將全部相關的能力和工具串接在一塊兒;底部是應用PAAS平臺,效能平臺經過openAPI與之交互,打通環境管理和環境部署等功能;右側是分佈式中間件,研發效能平臺經過研發容器,統一管理多環境的中間件配置,既實現環境間的隔離,又實現了環境間的自動轉換和同步;此外研發效能平臺與技術風險防控平臺打通,把技術風險防控的措施落實在研發過程當中;此外,螞蟻研發效能平臺先天具有開放集成能力,能夠經過組件的方式對接企業自有的工具平臺,最大化發揮既有資產的價值。
5、結語
不管對內部仍是外部,螞蟻研發效能平臺一直秉承並將繼續追求這樣一個初心——提高研發者幸福感,提升企業創新效率,讓咱們一塊兒從新定義研發!