云原生時代，應用架構(gòu)將如何演進？
云原生已經(jīng)進入了PaaS上云為主的階段
阿里巴巴已經(jīng)經(jīng)歷了IaaS上云的階段，邁進到了PaaS上云的時代。在去年的“雙11”，阿里巴巴就已經(jīng)實現(xiàn)了電商核心系統(tǒng)的全面上云，這里的上云主要是在IaaS層。所謂IaaS主要就是對計算、網(wǎng)絡、存儲的虛擬化，經(jīng)過了這個階段，阿里巴巴就進入了PaaS上云的階段。在PaaS上云這個階段就需要使用更多的云產(chǎn)品，包括中間件、存儲、緩存甚至是應用托管平臺等。
?? 
IaaS階段和PaaS階段其實存在很大的差別。在IaaS階段，對于應用研發(fā)來說，所關心的往往就是基礎設施和資源，通俗來講就是虛擬機或者容器等，這些對應用架構(gòu)幾乎沒有任何侵入。但是在PaaS上云階段，當你使用云產(chǎn)品，比如云Redis、云RDS、云OSS、云RabbitMQ等的時候，都會對于應用架構(gòu)產(chǎn)生比較強的侵入。那么，這樣的侵入會對應用架構(gòu)產(chǎn)生什么樣的影響，是所有研發(fā)架構(gòu)師所需要思考的一個問題。
云原生技術
如果大家嘗試去搜索云原生技術，就會看到Google Cloud的定義、CNCF的定義以及其他很多的云產(chǎn)商以及開源軟件的定義，而這些定義看法都各有不同。簡單歸納可以分為如下圖所示的幾類，縱向來看，分為了應用架構(gòu)、生命周期管理、流量管理，以及基礎設施及依賴四個維度;橫向來看，又分為了微服務、12 Factor Apps、容器、BaaS、GitOps/IaC以及Service Mesh幾個維度。
?? 
今天，大家都會談到基于微服務架構(gòu)做云原生，而不是基于巨石應用架構(gòu)或者簡單的CS架構(gòu)。Quarkus提出了12 Factor Apps，意思就是說如果在今天想要讓應用跑在Quarkus等這些應用托管平臺上，對于應用具有一定的要求，大概是12條原則，比如配置和代碼分離等，當然后續(xù)還有很多的擴展。這些原則中的很多條目的意思都是說只要你符合這些原則，那么應用托管平臺就能夠為你提供更多的能力，比如免運維等。容器的核心是使用一種標準的交互方式讓平臺能夠管理應用的生命周期，包括發(fā)布、擴容以及自愈等。
BaaS——Backend as a Service，能夠盡量使用現(xiàn)有的服務來構(gòu)建應用程序。Service Mesh的本質(zhì)是管理流量，今天的應用程序都在接收流量，提供服務時流量又需要出去，在這個過程中如何管理服務發(fā)現(xiàn)、流量路由規(guī)則等都需要Service Mesh技術。最后需要重點介紹的就是GitOps和IaC(Infrastructure as Code)，這些技術如今在行業(yè)里面得到了越來越多的關注，盡管還沒有事實上的標準，但是很多云計算公司正在不斷努力。其含義是說今天在使用基礎設施的時候，可以用代碼去聲明這些基礎設施的需求?？偠灾?，上述這些內(nèi)容都是圍繞應用架構(gòu)、生命周期管理、流量管理，以及基礎設施及依賴這四個維度的。
業(yè)務關心的是交付速度
對于業(yè)務而言，最關心的往往是交付速度。如果你和業(yè)務總監(jiān)或者CTO去聊，他們就會問你，擁有這么多的技術對于業(yè)務有什么好處?可能會談到成本的優(yōu)勢、管理的優(yōu)勢，但是對于幾乎所有業(yè)務而言，最核心的是研發(fā)效率的提升。所以我們應該思考云原生技術如何才能幫助實現(xiàn)更快的交付。
借助云原生技術來提升交付服務的速度可以大致分為三個步驟。
標準化平臺/服務和應用的協(xié)議
將平臺/服務和應用之間的協(xié)議進行標準化。如果IaaS層用云的話協(xié)議就是機器，就是虛擬機、容器等，對于業(yè)務應用而言，看到的就是一個操作系統(tǒng)，這樣應用就可以使用操作系統(tǒng)上的各種資源，這樣做的好處在于不需要關心物理機以及機器的故障等問題。
與業(yè)務無關能力進一步解耦至平臺
對于業(yè)務應用而言，看到的就不是一個操作系統(tǒng)了，會給到一個更加上層的協(xié)議，讓平臺幫助應用實現(xiàn)自動伸縮以及自愈等，還可以幫助應用實現(xiàn)自動騰挪，當?shù)讓踊A設施發(fā)生故障的時候，可以將應用從一臺機器遷移到另外一臺機器，也就是生命周期管理?；谏鲜鰠f(xié)議，平臺的很多能力就能夠下沉，比如原本需要手工管理的事情只需要通過代碼聲明就可以很好地實現(xiàn)了，有了這些協(xié)議之后，業(yè)務應用就能夠?qū)⑾嚓P的生命周期管理托管給平臺。
應用架構(gòu)升級
除了上述兩點之外，第三步就是讓應用架構(gòu)需要通過升級來適應，這樣才能讓相關能力下沉到云平臺。
IaaS上云階段到云原生上云階段的轉(zhuǎn)變
進一步細化就會發(fā)現(xiàn)，在原來的IaaS上云階段，除了需要關心業(yè)務邏輯之外，還需要關心業(yè)務應用的生命周期管理、流量管理，還需要自己進行搭建和配置中間件，比如在云環(huán)境中搭建Redis、kafka等，也就是說花費了大量時間在應用依賴管理的事情上，無法讓云平臺進行管理。今天，在PaaS上云或者云原生上云的階段，想要做到的就是盡量使用云平臺提供的能力，將更多的精力集中在業(yè)務本身，而將業(yè)務無關的通用技術能力都交給云來管理。
?? 
核心問題：
- 業(yè)務無關能力如何解耦至平臺?
- 平臺和業(yè)務(應用)之間的協(xié)議如何定義?
- 應用架構(gòu)需要如何適應?
以前在IaaS上云階段，應用和操作系統(tǒng)進行交互存在標準的協(xié)議，而今天在PaaS上云階段，這樣的協(xié)議應該是什么，需要被重新定義。此外，基于這樣的協(xié)議如何實現(xiàn)能力下沉，也是很多包括阿里云在內(nèi)的很多云廠商所做的事情，比如阿里云基于RocketMQ做了RocketMQ Service，基于容器的一些協(xié)議提供容器服務等等。當然，現(xiàn)在只是一個開始，未來這部分內(nèi)容將會更加豐富和完整。
例子1：Service Mesh把服務發(fā)現(xiàn)和流量從業(yè)務剝離
與此同時，應用架構(gòu)也需要去適應。這里以Service Mesh為例，之前在應用內(nèi)部的流量是SDK的形式，那么在演進的過程中如何將服務發(fā)現(xiàn)和流量等從業(yè)務SDK中剝離出來放到Sidecar里面去，進而交給云平臺處理，這就是應用架構(gòu)演進的一個例子。
?? 
- 服務注冊 & 發(fā)現(xiàn)
- 流量路由
- 流量回放
- 發(fā)布過程中流量控制
例子2：輕量化容器把日志采集從業(yè)務中剝離
以前在做日志采集的時候，需要在各個虛擬機中開啟一個日志采集進程，并將采集到的日志傳輸?shù)饺罩静杉脚_，并通過可視化界面進行分析。而今天，在云原生時代，更好的做法是讓容器服務從stdout來抓取日志，也可以通過配置的方式去特定日志目錄獲取日志數(shù)據(jù)。但是采集這個事情需要搬到Sidecar里面去實現(xiàn)Agent的升級。所以輕量化容器把日志采集從業(yè)務中剝離也是一個架構(gòu)演進的例子。
?? 
- 資源隔離
- 獨立升級
例子3：業(yè)務提供探針，讓平臺實現(xiàn)生命周期管理
生命周期管理對于應用架構(gòu)的要求就是原來的應用程序啟動之后是健康的還是不健康的，都是應用程序的運維或者研發(fā)需要負責和關心的。而在云原生時代，希望將這種協(xié)議固定住，通過業(yè)務提供探針，來判斷應用程序是健康的還是不健康的，這就需要在應用內(nèi)部通過HTTP協(xié)議或者Shell來提供健康信息，這樣才能夠應用生命周期管理落到平臺中去。
?? 
- 自動彈性
- 自動騰挪
- 自動重啟(自愈)
協(xié)議(Contract)=API+Configuration
統(tǒng)籌來看，協(xié)議就是API+配置。對于API而言，如果大家使用緩存，那么基本會將開源的協(xié)議當做API，這樣的協(xié)議通常會比閉源的協(xié)議更加友好。對于RPC協(xié)議，開源的GRPC和DUBBO會優(yōu)于私有的HSF。此外還有對于基礎設施的協(xié)議，比如Terraform、Pulumi這些其實是在定義一種開源的配置語言，這些配置語言能夠幫助聲明所需要的基礎設施，比如容器、磁盤、網(wǎng)絡、存儲等，雖然現(xiàn)在的配置語言種類比較多，但是未來最終會形成1到2種語言，就像是Java的SDK一樣，未來使用云資源必然會呈現(xiàn)出一套SDK來，這個SDK必然是根據(jù)一套配置代碼化語言來構(gòu)建的。進一步的，GitOps等將發(fā)布流程、發(fā)布策略也定義成了一套語言，而這在未來將會應用程序與云之間的標準協(xié)議。
Docker (& OCI) 是標準的軟件交付 API。
- 作為 RPC 協(xié)議，開源的 GRPC/DUBBO 優(yōu)于私有的 HSF。
- 作為緩存協(xié)議，開源的 Redis 優(yōu)于私有的 Tair。
- 微軟的 Dapr 嘗試基于 sidecar 架構(gòu)將 API 標準化到 HTTP/GRPC 層，以去 SDK，并支持多語言。
- Terraform，Pulumi 等 IaC 產(chǎn)品，通過配置語言聲明基礎設施。
- GitOps 進一步的使用代碼聲明環(huán)境、發(fā)布流程、發(fā)布策略內(nèi)容。
研發(fā)關注點的轉(zhuǎn)變
原來的時候，應用程序所需要關心的東西太多，比如各種SDK、各種運維事件，但是這些東西實際上都可以被抽象成一種模型，并且使用一種新的語言來定義，這也是整個云產(chǎn)業(yè)所關心的事情。
?? 
之所以一直強調(diào)新語言和新協(xié)議，是因為定義了新的語言或者協(xié)議之后，應用程序所需要關心的就是這些了。對于開發(fā)者而言，最關心的就是代碼，那么如果能夠用代碼來描述應用對于基礎設施、運維、托管的需求，那么就會對應用程序非常友好。應用程序只需要能夠?qū)舆@個協(xié)議，那么就能夠在專有云、公有云、阿里云上同時運行。
?? 
總結(jié)
未來，云上的資源會越來越豐富，在基礎設施之上，云平臺提供了更多的PaaS能力，就像是操作系統(tǒng)在提供了進程這些能力之上，還有很多的SDK。但是，這些能力目前在使用上還非常低效和不標準，使用過程也比較麻煩。今天我們在以類似匯編的形式使用云，云原生則在重新定義應用程序與云平臺之間的契約，并圍繞這個契約來構(gòu)建更高級的編程語言和工具。這就是云原生時代背景下，應用架構(gòu)演進非常重要的一個方向。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
