銀行基於雲原生架構下的 DevOps 建設

　　本文分享了金融級容器雲建設如何滿足生產級別要求；介紹了DevOps從“傳統”到“雲原生”的技術演進；詳細對比介紹了為何選擇Tekton+ARgoCD進行雲原生的DevOps實踐；以及如何做網路外掛選型改造。乾貨滿滿，值得參考借鑑。

　　 一、 背景和需求分析

　　在銀行業金融科技的創新過程中 ， 計算基礎架構的根基以及應用開發與運營的方式都已發生了翻天覆地的變化。基礎架構、平臺軟體、分散式應用 、容器和雲原生技術架構 ，以及適應快速、迭代式應用開發的文化和流程等——這些快速發展的技術和方式正在迅速整合，形成一種新型的IT管理方法，併為企業發展所依賴的關鍵傳統型IT架構提供有益補充。

　　全球雲端計算技術發展歷經20年，歷經虛擬化時代、傳統雲端計算時代演變為至今的雲原生技術時代。“雲”中的資源 可隨時獲取，按需使用，按使用付費，可無限擴充套件，這種特性被稱為像水電一樣使用 IT 基礎設施。雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在將雲應用中的非業務的技術元件部分進行最大化的剝離，從而讓雲原生設施接管應用中原有的大量非功能特性（如彈性、安全、可觀測性、灰度等），使業務不再有非功能性業務中斷困擾的同時具備輕量、敏捷、高度自動化的特點。雲原生架構的典型技術代表是容器技術與Kubernetes編排排程技術，在企業的數字化轉型過程中 ，兩者也成為雲原生時代下的新型PaaS平臺計算基礎架構的根基 。

　　DevOps（Development和Operations的組合詞）起源於 2007 年，是一組過程、方法與系統的統稱，用於促進開發（應用程式/軟體工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。它的出現是由於軟體行業日益清晰地認識到：為了按時交付軟體產品和服務，開發和運維工作必須緊密合作。DevOps優勢明顯：能夠對各種修改需求做出快速的反應、能夠實現靈活的安全部署與編排、能夠建立完善的協作與溝通渠道、能夠快速地識別出程式碼中的錯誤或漏洞、開發團隊聚焦關鍵問題，不必過度專注於各項安全功能。

　　既然雲端計算和DevOps技術都歷經發展了多年，每家金融機構目前所處於的雲端計算和DevOps建設階段可能各不相同，如何能全面覆盤整個技術的演進歷程，不走無謂的彎路和老路，緊跟雲原生技術的發展趨勢去做雲原生化DevOps尤為重要。但在如今開源技術社群的雲技術和DevOps系統種類非常之多，如何高效、低成本、安全合規且符合技術潮流等多重維度來選型相應的工具系統對於企業進行數字化轉型尤為重要。還有金融網際網路業務如雨後春筍發展迅猛，對於業務產品上線速率和使用者體驗尤為重要，對於灰度釋出技術棧的選型和實踐也急需提上日程。最後金融級雲原生容器雲建設如何滿足生產級別要求，對於容器化和非容器化系統共存且都應用微服務平臺的架構下，如何做網路外掛選型改造，針對以上需求痛點進行以下內容分享。

　　二、 “傳統”DevOps 如何技術演進為“雲原生”DevOps

　　DevOps關鍵技術發展歷程經歷了四代，第一代是基於物理機/獨立虛機技術的時代缺點較多，如 資源環境交付 ：資源環境的搭建與應用部署過程割裂開來，建立系統資源環境效率低、耗時、風險高，系統變更需靜態配置結合人工協調；應用軟體交付 的週期長、迭代慢，且手工配置、自動化率低，不能視覺化交付，不能以環境+系統為單位交付。第二代是基於IaaS技術的時代優勢明顯，可一鍵自動化：建立環境到部署安裝應用元件整個過程的一鍵建立和部署，資源和應用同時交付，擴縮容後服務自動註冊；叢集感知能力強：IaaS資源可程式設計介面實現叢集感知，自動協調控制、動態配置，可提高開發測試和交付的效率。第一代和第二代可定義為“傳統”DevOps時代。第三代是基於容器技術的時代，容器技術的輕量級和遷移便捷性體現的淋漓盡致。應用跨雲遷移性：遷移後環境一致性，遷移部署速度快，一次打包、到處執行；輕量級交付能力強：快速彈性伸縮、提高資源利用率、故障自動遷移。第四代是基於雲原生技術的時代，全面體現在全棧自動化和雲原生工具生態能力類。全棧自動化體現為：流水線自動化、故障自愈 、支援跨資料中心排程 、以整套環境為單位交付；雲原生工具生態豐富：K8S原生類CI/CD系統 、服務視覺化編排 、滾動升級釋出 、流量接入/灰度釋出能力。

　　第三代和第四代可定義為“雲化”DevOps時代。

　　三、 雲原生和DevOps 的結合實踐

　 　江蘇蘇寧銀行DevOps總體架構

　　江蘇蘇寧銀行DevOps總體架構是以平臺為支撐，以流程為引擎全面打造金融級雲原生DevOps平臺架構。從底至上分為三層，支撐平臺層：管理DevOps流程中涉及的各類資源，包括程式碼管理、持續整合、配置檔案、應用例項等，同時提供部署、配置等Ops服務。自動化流程引擎層：面向可編排任務流程，提供任務的編排、配置、執行等功能，透過該流程引擎支撐不同應用的不同DevOps流程，實現DevOps的自定義特性；可自定義流程層：把DevOps流程抽象並具體化成一個個獨立的動作，形成標準化DevOps流程。

　　江蘇蘇寧銀行DevOps系統選型分析

　　上面介紹了“雲化”DevOps時代的技術能力，但在當今市面上開源的DevOps系統工具種類繁多，如何正確、高效且符合雲原生技術發展趨勢等多重維度來選型DevOps工具系統對於企業進行數字化轉型尤為重要。

　　那麼雲化DevOps系統到底是什麼？對比分析開源界主流DevOps CI/CD工具系統：Jenkins作為老牌CI/CD工具，具備一定的技術歷史背景，但明顯感覺太重 、Jenkins的Pipeline語法學習成本較高 、非kubernetes原生態工具；Spinnaker持續交付平臺，是一款專注於多雲平臺的CD平臺，功能專注於持續交付，對於CI/CT並不擅長；Gitlab雖帶有CI/CD系統，但非kubernetes原生，考慮低耦合設計，為避免和Gitlab耦合，不想用gitlab-ci；Tekton是 Google 開源的 kubernetes 原生 CI/CD 系統，作為CDF四個初始專案之一、基於kubernetes CRD可自定義的pipeline流水線 ，但在工作流控制上的支援較弱；Argo則是一款遵循宣告式GitOps理念的持續部署工具，應用定義、配置和環境資訊是宣告式的且可以進行版本控制，應用部署和生命週期管理是全自動化的且可審計，支援對多環境、多Kubernetes叢集上的應用進行統一部署和管理。結合以上分析，我們選擇Tekton+ArgoCD進行雲原生的DevOps實踐。

　　江蘇蘇寧銀行Tekton+ArgoCD 實踐-場景

　　準備工作：

　　1、準備Git Repo

　　Tekton Pipeline、app code、kubernetes deploy三部分

　　2、安裝Tekton/ArgoCD客戶端、Tekton Operator、ArgoCD Operator和ArgoCD服務端環境

　　3、建立ArgoCD的應用

　　4、建立Tekton Pipeline

　　5、允許Tekton Pipeline更新Infra Repo中的內容

　　6、建立Webhook並配置Code Repo的Webhook

　　7、執行Tekton Pipeline

　　手動執行tkn pipeline start

　　Gitlab上修改及提交Code，Webhook觸發

　　場景描述如下：

　　應用程式碼放在Code Repository中，程式碼變化後會透過Webhook觸發Tekton的Pipeline執行。

　　Tekton的Pipeline先從Code Repository中獲得應用程式碼，然後Build成Image，隨後將應用Image推送到容器雲平臺內部的Image Registry中。最後再更新Infra Repository中的部署配置。

　　ArgoCD發現Infra Repository中的部署配置發生變化後自動同步到容器雲平臺。

　　容器平臺根據新的部署配置從其內部的Image Registry獲取最新的應用Image，然後部署到容器雲平臺。

　　ArgoCD+Argo Rollouts支援blue/green、canary多種部署方式，結合開源的keptn做SLI/SLO及自動化測試。

　 　基於Argocd-Rollouts 進行 blue/green canary釋出

　　在雲端計算技術或雲原生技術出現之前，一些網際網路公司也有灰度釋出的需求，也會用基於一些開源工具做定製化研發，如使用Nginx等，使用其定製開發一些 基 於 Request Header 流量切分、基於服務權重的流量切分、基於 Cookie 的流量切分等的規則引擎。目前業內流行的blue/green、canary釋出技術有幾類，引入和改進適合自身場景的灰度釋出技術很重要。如可以使用服務網格Istio的Istio Gateway + VirtualService + DestinationRule 做灰度釋出，但由於Istio自身技術棧具體有一定深度，要全面掌握其技術運用和維護需要一定的成本，故只為了進行灰度釋出選用Istio會導致學習成本和應用成本過高；另外也可以基於K8S的Ingress進行 配置Ingress Annotations來實現不同場景下的灰度釋出和測試 ，其本質就是Nginx的應用；第三類則是使用基於Argocd-Rollouts進行blue/green canary釋出，既然我們選擇使用Tekton+ArgoCD做DevOps系統工具，為保持技術棧統一則繼續深度使用基於雲原生的Argocd-Rollouts進行灰度釋出。提前編寫好yaml編排檔案，釋出流程如下：

　　新舊灰度對比

　　在使用了雲原生灰度釋出技術後，很大程度上改進了原灰度系統的不足，改善了使用者業務系統體驗，提升了程式碼釋出質量和業務投產效率。

　 　四、 金融生產級雲原生容器雲平臺的最佳化

　　江蘇蘇寧銀行雲平臺總體架構

　　江蘇蘇寧銀行在南京有兩個資料中心，基於雙資料中心的基礎設施之上構建雲端計算平臺，從底而上的分為四層：底層是基礎設施平臺，含計算伺服器、儲存、網路、安全裝置等，雙資料中心基礎設施池化；基於底層基礎設施平臺構建雲端計算IaaS層，技術棧分為開源棧OpenStack雲平臺和閉源棧VMware雲平臺，兩者形成統一混合資源池，資源申請無需關注底層是何技術棧，雙資料中心網路二層打通，跨資料中心可遷移雲主機；基於IaaS層資源池構建雲原生容器雲平臺；頂層透過多租戶管理體系設計統一雲管管理和編排排程各類資源，並提供豐富的服務目錄含各資源管理類、DevOps類、監控運維類，以此滿足金融業的服務指標、服務目標、服務質量等級等。

　　金融雲原生容器雲建設以上生產為目標

　　如我們是以上生產為目標，列舉幾個原則：

　　1、儘量不改變現有生產網路架構模式、不改變生產系統IP地址以及防火牆策略，使現有的防火牆規則對K8S叢集中的POD也生效，那麼可以使用macvlan這種網路模型，這樣POD ip和宿主機屬於同一網路平面，既所有的網路流量都會經過現有交換機和防火牆（這種場景下可以簡單的理解為POD就是虛擬機器），需要提前規劃足夠多的IP地址資源池來給後面所有的POD使用。使用macvlan最大的問題：受技術原理限制（主要是underlay 2層流量不經過宿主機的3層及以上的協議棧，報文沒有用iptables，ipvs處理，所以K8s裡的Service、QoS、 N etworkpolicy沒法實現），二是需要開啟混雜模式，這種模式下會造成網路卡過多的接受非自身處理的資料包。

　　2、還需要考慮叢集內部的網路安全策略以及QoS，雖可透過Calico的 N etwork policy來配置ipvs來實現，但原生Calico均是命令列，操作不方便和易出錯。

　　3、需要考慮叢集內POD與第三方外圍系統（如虛機某埠）安全策略（如核心生產區到外聯DMZ區或者核心生產區到網際網路DMZ區，需要開點到點的防火牆策略，源和目的都是物理IP），用macvlan也可以解決此需求，但不支援Service

　　4、金融場景下可考慮使用linux brige-vlan模式解決以上痛點。

　　需要考慮的底層技術棧有很多

　　由於金融業對生產系統的高可用、穩定性、效能、安全等要求較高，故云原生容器雲要達到生產級別的要求需要考慮、最佳化解決的底層技術問題有很多，現僅舉例如下：

　　1、K8S中CPU NUMA排程能力最佳化

　　2、K8S叢集排程能力最佳化，如：宿主機當機場景後的排程策略

　　3、K8S管理Node的能力

　　4、彈性伸縮CA、HPA、VPA能力最佳化

　　5、拉取映象規則：空負載伺服器、有負載伺服器，計數器規則、就“近”原則

　　6、東西向QoS、Networkpolicy，視覺化操控等

　　7、IPAM能力網路定製

　　8、API Server/ETCD效能最佳化

　　9、Harbor需要做雙Harbor進行同步，保證映象倉庫高可用

　　10、Etcd要用ssd做加速，做兩個etcd叢集，把儲存的資料按事件型別不同分別讀寫不同的叢集

　　11、還有很多……

　 　基於Kubernetes構建的雲原生DevOps容器雲底座

　　DevOps 基礎架構監控中心

　　DevOps基礎架構監控中心可全面監控Kubernetes各大元件的核心引數，如Etcd的庫大小、客戶端流量、gRPC流式訊息、WAL日誌同步時間、庫同步時間、Raft提議等；APIServer的請求延遲時間、每秒請求數等；排程器監控排程次數、排程速率、排程延遲等，視覺化監控粒度之細、監控引數之全面性在 K8S的監控領域並不多見。

　　DevOps 專案管理

　　DevOps專案管理可以根據企業空間、使用者空間、專案名稱空間等有效規劃和隔離各類資源和物件的抽象集合，便於DevOps專案日常管理和運維操控。

　　江蘇蘇寧銀行DevOps +容器雲實踐效果

　　容器雲實踐效果

　　極大程度的節源提效：資源利用率提升60%，伺服器/機櫃成本下降60% ，且在生產環境各場景下發揮自動化和應急的重要作用，具體如下：

　　雲原生DevOps實踐效果

　　環境交付、版本釋出週期提速 2-3 倍；提升投產質量，提升使用者體驗 ，具體如下：

　　五、基於雲原生 的 DevOps技術趨勢

　　雲原生技術已逐漸成為金融科技行業的技術標配，DevOps技術也已發展有十幾年，兩者的強強聯手、有效結合必將是金融業數字化轉型的利器和必經之路。基於 雲原生 的 DevOps 全行業 技術趨勢 預測為：DevSecOps將被優先考慮、將更廣泛的深度使用Kubernetes、從CI pipeline轉移到DevOps組裝線、強調Serverless架構、AI助力DevOps團隊實現自動化、Golang將更受歡迎。銀行是非常重視安全合規的機構、金融網際網路產品釋出快且重視使用者產品體驗、在金融領域會全面使用金融AI技術，因此江蘇蘇寧銀行會重點關注DevOps的安全、基於雲原生的灰度釋出回滾技術使用、金融AI助力DevOps等方面。

　　【作者】蔣立傑，雲端計算專家，具備11年+的雲端計算架構規劃、研發、交付運維經驗，雲端計算主要技術方向：基於OpenStack+Kvm的私有云、基於Docker+Rancher/Kubernetes的容器雲PaaS、分散式雲資料庫、分散式雲端儲存等。阿里雲MVP-雲原生領域最有價值專家、CNCF-KubeSphere Ambassador、中國DevOps社群技術專家、國內雲端計算業首批技術專家、前阿里雲金融雲首家戰略生態系公司雲端計算架構/DevOps負責人、前中興通訊雲端計算架構專家。