運營商IT系統云原生部署方案研究

蔣明燕（上海郵電設計咨詢研究院有限公司，上海 200092）

1 云原生的定義及關鍵技術

云原生應用（Cloud Native Application）是指針對云計算基礎設施進行優化設計的應用，適合部署運行在現代的云計算平臺上，能充分利用云平臺所提供的資源和服務，是一系列云計算技術體系和管理方法的集合。云原生應用具備良好的擴展、伸縮和容錯能力。云原生涉及的技術棧十分廣泛，生態十分繁榮，產品也正在被廣泛應用。

云原生技術由云原生計算基金會（Cloud Native Computing Foundation，CNCF）提出，有利于各組織在公有云、私有云和混合云等新型動態環境中構建和運行可彈性擴展的應用。云原生的關鍵技術包括不可變基礎設施、容器技術、微服務和無服務器（Serverless），其技術架構如圖1所示。

圖1 云原生技術架構

不可變基礎設施指運行服務的服務器在完成部署后，不再進行更改。采用云端虛擬化基礎設施作為構建基礎，通過容器來打包及構建整體服務運行環境，實現容器鏡像的自動化構建及版本化管理；通過持續部署系統，實現自動化部署。

容器技術包括容器運行時和編排調度。運行時是容器的運行環境，體現為各種開源容器產品，比如最常用的Docker。編排與調度是云原生的基石，是貫徹容器到服務實例的橋梁，其中Kubernetes 已成為事實標準。

微服務包括服務治理工具與編排調度服務。服務治理體系目前包括MicroService 與ServiceMesh，以及其中采用的一系列開源工具，如ZK、API網關等。

Serverless 構建服務形態，包括一系列產品，其中Lambda等注冊平臺比較成熟，開源產品則剛剛起步。

這些技術可用于構建容錯性好、易于管理和便于觀察的松耦合系統，讓應用處于待發布狀態，從而解決環境一致性問題。

2 云應用模型分類及云原生應用

如圖2 所示，云應用模型分為IaaS、PaaS、Serverless及SaaS。

圖2 云應用模型分類示意

IaaS 環境中，云服務提供商提供網絡、存儲、服務器及虛擬化，開發者則負責操作系統、中間件、運行時環境、數據及應用；PaaS 環境中，云服務提供商提供網絡、存儲、服務器、虛擬化、操作系統、中間件及運行時環境，開發者則僅需負責數據及應用；Serverless 環境中，云服務提供商提供網絡、存儲、服務器、虛擬化、操作系統、中間件、運行時環境及數據，而開發者則僅負責應用；SaaS 環境中，從網絡、存儲、服務器、虛擬化、操作系統、中間件、運行時環境、數據到應用均由云服務提供商提供。

一般認為IaaS 型應用屬于從物理機環境直接遷移到虛擬機環境的云遷移應用，其開發、部署、管理和運維方式與傳統應用類似，并非真正的云原生應用。其余3類應用才是具備敏捷交付和高度自動化管理能力的真正云原生應用。

目前云原生應用典型的應用交付方式包括代碼式交付、鏡像式交付、腳本式交付和應用包交付?；贙ubernetes 的PaaS 平臺大多支持上述4 種應用交付方式。

3 云原生成熟度模型

云原生架構關鍵架構維度用SESORA 表示，即服務化能力（Service）+彈性能力（Elasticity）+無服務器化程度（Serverless）+可觀測性（Observability）+韌性能力（Resilience）+自動化能力（Automation）。關鍵指標維度和云原生架構成熟度等級分別如表1和表2所示。

表1 關鍵指標維度

表2 云原生架構成熟度等級

云原生成熟度評估包括2 個步驟：第一，根據SESORA 對6 個維度分別評分并匯總；第二，根據分值分段獲得評分結果。

對某運營商IT 應用進行云原生成熟度評估后，發現其成熟度較低，具有很大演進空間。

4 運營商IT系統上云需求

運營商IT 系統目前存在資源利用率低、運維成本高、管理復雜、部署耗時久、開發與生產運維割裂等問題。前期采用SOA 架構進行改造的效果并不理想，采用微服務化的架構方式及容器化的承載、運維模式更符合互聯網化技術發展演進和企業發展趨勢。

云原生核心特點是應用容器化封裝、編排和交付、微服務設計、研發運營一體化。云原生應用將給運營商帶來應用的敏捷構建和迭代、更順暢的多團隊協作以及更高效的云資源利用。微服務是把一個單體項目拆分為多個微服務，每個微服務可以獨立技術選型、獨立開發、獨立部署、獨立運維，并且多個服務相互協調、相互配合，最終完成用戶的價值。微服務架構是一種松耦合、去中心化的架構模式。大部分大型網站系統如Twitter、Netflix、Amazon 和eBay 都已經從傳統整體型架構遷移到微服務架構。

為了降低開發成本、提升軟件生產率，云原生和微服務已成為軟件架構的發展趨勢。軟件部署架構從單機到分布式再到云原生，軟件組件可通過API 按需調用，從而實現了基礎設施的自動化以及快速的軟件交付。軟件系統架構也經歷了從單體架構到SOA再到微服務的架構演進，實現了服務的原子特性，可以更加靈活地獨立開發和部署。

IT 系統主要包括互聯網類、OLTP、OLAP、后臺數據處理、大數據交互等不同應用類別，上云的技術特點也各有不同（見圖3）。

圖3 各類型IT系統上云技術實現示意

a）互聯網業務。異構且技術棧眾多，關鍵應用需容器化部署，架構易水平擴展，需著重考慮業務的安全隔離問題。

b）OLTP 業務。需實現集群多租戶共享及應用容器化部署。

c）OLAP 分析報表業務。數據庫采用PostgreSQL數據庫進行替代，支持資源動態擴縮容。

d）后臺數據處理。密集計算以物理機為主，數據庫根據場景可以選擇PostgreSQL、TeleDB、時序數據庫等組件。

e）數據交互類。需實現應用容器化及動態伸縮。

f）公共基礎類。平遷到運營商云資源池的虛機或物理機上進行部署。

運營商IT 系統上云有兩大技術目標：第一，打造敏捷IT，提升交付效率與質量；第二，實現智慧IT，提升智能彈性計算能力、智能運維能力。云原生是云服務商、互聯網企業、系統集成商、通信運營商等共同定義和遵循的應用開發、交付、運營范式，是今后云計算的主流技術方向。因此運營商IT 全面上云需參考和推廣云原生應用。

5 運營商IT系統云原生部署方案

5.1 目標架構

運營商IT 系統總體向“平臺+應用”架構逐步演進，采用微服務架構，能力微服務化，統一編排、高效復用。運營商IT 系統云原生目標架構自底向上包括基于容器的不可變基礎設施層、中間件層、能力層、微服務層、應用層以及安全管理和運營監控（見圖4）。

圖4 運營商IT系統云原生目標架構

5.2 演進路徑

云原生落地需基于業務敏捷性、健壯性逐步實施（見圖5）。

圖5 云原生演進路徑

最初，基礎設施云化為上層應用提供計算、網絡、存儲基礎架構資源。然后，構建PaaS 平臺實現Devops：通過容器+微服務+Devops，構建應用架構不斷迭代更新的循環。最后，實現微服務治理及API運營：復雜業務分拆、松耦合，獨立更新部署，管理及流程自動化，基于API實現分布式集成管理和流程自動化。

5.3 部署要點

為實現上述IT 系統云原生目標架構，需從構建不可變基礎設施、下沉中間件統一開放服務化接口、采用微服務框架構建軟件系統以及軟件系統架構分層解耦幾個方面分別考慮部署要點。

5.3.1 構建基于容器的不可變基礎設施

不可變基礎設施里的“不可變”和程序設計中的“不可變”概念類似。程序設計中的不可變變量在完成賦值后就不能再更改，只能創建新的不可變變量來整體替換舊的。由于該特性，并發環境下也可以安全地使用變量。對于基礎設施的不可變性，最基本的就是指運行服務的服務器在完成部署后，就不再進行更改。

在構建云原生時，要實現不可變基礎設施，需從以下幾點著手。

a）使用云基礎設施作為構建基礎。標準化的敏捷基礎設施通過服務化的方式對外開放，并對應用用量進行統計。底層基礎設施根據容器和PaaS 中間件要求進行配置和擴容，硬件配置整體保持穩定、不允許修改，通過更新模板和實例實現運行環境的變更。

b）通過容器技術來打包及整體構建服務運行環境。軟件系統不直接操作底層基礎設施，而是通過業務性能指標提交具體需求，使用IaC、工具、API 方式進行配置和部署。

c）實現容器鏡像的自動化構建及版本化管理。軟件系統可根據通用模板定制鏡像運行應用，對模板有更新需求時統一提交申請。所有應用通過鏡像進行發布、構建，按照統一的DevOps流程自動化構建、自動化測試、自動化發布，不允許定制發布。

d）通過持續部署系統，實現自動化部署。資源統一觀測和管控，根據業務運行情況和應用配置自動伸縮。

5.3.2 下沉中間件，統一開放服務化接口

中間件處于系統軟件（操作系統和網絡軟件）與應用軟件之間，它能使應用軟件進行跨網絡的協同工作。中間件為應用軟件提供了操作系統所提供的服務之外的服務，可以將其描述為“軟件膠水”。中間件能夠讓軟件開發者方便地處理通信、輸入和輸出，專注在應用本身。中間件包括消息中間件、分布對象中間件、遠程過程調用中間件、數據訪問中間件、事務處理中間件等。

a）將標準中間件下沉到云基礎設施（容器、裸金屬容器），成為云原生服務的一部分。

b）對中間件進行服務化改造，提供標準調用規范。

c）應用與中間件解耦，不感知中間件的存在，通過API服務的方式使用中間件能力。

d）中間件統一運維管理，可感知應用狀態，實現計算和存儲能力的自動伸縮。

e）引用標準鏡像方式，實現虛擬機和裸金屬的標準化安裝，根據應用要求實現自動化部署。

應用軟件根據業務要求提出性能、網絡、負載均衡等業務指標要求，硬件評估和擴容由不可變基礎設施統籌管理。

5.3.3 采用微服務框架構建軟件系統

采用微服務框架構建軟件系統需考慮微服務能力抽取、能力分層、能力構建、能力調用和能力編排等幾個方面。

a）微服務能力抽取。主要包括面向客戶操作的邏輯控制抽取能力和面向數據存儲、計算的對象操作抽取能力。在領域層（軟件所關注的主題區域）以單個、場景化的能力為主抽取，微服務不能超過單一職責。

b）能力分層。區分場景和業務原子化能力，構建可復用的原子化能力。復雜邏輯按照業務需求基于原子服務組合能力在應用層實現。

c）能力構建。原子化能力以完成業務的最小操作為目標，需要具備冪等性（任意多次執行所產生的影響均與一次執行的影響相同）；事務能力需要同時提供DO/UNDO 2種，以保障事務一致性。

d）能力調用。面向客戶UI 操作的能力要同步調用，如果異步則需要考慮調用過程可視；事務型業務能力調用要按照統一監控要求自動埋點，跟蹤標識業務流程；面向后端邏輯處理的能力盡量異步，并提供失敗重試機制。

e）能力編排。面向能力規格、能力對象進行能力調用時要設定優先級，以便在資源緊張時優先保障重點客戶的重點業務。

此外，在部分業務場景，微服務還需逐步按需引入Serverless、服務網格（Service Mesh）技術。

Serverless 可以細分為后端即服務（BaaS）和函數即服務（FaaS）2 類。BaaS 指任何第三方提供的應用和服務，可通過API的形式開放不同細分領域的功能，比如提供云數據庫服務的Google Firebase 和Parse、提供統一用戶身份驗證服務的Auth0 等，讓用戶實現“前端+BaaS”完成整體服務的構建。FaaS 應用以函數的形式存在，并由第三方云平臺托管運行，函數是比微服務更小更獨立的運行單元。應用軟件開發業務邏輯，注冊觸發事件，通過事件觸發函數邏輯并執行，后端服務通過調用下沉的中間件服務實現，資源管控由基礎設施統一提供。根據需求，應用形態可選擇服務形態和函數形態。

作為云原生技術棧的一部分，Service Mesh指由云原生應用的服務化組件構成的一種網格，即在應用內部或者應用之間由服務訪問、調用、負載均衡等服務連接關系構成的一種網絡。Istio 是目前Service Mesh技術的實施標準，是一個與Kubernetes 緊密結合的、適用于云原生場景的、Service Mesh 形態的、用于服務治理的開放平臺。Istio服務治理涉及連接、安全、策略執行和可觀察性。在實踐中，Service Mesh通常以輕量級網絡代理陣列的形式實現，這些代理與應用程序代碼部署在一起，應用程序無需感知代理的存在。

將業務能力、數據能力等能力微服務化，可實現統一編排、高效復用。

5.3.4 軟件系統架構分層解耦

基于分層解耦原則，軟件系統采用微服務化架構建設，將業務實現與底層能力構建分離，屏蔽外部變化對業務核心服務能力的影響。軟件系統根據本系統的業務特征劃分領域構建原子能力，根據層次結構構建功能。每一層設計保持內聚，并且只依賴其下層，上層和下層松散耦合（各自為獨立個體，通過簡單引用關聯）。

采用微服務架構的軟件系統分層包括表示層、網關層、應用層、領域層、中間件層以及基礎設施層。如前文所述，中間件層和基礎設施層由不可變基礎設施和統一開放服務化接口的下沉中間件提供。軟件系統以領域層為核心構建微服務原子能力。

6 云原生對運營商的意義

云原生對運營商具有重大意義，具體如下。

a）避免軟件廠商的綁架?；谖⒎盏募軜嫿怦钍沟密浖到y從黑盒變為白盒，核心微服務自主掌控；通過定義統一的微服務交互接口，支持實現同一功能的微服務的可替換。

b）支持軟件系統的全網統一部署。構建集團級容器鏡像庫，通過軟件鏡像的統一下發，實現軟件系統的集約管理；支持以微服務為單位的軟件升級，降低系統運維壓力。

c）助推業務應用創新。容器和微服務可用于支持PaaS 平臺的能力開放，實現云服務的增值；容器和微服務有效支持持續集成和交付，加速業務上線。

7 結束語

云原生具備快速交付、容器運行、可靠容錯、靈活擴展、自動伸縮、透明通信等特點。本文分析了云原生的關鍵技術，對云應用進行模型分類并定義了云原生應用，給出了云原生成熟度模型及評估辦法，進而結合運營商IT系統上云的需求，闡述了運營商IT系統云原生目標架構及部署要點，包括構建基于容器的不可變基礎設施，實現自動化部署、動態擴縮容；下沉中間件，統一開放服務化接口；采用微服務框架構建軟件系統；軟件系統架構分層解耦等。

運營商IT 系統云原生部署便于運營商自主掌控核心微服務、構建容器鏡像庫、匯聚全網原子能力池，沉淀數據資產。一方面，可將云網資源及能力通過服務的方式提供給數字化平臺，并支持多種服務模式和靈活的商業模式；另一方面，數字化平臺可以通過云網基礎設施提供的云原生開發能力，靈活構建更高層次的數字化能力并面向行業提供數字化解決方案。