資安

淺析阿里《雲原生架構白皮書》

2020-07-24

簡介

提前看了《雲原生架構白皮書》一直想著要寫點東西，拖延來去《白皮書》已經正式發佈2天了，我還遲遲沒有動手。沒動手的一方面原因是我的懶癌症又犯了；另一個原因是《白皮書》覆蓋面之廣，基本觸及到雲原生的方方面面，而我在雲原生方面的知識儲備不足以支撐我寫出一篇好文。
雲原生概念雖然在2013年就已被提出，但到目前為止各家對它的理解都些許不同的側重，在這兒阿里給出了自己對雲原生的理解。看《白皮書》目錄如下圖，全文從7個章節對雲原生架構進行剖析、講解。我也從這7個方面帶大家快速過一遍……

whitepaper-cloudnative1.png

為什麼需要雲原生

這一部分內容比較少，大家可以看下《白皮書》上是怎麼說的。我理解的重點是：科技發展進入了雲的時代，硬件升級，更新速度要求越來越高，「生產關係」已經嚴重製約「生產力」的發展。在雲的時代，需要新的技術架構，來解決人們「生產力」越來越高的要求。於是，雲原生架構應運而生。

雲原生架構

雲原生架構定義

從技術的角度，雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在將雲應用中的 非業務代碼部分進行最大化的剝離，從而讓雲設施接管應用中原有的大量非功能特性(如彈性、韌性、安全、 可觀測性、灰度等)，使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。

whitepaper-cloudnative2.png

利用雲服務和提升軟件交付能力，進一步加快軟件開發
讓開發專注於對公司業務最核心的部分，剝離大量非功能性特性
具有高度自動化的軟件交付

雲原生架構原則

  1. 服務化原則: 把一個大服務拆分成多個小服務，每個小團隊負責指定服務，各個服務間的升級互不影響，加快業務迭代的速度。
  2. 彈性原則: 彈性是指系統的部署規模可以隨著業務量的變化自動伸縮。
  3. 可觀測原則: 可觀測性是指通過log, trace, metric等手段，讓一次點擊背後的多次服務調用的耗時、返回值和參數都清晰可見。
  4. 韌性原則: 韌性是指當軟件所依賴的軟硬件組件出現各種異常時，軟件表現出來的抵禦能力。
  5. 所有過程自動化原則: 軟件技術棧的複雜度和組件規模的增加，帶來了軟件交付的複雜性，通過使用自動化交付工具實現交付和運維的自動化。
  6. 零信任原則: 默認情況下不應該信任網絡內部和外部的任何人 / 設備 / 系統，需要基於認證和授權重構訪 問控制的信任基礎。
  7. 架構持續演進原則: 現在技術和業務還處在快速變化的時代，雲原生架構本身也需要具有具備持續演進能力。

主要架構模式

  1. 服務化架構模式: 服務化架構是雲時代構建雲原生應用的標準架構模式，要求以應用模塊為顆粒度劃分一個軟件，以接口契約(例如 IDL)定義彼此業務關係，以標準協議(HTTP、gRPC 等)確保彼此的互聯互通，結合 DDD(領域模型驅動)、TDD(測試驅動開發)、容器化部署提升每個接口的代碼質量和迭代速度。
  2. Mesh 化架構模式: Mesh化架構是把中間件框架(比如 RPC、緩存、異步消息等)從業務進程中分離，讓中間件 SDK與業務代碼進一步解耦。
  3. Serverless 模式: Serverless模式更進一步，把用戶從非核心中解放出來，只需要關心核心業務邏輯。
  4. 存儲計算分離模式: 把存儲這種有狀態的操作和計算這種不需要狀態的操作分別用不同的方式處理。
  5. 分佈式事務模式: 微服務模式提倡每個服務使用私有的數據源，而不是像單體這樣共享數據源。但實際使用場景中總有一些別的因素考量。所以有下面幾個分佈式事務模式分別適應不同的場景：XA模式、BASE、TCC模式、SAGA模式、AT 模式。
  6. 可觀測架構: 可觀測架構包括 Logging、Tracing、Metrics 三個方面。
  7. 事件驅動架構: 本質上是一種應用 / 組件間的集成架構模式。

典型的雲原生架構反模式

  1. 龐大的單體應用: 龐大單體應用的最大問題在於缺乏依賴隔離，因此需要考慮通過服務化進行一定的拆分。
  2. 單體應用“硬拆”為微服務: 服務的拆分需要適度，過分服務化拆分反而會導致新架構與組織能力的不匹配。
  3. 缺乏自動化能力的微服務: 當軟件規模變大後，自動化能力的缺失還會帶來更大的危害。

主要的雲原生技術

容器技術

容器技術背景與價值

whitepaper-cloudnative3.png

Docker 提出了創新的應用打包規範 —— Docker 鏡像，解耦了應用與運行環境，使應用可以在不同計 算環境間一致、可靠地運行。讓開發所需要的靈活性、開放 性和運維所關注的標準化、自動化達成相對平衡。

容器編排

Kubernetes 已經成為容器編排的事實標準，被廣泛用於自動部署，擴展和管理容器化應用。Kubernetes 提
供了分佈式應用管理的核心能力。
Kubernetes 在容器編排中有幾個關鍵設計理念:

1. 聲明式API
2. 可擴展性架構
3. 可移植性

雲原生微服務

微服務發展背景

在雲原生時代，雲原生微服務體系將充分利用雲資源的高可用和安全體系，讓應用獲得更有保障的彈性、 可用性與安全性。

微服務設計約束

相較於單體應用，微服務架構的架構轉變，在提升開發、部署等環節靈活性的同時，也提升了在運維、監控環節的複雜性。
1 微服務個體約束: 個微服務修改或者發佈時，不應該影響到同一系統裡另一個微服務的業務交互。
2 微服務與微服務之間的橫向關係: 主要微服務的可發現性和可交互性處理服務間的橫向關係。
3 微服務與數據層之間的縱向約束: 在微服務領域，提倡數據存儲隔離原則。對於有狀態的微服務，通常使用計算與存儲分離的方式.
4 全局視角下的微服務分佈式約束: 微服務系統設計一開始，就需要考慮全局視角。

雲原生微服務典型架構

第一代微服務架構:
whitepaper-cloudnative5.png

第二代微服務架構:
whitepaper-cloudnative6.png

第三代微服務架構:
whitepaper-cloudnative7.png

第四代微服務架構:
whitepaper-cloudnative8.png

主要微服務技術

Apache Dubbo
Spring Cloud
Eclipse MicroProfile
Tars
SOFAStack
Dapr

Serverless

1 技術特點

全託管的計算服務
通用性
自動的彈性伸縮
按量計費

2 常見場景

小程序 /Web/Mobile/API 後端服務
大規模批處理任務
基於事件驅動架構的在線應用和離線數據處理
開發運維自動化

3 技術關注點

計算資源彈性調度
負載均衡和流控
安全性

開放應用模型(OAM)

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

Service Mesh 技術

Service Mesh 是分佈式應用在微服務軟件架構之上發展起來的新技術，旨在將那些微服務間的連接、安全、流 量控制和可觀測等通用功能下沉為平臺基礎設施，實現應用與平臺基礎設施的解耦。這個解耦意味著開發者無需關注 微服務相關治理問題而聚焦於業務邏輯本身，提升應用開發效率並加速業務探索和創新。

根據 Gartner 研究報告，Istio 有望成為 Service Mesh 的事實標準（話外音:OUC的成立不知道會不會對此事造成影響？），而 Service Mesh 本身也將成為容器服務技術的標配技術組件。

DevOps

1 概述
DevOps 就是為了提高軟件研發效率，快速應對變化，持續交付價值的的一系列理念和實踐，其基本思想就是 持續部署(CD)，讓軟件的構建、測試、發佈能夠更加快捷可靠，以儘量縮短系統變更從提交到最後安全部署到生產 系統的時間。

要實施 DevOps，需要遵循一些基本原則，這些原則被簡寫為 CAMS:

文化(Culture) 
自動化(Automation) 
度量(Measurement) 
共享(Sharing)

運維平臺一般都經歷過如下幾個發展階段:手工、腳本、工具、平臺、智能化運維等。
現有運維平臺雖然很多實現方式，但總體來說分為兩類:

指令式 
聲明式

阿里雲原生架構設計

阿里巴巴獨有的雲原生架構設計方法——ACNA(Alibaba Cloud Native Architecting)。ACNA 是一個 「4+1」 的架構設計流程
「4」 代表架構設計的關鍵視角，包括:

企業戰略視角
業務發展視角
組織能力視角
雲原生技術架構視角

「1」 表示雲原生架構的架構持續演進閉環。

4 個架構視角和一個閉環的關係如下圖所示:

whitepaper-cloudnative4.png

阿里雲原生產品介紹

雲原生產品家族

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

阿里巴巴雲原生產品家族

  1. 容器產品家族:
容器服務 Kubernetes 版(ACK)
Serverless Kubernetes(ASK)
鏡像服務(ACR)
  1. 微服務產品家族
EDAS(企業分佈式應用服務)
MSE(微服務引擎)
ACM(應用配置管理)
CSB Micro Gateway(微服務網關服務)
GTS(全局事務服務)
ARMS(應用實時監控服務 ) 
鏈路追蹤(Tracing Analysis)
PTS(Performance Testing Service)
  1. Serverless 產品家族
FC(函數計算)
SAE(Serverless 應用引擎)
Serverless 工作流
  1. Service Mesh 產品家族
託管服務網格(ASM)
AHAS(應用高可用服務)
  1. 消息產品家族
消息隊列 RocketMQ 版
消息隊列 Kafka 版
消息隊列 AMQP 版
微消息隊列 MQTT 版
阿里雲消息服務 MNS
事件總線 EventBridge
  1. 雲原生數據庫產品家族
PolarDB
PolarDB-X
  1. 雲原生大數據產品家族
雲原生數據倉庫 AnalyticDB MySQL 版
雲原生數據倉庫 AnalyticDB PostgreSQL 版

各行業面臨的挑戰&解決方案

分別舉了「申通」「完美日記」「特步」「中國聯通」「Timing App」5個例子

雲原生架構未來發展趨勢

容器技術發展趨勢

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

新的容器運行時技術解決了安全隔離性、執行效率和通用性三個不同維度的要求:

KataContainer
Firecracker
gVisor
Unikernel

趨勢二:雲原生操作系統開始浮現

Linux 的計算調度單元是進程，調度範圍限制在一臺計算節點。而 Kubernetes 的調度單位是 Pod， 可以在分佈式集群中進行資源調度，甚至跨越不同的雲環境。

whitepaper-cloudnative11.png

趨勢三: Serverless 容器技術逐漸成為市場主流

通過 Serverless 容器，一方面根本性解決 Kubernetes 自身複雜性問題，讓用戶無需受困於 Kubernetes 集群容量規劃、安全維護、故障診斷等運維工作; 一方面進一步釋放雲計算能力，將安全、可用性、可伸縮性等需求下沉到基礎設施實現。

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

對於企業客戶而言，有些業務出於對數據主權、安全隱私的考量，會採用混合雲架構。一些企業為了滿足安全合規、成本優化、提升地域覆蓋性和避免雲廠商鎖定等需求，會選擇多個雲廠商。混合雲 / 多雲 架構已成為企業上雲新常態。

基於雲原生的新一代應用編程界面

包括生命週期管理、運維管理、配置範圍和擴展和管理、以及語言無關的編程框架，一起構成了嶄新的應 用與雲之間的編程界面。這一變革的核心邏輯還是把應用中和業務無關的邏輯和職責，剝離到雲服務，並在這個過程 中形成標準，讓應用開發者能夠在專有云、公有云、或者混合雲的場景中，都能有一致的研發運維體驗。

Serverless 發展趨勢

1 趨勢一:Serverless 將無處不在
2 趨勢二:Serverless 將通過事件驅動的方式連接雲及其生態中的一切
3 趨勢三:Serverless 計算將持續提高計算密度，實現最佳的性能功耗比和性能價格比

Leave a Reply

Your email address will not be published. Required fields are marked *