雲原生已經進入了PaaS上雲為主的階段
阿裡巴巴已經經曆了IaaS上雲的階段，邁進到了PaaS上雲的時代。在去年的“雙11”，阿裡巴巴就已經實作了電商核心系統的全面上雲，這裡的上雲主要是在IaaS層。所謂IaaS主要就是對計算、網絡、存儲的虛拟化，經過了這個階段，阿裡巴巴就進入了PaaS上雲的階段。在PaaS上雲這個階段就需要使用更多的雲産品，包括中間件、存儲、緩存甚至是應用托管平台等。
IaaS階段和PaaS階段其實存在很大的差别。在IaaS階段，對于應用研發來說，所關心的往往就是基礎設施和資源，通俗來講就是虛拟機或者容器等，這些對應用架構幾乎沒有任何侵入。但是在PaaS上雲階段，當你使用雲産品，比如雲Redis、雲RDS、雲OSS、雲RabbitMQ等的時候，都會對于應用架構産生比較強的侵入。那麼，這樣的侵入會對應用架構産生什麼樣的影響，是所有研發架構師所需要思考的一個問題。
雲原生技術
如果大家嘗試去搜尋雲原生技術，就會看到Google Cloud的定義、CNCF的定義以及其他很多的雲産商以及開源軟體的定義，而這些定義看法都各有不同。簡單歸納可以分為如下圖所示的幾類，縱向來看，分為了應用架構、生命周期管理、流量管理，以及基礎設施及依賴四個次元；橫向來看，又分為了微服務、12 Factor Apps、容器、BaaS、GitOps/IaC以及Service Mesh幾個次元。
今天，大家都會談到基于微服務架構做雲原生，而不是基于巨石應用架構或者簡單的CS架構。Quarkus提出了12 Factor Apps，意思就是說如果在今天想要讓應用跑在Quarkus等這些應用托管平台上，對于應用具有一定的要求，大概是12條原則，比如配置和代碼分離等，當然後續還有很多的擴充。這些原則中的很多條目的意思都是說隻要你符合這些原則，那麼應用托管平台就能夠為你提供更多的能力，比如免運維等。容器的核心是使用一種标準的互動方式讓平台能夠管理應用的生命周期，包括釋出、擴容以及自愈等。
BaaS——Backend as a Service，能夠盡量使用現有的服務來建構應用程式。Service Mesh的本質是管理流量，今天的應用程式都在接收流量，提供服務時流量又需要出去，在這個過程中如何管理服務發現、流量路由規則等都需要Service Mesh技術。最後需要重點介紹的就是GitOps和IaC（Infrastructure as Code），這些技術如今在行業裡面得到了越來越多的關注，盡管還沒有事實上的标準，但是很多雲計算公司正在不斷努力。其含義是說今天在使用基礎設施的時候，可以用代碼去聲明這些基礎設施的需求。總而言之，上述這些内容都是圍繞應用架構、生命周期管理、流量管理，以及基礎設施及依賴這四個次元的。
業務關心的是傳遞速度
對于業務而言，最關心的往往是傳遞速度。如果你和業務總監或者CTO去聊，他們就會問你，擁有這麼多的技術對于業務有什麼好處？可能會談到成本的優勢、管理的優勢，但是對于幾乎所有業務而言，最核心的是研發效率的提升。是以我們應該思考雲原生技術如何才能幫助實作更快的傳遞。
借助雲原生技術來提升傳遞服務的速度可以大緻分為三個步驟。
标準化平台/服務和應用的協定
将平台/服務和應用之間的協定進行标準化。如果IaaS層用雲的話協定就是機器，就是虛拟機、容器等，對于業務應用而言，看到的就是一個作業系統，這樣應用就可以使用作業系統上的各種資源，這樣做的好處在于不需要關心實體機以及機器的故障等問題。
與業務無關能力進一步解耦至平台
對于業務應用而言，看到的就不是一個作業系統了，會給到一個更加上層的協定，讓平台幫助應用實作自動伸縮以及自愈等，還可以幫助應用實作自動騰挪，當底層基礎設施發生故障的時候，可以将應用從一台機器遷移到另外一台機器，也就是生命周期管理。基于上述協定，平台的很多能力就能夠下沉，比如原本需要手工管理的事情隻需要通過代碼聲明就可以很好地實作了，有了這些協定之後，業務應用就能夠将相關的生命周期管理托管給平台。
應用架構更新
除了上述兩點之外，第三步就是讓應用架構需要通過更新來适應，這樣才能讓相關能力下沉到雲平台。
IaaS上雲階段到雲原生上雲階段的轉變
進一步細化就會發現，在原來的IaaS上雲階段，除了需要關心業務邏輯之外，還需要關心業務應用的生命周期管理、流量管理，還需要自己進行搭建和配置中間件，比如在雲環境中搭建Redis、kafka等，也就是說花費了大量時間在應用依賴管理的事情上，無法讓雲平台進行管理。今天，在PaaS上雲或者雲原生上雲的階段，想要做到的就是盡量使用雲平台提供的能力，将更多的精力集中在業務本身，而将業務無關的通用技術能力都交給雲來管理。
核心問題：
- 業務無關能力如何解耦至平台？
- 平台和業務（應用）之間的協定如何定義？
- 應用架構需要如何适應？
以前在IaaS上雲階段，應用和作業系統進行互動存在标準的協定，而今天在PaaS上雲階段，這樣的協定應該是什麼，需要被重新定義。此外，基于這樣的協定如何實作能力下沉，也是很多包括阿裡雲在内的很多雲廠商所做的事情，比如阿裡雲基于RocketMQ做了RocketMQ Service，基于容器的一些協定提供容器服務等等。當然，現在隻是一個開始，未來這部分内容将會更加豐富和完整。
例子1：Service Mesh把服務發現和流量從業務剝離
與此同時，應用架構也需要去适應。這裡以Service Mesh為例，之前在應用内部的流量是SDK的形式，那麼在演進的過程中如何将服務發現和流量等從業務SDK中剝離出來放到Sidecar裡面去，進而交給雲平台處理，這就是應用架構演進的一個例子。
- 服務注冊 & 發現
- 流量路由
- 流量回放
- 釋出過程中流量控制
例子2：輕量化容器把日志采集從業務中剝離
以前在做日志采集的時候，需要在各個虛拟機中開啟一個日志采集程序，并将采集到的日志傳輸到日志采集平台，并通過可視化界面進行分析。而今天，在雲原生時代，更好的做法是讓容器服務從stdout來抓取日志，也可以通過配置的方式去特定日志目錄擷取日志資料。但是采集這個事情需要搬到Sidecar裡面去實作Agent的更新。是以輕量化容器把日志采集從業務中剝離也是一個架構演進的例子。
- 資源隔離
- 獨立更新
例子3：業務提供探針，讓平台實作生命周期管理
生命周期管理對于應用架構的要求就是原來的應用程式啟動之後是健康的還是不健康的，都是應用程式的運維或者研發需要負責和關心的。而在雲原生時代，希望将這種協定固定住，通過業務提供探針，來判斷應用程式是健康的還是不健康的，這就需要在應用内部通過HTTP協定或者Shell來提供健康資訊，這樣才能夠應用生命周期管理落到平台中去。
- 自動彈性
- 自動騰挪
- 自動重新開機（自愈）
協定（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、各種運維事件，但是這些東西實際上都可以被抽象成一種模型，并且使用一種新的語言來定義，這也是整個雲産業所關心的事情。
之是以一直強調新語言和新協定，是因為定義了新的語言或者協定之後，應用程式所需要關心的就是這些了。對于開發者而言，最關心的就是代碼，那麼如果能夠用代碼來描述應用對于基礎設施、運維、托管的需求，那麼就會對應用程式非常友好。應用程式隻需要能夠對接這個協定，那麼就能夠在專有雲、公有雲、阿裡雲上同時運作。
總結
未來，雲上的資源會越來越豐富，在基礎設施之上，雲平台提供了更多的PaaS能力，就像是作業系統在提供了程序這些能力之上，還有很多的SDK。但是，這些能力目前在使用上還非常低效和不标準，使用過程也比較麻煩。今天我們在以類似彙編的形式使用雲，雲原生則在重新定義應用程式與雲平台之間的契約，并圍繞這個契約來建構更進階的程式設計語言和工具。這就是雲原生時代背景下，應用架構演進非常重要的一個方向。