解讀容器 2019：

作者 | 張磊  阿裡雲進階技術專家、CNCF 官方大使，Kubernetes 項目資深成員和聯合維護者

在下一個十年交替之際，你是否知道，這個看似波瀾不驚的雲原生技術生态，又在孕育和經曆着哪些全新的變革呢？

前言

• 在這一年，這個生态具有标志性意義的 KubeCon，史無前例的吸引到了一萬兩千人湧入聖地亞哥，整個會議的贊助商清單，多到一張十餘米長的巨幅海報才堪堪放下。
• 在這一年，Kubernetes 終于成為了廣受認可的基礎設施領域工業标準，而這個标準的确立，則以 AWS 的重量級投入畫上了圓滿的句号。
• 在這一年，在社群頭部參與者的持續推進下，“規模”與“性能”終于成為了 Kubernetes 項目的重要關鍵詞，這不僅真正意義上打通了 Kubernetes 在企業生産環境中大規模落地的最後一公裡，也讓 Kubernetes 第一次成為了 “雙11” 等頂級網際網路規模化場景中實實在在的技術主角。

規模：Kubernetes 項目的新名片

如果要提名 2019 年的雲原生技術演進的重要節點，那麼“規模”一定是其中最當仁不讓的關鍵詞。

出于設計理念上的側重點考慮，Kubernetes 項目在過去乃至到 2019 年之前的很長一段時間内，也并不把“規模”作為整個項目演進的核心優先級來對待。這裡的主要原因在于 Kubernetes 的設計思想是“以應用為中心”的基礎設施，是以相比于傳統作業編排排程管理項目（比如 Mesos 和 Yarn 等）關注的資源效能問題，Kubernetes 的核心競争力則一直放在工作負載描述、服務發現、容器設計模式等更高緯度的應用基礎設施建構上。當然，另一方面的原因在于，對于 Kubernetes 服務提供商，比如 GKE 來說，他們對于規模與性能訴求也是比較有限的。

這個狀态，随着 2019 年初頂級網際網路公司對 Kubernetes 社群的重量級投入而被打破。事實上，Kubernetes 本身的規模與性能優化并不是一個“不可解”的問題，但是整個社群長期以來欠缺大規模場景和專門的工程力量投入，最終使得發現、診斷和修複整個容器編排與管理鍊路中各個性能障礙成了一個遙不可及的事情。

在這條關鍵鍊路當中， Kubernetes 的規模性問題又可以細分為：以 etcd 為代表的“資料面”、以 kube-apiserver 為代表“管控面”和以 kubelet 及各種 Controller 組成的“生産 / 消費面”三個問題域。在場景的推動下，Kubernetes 以及 etcd 社群在過去的一年裡，正是圍繞這三個問題域進行了大量的優化，例如：

• 資料面

通過優化 etcd 底層資料庫的資料結構和算法，将 etcd 百萬鍵值對随機寫性能提升 24 倍。

• 管控面

為 kube-apiserver 添加 Bookmark 機制，将 APIServer 重新開機時需要重新同步的事件降低為原來的 3%，性能提高了數十倍。

• 生産 / 消費面

将 Kubernetes 節點向 APIServer 的心跳機制從“定時發送”修改為“按需發送”，進而大大減少了規模化場景下 kubelet 對 APIServer 帶來的巨大壓力，大幅提高了 Kubernetes 所能支援的節點數目上限。

除此之外，在規模化 Kubernetes 落地的具體場景中，圍繞着上述三個問題域、在生産環境中經曆了充分驗證的規模與性能優化實踐也在 KubeCon 等技術演講中浮出水面。比如：如何讓多個 kube-apiserver 更均衡的處理生産 / 消費請求、避免性能熱點；如何通過合理的設定主備 Controller，讓更新 Controller 時無需大量重新同步資料，進而降低 controller 恢複時對 API Server 的性能沖擊等等。

這些 Kubernetes 規模與性能領域的“全鍊路優化”工作，幾乎全部源自于真實的網際網路級規模化場景，而它們最終完成的得益于頂級開源社群的協同與所有參與者的共同努力。而規模化與性能問題的逐漸解決不僅僅帶來了為 Kubernetes 項目帶來了充足的底氣，也正在迅速改變着整個基礎設施領域的基本格局。

2019 年 5 月，Twitter 公司在舊金山總部正式宣布 Twitter 的基礎設施将從 Mesos 全面轉向 Kubernetes。 這個新聞仿佛給當時略顯沉悶的技術社群裡扔進了一顆重磅炸彈一般，一時間傳言四起。

事實上，早在一年前，Twitter 公司的工程師就已經成為了灣區“大規模叢集管理小組（ CMWS， Cluster Mgmt at Web Scale）”裡的重要成員和分享常客。 CMWS 是一個專門針對大規模場景下的叢集管理問題而成立的閉門組織，其創始成員包括了阿裡巴巴、Pinterest、Linkedin、Netflix、Google、Uber、Facebook、Apple 等一大批全球頂級技術公司。該小組成員會在每個月舉行閉門 Meetup，圍繞具體的議題進行深度技術分享和交流，推動小組成員更快更好的在網際網路場景中落地 Kubernetes 技術體系。衆所周知，出于規模和性能的考慮，灣區的網際網路公司一直以來都是 Mesos 項目的重度使用者，而此次 Twitter 的轉變，實際上隻是 CMWS 小組成員中的一位而已。

雲原生的本質與誤區

盡管一路高歌猛進，但其實哪怕在 2019 年，還是有很多人對“雲原生”充滿了疑惑甚至誤解。這想必也是為何，我們一直能夠在不同的場合聽到關于雲原生的各種不同的定義。有人說，雲原生就是 Kubernetes 和容器；也有人說，雲原生就是“彈性可擴充”；還有人說，雲原生就是 Serverless；而後來，有人幹脆做出判斷：雲原生本身就是“哈姆雷特”，每個人的了解都是不一樣的。

實際上，自從這個關鍵詞被 CNCF 和 Kubernetes 技術生态“借用”之初，雲原生的意義和内涵，就是非常确定的。在這個生态當中，雲原生的本質是一系列最佳實踐的結合；更詳細的說，雲原生為實踐者指定了一條低心智負擔的、能夠以可擴充、可複制的方式最大化地利用雲的能力、發揮雲的價值的最佳路徑。

是以說，雲原生并不指代某個開源項目或者某種技術，它是一套指導軟體與基礎設施架構設計的思想。這裡關鍵之處在于，基于這套思想建構出來的應用和應用基礎設施，将天然能夠與“雲”天然地內建在一起，将“雲”的最大能力和價值發揮出來。

這種思想，以一言以蔽之，就是“以應用為中心”。

正是因為以應用為中心，雲原生技術體系才會無限強調讓基礎設施能更好的配合應用、以更高效方式為應用“輸送”基礎設施能力，而不是反其道而行之。而相應的， Kubernetes 、Docker、Operator 等在雲原生生态中起到了關鍵作用的開源項目，就是讓這種思想落地的技術手段。

以應用為中心，是指導整個雲原生生态和 Kubernetes 項目蓬勃發展至今的重要主線。

“下沉”的應用基礎設施能力與 Service Mesh

帶着這樣一條主線，我們回過頭來重新審視 2019 年雲原生生态的技術演進，會稍微清晰一些。

大家可能聽說過，在這次以 Kubernetes 為代表的基礎設施領域的演進過程中，總是伴随着一個重要的關鍵詞，那就是應用基礎設施能力的“下沉”。

在過去，我們編寫一個應用所需要的基礎設施能力，比如，資料庫、分布式鎖、服務注冊 / 發現、消息服務等等，往往是通過引入一個中間件庫來解決的。這個庫，其實就是專門的中間件團隊為你編寫的服務接入代碼，使得你可以在不需要深入了解具體基礎設施能力細節的前提下，以最小的代價學習和使用這些基礎設施能力。這其實是一種樸素的“關注點分離”的思想。不過更确切的說，中間件體系的出現，并不單單是要讓“專業的人做專業的事”，而更多是因為在過去，基礎設施的能力既不強大、也不标準。這就意味着，假如沒有中間件來把這些的基礎設施細節給屏蔽掉、把接入方式統一掉，業務研發就必須“被迫營業”，去學習無數晦澀的基礎設施 API 和調用方法，對于“生産力就是一切”的研發同學來說，這顯然是不可接受的。

不過，基礎設施本身的演進過程，實際上也伴随着雲計算和開源社群的迅速崛起。時至今日，以雲為中心、以開源社群為依托的現代基礎設施體系，已經徹底的打破了原先企業級基礎設施能力良莠不齊、或者隻能由全世界幾家巨頭提供的情況。

這個變化，正是雲原生技術改變傳統應用中間件格局的開始。更确切的說，原先通過應用中間件提供和封裝的各種基礎設施能力，現在全都被 Kubernetes 項目從應用層“拽”到了基礎設施層也就是 Kubernetes 本身當中。而值得注意的是，Kubernetes 本身其實也不是這些能力的直接提供者， Kubernetes 項目扮演的角色，是通過聲明式 API 和控制器模式把更底層的基礎設施能力對使用者“暴露”出去。這些能力，或者來自于“雲”（比如 PolarDB 資料庫服務）；或者來自于生态開源項目（比如 Prometheus 和 CoreDNS）。

這也是為什麼 CNCF 能夠基于 Kubernetes 這樣一個種子迅速建構起來一個數百個開源項目組成的龐大生态的根本原因：Kubernetes 從來就不是一個簡單的平台或者資源管理項目，它是一個分量十足的“接入層”，是雲原生時代真正意義上的“作業系統”。

可是，為什麼隻有 Kubernetes 能做到這一點呢？

這是因為， Kubernetes 是第一個真正嘗試以“應用為中心“的基礎設施開源項目。

以應用為中心，使得 Kubernetes 從第一天開始，就把聲明式 API 、而不是排程和資源管理作為自己的立身之本。聲明式 API 最大的價值在于“把簡單留給使用者，把複雜留給自己”。通過聲明式 API，Kubernetes 的使用者永遠都隻需要關心和聲明應用的終态，而不是底層基礎設施比如雲盤或者 Nginx 的配置方法和實作細節。注意，這裡應用的“終态”，不僅僅包括應用本身的運作終态，還包括了應用所需要的所有底層基礎設施能力比如路由政策、通路政策、存儲需求等所有應用依賴的終态。

這，正是以“應用為中心”的切實展現。

是以說，Kubernetes 并沒有讓中間件消失，而是把自己變成了一種“聲明式的”、“語言無關的”中間件，這正是應用基礎設施能力“下沉”的真實含義。

應用基礎設施能力“下沉”，實際上伴随着整個雲原生技術體系和 Kubernetes 項目的發展始終。比如， Kubernetes 最早提供的應用副本管理、服務發現和分布式協同能力，其實就是把建構分布式應用最迫切的幾個需求，通過 Replication Controller，kube-proxy 體系和 etcd “下沉”到了基礎設施當中。而 Service Mesh ，其實就更進一步，把傳統中間件裡至關重要的“服務與服務間流量治理”部分也“下沉”了下來。當然，這也就意味着 Service Mesh 實際上并不一定依賴于 Sidecar ：隻要能無感覺的攔截下來服務與服務之間的流量即可（比如 API Gateway 和 lookaside 模式）。

随着底層基礎設施能力的日趨完善和強大，越來越多的能力都會被以各種各樣的方式“下沉”下來。而在這個過程中，CRD + Operator 的出現，更是起到了關鍵的推進作用。 CRD + Operator，實際上把 Kubernetes 聲明式 API 驅動對外暴露了出來，進而使得任何一個基礎設施“能力”的開發者，都可以輕松的把這個“能力”植入到 Kubernetes 當中。當然，這也就展現了 Operator 和自定義 Controller 的本質差別：Operator 是一種特殊的自定義 Controller，它的編寫者，一定是某個“能力”對應的領域專家比如 TiDB 的開發人員，而不是 K8s 專家。遺憾的是目前的 Operator Framework 的發展并沒有展現出這個深層含義：太多的 K8s Controller 細節被暴露給了 Operator 的開發者，這是不對的。

在 2019 年，Service Mesh 生态取得了長足的進步，并且從原本 Istio 的絕對統治地位，來到了更接近于“諸侯争鳴”的局面。畢竟，“中間件”這個生态，在過去也很難出現完全一家獨大的狀态，而 Google “一如既往”的宣布 Istio 項目暫時不捐贈給任何一個開源社群，其實也隻是給這個趨勢增加一個推波助瀾的作用而已。其實，作為這波 Service Mesh 浪潮中應用基礎設施能力“下沉”的集大成者，Istio 項目已經在跟 Kubernetes 項目本身産生越來越多的“局部沖突”（比如跟 kube-proxy 體系的關系）。在未來，具體某種“聲明式中間件”的能力是 Kubernetes Core 還是 Mesh 插件來提供，可能會有更多的争論出現，而在這個過程中，我們也會看到 Istio 更多的“侵入”到 Kubernetes 的網絡甚至容器運作時層面當中，這将使得基礎設施變得越來越複雜、越來越“黑科技”化。

聲明式應用基礎設施的主旋律

是以一個不争的事實是，Kubernetes 項目的其實會越來越複雜、而不是越來越簡單。

更确切地說，“聲明式基礎設施”的基礎，就是讓越來越多的“複雜”下沉到基礎設施裡，無論是插件化、接口化的 Kubernetes “民主化”的努力，還是容器設計模式，或者 Mesh 體系，這些所有讓人興奮的技術演進，最終的結果都是讓 Kubernetes 本身變得越來越複雜。而聲明式 API 的好處就在于，它能夠在基礎設施本身的複雜度以指數級攀升的同時，至少保證使用者的互動界面複雜度仍然以線性程度上升。否則的話，如今的 Kubernetes 恐怕早就已經重蹈了 OpenStack 的災難而被人抛棄。

“複雜”，是任何一個基礎設施項目天生的特質而不是缺點。今天的 Linux Kernel 一定比 1991 年的第一版複雜不止幾個數量級；今天的 Linux Kernel 開發人員也一定沒辦法像十年前那樣對每一個 Module 都了如指掌。這是基礎設施項目演進的必然結果。

但是，基礎設施本身的複雜度，并不意味着基礎設施的所有使用者都應該承擔所有這些複雜度本身。這就好比我們每一個人其實都在“使用” Linux Kernel，但我們并不會抱怨“Linux Kernel 實在是太複雜了”：很多時候，我們甚至并不知道 Linux Kernel 的存在。

為了更好的說明 Kubernetes 的“複雜性”問題，我們需要先闡述一下目前的 Kubernetes 體系覆寫的三類技術群體：

• 基礎設施工程師

在公司裡，他們往往稱作“Kubernetes 團隊”或者“容器團隊”。他們負責部署、維護 Kubernetes 及容器項目、進行二次開發、研發新的功能和插件以暴露更多的基礎設施能力。他們是 Kubernetes 與容器領域裡的專家，也是這個生态裡的中堅力量。

• 運維工程師（含運維研發和 SRE）

他們以及他們開發的工具和流水線（Pipeline），是保障關鍵業務穩定和正确運作的基石，而 Kubernetes 項目對他們來說，則是供給和研發運維能力的核心基礎依賴。理想情況下，運維工程師是 Kubernetes 項目的最重要使用者。

• 業務研發工程師

目前的 Kubernetes 項目使用者中，業務研發的比重很小。他們本身對基礎設施并不感冒，但是也有可能被 Kubernetes 的“聲明式中間件”的能力被吸引，逐漸接受了依賴 Kubernetes 提供的基礎設施原語來編寫和部署應用。

上述三種使用群體在不同的公司内可能會有重合，而 Kubernetes 與生俱來的“複雜”，卻對上述三種使用者都有着深遠的影響。在 2019 年，雲原生生态也正在從上述三個角度出發，試圖解決 Kubernetes 複雜度對不同使用者帶來的問題。

Serverless Infrastructure 方興未艾

自然的，Kubernetes 生态首先希望解決的是基礎設施工程師面對的複雜度。在這裡聲明式 API 其實已經幫了很大的忙，但是部署和運維 Kubernetes 本身還是一個挑戰。這正是類似 kubeadm 、kops 項目，以及 Kubernetes 托管項目和服務（比如 GKE，ACK，EKS 等）的重要價值點。

另一方面，在幫助基礎設施工程師緩解複雜度問題的過程中，有一部分公有雲提供商逐漸發現了這樣一個事實：Kubernetes 工程師實際上也不希望關心更底層基礎設施比如網絡、存儲、主控端的細節和特性。這就好比一個電器工程師，怎麼會去關心發電廠裡的事情呢？

是以很多公有雲提供商先後推出了 Serverless Kubernetes 的服務。這種服務保留了 Kubernetes 的 Control Plane，但是把 Kubernetes 中的 kubelet 元件、以及相應的網絡、存儲等諸多 IaaS 相關概念去掉，然後用 Virtual Kubelet 項目把 Kubernetes Control Plane 直接對接到一個叫做 Serverless Container 的服務上來直接接入 IaaS 的能力。所謂 Serverless Container，實際上就是把虛拟機以及相應的網絡存儲等依賴，通過一個容器 API 暴露出來，比如 Microsoft 的 ACI，AWS 的 Fargate 以及阿裡雲的 ECI。由于從使用者視角來看，他看到的效果是 Kubernetes 裡面的 Node 被去掉了，是以這種服務方式又被稱作“Nodeless”。

Nodeless 從 Kubernetes 中移除最讓人頭疼的節點和資源管理部分，是以它在使用上非常簡單，底層資源的問題也完全不必使用者操心，可謂省心省力無限彈性；而相應的折衷是 kubelet 的缺失會為 Kubernetes 的功能完整性打上折扣。

在 2019 年底，AWS 在 Re:Intent 大會上宣布的 EKS on Fargate 服務之後，迅速在業界引起了巨大的反響。EKS on Fargate 的設計跟 Serverless Kubernetes 是類似的，主要差異點在于它并沒有使用 Virtual Kubelet 來直接去掉 Node 的概念，而是依然使用 kubelet 向 Fargate 服務申請 EC2 虛拟機當 Pod 用，進而更好的保留了 Kubernetes 功能完整度。這種方式，我們可以稱作 Serverless Infrastructure，即：一個不需要關心底層基礎設施細節的 Kubernetes。

實際上，在 2019 年中旬，阿裡就已經在 Kubernetes 社群提出了 Virtual Cluster 架構。它的核心思想是，在一個“基礎 Kubernetes 叢集（元叢集）”上，可以“虛拟出”無數個完整的 Kubernetes 叢集來給不同的租戶使用。可以看到，這個思路跟 EKS on Fargate 的設計不謀而合但走的更遠：Fargate 目前需要通過 EC2 虛拟機和對應的虛拟機管控系統來實作容器運作時的隔離，而 Virtual Cluster 則直接通過 KataContainers 使得所有租戶可以安全的共享同一個主控端，進而大大提高了資源使用率（這也正是 KataContainers 最大的魅力所在）。不過，相信很快 EKS on Fargate 也會通過 Firecracker 逐漸走向 Virtual Cluster 架構。與 Virtual Cluster 類似的另一個商業産品，就是 VMware 的 Project Pacific：它通過“魔改” kubelet，在 vSphere 之上實作了“虛拟出” 租戶 Kubernetes 叢集的目的。

作為開源界的 EKS on Farge 和 Project Pacific，Virtual Cluster 目前是 Kubernetes 上遊多租工作組的核心孵化項目并且已經進行過多次 PoC，非常值得關注。

建構 “以應用為中心”的運維體系

從 Nodeless 到 Virtual Cluster，2019 年的雲原生生态正在全力以赴的解決基礎設施工程師的煩惱。不過，更加重要的運維工程師和業務研發所面臨的問題，卻似乎一直被忽視至今。要知道，他們其實才是抱怨“Kubernetes 複雜”的主要群體。

這裡的本質問題在于，Kubernetes 項目的定位是“The Platform for Platform”，是以它的核心功能原語服務的對象是基礎設施工程師，而不是運維和研發；它的聲明式 API 設計、CRD Operator 體系，也是為了友善基礎設施工程師接入和建構新基礎設施能力而設計的。這就導緻作為這些能力的使用者和終端受益者，運維工程師和業務研發實際上跟 Kubernetes 核心定位之間存在着明顯的錯位；而現有的運維體系和系統，跟 Kubernetes 體系之間也存在着巨大的鴻溝。

為了解決這個問題，很多公司群組織落地 Kubernetes 的時候實際上采用了“ PaaS 化”的思路，即：在 Kubernetes 之上再建構一個 PaaS 系統，通過 PaaS API（或者 UI）把 Kubernetes 跟業務運維和業務研發隔離開來。這樣做的好處在于，Kubernetes 的基礎設施能力真的就變成了“基礎設施”：業務運維和研發真正學習和使用的是這個 PaaS，Kubernetes 的“複雜性”問題也迎刃而解了。

但這種做法從本質上來說，其實跟 Kubernetes “以應用為中心”的設計是不一緻的。Kubernetes 一旦退化成了“類 IaaS 基礎設施”，它的聲明式 API、容器設計模式、控制器模型就根本無法發揮出原本的實力，也很難接入到更廣泛的生态。在 Kubernetes 的世界裡，傳統 PaaS 提供的各項能力比如 CI/CD、應用打包托管、釋出擴容，現在都可以通過一個個的 CRD Controller 的方式作為插件部署在 Kubernetes 當中，這跟應用基礎設施“下沉”的過程其實是類似的。

當然，在這個過程中，這些插件就成了如何将 Kubernetes 與現有的運維體系進行對接和融合的關鍵所在。比如：如何做應用原地更新、固定 IP，如何避免 Pod 被随意驅逐，如何按照公司運維規範統一管理和釋出 Sidecar 容器等等。在 2019 年 KubeCon 上海，自定義工作負載開源項目 OpenKruise 的釋出，其實正是 Kubernetes 與現有運維體系成功對接的典型案例。一句話：在現代雲原生技術體系當中，“運維能力”可以直接通過聲明式 API 和控制器模型成為 Kubernetes 基礎設施的一部分。是以在大多數情況下，其實并不需要一個運維 PaaS 的存在。

但是，即使做到了“運維能力”雲原生化這一點，“以應用為中心”的基礎設施其實也才剛剛起步。

把“以應用為中心”進行到底

跟傳統中間件從業務研發視角出發不同，雲原生乃至整個應用基礎設施“下沉”的革命，是從底向上開始的。它起始于 Google Borg/Omega 這樣比“雲計算”還要底層的容器基礎設施建構理念，然後逐層向上透出“以應用為中心”的設計思想。出于基礎設施本身與生俱來的高門檻和聲明式應用管理理論被接納的速度，直到 2019 年，社群對 Kubernetes 體系的認識其實才剛剛從“類 IaaS 基礎設施”、“資源管理與排程”，堪堪上升到“以應用為中心的運維能力”的次元上來。

當然，這次“以應用為中心”的技術革命，一定不會在“運維”這個節點就戛然而止。那麼接下來呢？

實際上，聲明式 API 和控制器化，是将底層基礎設施能力和運維能力接入 Kubernetes 的手段但并非目的。Kubernetes 打造“以應用為中心”的基礎設施真正希望達成的目标，是讓”應用“變成基礎設施中的絕對主角，讓基礎設施圍繞“應用”建構和發揮作用，而不是反之。

具體來說，在下一代“以應用為中心”的基礎設施當中，業務研發通過聲明式 API 定義的不再是具體的運維配置（比如：副本數是 10 個），而是“我的應用期望的最大延時是 X ms”。接下來的事情，就全部會交給 Kubernetes 這樣的應用基礎設施來保證明際狀态與期望狀态的一緻，這其中，副本數的設定隻是後續所有自動化操作中的一個環節。隻有讓 Kubernetes 允許研發通過他自己的視角來定義應用，而不是定義 Kubernetes API 對象，才能從根本上的解決 Kubernetes 的使用者“錯位”帶來的各種問題。

而對于業務運維來說，下一代“以應用為中心”的基礎設施，必須能夠從應用的視角對運維能力進行封裝和再發現，而不是直接讓運維人員去學習和操作各種底層基礎設施插件。**舉個例子，對于 kube-ovn 這樣一個 Kubernetes 網絡插件來說，運維人員拿到的不再是 kube-ovn 本身的使用文檔或者 CRD，而是這個插件能夠提供的一系列運維能力的聲明式描述，比如：“動态 QoS 配置 CRD”、“子網隔離配置 CRD”。然後，運維人員隻需要通過這些聲明式 API ，為某個應用綁定它所需要的動态 QoS 和子網隔離的具體政策值即可。剩下的所有事情就全交給 Kubernetes 了。

這樣，在底層基礎設施層逐漸 Serverless 化、運維能力也越來越多的接入到 Kubernetes 體系當中之後，雲原生的下一站将會繼續朝着“把以應用為中心進行到底”的方向不斷邁進。

在 2019 年 4 月，Google Cloud 釋出了 Cloud Run 服務，第一次把 Serverless Application 的概念呈現給大衆。2019 年 9 月，CNCF 宣布成立應用傳遞領域小組，宣布将“應用傳遞”作為雲原生生态的第一等公民。 2019 年 10 月，Microsoft 釋出了基于 Sidecar 的應用中間件項目 Dapr ，把“面向 localhost 程式設計”變成了現實。

而在 2019 年 10 月，阿裡巴巴則聯合 Microsoft 共同釋出了 Open Application Mode（OAM）項目，第一次對“以應用為中心”的基礎設施和建構規範進行了完整的闡述。在 2019 年，我們已經能夠切實感受到一場新的雲計算革命正在興起。在這場革命的終态，任何一個符合“以應用為中心“規範的軟體，将能夠從研發而不是基礎設施的視角自描述出自己的所有屬性，以及自己運作所需要所有的運維能力和外部依賴。

這樣的應用才能做到天生就是 Serverless Application：它可以被“自動比對”到任何一個滿足需求的“以應用為中心”的運作平台上去運作，我們不再需要關心任何基礎設施層面的細節和差異性。

總結

2019 年，在 Kubernetes 技術體系的規模性問題逐漸解決之後，整個雲原生生态正在積極的思考和探索如何達成雲原生技術理念“以應用為中心”的最終願景。而從 Serverless Infrastructure 到 Serverless Application，我們已經看到雲原生技術棧正在迅速朝“應用”為中心聚攏和收斂。我們相信在不久的未來，一個應用要在世界上任何一個地方運作起來，唯一要做的，就是聲明“我是什麼”，“我要什麼”。在這個時候，所有的基礎設施概念包括 Kubernetes、Istio、Knative 都會“消失不見”：就跟 Linux Kernel 一樣。

我們拭目以待。

“阿裡巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”