![1.png](https://ucc.alicdn.com/pic/developer-ecology/0a0a98bb1e264836819ec8238c4de19e.png)

作者 | 許曉斌  阿里雲高階技術專家

> **導讀**：如何藉助雲原生技術來提升交付速度？雲原生時代背景下，研發的關注點又會有哪些轉變？阿里雲高階技術專家許曉斌透過本文分享從 IaaS 上雲時代到 PaaS 上雲時代的應用架構演進方向，以及雲原生技術與應用架構演進的關係。

# 雲原生已經進入了 PaaS 上云為主的階段

阿里巴巴已經經歷了 IaaS 上雲的階段，邁進到了 PaaS 上雲的時代。在去年的“雙11”，阿里巴巴就已經實現了電商核心系統的全面上雲，這裡的上雲主要是在 IaaS 層。所謂 IaaS 主要就是對計算、網路、儲存的虛擬化，經過了這個階段，阿里巴巴就進入了 PaaS 上雲的階段。在 PaaS 上雲這個階段就需要使用更多的雲產品，包括中介軟體、儲存、快取甚至是應用託管平臺等。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/0f8a8c4d768f466e8290fd82609d78b0.png)

IaaS 階段和 PaaS 階段其實存在很大的差別。在 IaaS 階段，對於應用研發來說，所關心的往往就是基礎設施和資源，通俗來講就是虛擬機器或者容器等，這些對應用架構幾乎沒有任何侵入。但是在 PaaS 上雲階段，當你使用雲產品，比如雲 Redis、雲 RDS、雲 OSS、雲 RabbitMQ 等的時候，都會對於應用架構產生比較強的侵入。那麼，這樣的侵入會對應用架構產生什麼樣的影響，是所有研發架構師所需要思考的一個問題。

# 雲原生技術

如果大家嘗試去搜尋雲原生技術，就會看到 Google Cloud 的定義、CNCF 的定義以及其他很多的雲廠商以及開源軟體的定義，而這些定義看法都各有不同。簡單歸納可以分為如下圖所示的幾類，縱向來看，分為應用架構、生命週期管理、流量管理，以及基礎設施及依賴四個維度；橫向來看，又分為微服務、12 Factor Apps、容器、BaaS、GitOps/IaC 以及 Service Mesh 幾個維度。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/43332e94d17c4cb5a82f5b4da5fc463a.png)

今天，大家都會談到基於微服務架構做雲原生，而不是基於巨石應用架構或者簡單的 CS 架構。Quarkus 提出了 12 Factor Apps，意思就是說如果在今天想要讓應用跑在 Quarkus 等這些應用託管平臺上，對於應用具有一定的要求，大概是 12 條原則，比如配置和程式碼分離等，當然後續還有很多的擴充套件。這些原則中的很多條目的意思都是說只要你符合這些原則，那麼應用託管平臺就能夠為你提供更多的能力，比如免運維等。容器的核心是使用一種標準的互動方式讓平臺能夠管理應用的生命週期，包括髮布、擴容以及自愈等。

BaaS——Backend as a Service，能夠儘量使用現有的服務來構建應用程式。Service Mesh 的本質是管理流量，今天的應用程式都在接收流量，提供服務時流量又需要出去，在這個過程中如何管理服務發現、流量路由規則等都需要 Service Mesh 技術。最後需要重點介紹的就是 GitOps 和 IaC（Infrastructure as Code），這些技術如今在行業裡面得到了越來越多的關注，儘管還沒有事實上的標準，但是很多雲端計算公司正在不斷努力。其含義是說今天在使用基礎設施的時候，可以用程式碼去宣告這些基礎設施的需求。總而言之，上述這些內容都是圍繞應用架構、生命週期管理、流量管理，以及基礎設施及依賴這四個維度的。

# 業務關心的是交付速度

對於業務而言，最關心的往往是交付速度。如果你和業務總監或者 CTO 去聊，他們就會問你，擁有這麼多的技術對於業務有什麼好處？可能會談到成本的優勢、管理的優勢，但是對於幾乎所有業務而言，最核心的是研發效率的提升。所以我們應該思考雲原生技術如何才能幫助實現更快的交付。

藉助雲原生技術來提升交付服務的速度可以大致分為三個步驟。

## 1. 標準化平臺/服務和應用的協議

將平臺/服務和應用之間的協議進行標準化。如果 IaaS 層用雲的話協議就是機器，就是虛擬機器、容器等，對於業務應用而言，看到的就是一個作業系統，這樣應用就可以使用作業系統上的各種資源，這樣做的好處在於不需要關心物理機以及機器的故障等問題。

## 2. 與業務無關能力進一步解耦至平臺

對於業務應用而言，看到的就不是一個作業系統了，會給到一個更加上層的協議，讓平臺幫助應用實現自動伸縮以及自愈等，還可以幫助應用實現自動騰挪，當底層基礎設施發生故障的時候，可以將應用從一臺機器遷移到另外一臺機器，也就是生命週期管理。基於上述協議，平臺的很多能力就能夠下沉，比如原本需要手工管理的事情只需要透過程式碼宣告就可以很好地實現了，有了這些協議之後，業務應用就能夠將相關的生命週期管理託管給平臺。

## 3. 應用架構升級

除了上述兩點之外，第三步就是讓應用架構需要透過升級來適應，這樣才能讓相關能力下沉到雲平臺。

# IaaS 上雲階段到雲原生上雲階段的轉變

進一步細化就會發現，在原來的 IaaS 上雲階段，除了需要關心業務邏輯之外，還需要關心業務應用的生命週期管理、流量管理，還需要自己進行搭建和配置中介軟體，比如在雲環境中搭建 Redis、kafka 等，也就是說花費了大量時間在應用依賴管理的事情上，無法讓雲平臺進行管理。今天，在 PaaS 上雲或者雲原生上雲的階段，想要做到的就是儘量使用雲平臺提供的能力，將更多的精力集中在業務本身，而將業務無關的通用技術能力都交給雲來管理。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/a665a86a83b14f57a40b7e19dc5eaf8e.png)

核心問題：

- 業務無關能力如何解耦至平臺？
- 平臺和業務（應用）之間的協議如何定義？
- 應用架構需要如何適應？

以前在 IaaS 上雲階段，應用和作業系統進行互動存在標準的協議，而今天在 PaaS 上雲階段，這樣的協議應該是什麼，需要被重新定義。此外，基於這樣的協議如何實現能力下沉，也是很多包括阿里雲在內的很多雲廠商所做的事情，比如阿里雲基於 RocketMQ 做了 RocketMQ Service，基於容器的一些協議提供容器服務等等。當然，現在只是一個開始，未來這部分內容將會更加豐富和完整。

## 例子 1：Service Mesh 把服務發現和流量從業務剝離

與此同時，應用架構也需要去適應。這裡以 Service Mesh 為例，之前在應用內部的流量是 SDK 的形式，那麼在演進的過程中如何將服務發現和流量等從業務 SDK 中剝離出來放到 Sidecar 裡面去，進而交給雲平臺處理，這就是應用架構演進的一個例子。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/f6937f9de19a4d09907a77138148c9df.png)

- 服務註冊 & 發現
- 流量路由
- 流量回放
- 釋出過程中流量控制

## 例子 2：輕量化容器把日誌採集從業務中剝離

以前在做日誌採集的時候，需要在各個虛擬機器中開啟一個日誌採集程式，並將採集到的日誌傳輸到日誌採集平臺，並透過視覺化介面進行分析。而今天，在雲原生時代，更好的做法是讓容器服務從 stdout 來抓取日誌，也可以透過配置的方式去特定日誌目錄獲取日誌資料。但是採集這個事情需要搬到 Sidecar 裡面去實現 Agent 的升級。所以輕量化容器把日誌採集從業務中剝離也是一個架構演進的例子。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/419038c2d6574706bf4a2a4103580c66.png)

- 資源隔離
- 獨立升級

## 例子 3：業務提供探針，讓平臺實現生命週期管理

生命週期管理對於應用架構的要求就是原來的應用程式啟動之後是健康的還是不健康的，都是應用程式的運維或者研發需要負責和關心的。而在雲原生時代，希望將這種協議固定住，透過業務提供探針，來判斷應用程式是健康的還是不健康的，這就需要在應用內部透過 HTTP 協議或者 Shell 來提供健康資訊，這樣才能夠應用生命週期管理落到平臺中去。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/e9aeed970c12416f91b1a356d86b8153.png)

- 自動彈性
- 自動騰挪
- 自動重啟（自愈）

# 協議（Contract）=API+Configuration

統籌來看，協議就是 API+配置。對於 API 而言，如果大家使用快取，那麼基本會將開源的協議當做 API，這樣的協議通常會比閉源的協議更加友好。對於 RPC 協議，開源的 GRPC 和 DUBBO 會優於私有的 HSF。此外還有對於基礎設施的協議，比如 Terraform、Pulumi 這些其實是在定義一種開源的配置語言，這些配置語言能夠幫助宣告所需要的基礎設施，比如容器、磁碟、網路、儲存等，雖然現在的配置語言種類比較多，但是未來最終會形成 1 到 2 種語言，就像是 Java 的 SDK 一樣，未來使用雲資源必然會呈現出一套 SDK 來，這個 SDK 必然是根據一套配置程式碼化語言來構建的。進一步的，GitOps 等將釋出流程、釋出策略也定義成了一套語言，而這在未來將會應用程式與雲之間的標準協議。

- Docker (& OCI) 是標準的軟體交付 API；
- 作為 RPC 協議，開源的 GRPC/DUBBO 優於私有的 HSF；
- 作為快取協議，開源的 Redis 優於私有的 Tair；
- 微軟的 Dapr 嘗試基於 sidecar 架構將 API 標準化到 HTTP/GRPC 層，以去 SDK，並支援多語言；
- Terraform，Pulumi 等 IaC 產品，透過配置語言宣告基礎設施；
- GitOps 進一步的使用程式碼宣告環境、釋出流程、釋出策略內容。

# 研發關注點的轉變

原來的時候，應用程式所需要關心的東西太多，比如各種 SDK、各種運維事件，但是這些東西實際上都可以被抽象成一種模型，並且使用一種新的語言來定義，這也是整個雲產業所關心的事情。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/07ceb0aa823348229b1556af1b51fe52.png)

之所以一直強調新語言和新協議，是因為定義了新的語言或者協議之後，應用程式所需要關心的就是這些了。對於開發者而言，最關心的就是程式碼，那麼如果能夠用程式碼來描述應用對於基礎設施、運維、託管的需求，那麼就會對應用程式非常友好。應用程式只需要能夠對接這個協議，那麼就能夠在專有云、公有云、阿里雲上同時執行。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/d3236abd28ef4efb93b616af5baaeeeb.png)

# 總結

未來，雲上的資源會越來越豐富，在基礎設施之上，雲平臺提供了更多的 PaaS 能力，就像是作業系統在提供了程式這些能力之上，還有很多的 SDK。但是，這些能力目前在使用上還非常低效和不標準，使用過程也比較麻煩。今天我們在以類似彙編的形式使用雲，雲原生則在重新定義應用程式與雲平臺之間的契約，並圍繞這個契約來構建更高階的程式語言和工具。這就是雲原生時代背景下，應用架構演進非常重要的一個方向。

點選即可檢視雲原生架構白皮書：[https://developer.aliyun.com/topic/cn-architecture-paper](https://developer.aliyun.com/topic/cn-architecture-paper)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495335&idx=1&sn=de4f3a345c2b31122a4bcdad7d538eb4&chksm=fae6e568cd916c7ecdbd1c0efd1b0a277bea83f0d62a973c2710674106b8df38b80d7dd484e5&token=897667441&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

雲原生時代，應用架構將如何演進？

相關文章