零售雲是阿裡三朵業務雲：零售雲、金融雲和政務雲之一，将開辟阿裡在電商、零售行業的新藍海，2B快速傳遞、賦能合作夥伴更快業務增長和節省成本。雲原生是零售雲的最重要的技術底座，雲原生是什麼，會走向哪裡，在零售2B傳遞的場景上該如何應用，怎麼能夠結合幫助建設零售雲系列産品體系，值得我們的思考和探索，也将有效指導我們接下來幾年的零售雲項目和産品建設。
雲原生定義、阿裡巴巴雲原生架構方法論及産品體系
雲原生定義
Cloud Native 翻譯為雲原生，是 Matt Stine 提出的一個概念，它是一個思想的集合，包括 DevOps 、持續傳遞（Continuous Delivery）、微服務（MicroServices）、靈活基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。Cloud Native 既包含技術（微服務，靈活基礎設施），也包含管理（DevOps，持續傳遞，康威定律，重組等）。Cloud Native 也可以說是一系列技術、企業管理方法的集合。
雲原生的本質
雲原生本質是以應用為中心，讓應用能最大限度享受到雲計算的紅利。雲原生是雲計算的下一站，雲原生架構是引領未來十年的新一代技術架構。雲原生讓雲計算變得标準、開放、簡單高效、觸手可及。
雲原生應用開發的最佳實踐原則：12-Factor
1、 基準代碼：一份基準代碼（Codebase），多份部署（deploy）
基準代碼和應用之間總是保持一一對應的關系，一份代碼可以部署在開發環境、測試環境、預發環境及産線環境。
多個應用共享一份基準代碼是有悖于 12-Factor 原則的。解決方案如下：
将共享的代碼拆分為獨立的類庫，然後使用依賴管理政策去加載它們。所有部署的基準代碼相同，但每份部署可以使用其不同的版本。比如，開發人員可能有一些送出還沒有同步至預釋出環境；預釋出環境也有一些送出沒有同步至生産環境。但它們都共享一份基準代碼，我們就認為它們隻是相同應用的不同部署而已。
2、 依賴——顯式聲明依賴關系（Dependency）
12-Factor 規則下的應用程式不會隐式依賴系統級的類庫。它一定通過依賴清單，确切地聲明所有依賴項。大多數程式設計語言都會提供一個打包系統，比如 java 使用 maven ，應用依賴了哪些第三方庫，要顯示地定義在 POM 檔案裡。
3、 配置：在環境中存儲配置
配置要和代碼完全分離，環境變量可以非常友善地在不同的部署間做修改，卻不動一行代碼。配置主要包括資料庫資訊，緩存資訊，第三方服務證書，每份部署特有的配置，如域名等資訊。
判斷一個應用是否正确地将配置排除在代碼之外，一個簡單的方法，看該應用的基準代碼是否可以立刻開源，而不用擔心會暴露任何敏感的資訊。
4、 後端服務：把後端服務當作附加資源
後端服務是指程式運作所需要的通過網絡調用的各種服務，如資料庫，消息系統及緩存系統。
12-Factor 應用的任意部署，都應該可以在不進行任何代碼改動的情況下，進行後端服務的切換，比如将本地 MySQL 資料庫換成第三方服務（例如阿裡雲的 RDS）。另外，部署可以按需加載或解除安裝資源。例如，如果應用的資料庫服務由于硬體問題出現異常，管理者可以從最近的備份中恢複一個資料庫，解除安裝目前的資料庫，然後加載新的資料庫 。整個過程都不需要修改代碼。
5、 建構->釋出->運作：嚴格分離建構和運作
基準代碼 轉化為一份部署(非開發環境)需要以下三個階段：
建構階段，将代碼倉庫轉化為可執行包的過程。建構時會使用指定版本的代碼,擷取和打包依賴項,編譯成二進制檔案和資源檔案。
釋出階段，将建構的結果和目前部署所需配置相結合，并能夠立刻在運作環境中投入使用。
運作階段(“運作時”)，針對標明的釋出版本，在執行環境中啟動一系列應用程式程序。
每一個釋出版本必須對應一個唯一的釋出 ID,一旦釋出就不可修改，任何的變動都應該産生一個新的釋出版本。另外，釋出管理工具需要能友善的回退至較舊的釋出版本。
6、 程序：以一個或多個無狀态程序運作應用
運作環境中，應用程式通常是以一個和多個程序運作的。12-Factor應用的程序必須無狀态且無共享，任何需要持久化的資料都要存儲在後端服務内，比如資料庫或緩存。
7、 端口綁定：通過端口綁定提供服務
12-Factor應用完全自我加載，而不依賴于任何網絡伺服器就可以建立一個面向網絡的服務。網際網路應用通過端口綁定來提供服務，并監聽發送至該端口的請求。比如，線上上環境中，請求統一發送至公共域名，然後路由至綁定了端口的網絡程序。
8、 并發：通過程序模型進行擴充
在 12-factor 應用中，程序是一等公民。12-Factor 應用的程序主要借鑒于 unix 守護程序模型 。開發人員可以運用這個模型去設計應用架構，将不同的工作配置設定給不同的程序類型。例如，HTTP 請求可以交給web程序來處理，而常駐的背景工作則交由 worker程序負責。
9、 易處理：快速啟動和優雅終止可最大化健壯性
12-Factor 應用的程序是易處理的，即它們可以瞬間開啟或停止。這有利于快速、彈性的伸縮應用，迅速部署變化的代碼或配置，穩健的部署應用。
程序應當追求最小啟動時間，并且一旦接收到終止信号（SIGTERM），可以優雅的終止。程序還應當在面對突然死亡時保持健壯，例如底層硬體故障。無論如何，12-Factor應用都應該可以設計能夠應對意外的、不優雅的終結。
10、 開發環境與線上環境等價：盡可能的保持開發，預釋出，線上環境相同
12-Factor 應用的開發人員應該避免在不同環境間使用不同的後端服務，即使擴充卡已經可以幾乎消除使用上的差異。這是因為，不同的後端服務意味着會突然出現的不相容，進而導緻測試、預釋出都正常的代碼線上上出現問題。這些錯誤會給持續部署帶來阻力。從應用程式的生命周期來看，消除這種阻力需要花費很大的代價。
11、 日志：把日志當作事件流
12-factor 應用本身從不考慮存儲自己的輸出流。不應該試圖去寫或者管理日志檔案。相反，每一個運作的程序都會直接的标準輸出（stdout）事件流。開發環境中，開發人員可以通過這些資料流，實時在終端看到應用的活動。
12、 管理程序:背景管理任務當作一次性程序運作
一次性管理程序主要指一些管理或維護應用的一次性任務，比如，運作資料遷移，運作一些送出到代碼倉庫的一次性腳本等。它們應該和正常的常駐程序使用同樣的環境。這些管理程序和任何其他的程序一樣使用相同的代碼和配置，基于某個釋出版本運作。背景管理代碼應該随其他應用程式代碼一起釋出，進而避免同步問題。
以上了解了 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 産品家族、消息産品、雲原生資料庫家族、雲原生大資料産品家族等。
1、容器産品家族
2、微服務産品家族
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 調試和監測 等多種能力，緊密結合監控、流控等産品提供一站式高可用能力，高效檢驗和管理業務性能。
3、Serverless 産品家族
FC（函數計算）是一個事件驅動的全托管 Serverless 計算服務，使用者無需管理伺服器等基礎設施， 隻需編寫代碼并上傳，函數計算會準備好計算資源，并以彈性、可靠的方式運作業務代碼。
SAE（Serverless 應用引擎）實作了 Serverless 架構 + 微服務架構的完美融合，真正按需使用、按量計費，節省閑置計算資源，同時免去 IaaS 運維，有效提升開發運維效率；SAE 支援 Spring Cloud、Dubbo 和 HSF 等流行的微服務架構。
Serverless 工作流是一個用來協調多個分布式任務執行的全托管 Serverless 雲服務，緻力于簡化開發和運作業務流程所需要的任務協調、狀态管理以及錯誤處理等繁瑣工作，讓使用者聚焦業務邏輯開發。使用者可以用順序、分支、并行等方式來編排分布式任務，服務會按照設定好的順序可靠地協調任務執行， 跟蹤每個任務的狀态轉換，并在必要時執行使用者定義的重試邏輯，以確定工作流順利完成。
4、Service Mesh産品家族
服務網格（ASM）提供全托管的微服務應用流量管理平台，相容 Istio 的同時，支援多個 Kubernetes 叢集中應用的統一流量管理，為容器和虛拟機中應用服務提供一緻的通信、安全和可觀測能力。
AHAS（應用高可用服務）是專注于提高應用及業務高可用的工具平台，目前主要提供應用架構探測感覺，故障注入式高可用能力評測和流控降級高可用防護三大核心能力，通過各自的工具子產品可以快 速低成本的在營銷活動場景、業務核心場景全面提升業務穩定性和韌性。
5、消息産品家族
消息隊列 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 協定在這些應用之間路 由事件，幫助使用者輕松建構松耦合、分布式的事件驅動架構。
6、資料庫産品家族
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 及阿裡雲各行業客戶業務的考驗，助力企業加速完成業務數字化轉型。
7、大資料産品家族
雲原生資料倉庫 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 解決方案。
零售雲基于雲原生的接下來規劃和挑戰
個人觀點，我們需要基于阿裡巴巴雲原生架構設計方法論：
一、組織視角
組織上需要從技術、業務和産品體系建設規劃好陣型，進行很好的排兵布陣，需要更多的各領域的優秀人才加入建設，建議組織上重點需要内部各領域專有人才定向培養，内部同學有可持續發展通道才能留住人才、用好人才，用人做事在零售雲組織體系上尤其重要，而不是做事用人，否則項目就會把整個組織拖垮。
二、企業和業務視角
從 ISV 和客戶視角去看零售雲該怎麼建構産品和快速傳遞，而雲原生技術體系将可以幫助快速建構 2B 生态的産品和技術體系。雲原生技術體系基本可以使用阿裡雲的雲産品和技術基礎實施，面對不能滿足的場景需要考慮自建還是共建方式，我的了解是零售雲是業務和産品為導向的， 2B 傳遞有很多個性化的訴求，阿裡雲的雲原生體系更多的是從通用角度考慮，對于個性化和差異化需求，零售雲需要進行補充和擴充雲原生技術/産品體系建設，諸如商業能力客戶側部署釋出不能依賴阿裡雲雲效，服務 SLA 的标準差異化等。
三、雲原生技術架構視角
零售雲目前已經基于阿裡雲 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/ 宜搭，我們需要有一個底座，需要和雲原生的技術體系結合，然後更好更多的整合産品進來形成一個場景系列解決方案。低代碼開發的思考，我将在另外一篇文章中進行總結和思考。