談談我對零售雲在雲原生總結與思考

簡介： 雲原生是零售雲的最重要的技術底座，雲原生是什麼，會走向哪裏，在零售2B交付的場景上該如何應用，怎麼可以結合幫助建設零售雲系列產品體系，值得咱們的思考和探索，也將有效指導咱們接下來幾年的零售雲項目和產品建設。

零售雲是阿里三朵業務雲：零售雲、金融雲和政務雲之一，將開闢阿里在電商、零售行業的新藍海，2B快速交付、賦能合做夥伴更快業務增加和節省成本。雲原生是零售雲的最重要的技術底座，雲原生是什麼，會走向哪裏，在零售2B交付的場景上該如何應用，怎麼可以結合幫助建設零售雲系列產品體系，值得咱們的思考和探索，也將有效指導咱們接下來幾年的零售雲項目和產品建設。

雲原生定義、阿里巴巴雲原生架構方法論及產品體系

雲原生定義

Cloud Native 翻譯爲雲原生，是 Matt Stine 提出的一個概念，它是一個思想的集合，包括 DevOps 、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。Cloud Native 既包含技術（微服務，敏捷基礎設施），也包含管理（DevOps，持續交付，康威定律，重組等）。Cloud Native 也能夠說是一系列技術、企業管理方法的集合。

雲原生的本質

雲原生本質是以應用爲中心，讓應用能最大限度享受到雲計算的紅利。雲原生是雲計算的下一站，雲原生架構是引領將來十年的新一代技術架構。雲原生讓雲計算變得標準、開放、簡單高效、觸手可及。

雲原生應用開發的最佳實踐原則：12-Factor

一、 基準代碼：一份基準代碼（Codebase），多份部署（deploy）

基準代碼和應用之間老是保持一一對應的關係，一份代碼能夠部署在開發環境、測試環境、預發環境及產線環境。

多個應用共享一份基準代碼是有悖於 12-Factor 原則的。解決方案以下：

將共享的代碼拆分爲獨立的類庫，而後使用依賴管理策略去加載它們。全部部署的基準代碼相同，但每份部署可使用其不一樣的版本。好比，開發人員可能有一些提交尚未同步至預發佈環境；預發佈環境也有一些提交沒有同步至生產環境。但它們都共享一份基準代碼，咱們就認爲它們只是相同應用的不一樣部署而已。

二、 依賴——顯式聲明依賴關係（Dependency）

12-Factor 規則下的應用程序不會隱式依賴系統級的類庫。它必定經過依賴清單，確切地聲明全部依賴項。大多數編程語言都會提供一個打包系統，好比 java 使用 maven ，應用依賴了哪些第三方庫，要顯示地定義在 POM 文件裏。

三、 配置：在環境中存儲配置

配置要和代碼徹底分離，環境變量能夠很是方便地在不一樣的部署間作修改，卻不動一行代碼。配置主要包括數據庫信息，緩存信息，第三方服務證書，每份部署特有的配置，如域名等信息。

判斷一個應用是否正確地將配置排除在代碼以外，一個簡單的方法，看該應用的基準代碼是否能夠馬上開源，而不用擔憂會暴露任何敏感的信息。

四、 後端服務：把後端服務看成附加資源

後端服務是指程序運行所須要的經過網絡調用的各類服務，如數據庫，消息系統及緩存系統。

12-Factor 應用的任意部署，都應該能夠在不進行任何代碼改動的狀況下，進行後端服務的切換，好比將本地 MySQL 數據庫換成第三方服務（例如阿里雲的 RDS）。另外，部署能夠按需加載或卸載資源。例如，若是應用的數據庫服務因爲硬件問題出現異常，管理員能夠從最近的備份中恢復一個數據庫，卸載當前的數據庫，而後加載新的數據庫 。整個過程都不須要修改代碼。

五、 構建->發佈->運行：嚴格分離構建和運行

基準代碼 轉化爲一份部署(非開發環境)須要如下三個階段：

構建階段，將代碼倉庫轉化爲可執行包的過程。構建時會使用指定版本的代碼,獲取和打包依賴項,編譯成二進制文件和資源文件。

發佈階段，將構建的結果和當前部署所需配置相結合，並可以馬上在運行環境中投入使用。

運行階段(「運行時」)，針對選定的發佈版本，在執行環境中啓動一系列應用程序進程。

每個發佈版本必須對應一個惟一的發佈 ID,一旦發佈就不可修改，任何的變更都應該產生一個新的發佈版本。另外，發佈管理工具須要能方便的回退至較舊的發佈版本。

六、 進程：以一個或多個無狀態進程運行應用

運行環境中，應用程序一般是以一個和多個進程運行的。12-Factor應用的進程必須無狀態且無共享，任何須要持久化的數據都要存儲在後端服務內，好比數據庫或緩存。

七、 端口綁定：經過端口綁定提供服務

12-Factor應用徹底自我加載，而不依賴於任何網絡服務器就能夠建立一個面向網絡的服務。互聯網應用經過端口綁定來提供服務，並監聽發送至該端口的請求。好比，在線上環境中，請求統一發送至公共域名，而後路由至綁定了端口的網絡進程。

八、 併發：經過進程模型進行擴展

在 12-factor 應用中，進程是一等公民。12-Factor 應用的進程主要借鑑於 unix 守護進程模型 。開發人員能夠運用這個模型去設計應用架構，將不一樣的工做分配給不一樣的進程類型。例如，HTTP 請求能夠交給web進程來處理，而常駐的後臺工做則交由 worker進程負責。

九、 易處理：快速啓動和優雅終止可最大化健壯性

12-Factor 應用的進程是易處理的，即它們能夠瞬間開啓或中止。這有利於快速、彈性的伸縮應用，迅速部署變化的代碼或配置，穩健的部署應用。

進程應當追求最小啓動時間，而且一旦接收到終止信號（SIGTERM），能夠優雅的終止。進程還應當在面對忽然死亡時保持健壯，例如底層硬件故障。不管如何，12-Factor應用都應該能夠設計可以應對意外的、不優雅的終結。

十、 開發環境與線上環境等價：儘量的保持開發，預發佈，線上環境相同

12-Factor 應用的開發人員應該避免在不一樣環境間使用不一樣的後端服務，即便適配器已經能夠幾乎消除使用上的差別。這是由於，不一樣的後端服務意味着會忽然出現的不兼容，從而致使測試、預發佈都正常的代碼在線上出現問題。這些錯誤會給持續部署帶來阻力。從應用程序的生命週期來看，消除這種阻力須要花費很大的代價。

十一、 日誌：把日誌看成事件流

12-factor 應用自己從不考慮存儲本身的輸出流。不該該試圖去寫或者管理日誌文件。相反，每個運行的進程都會直接的標準輸出（stdout）事件流。開發環境中，開發人員能夠經過這些數據流，實時在終端看到應用的活動。

十二、 管理進程:後臺管理任務看成一次性進程運行

一次性管理進程主要指一些管理或維護應用的一次性任務，好比，運行數據遷移，運行一些提交到代碼倉庫的一次性腳本等。它們應該和正常的常駐進程使用一樣的環境。這些管理進程和任何其餘的進程同樣使用相同的代碼和配置，基於某個發佈版本運行。後臺管理代碼應該隨其餘應用程序代碼一塊兒發佈，從而避免同步問題。

以上了解了 12-Factor 應用原則。在咱們學習 K8s 的過程當中，我的認爲 K8s 結合service mesh 很好的知足了上面的每條原則。設計 K8s 和 ServiceMesh 的人很偉大，提出 12 原則的 AdamWiggins 很偉大。

阿里巴巴雲原生架構方法論

阿里巴巴雲原生架構設計方法

阿里巴巴獨有的雲原生架構設計方法——ACNA（Alibaba Cloud Native Architecting）以下：

ACNA 是一個 「4+1」 的架構設計流程，「4」 表明架構設計的關鍵視角，包括企業戰略視角、業務發展視角、組織能力視角和雲原生技術架構視角；「1」 表示雲原生架構的架構持續演進閉環。

值得一提的是，ACNA 除了是一個架構設計方法，也包含了對雲原生架構的評估體系、成熟度衡量體系、行業應用最佳實踐、技術和產品體系、架構原則、實施指導等。

另外，雲原生架構演進是一個持續迭代的過程，每一次迭代都是從企業戰略、業務訴求到架構設計與實施的一個完整閉環，總體關係以下圖：

阿里巴巴雲原生成熟度模型

由 於 雲 原 生 架 構 包 含 了 6 個 關 鍵 架 構 維 度（ 簡 寫 爲 SESORA，Service + Elasticity + Serverless + Observability + Resilience + Automation），所以咱們先定義關鍵維度的成熟度級別：

阿里巴巴雲原生產品體系

阿里巴巴雲原生產品家族包括容器產品家族、微服務產品家族、Serverless 產品家族、Service Mesh 產品家族、消息產品、雲原生數據庫家族、雲原生大數據產品家族等。

一、容器產品家族

二、微服務產品家族

EDAS（企業分佈式應用服務）是一個面向微服務應用的應用全生命週期 PaaS 平臺，產品全面支持 HSF、Dubbo、Spring Cloud 技術體系，提供 ECS 集羣和 K8s 集羣的應用開發、部署、監控、運維等全棧式解決方案。

MSE（微服務引擎）是一個面向業界主流開源微服務框架 Spring Cloud、Dubbo 的微服務平臺， 包含治理中心、託管註冊 / 配置中心，一站式的解決方案幫助用戶提高微服務的開發效率和線上穩定性。

ACM（應用配置管理），是一款應用配置中心產品，實如今微服務、DevOps、大數據等場景下的 分佈式配置服務，保證配置的安全合規。

CSB Micro Gateway（微服務網關服務）針對微服務架構下 API 開放的特色，提供能與微服務環 境的治理策略無縫銜接的網關服務，實現高效的微服務 API 開放。

GTS（全局事務服務）用於實現分佈式環境下特別是微服務架構下的高性能事務一致性，能夠與多種數據源、微服務框架配合使用，實現分佈式數據庫事務、多庫事務、消息事務、服務鏈路級事務及各類組合。

ARMS（應用實時監控服務 ) 是一款應用性能管理產品，包含前端監控、應用監控和 Prometheus 監控三大子產品，涵蓋了瀏覽器、小程序、APP、分佈式應用和容器環境等性能管理，實現全棧式性能監控和端到端全鏈路追蹤診斷。鏈路追蹤（Tracing Analysis）爲分佈式應用的開發者提供了完整的調用鏈路還原、調用請求量統計、 鏈路拓撲、應用依賴分析等工具，可以幫助開發者快速分析和診斷分佈式應用架構下的性能瓶頸，提升 微服務時代下的開發診斷效率。

PTS（Performance Testing Service）是一款雲化測試工具，提供性能測試、API 調試和監測 等多種能力，緊密結合監控、流控等產品提供一站式高可用能力，高效檢驗和管理業務性能。

三、Serverless 產品家族

FC（函數計算）是一個事件驅動的全託管 Serverless 計算服務，用戶無需管理服務器等基礎設施， 只需編寫代碼並上傳，函數計算會準備好計算資源，並以彈性、可靠的方式運行業務代碼。

SAE（Serverless 應用引擎）實現了 Serverless 架構 + 微服務架構的完美融合，真正按需使用、按量計費，節省閒置計算資源，同時免去 IaaS 運維，有效提高開發運維效率；SAE 支持 Spring Cloud、Dubbo 和 HSF 等流行的微服務架構。

Serverless 工做流是一個用來協調多個分佈式任務執行的全託管 Serverless 雲服務，致力於簡化開發和運行業務流程所須要的任務協調、狀態管理以及錯誤處理等繁瑣工做，讓用戶聚焦業務邏輯開發。用戶能夠用順序、分支、並行等方式來編排分佈式任務，服務會按照設定好的順序可靠地協調任務執行， 跟蹤每一個任務的狀態轉換，並在必要時執行用戶定義的重試邏輯，以確保工做流順利完成。

四、Service Mesh產品家族

服務網格（ASM）提供全託管的微服務應用流量管理平臺，兼容 Istio 的同時，支持多個 Kubernetes 集羣中應用的統一流量管理，爲容器和虛擬機中應用服務提供一致的通訊、安全和可觀測能力。

AHAS（應用高可用服務）是專一於提升應用及業務高可用的工具平臺，目前主要提供應用架構探測感知，故障注入式高可用能力評測和流控降級高可用防禦三大核心能力，經過各自的工具模塊能夠快 速低成本的在營銷活動場景、業務核心場景全面提高業務穩定性和韌性。

五、消息產品家族

消息隊列 RocketMQ 版是阿里雲基於 Apache RocketMQ 構建的低延遲、高併發、高可用、高可 靠的分佈式消息中間件。該產品最初由阿里巴巴自研並捐贈給 Apache 基金會，服務於阿里集團 13 年， 覆蓋全集團全部業務，支撐千萬級併發、萬億級數據洪峯，歷年刷新全球最大的交易消息流轉記錄。

消息隊列 Kafka 版是阿里雲基於 Apache Kafka 構建的高吞吐量、高可擴展性的分佈式消息隊列服 務，普遍用於日誌收集、監控數據聚合、流式數據處理、在線和離線分析等，是大數據生態中不可或缺 的產品之一，阿里雲提供全託管服務，用戶無需部署運維，更專業、更可靠、更安全。

消息隊列 AMQP 版由阿里雲基於 AMQP 標準協議自研，徹底兼容 RabbitMQ 開源生態以及多語 言客戶端，打造分佈式、高吞吐、低延遲、高可擴展的雲消息服務。

微消息隊列 MQTT 版是專爲移動互聯網 (MI)、物聯網 (IoT) 領域設計的消息產品，覆蓋互動直播、 金融支付、智能餐飲、即時聊天、移動 Apps、智能設備、車聯網等多種應用場景；經過對 MQTT、 WebSocket 等協議的全面支持，鏈接端和雲之間的雙向通訊，實現 C2C、C2B、B2C 等業務場景之 間的消息通訊，可支撐千萬級設備與消息併發，真正作到萬物互聯。

阿里雲消息服務 MNS 是一種高效、可靠、安全、便捷、可彈性擴展的分佈式消息服務 , 可以幫助應 用開發者在他們應用的分佈式組件上自由的傳遞數據、通知消息，構建鬆耦合系統。

事件總線 EventBridge 是阿里雲提供的一款無服務器事件總線服務，支持阿里雲服務、自定義應用、 SaaS 應用以標準化、中心化的方式接入，並可以以標準化的 CloudEvents 1.0 協議在這些應用之間路 由事件，幫助用戶輕鬆構建鬆耦合、分佈式的事件驅動架構。

六、數據庫產品家族

PolarDB 是阿里巴巴自主研發的下一代關係型分佈式雲原生數據庫，目前兼容三種數據庫引擎：MySQL、PostgreSQL、高度兼容 Oracle 語法；計算能力最高可擴展至 1000 核以上，存儲容量最高 消息產品家族 雲原生數據庫產品家族 6 7 The Cloud-native Architecture White Paper by Alibaba Cloud 50 可達 100T。PolarDB 通過阿里巴巴雙十一活動的最佳實踐，讓用戶既享受到開源的靈活性與價格，又享受到商業數據庫的高性能和安全性。

PolarDB-X（原 DRDS 升級版）是由阿里巴巴自主研發的雲原生分佈式數據庫，融合分佈式 SQL 引擎 DRDS 與分佈式自研存儲 X-DB，專一解決海量數據存儲、超高併發吞吐、大表瓶頸以及複雜計算效率等數據庫瓶頸難題，歷經各屆天貓雙 11 及阿里雲各行業客戶業務的考驗，助力企業加速完成業務數字化轉型。

七、大數據產品家族

雲原生數據倉庫 AnalyticDB MySQL 版（簡稱 ADB，原分析型數據庫 MySQL 版）是一種支持 高併發低延時查詢的新一代雲原生數據倉庫，全面兼容 MySQL 協議以及 SQL:2003 語法標準，能夠對 海量數據進行即時的多維分析透視和業務探索，快速構建企業雲上數據倉庫。產品規格按需可選，基礎 版成本最低，適合 BI 查詢應用；集羣版提供高併發數據實時寫入和查詢能力，適用於高性能應用；彈性 模式版本存儲廉價按量計費，適用於 10TB 以上數據上雲場景。

雲原生數據倉庫 AnalyticDB PostgreSQL 版，支持標準 SQL 2003，兼容 PostgreSQL / Greenplum, 高度兼容 Oracle 語法生態；具備存儲計算分離，在線彈性平滑擴容的特色；既支持任意 維度在線分析探索，也支持高性能離線數據處理；是面向互聯網，金融，證券，保險，銀行，數字政務， 新零售等行業有競爭力的數據倉庫方案。

雲原生幾個核心技術和將來發展趨勢

1. 容器

容器做爲標準化軟件單元，它將應用及其全部依賴項打包，使應用再也不受環境限制，在不一樣計算環境間快速、可靠地運行。

隨後開源的 Kubernetes，憑藉優秀的開放性、可擴展性以及活躍開發者社區，在容器編排之戰中脫穎而出，成 爲分佈式資源調度和自動化運維的事實標準。Kubernetes 屏蔽了 IaaS 層基礎架構的差別並憑藉優良的可移植性， 幫助應用一致地運行在包括數據中心、雲、邊緣計算在內的不一樣環境。企業能夠經過 Kubernetes，結合自身業務特 徵來設計自身雲架構，從而更好支持多雲 / 混合雲，免去被廠商鎖定的顧慮。伴隨着容器技術逐步標準化，進一步促進了容器生態的分工和協同。基於 Kubernetes，生態社區開始構建上層的業務抽象，好比服務網格 Istio、機器學 習平臺 Kubeflow、無服務器應用框架 Knative 等。

Kubernetes 已經成爲容器編排的事實標準，被普遍用於自動部署，擴展和管理容器化應用。Kubernetes 提 供了分佈式應用管理的核心能力：

資源調度：根據應用請求的資源量 CPU、Memory，或者 GPU 等設備資源，在集羣中選擇合適的節點來運 行應用；

應用部署與管理：支持應用的自動發佈與應用的回滾，以及與應用相關的配置的管理；也能夠自動化存儲卷 的編排，讓存儲卷與容器應用的生命週期相關聯；

自動修復：Kubernetes 能夠會監測這個集羣中全部的宿主機，當宿主機或者 OS 出現故障，節點健康檢查 會自動進行應用遷移；K8s 也支持應用的自愈，極大簡化了運維管理的複雜性；

服務發現與負載均衡：經過 Service 資源出現各類應用服務，結合 DNS 和多種負載均衡機制，支持容器化 應用之間的相互通訊；

彈性伸縮：K8s 能夠監測業務上所承擔的負載，若是這個業務自己的 CPU 利用率太高，或者響應時間過長， 它能夠對這個業務進行自動擴容。

Kubernetes 的控制平面包含四個主要的組件：API Server、Controller、Scheduler 以及 etcd。以下圖：

2. 微服務

微服務四代架構演進：

第一代

第一代微服務架構中，應用除了須要實現業務邏輯以外，還須要自行解決上下游尋址、通信，以及容錯等問題。隨着微服務規模擴大，服務尋址邏輯的處理變得愈來愈複雜，哪怕是同一編程語言的另外一個應用，上述微服務的基礎能力都須要從新實現一遍。

第二代

第二代微服務架構中，引入了旁路服務註冊中心做爲協調者來完成服務的自動註冊和發現。服務之間的通信以及容錯機制開始模塊化，造成獨立服務框架。可是隨着服務框架內功能日益增多，用不一樣語言的基礎功能複用顯得十分困難，這也就意味着微服務的開發者被迫被綁定在某種特定語言上，從而違背了微服務的敏捷迭代原則。

第三代

2016 年出現了第三代微服務架構 - 服務網格，原來被模塊化到服務框架裏的微服務基礎能力，被進一步的從一 個 SDK 演進成爲一個獨立進程 - Sidecar。這個變化使得第二代架構中多語言支持問題得以完全解決，微服務基礎 能力演進和業務邏輯迭代完全解耦。這個架構就是在雲原生時代的微服務架構 - Cloud Native Microservices，邊車（Sidecar）進程開始接管微服務應用之間的流量，承載第二代中服務框架的功能，包括服務發現、調用容錯，到豐富的服務治理功能，例如：權重路由、灰度路由、流量重放、服務假裝等。

第四代

近兩年開始，隨着 AWS Lambda 的出現，部分應用開始嘗試利用 Serverless 來架構微服務，這種方式被稱之爲第四代微服務架構。在這個架構中，微服務進一步由一個應用簡化爲微邏輯（Micrologic），從而對邊車模式提出了更高訴求，更多可複用的分佈式能力從應用中剝離，被下沉到邊車中，例如：狀態管理、資源綁定、鏈路追蹤、事務管理、安全等等。同時，在開發側開始提倡面向 localhost 編程的理念，提供標準 API 屏蔽掉底層資源、服務、 基礎設施的差別，進一步下降微服務開發難度。這個也就是目前業界提出的多運行時微服務架構（Muti-Runtime Microservices）。

OAM

2019 年底，阿里雲聯合微軟共同發佈了 Open Application Model (OAM) 開源項目，其主要目標是解決從 Kubernetes 項目到「以應用爲中心」的平臺之間最關鍵環節——標準化應用定義。

OAM 的第一個設計目標就是補充「應用」這一律念，創建對應用和它所需的運維能力定義與描述的標準 規範。換而言之，OAM 既是標準「應用定義」同時也是幫助封裝、組織和管理 Kubernetes 中各類「運維能力」。

OAM 項目的第二個設計目標就是提供更高層級的應用層抽象和以應用關注點分離的定義模型。

相 比 於 傳 統 PaaS 封 閉、 不 能 同「 以 Operator 爲 基 礎 的 雲 原 生 生 態」 銜 接 的 現 狀， 基 於 OAM 和 Kubernetes 構建的現代雲原生應用管理平臺的本質是一個「以應用爲中心」的 Kubernetes，保證應用平臺可以無縫接入整個雲原生生態。同時，OAM 進一步屏蔽掉容器基礎設施的複雜性和差別性，爲平臺使用者帶來低心智負擔的、標準化的、一致化的應用管理與交付體驗，讓一個應用描述能夠徹底不加修改的在雲、邊、端等任何環境下直接交付運行起來。

無狀態服務Serverless

當 BaaS 雲服務日趨完善時，Serverless 由於屏蔽了服務器的各類運維複雜度，讓開發人員能夠將 更多精力用於業務邏輯設計與實現，而逐漸成爲雲原生主流技術之一。Serverless 計算包含如下特徵：

全託管的計算服務，客戶只須要編寫代碼構建應用，無需關注同質化的、負擔繁重的基於服務器等基礎設施 的開發、運維、安全、高可用等工做；

通用性，結合雲 BaaS API 的能力，可以支撐雲上全部重要類型的應用；

自動的彈性伸縮，讓用戶無需爲資源使用提早進行容量規劃；

按量計費，讓企業使用成本得有效下降，無需爲閒置資源付費。

服務網格Service Mesh

Service Mesh 是分佈式應用在微服務軟件架構之上發展起來的新技術，旨在將那些微服務間的鏈接、安全、流 量控制和可觀測等通用功能下沉爲平臺基礎設施，實現應用與平臺基礎設施的解耦。這個解耦意味着開發者無需關注 微服務相關治理問題而聚焦於業務邏輯自己，提高應用開發效率並加速業務探索和創新。換句話說，由於大量非功能 性從業務進程剝離到另外進程中，Service Mesh 以無侵入的方式實現了應用輕量化。

Service Mesh的典型架構：

Service A 調用 Service B 的全部請求，都被其下的 Proxy（在 Envoy 中是 Sidecar） 截獲， 代理 Service A 完成到 Service B 的服務發現、熔斷、限流等策略，而這些策略的總控是在 Control Plane 上配置。

行業現狀：Service Mesh 目前在市場仍處於早期採用 (Early adoption) 階段。除 Istio 之外，Google 與 AWS 分別推出了各自的雲服務 Traffic Director、 App Mesh。這兩個 Service Mesh 產品與 Istio 雖有所不一樣，但與 Istio 一樣地採納了 Envoy 做爲數據平面。此外，阿里雲、騰訊雲、華爲雲也 都推出了 Service Mesh 產品，一樣採用 Envoy 技術做爲數據面並在此基礎上提供了應用發佈、流量管控、APM 等能力。
DevOps

DevOps 就是爲了提升軟件研發效率，快速應對變化，持續交付價值的的一系列理念和實踐，其基本思想就是 持續部署（CD)，讓軟件的構建、測試、發佈可以更加快捷可靠，以儘可能縮短系統變動從提交到最後安所有署到生產 系統的時間。要實現持續部署（CD)，就必須對業務進行端到端分析，把全部相關部門的操做統一考慮進行優化，利用所可用的技術和方法，用一種理念來整合資源。DevOps 理念從提出到如今，已經深入影響了軟件開發過程。DevOps 提倡打破開發、測試和運維之間的壁壘，利用技術手段實現各個軟件開發環節的自動化甚至智能化，被證明對提升軟件生產質量、安全，縮短軟件發佈週期等都有很是明顯的促進做用，也推進了 IT 技術的發展。

DevOps四大原則：

文化（Culture）---要實施 DevOps，就首先要讓開發和運維人員認識到他們的目標是一致的，只是工做崗位不一樣，須要共擔責任。這就是 DevOps 須要首先在文化層面解 決的問題。只有解決了認知問題，才能打破不一樣團隊之間的鴻溝，實現流程自動化，把你們的工做融合成一體。

自動化（Automation）---DevOps 的持續集成的目標就是小步快跑，快速迭代，頻繁發佈。實施 DevOps，首先就要分析已有的軟件開發流程，儘可能利用各類工具和平臺，實現開發和發佈過程的自動化。通過多年發展，業界已經有一套比較成熟的工具鏈能夠參考和使用，不過具體落地還需因地制宜。

度量（Measurement）---經過數據能夠對每一個活動和流程進行度量和分析，找到工做中存在的瓶頸和漏洞以及對於危急狀況的及時報警等。經過分析，能夠對團隊工做和系統進行調整，讓效率改進造成閉環。度量首先要解決數據準確性、完整性和及時性問題，其次要創建正確的分析指標。DevOps 過程考覈的標準應該鼓勵團隊更加註重工具的建設，自動化的加速和各個環節優化，這樣才能最大可能發揮度量的做用。

共享（Sharing）--- 要實現真正的協做，還須要團隊在知識層面達成一致。經過共享知識，讓團隊共同進步：可見度 visibility：讓每一個人能夠了解團隊其它人的工做。這樣能夠知道是否某一項工做會影響另外一部分。經過相互反饋，讓問題儘早暴露。透明性 transparency：讓每一個人都明白工做的共同目標，知道爲何要幹什麼。缺少透明性就會致使工做安排失調。知識的傳遞 transfer of knowledge ：知識的傳遞是爲了解決兩個問題，一個是爲了不某我的成爲單點，從而致使一我的的休假或離職，就致使工做不能完成。另外一個是提升團隊的集體能力，團隊的集體能力要高於我的的能力。

雲原生將來發展趨勢

趨勢一：無處不在的計算催生新一代容器實現

隨着互聯網的發展到萬物智聯，5G、AIoT 等新技術的涌現，隨處可見的計算需求已經成爲現實。針對不一樣計算場景，容器運行時會有不一樣需求。KataContainer、Firecracker、gVisor、Unikernel 等新的容器運行時技術層出不窮，分別解決安全隔離性、執行效率和通用性三個不一樣維度的要求。OCI（Open Container Initiative）標準的出現，使不一樣技術採用一致的方式進行容器生命週期管理，進一步促進了容器引擎技術的持續創新。其中，咱們能夠預見如下幾個細分方向的將來趨勢：

基於 MicroVM 的安全容器佔比將逐漸增長，提供更強的安全隔離能力。虛擬化和容器技術的融合，已成爲將來重要趨勢。在公共雲上，阿里雲容器服務已經提供了對基於 KataContainer 的阿里雲的袋鼠容器引擎支持，能夠運行不可信的工做負載，實現安全的多租隔離。

基於軟硬一體設計的機密計算容器開始展露頭角。好比阿里雲安全、系統軟件、容器服務團隊以及螞蟻金服可信原生團隊共同推出了面向機密計算場景的開源容器運行時技術棧 inclavare-containers ，支持基於 Intel SGX 機密計算技術的機密容器實現，如螞蟻金服的 Occlum、開源社區的 Graphene 等 Libary OS。它極大下降了機密計算的技術門檻，簡化了可信應用的開發、交付和管理。

WebAssembly做爲新一代可移植、輕量化、應用虛擬機，在IoT，邊緣計算，區塊鏈等場景會有普遍的應用前景。WASM/WASI 將會成爲一個跨平臺容器實現技術。近期 Solo.io 推出的 WebAssembly Hub 就將 WASM 應用經過 OCI 鏡像標準進行統一管理和分發，從而更好地應用在 Istio 服務網格生態中。

趨勢二：雲原生操做系統開始浮現

Kubernetes 已經成爲雲時代的操做系統。對比 Linux 與 Kubernetes 的概念模型，他們都是定義了開放的、 標準化的訪問接口；向下封裝資源，向上支撐應用。

服務網格的技術發展上數據平面與控制平面間的協議標準化是必然趨勢。大致上，Service Mesh 的技術發展圍 繞着「事實標準」去展開——共建各雲廠商共同採納的開源軟件。從接口規範的角度：Istio 採納了 Envoy 所實現的 xDS 協議，將該協議看成是數據平面和控制平面間的標準協議；Microsoft 提出了 Service Mesh Interface（SMI）， 致力於讓數據平面和控制平面的標準化作更高層次的抽象，以期爲 Istio、Linkerd 等 Service Mesh 解決方案在服務觀測、流量控制等方面實現最大程度的開源能力複用。UDPA（Universal Data Plane API）是基於 xDS 協議而發展起來，以便根據不一樣雲廠商的特定需求便捷地進行擴展並由 xDS 去承載。

服務註冊發現和配置中心的功能主要致力於解決微服務在分佈式場景下的服務發現和分佈式配置管理兩個核心 問題。隨着雲原生技術的發展，服務發現領域出現了兩個趨勢，一個是服務發現標準化（Istio），一個是服務下沉 (CoreDNS)；配置管理領域也有兩個趨勢，一個是標準化（ConfigMap），一個是安全 (Secret)。

趨勢三：Serverless 容器技術逐漸成爲市場主流

Serverless 和 容 器 技 術 也 開 始 融 合 得 到 了 快 速 的 發 展。通 過 Serverless 容 器， 一 方 面 根 本 性 解 決 Kubernetes 自身複雜性問題，讓用戶無需受困於 Kubernetes 集羣容量規劃、安全維護、故障診斷等運維工做；一方面進一步釋放雲計算能力，將安全、可用性、可伸縮性等需求下沉到基礎設施實現。

趨勢四：動態、混合、分佈式的雲環境將成爲新常態

上雲已經是大勢所趨，但對於企業客戶而言，有些業務出於對數據主權、安全隱私的考量，會採用混合雲架構。一些企業爲了知足安全合規、成本優化、提高地域覆蓋性和避免雲廠商鎖定等需求，會選擇多個雲廠商。混合雲 / 多雲 架構已成爲企業上雲新常態。Gartner 指出，" 到 2021，超過 75% 的大中型組織將採用多雲或者混合 IT 戰略。"

阿里雲容器服務 ACK 去年 9 月份發佈了混合雲 2.0 架構，提供了完備的混合雲 Kubernetes 管理能力。

零售雲基於雲原生體系建設和挑戰

零售雲是雲原生應用實踐的良好土壤

CTO 魯肅提過：阿里經濟體是雲原生技術發展的最好土壤。而零售雲是阿里經濟體重要的一個分支，同時是阿里業務中臺對外輸出建設2B生態的重要戰略方向，因此零售雲無疑是雲原生應用發展實踐的極好土壤。當前，在這半年來實踐和應用了雲原生技術構建了產品-零售雲研發運營平臺（即雲上星環）。

服務化能力：商業能力API，商業能力二次開發SDK
彈性能力：站點PaaS部署發佈規劃建設中
自動化水平：一鍵拉起環境，一鍵部署平臺應用
可觀測性：一鍵日誌查詢和監控運維

零售雲基於雲原生的技術架構：

零售雲基於雲原生技術體系之上的分層架構：

零售雲DevOps實踐

研發運營平臺是零售雲的重要的研發、監控和運維一體化平臺，爲零售雲業務系統研發提供完整的 DevOps 解決方案。

零售雲基於雲原生的接下來規劃和挑戰

我的觀點，咱們須要基於阿里巴巴雲原生架構設計方法論：

1、組織視角

組織上須要從技術、業務和產品體系建設規劃好陣型，進行很好的排兵佈陣，須要更多的各領域的優秀人才加入建設，建議組織上重點須要內部各領域專有人才定向培養，內部同窗有可持續發展通道才能留住人才、用好人才，用人作事在零售雲組織體系上尤爲重要，而不是作事用人，不然項目就會把整個組織拖垮。

2、企業和業務視角

從 ISV 和客戶視角去看零售雲該怎麼構建產品和快速交付，而云原生技術體系將能夠幫助快速構建 2B 生態的產品和技術體系。雲原生技術體系基本可使用阿里雲的雲產品和技術基礎實施，面對不能知足的場景須要考慮自建仍是共建方式，個人理解是零售雲是業務和產品爲導向的， 2B 交付有不少個性化的訴求，阿里雲的雲原生體系更多的是從通用角度考慮，對於個性化和差別化需求，零售雲鬚要進行補充和擴展雲原生技術/產品體系建設，諸如商業能力客戶側部署發佈不能依賴阿里云云效，服務 SLA 的標準差別化等。

3、雲原生技術架構視角

零售雲當前已經基於阿里雲 Kubernetes(ACK) 構建了零售雲中臺飛鶴版本，零售雲中臺基線版本在建設中。面向明年20家客戶交付，後年 100 家客戶交付，咱們須要構建通用的技術底座和產品基線，以通用的技術底座和產品基線進行快速複製分支交付和版本管理，知足獨立部署交付和 SaaS 交付兩種模式。當前構建獨立部署交付模式，務必須要考慮 SaaS 交付的產品和技術體系，在適當時機須要開始 PaaS 平臺的建設。

容器咱們須要堅決的使用 Kubernetes（ACK），結合零售行業的特性，Serverless 不是強需求， ASK 短時間能夠不用。容器建設上須要考慮多租戶容器邏輯和物理隔離，多租戶容器運行時管理等。

微服務結合零售雲現狀，咱們採用了 Dubbo 框架，建議能夠走向微服務第三代架構，增強 SideCar 的規劃和建設，諸如多租戶數據隔離、權重路由、灰度路由、流量重放、服務假裝、流量打標、流量調度、計量管理、計費管理都將是須要重點建設方向，能夠架構設計上保證可擴展能力建設，這些能力根據咱們前方項目打仗來適度調整優先級。

OAM 方面能夠結合阿里雲的進展狀況以及零售雲近三年項目交付的場景來看是否須要引入，咱們的技術架構是能夠支持可擴展這些基礎能力的。

服務網格 ServiceMesh 跟微服務架構聯繫起來，即 SideCar 的規劃和建設(須要看看阿里雲的 SideCar 是否知足零售雲需求），lstio 能夠解決開發人員和運維人員所面臨的從單體應用向分佈式微服務架構轉變的挑戰，部署交付是一個難點和挑戰，Istio 爲可擴展性而設計，能夠知足不一樣的部署需求。

DevOps 是咱們建設的一個重點，研發平臺、產品中心、支撐平臺（SideCar能夠放在這裏建設）和站點 PaaS ，以及通用的 PaaS 交付平臺建設在中長期的意義很是關鍵，這個產品體系當前仍是初步規劃階段，還須要驗證和實踐，建議須要更全面和更深度的探索後進一步完善咱們的產品體系，避免產品的重複和來回廢棄折騰建設。商業能力是零售雲對外交付的輸出產物，商業能力建設和商業能力研發平臺建設是重心。當零售雲中臺的開發和版本演進變成一個常規化的easy事，商業能力對外交付變成快速可持續迭代的狀態，那麼咱們的產品建設就初成形態了。

低代碼開發也是一個重要方向，指望可以低成本交付以及客戶低成本開發運維，低代碼開發是很是關鍵，相似 Salesforce 的 Ligthnig 產品的建設，咱們須要從多維度去建設，客戶基於商業能力二次開發須要低代碼開發， Maybe 基於元數據驅動建設零售雲產品體系是好的選擇，這個方向須要探索和結合場景實踐，低代碼開發須要根據場景選擇產品，有些場景適合使用紀元，有些場景適合使用 Astore ，有些場景適合使用相似斑馬產品，有些場景適合使用宜搭 Pro/ 宜搭，咱們須要有一個底座，須要和雲原生的技術體系結合，而後更好更多的整合產品進來造成一個場景系列解決方案。低代碼開發的思考，我將在另一篇文章中進行總結和思考。

原文連接本文爲阿里雲原創內容，未經容許不得轉載。