導讀
中國移動云能力中心王超應邀參加由中國信通院主辦的2021可信云大會，并在云原生分論壇發表了以《移動云云空間的云原生轉型實踐分享》為主題的演講，以下是精彩內容分享。
1 定義云原生
數字世界再一次加速，我們已經從云化時代發展到了云原生時代。似乎整個行業都在討論云原生，包括分布式系統、微服務、容器化、無服務器計算以及其他新興技術和架構的作用，但 IT 從業人員和決策者仍然對云原生的真正含義以及利用云原生技術可達到的最終目標存有困惑。自從Paul Fremantle在2010年首次提出Cloud Native概念后，許多組織和專家都嘗試定義云原生：
Paul Fremantle （2010年）
他認為，應用程序當前可能無法充分利用云環境，需要考慮一些技術屬性，中間件和應用才能在云環境中良好運行（更好的利用資源、更快的配置、更好的治理），成為“Cloud Native”，此時云原生可以認為是一種云上應用構建理念。這些核心技術屬性包括：分布式、彈性、多租戶、自助服務、精細計量和計費、增量部署和測試。
Matt Stine（2015年）
Matt Stine在《Migrating to Cloud-Native Application Architectures》一書中表示，在單體應用向云原生遷移的過程中，需要從組織架構、技術和文化等多個方面共同變革。同時為云原生提出了一組最佳實踐：十二因子、微服務、敏捷基礎設施、基于API的協作、反脆弱性。
CNCF（2015年）
云原生計算基金會（CNCF）成立，將云原生定義為：容器化封裝、自動化管理、面向微服務。
Matt Stine（2017年）
Matt Stine在一次媒體小組討論中表示，云原生架構具有以下六個屬性：模塊化（通過微服務）、可觀察性、可部署性、可測試性、可處理性、可替換性。
CNCF（2018年）
云原生計算基金會（CNCF）重新定義云原生為：云原生技術有助于各組織在公有云、私有云和混合云等現代、動態環境中，構建和運行可彈性擴展的應用。代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
這些技術能夠構建韌性好、可管理和便于觀察的松散耦合系統。結合可靠的自動化手段，云原生技術使得工程師能夠輕松地對系統做出頻繁和可預測的重大變更。
綜上我們可知，云原生的定義一直在不斷變化和演進中，但始終有一個核心的目標：“以應用為中心，實現價值用云”，讓我們的應用系統和IT架構完全基于云原生，讓我們的業務系統生于云、長于云。
2 企業數字化進程的啟示
讓我們再回顧一下，企業數字化的三個階段以及它們的特點：
階段1：前云時代
軟件開發：使用瀑布模型，完整的軟件一般需要數年時間才能完成開發交付，并且在進行新功能發布或者其他增量時，花費的時間較久。開發、QA和運維是不同的團隊，協作不多。
基礎設施：一開始直接使用物理硬件，后隨著服務器虛擬化的興起，可以使用性能更強大的物理服務器來部署虛擬服務器。
運維：運維任務通常手工完成，限制了系統可運維的規模。經過一段時間的發展，技術人員開始嘗試使用配置管理工具，以減少維護基礎設施帶來的工作量和復雜度。
階段2：云化時代
軟件開發：技術人員開始使用敏捷開發模型和DevOps體系，以替代瀑布模型，這使得可以更快、更高質量地完成軟件開發及交付。
基礎設施：云將運行應用程序所需的資源和依賴作為即開即用的服務提供。應用構建者將云作為一種新型IT基礎設施，使得他們可以專注于核心業務部分而無需關心底層基礎架構。
運維：云上運維和管理的自動化程度進一步提升，包括開通、配置、擴容和自我恢復。
階段3：云原生時代
軟件開發：單體應用程序逐漸被微服務、服務網格和無狀態計算等新技術改變，結合云原生產品，開始真正充分利用云的關鍵特性。
基礎設施：云通過平臺提供多種服務支撐。應用構建者通常采用多云或混合云方法，將應用程序和服務部署在最能發揮價值的地方。
運維：基于分布式構建的應用系統，開始使用全新的部署方法：容器和彈性調度平臺，這些在基礎設施中增加的抽象，能夠使運維人員以新的方式觀察和處理系統健康狀態及性能表現。
在云化時代，企業將IT系統搬遷上云，業務應用都部署和運行在云上，消除傳統硬件的束縛，實現了敏捷化的資源編排能力。通過池化資源，一定程度上解決了部署、運維方面的難題，但傳統應用在架構、交付、部署形式等方面并沒有充分體現對云關鍵屬性的應用，無法發揮云的正真價值。
隨著企業數字化進程不斷推進，對云的理解和應用也更加深入，應用構建者們意識到僅僅簡單地將IT系統搬遷上云，往往無法真正享受云帶來的最大價值，需要由現在的ON CLOUD進階到IN CLOUD，同時使用云提供的新生能力與既有能力有機協同，基于云原生的技術、架構和服務來構建企業應用，充分利用云的優勢來助力企業應用和業務發展，將企業的數字化建設、業務智能升級帶入新階段。
3 云原生應用的概念和特點
對應用來說，云原生是一個形容詞，體現的是應用為云而生的需求：應用需要做什么樣的設計才能正真實現價值用云，這背后是一套“以應用為中心” 的技術體系和方法論，用于指導構建和運行云上應用。換句話說，云原生強調的IN CLOUD，并不是指應用所在的位置，而是指應用構建和運行的方式。
在云原生的語義下，“以應用為中心”并不等于重應用、輕平臺，相反是平臺上探、復雜性下沉，云平臺通過云服務和產品，接管應用構建過程中更多的標準功能和非功能性特性，減輕乃至消除了應用對存儲、計算、網絡等資源的關注和依賴，云平臺通過標準產品提供技術及業務能力，使應用能專注在業務需求實現上。
3.1 云原生應用
云原生應用是傳統應用的再進一步，是為云而設計的應用程序，基于云構建，依賴云上服務和能力，最大化運用云的潛能，發揮云的價值，旨在充分利用云計算模型以提升速度、靈活性和質量，同時降低部署風險。云原生應用的立意并不關注應用程序在哪里運行，而是關注應用程序如何構建、部署和管理。
云原生應用自身基于云原生技術（微服務、容器化、CICD等），完成設計與構建，同時通過與云平臺提供的相關可靠產品及能力（容器服務、安全產品、中間件等）充分整合，盡可能的剝離非功能性特性及邏輯（韌性/容錯、可觀測性、安全、連續性、一致性），讓云接管，從而輕量化應用。
3.1.1 云原生應用特點
敏捷：應用迭代周期更短，能快速應對外部變化，用最少的試錯來達到最終目標。
彈性/可擴展：應用可隨業務流量自動擴縮容，具備較高的業務抗性。同時，具備對現有基礎設施的橫向、縱向擴展能力。
分布式：應用遵循低耦合的分布式模式，各個節點可以部署在不同的網絡/地域中。
3.1.2 云原生應用的開發和傳統應用開發之間的差異
云原生應用更加關注上市速度，所以應用開發需要更多敏捷、服務化開發及持續交付的方法。通過供跨開發團隊和交付團隊的DevOps協作、更加模塊化的架構以及靈活可擴展的基礎設施提供支撐，讓云原生應用支持多種環境，具備良好的可移植性。
對應用來說，簡單的轉向微服務架構并不能帶來企業數字業務所需的服務質量和交付頻率，同樣的，僅采用支持敏捷開發或IT自動化的工具不會提高云原生應用的構建速度。想要成功構建良好的云原生應用，需要的是實踐、技術、流程和思維方式的有機結合。
云原生應用開發有兩個互補的部分：云上應用服務或中間件，可以加速云原生應用的開發；云上基礎設施服務或容器平臺，可以加速云原生應用的交付和部署。
3.1.3 云原生應用開發及交付的四項原則
·基于服務化的架構
服務化架構，例如微服務，提倡構建模塊化、松散耦合的業務服務。微服務的優勢可以提升應用的構建速度而不會增加過多的復雜性，帶來良好的獨立性和業務敏捷性。
·基于API的通信交互
多個服務之間通過輕量、技術棧無關的API暴露和交互，能降低部署、擴展和維護的復雜性和開銷。
·基于容器的基礎設施
云原生應用使用容器在不同環境和基礎設施（包括公有云、私有云和混合云）之間實現真正的應用可移植性。容器技術能在單個操作系統中為多個應用服務劃分計算資源，并確保應用服務之間的安全與隔離。使用Kubernetes等容器編排平臺，實現一定的業務抗性和彈性。
·DevOps流程
DevOps原則側重于與交付團隊（包括開發、QA、安全和 運維團隊）協作構建，共同交付應用程序。同時，使用DevOps自動化功能，支持定期增量和持續交付，并引入灰度發布、藍綠發布等來保持一定的業務連續性。
4 云原生應用構建實踐
4.1 轉向微服務
云原生應用的特點包括分布式和敏捷，這就要求將單體應用拆分為多個服務（分布式系統），而使用微服務架構是將應用程序拆分為較小服務的可靠方法，它有以下優勢：
·可擴展/解耦
擴展單個服務，而不是應用整體，且服務可部署在任意網絡節點
·互不干擾的技術棧
相互獨立，遠程通信，按需選型
·易于開發
服務小且獨立，研發過程更可控，適合小兵團組合作戰
·易于交付
每次更改涉及特定服務而不是整體，以較小的增量開發來滿足單次交付需求
微服務的概念自2011年首次提出起，就展現出了比SOA更加優越的特性，在各類方法論和支撐技術加持下，微服務架構的分布式系統易于具備敏捷性、彈性、可擴展等方面的優勢，深度契合云上應用的要求，那么如何設計一個良好的微服務架構系統呢，可以從以下幾個方面考慮：
⑴ 服務設計原則
·無狀態計算
服務節點不持有狀態，支持微服務在運行中，隨時按需彈性擴縮容。這也是分布式架構的關鍵點之一，將無狀態的計算與有狀態的數據分開，微服務計算節點只負責狀態數據的分發與處理，而有狀態數據的存儲則依賴后端的各類中間件中。
·圍繞業務、先粗后細
微服務架構的分布式系統要求我們的系統拆分成一個個獨立且松散耦合的服務進程，要為每個服務劃分好明確的邊界，通常圍繞業務，以界限上下文關聯和聚合形成服務，而不是通過技術屬性。在系統設計早期，可以將上下文界定的較粗，以較粗的粒度形成微服務，在后續的規劃、設計與運行中，對服務有了更多認識后，再調整界定粒度，進一步拆分或者合并。
·容錯與自我保護
微服務架構帶來的問題之一就是復雜的服務依賴，并且隨著時間推移，每個服務都可能依賴更多的服務，在調用鏈的某些服務不可用時，可能會因為調用堆積引起雪崩效應，無限的影響上游服務，需要有良好的機制（例如引入斷路器），識別依賴服務的健康狀態，并在發生問題時保護自身。
·冪等性、一致性
這是分布式系統永恒的話題之一，由于微服務眾多，眾多的服務請求都在網絡中發生，當發生網絡抖動、重復請求等異常情況時，服務需要具備良好的冪等設計來避免請求被重復處理。此外，在微服務架構的系統中，狀態在多個服務之間流轉，需要一致性來確保業務得到正確的處理，這就涉及到強一致性和最終一致性在系統中應用。
·向前和向后兼容
微服務的優勢之一就是各個服務可以獨立演進和迭代，而服務間復雜的依賴關系顯而易見就帶來了各個微服務版本兼容的問題，向后兼容要求服務自身迭代不能影響其他服務對自己身依賴和調用，實現多版并存，向前兼容要求服務自身能夠接受并消化其他服務的迭代，保持系統穩定。
⑵ 系統設計原則
·服務自治
單個微服務就是單個獨立的自治實體，體現在技術選型自由、部署自由、研發語言自由等方面，同時能夠自治業務邏輯和數據，需要從上到下（接入層、業務層、數據層等）全面的獨立，服務暴露出API（Application Programming Interface，應用編程接口），服務間通過API進行通信和調用。
·分層依賴
微服務整體架構設計需要分層，例如劃分出核心服務層、公共服務層、基礎服務層等，定義好服務的上下游關系落到具體的分層，并約定依賴方向，做好分層依賴，避免產生循環依賴導致系統整體耦合性上升。
·高效服務通信
微服務架構中的各個微服務之間通常通過遠程通信實現調用，通信的實現方式直接影響了服務間調用的效率和成功率，這就需要考慮技術選型，例如選擇具備多路復用、雙向流通信、二進制傳輸等特性的新型傳輸協議和組件。
·適當異步消息傳遞
當在多個微服務上下文中傳遞消息時，各自微服務不同的部署規模和處理能力帶來了服務間可能的調用堆積，可以使用適當的異步消息傳遞機制（請求響應異步、事件驅動異步、消息隊列異步），減少系統整體耦合度、提升處理性能。
·面向運維
微服務架構下產生了繁多的獨立服務實例，為系統運行期的運維帶來了一定的復雜性，所以要把運維復雜性考慮到系統的設計階段，由內而外的實現可觀測性、可部署性及可運維性。
在這個過程中，我們要清楚的意識到“微”不是目的，“敏捷”才是我們的最終目標，要依托微服務的理念，將應用程序打造成一個業務敏捷、技術敏捷的云原生應用。
4.2 應用容器化
應用微服務化之后為集成和交付帶來了挑戰，而容器和微服務就像豆漿油條一樣天生一對，是當下流行的開發實踐，可將應用程序轉換成可移植、可擴展、高效且易于管理的較小服務集合。
容器是一種輕量級的虛擬化技術，能夠在單一主機上提供多個隔離的操作系統環境 ，通過一系列的namespace進行進程隔離，每個容器都有唯一的可寫文件系統和資源配額。容器技術分為運行時和編排兩層，運行時負責容器的計算、存儲、網絡等，編排層負責容器集群的調度、服務發現和資源管理。
中國云原生用戶調研報告（2020）中調查數據顯示，60%以上的用戶已在生產環境中應用容器技術。43%的用戶已將容器技術用于核心生產業務，19%的用戶已將容器技術用于非核心生產環境。僅10%的用戶未考慮使用容器技術。同時，容器運行時多元化發展趨勢已經顯現，但Docker仍是現階段最主要的選擇。83%的用戶容器運行時技術選用Docker，9%的用戶選用 Containerd。此外，Kubernetes延續在容器編排技術領域的優勢地位，63%的用戶容器運行時技術選用Kubernetes，17%的用戶選用Docker Swarm。
容器技術能為使用者能帶來以下優勢：
·更快的初始化和執行
·更細的隔離與服務共存
·更輕松的編排管理
·更便捷的制品交付
在實際的研發過程中，常常有以下幾種訴求：
·在研發生命周期中，分別部署到不同的環境
·業務服務快速啟動/拆除/擴縮容
·業務服務實例混部
·只關心應用運行，而不關心在哪里運行
以上兩者可以發現，容器技術的優勢可以匹配研發過程中的訴求，容器可以幫助解耦應用和基礎設施，提高業務敏捷性，是實現“以應用為中心”架構的重要支撐。通過云、容器、微服務三者協同工作，將應用的開發和交付提升到傳統方法和技術無法達到的新高度，大大增加了應用生命周期的敏捷性和可靠性。
通常，云上的容器服務能提供高性能可伸縮的容器應用管理服務，容器化應用的生命周期管理可以提供多種應用發布方式。容器服務簡化了容器管理集群的搭建工作，整合了調度、配置、存儲、網絡等，打造云端最佳 容器運行環境。使用容器技術，用戶可以將微服務及其所需的所有配 置、依賴關系和環境變量打包成容器鏡像，輕松移植到全新的服務器 節點上，而無需重新配置環境，這使得容器成為部署單個微服務的最理想工具。
4.3、持續交付流水線
應用微服務化與容器化之后，還是會面臨“更快且頻繁交付”和“系統穩定且可靠”之間的矛盾。而持續交付（Continuous delivery）是一種軟件工程方法，旨在以更快的速度和更高的頻率來構建、測試和發布軟件。可以使生產中的應用程序進行更多增量更新，該方法有助于降低成本、耗時和交付變更的風險。使用者可通過完整的工具鏈，深度集成代碼倉庫、制品倉庫、項目管理、自動化測試等類別中的主流工具，快速實踐。
由上圖可以看到，持續交付是持續集成模型基礎上的延伸，使研發周期自動化更進一步，能夠快速發布到演示或UAT環境、以及執行自動化的系統集成測試。
4.3.1 實踐原則
在建設持續交付流水線的過程中，可以遵循以下策略：
⑴ 版本控制與分支策略
·可審核、可重復
每一次的版本構建都是可審核且可重復的，能夠利用版本控制策略回溯，以應對流水線中可能出現的失敗。
·包含整個交付物（代碼、數據庫、配置）
版本控制不能僅僅包含代碼，也要包含變更涉及的所有內容，避免遺漏，產生不一致。
·頻繁的分支合并
盡早、頻繁的合并分支，有利于發現最新的修改，能夠及時處理沖突。
⑵ 持續交付流水線
·合適的工具
采用合適的工具構建自己的流水線，考慮學習成本、維護、效果等多方面的因素。
·數據驅動
通過每一次自動化動作的指標量化數據，來驅動流水線向前或向后推進。
·控制與改進
通過每一次構建的動作效果與反饋，不斷改進流水線，添加自動化動作或者更新技術工具。
⑶ 更多的自動化
·檢測、構建、測試
在流水線中引入更多的自動化動作，盡量減少手工參與，可以覆蓋檢測、構建、測試等多個環節。
·覆蓋整個交付物
自動化的動作不僅要覆蓋代碼，也要包含全部交付物，例如腳本、SQL、配置等，避免遺漏。
·重復的體力勞動
如果在流水線上有重復的人工體力勞動，都建議嘗試將其納入自動化動作。
⑷ 良好的反饋機制
·全周期反饋
反饋機制要包含整個持續交付周期，對每一次動作都要有所響應，避免遺漏。
·快速反饋
在持續交付中，流水線要能夠在構建時快速給出結果，避免團隊等待而降低敏捷性。
·團隊積極響應反饋
團隊成員需要建立起迅速響應流水線反饋的文化，及時修改問題，提升效率，降低風險。
4.3.2 持續交付流水線樣例
一個典型的用于生產的持續交付流水線如上圖，充分融合了技術、流程與團隊，通過自動化動作與持續反饋機制，不斷發現交付物中的問題并予以修正，能夠大大降低部署到生產環境的風險。
持續交付并不要求最終交付物自動化部署到生產環境，在持續交付的語義下，生產環境部署變更是兩階段完成的，第一階段采用持續交付給出穩定的交付物，實現制品晉級并分發到發布制品庫，通過上線審核后，再通過發布管理平臺或其他方式部署到生產環境。
4.4、與云融合
從使用效用方面看，云原生極大的釋放了云的紅利，云原生充分繼承了云的設計思想，應用會更多基于云上進行本土應用開發，即云原生應用更加適合云的架構，而云計算也為云原生應用提供較好的基礎支撐。云計算的發展已進入成熟期，云原生作為新型基礎設施支撐數字化轉型的重要支撐技術，逐漸在人工智能、大數據、邊緣計算、5G等新興領域嶄露頭角，成為驅動數字基礎設施的強大引擎。
對使用者來說，使用云上提供的服務或產品，有助于剝離非功能性需求，敏捷化研發過程，實現提質降本增效。以移動云為例，目前規劃提供了多線條的產品線來支撐快速、高效的構建云原生應用。
云原生開發者服務
包括微服務治理引擎、DevOps工具鏈、應用開放平臺等，為開發者提供端到端的協同服務和研發工具，降低數字化技術使用門檻，提高資源的復合利用率，提升協作和交付效率。
云原生中間件產品線
包括消息隊列、數據庫、大數據、AI能力等，提供優勢云數能力及各類云上中間件，能將功能從應用中剝離，在運行時為應用動態賦能。
云原生計算產品線
包括容器服務、Serverless等，封裝異構基礎設施提供負載支撐，有效解決異構環境部署一致性問題，促進了資源的標準化。
5 結語
云上應用的共性需求促進了云上服務及產品的演進，云上服務及產品的繁榮也進一步促進了云上應用構建和運行形式的更新，這是一個雙向價值促進的過程。對應用本身來說，除了圍繞云原生代表技術來設計與構建之外，還要與云提供的各類服務及產品深度整合，根植于云，隨云而動--“to be Cloud Native”。
讓我們再回看Paul Fremantle在10多年前提到的未來：
strongly believe that it is only once a system really implements these attributes that it starts to give the full benefits of running in a cloud. And the benefits of "Cloud-Native" systems are immense: better utilization of resources, faster provisioning, better governance.
如今，未來已來。
作者簡介：
王超，中國移動云能力中心SaaS產品部技術專家組成員，曾負責能力開放平臺、服務治理平臺、移動云云網盤等產品及項目的研發工作，架構設計及研發管理經驗豐富，在互聯網大型業務系統的規劃、設計與調優方面有深入研究。
參考文獻
[1] 《云原生2.0白皮書》 - 中國信通院.
[2] 《mi-path-to-cloud-native-apps》 - redhat.
[3] 《云計算發展白皮書2020》 - 中國信通院.
[4] 《云原生發展白皮書2020》 - 中國信通院.
