喧嘩的背后：Serverless 的概念及挑戰(zhàn)

作者 | 許曉斌 阿里云高級(jí)技術(shù)專家，目前負(fù)責(zé)阿里集團(tuán) Serverless 研發(fā)運(yùn)維平臺(tái)建設(shè)，《Maven 實(shí)戰(zhàn)》作者，曾經(jīng)是 Maven 中央倉庫的維護(hù)者。

導(dǎo)讀：本文作者作為阿里集團(tuán) Serverless 研發(fā)運(yùn)維平臺(tái)負(fù)責(zé)人，從應(yīng)用架構(gòu)的角度去分析 Serverless 為何會(huì)讓那么多人著迷，它的核心概念究竟是什么，并總結(jié)了一些落地 Serverless 必然會(huì)面臨的問題。

前言

我曾在 《Serverless 的喧嘩與騷動(dòng)》一文中對(duì) Serverless 今天在行業(yè)中所處的狀態(tài)做了一個(gè)比喻，這個(gè)比喻是這么說的：

Serverless is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.

雖然距離寫那篇文章已經(jīng)過去了半年的時(shí)間，但是這種狀態(tài)在我看來其實(shí)沒有發(fā)生太大的變化，有很多的一線研發(fā)或者管理者對(duì) Serverless 技術(shù)的理解是非常片面的，有些甚至是錯(cuò)誤的。如果缺乏對(duì)應(yīng)用架構(gòu)演進(jìn)的理解，缺乏對(duì)于云基礎(chǔ)設(shè)施能力的理解，缺乏對(duì)風(fēng)險(xiǎn)的判斷，盲目的上新技術(shù)可能不僅無法兌現(xiàn)業(yè)務(wù)價(jià)值，浪費(fèi)精力，然而會(huì)引入無謂的技術(shù)風(fēng)險(xiǎn)。

本文嘗試從應(yīng)用架構(gòu)的角度，去分析 Serverless 為何會(huì)讓那么多人著迷，它的核心概念究竟是什么，以及從我個(gè)人的實(shí)際經(jīng)驗(yàn)出發(fā)，總結(jié)一些落地 Serverless 必然會(huì)面臨的問題。

應(yīng)用架構(gòu)的演進(jìn)

為了能更好的理解 Serverless，讓我們先來回顧一下應(yīng)用架構(gòu)的演進(jìn)方式。十多年前主流的應(yīng)用架構(gòu)都是單體應(yīng)用，部署形式就是一臺(tái)服務(wù)器加一個(gè)數(shù)據(jù)庫，在這種架構(gòu)下，運(yùn)維人員會(huì)小心翼翼地維護(hù)這臺(tái)服務(wù)器，以保證服務(wù)的可用性。隨著業(yè)務(wù)的增長(zhǎng)，這種最簡(jiǎn)單的架構(gòu)很快會(huì)面臨兩個(gè)問題。首先，這里只有一臺(tái)服務(wù)器，如果這臺(tái)服務(wù)器出現(xiàn)故障，例如硬件損壞，那么整個(gè)服務(wù)就會(huì)不可用；其次，業(yè)務(wù)量變大之后，一臺(tái)服務(wù)器的資源很快會(huì)無法承載所有流量。解決這兩個(gè)問題的最直接方法就是在流量入口加一個(gè)負(fù)載均衡器，同時(shí)單體應(yīng)用同時(shí)部署到多臺(tái)服務(wù)器上，這樣服務(wù)器的單點(diǎn)問題就解決了，同時(shí)這個(gè)單體應(yīng)用也具備了水平伸縮的能力。

業(yè)務(wù)進(jìn)一步增長(zhǎng)，更多的研發(fā)人員加入到團(tuán)隊(duì)，一起在單體應(yīng)用上開發(fā)特性。這個(gè)時(shí)候由于單體應(yīng)用內(nèi)的代碼沒有明確的物理邊界，大家很快就會(huì)遇到各種沖突，需要人工的協(xié)調(diào)，以及大量的 conflict merge 操作，研發(fā)效率直線下降。這個(gè)時(shí)候大家就開始把單體應(yīng)用拆分成一個(gè)個(gè)可以獨(dú)立開發(fā)、獨(dú)立測(cè)試、獨(dú)立部署的微服務(wù)應(yīng)用，服務(wù)和服務(wù)之間通過 API 通訊，如 HTTP，GRPC 或者 DUBBO?；陬I(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中 Bounded Context 拆分的微服務(wù)架構(gòu)能夠大幅提升中大型團(tuán)隊(duì)的研發(fā)效率，如果想了解關(guān)于 Bounded Context 的更多內(nèi)容，推薦大家閱讀領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)相關(guān)的書籍。

應(yīng)用從單體架構(gòu)演進(jìn)到微服務(wù)架構(gòu)，從物理的角度看，分布式就成了默認(rèn)選項(xiàng)了，這個(gè)時(shí)候應(yīng)用架構(gòu)師就不得不面對(duì)分布式帶來的新挑戰(zhàn)。在這個(gè)過程中大家都會(huì)開始使用一些分布式服務(wù)和框架，例如緩存服務(wù) Redis，配置服務(wù) ACM，狀態(tài)協(xié)調(diào)服務(wù) ZooKeeper，消息服務(wù) Kafka，還有通訊框架如 GRPC 或者 DUBBO，以及分布式追蹤系統(tǒng)等等，這里就不逐一羅列了。除了分布式環(huán)境帶來的挑戰(zhàn)之外，微服務(wù)架構(gòu)給運(yùn)維帶來的新的挑戰(zhàn)。研發(fā)人員原來只需要運(yùn)維一個(gè)應(yīng)用，現(xiàn)在可能就需要十個(gè)甚至更多的應(yīng)用的，這意味著安全 patch 升級(jí)，容量評(píng)估，故障診斷等事務(wù)工作量成倍的增長(zhǎng)，這個(gè)時(shí)候，應(yīng)用分發(fā)的標(biāo)準(zhǔn)，生命周期的標(biāo)準(zhǔn)，觀測(cè)的標(biāo)準(zhǔn)，自動(dòng)化彈性等能力的重要性就凸顯出來。

現(xiàn)在讓我們談下“云原生”這個(gè)詞，簡(jiǎn)單的理解，一個(gè)架構(gòu)是否是云原生，就是看這個(gè)架構(gòu)是否是長(zhǎng)在云上的。這個(gè)“長(zhǎng)在”云上的理解不是簡(jiǎn)單的說用云的 IaaS 層服務(wù)，比如簡(jiǎn)單的 ECS，OSS 這些基本的計(jì)算存儲(chǔ)；而是應(yīng)該理解成有沒有使用云上的分布式服務(wù)，比如 Redis，Kafka 等等，這些服務(wù)才是直接會(huì)直接影響到業(yè)務(wù)架構(gòu)的。前面我們說到，微服務(wù)架構(gòu)下，分布式服務(wù)是必要的，原來大家都是自己研發(fā)這樣的服務(wù)，或者基于開源版本自己運(yùn)維這樣的服務(wù)，而到了云原生的時(shí)代，業(yè)務(wù)就直接使用云服務(wù)了。

另外兩個(gè)不得不提的技術(shù)就是 Docker 和 Kubenetes，其中前者標(biāo)準(zhǔn)化了應(yīng)用分發(fā)的標(biāo)準(zhǔn)，不論是 Spring Boot 寫的應(yīng)用，還是 NodeJS 寫的應(yīng)用，都以鏡像的方式分發(fā)；而后者在前者的技術(shù)上又定義了應(yīng)用生命周期的標(biāo)準(zhǔn)，一個(gè)應(yīng)用從啟動(dòng)到上線，到健康檢查，下線，有了統(tǒng)一的標(biāo)準(zhǔn)。有了應(yīng)用分發(fā)的標(biāo)準(zhǔn)和生命周期的標(biāo)準(zhǔn)，云就能提供標(biāo)準(zhǔn)化的應(yīng)用托管服務(wù)。包括應(yīng)用的版本管理，發(fā)布，上線后的觀測(cè)，自愈等等。例如對(duì)于無狀態(tài)的應(yīng)用來說，一個(gè)底層物理節(jié)點(diǎn)的故障根本就不會(huì)影響到研發(fā)，因?yàn)閼?yīng)用托管服務(wù)基于標(biāo)準(zhǔn)化應(yīng)用生命周期可以自動(dòng)完成騰挪工作，在故障物理節(jié)點(diǎn)上將應(yīng)用的容器下線，在新的物理節(jié)點(diǎn)上啟動(dòng)同等數(shù)量的應(yīng)用容器。我們看到，云原生進(jìn)一步的釋放了價(jià)值紅利。

在此基礎(chǔ)上，由于應(yīng)用托管服務(wù)能夠感知到應(yīng)用運(yùn)行期的數(shù)據(jù)，例如業(yè)務(wù)流量的并發(fā)，cpu load，內(nèi)存占用等等，業(yè)務(wù)就可以配置基于這些指標(biāo)的伸縮規(guī)則，由平臺(tái)執(zhí)行這些規(guī)則，根據(jù)業(yè)務(wù)流量的實(shí)際情況增加或者減少容器數(shù)量，這就是最基本的 auto scaling，自動(dòng)伸縮。這就能夠幫助用戶避免在業(yè)務(wù)低峰期限制資源，節(jié)省成本，提升運(yùn)維效率。

在架構(gòu)的演進(jìn)過程中，研發(fā)運(yùn)維人員在逐漸的把關(guān)注點(diǎn)從機(jī)器上移走，希望更多地由平臺(tái)系統(tǒng)管理機(jī)器，而不是由人去管理，這就是一個(gè)很樸素的 Serverless 理解。

Serverless 的核心概念

其實(shí)我們都知道，雖然說是 Serverless，但 Server（服務(wù)器）是不可能真正消失的，Serverless 里這個(gè) less 更確切的說是開發(fā)不用關(guān)心的意思。這就好比現(xiàn)代編程語言 Java 和 Python，開發(fā)就不用手工分配和釋放內(nèi)存了，但內(nèi)存還在哪里，只不過交給垃圾收集器管理了。稱一個(gè)能幫助你管理服務(wù)器的平臺(tái)為 Serverless 平臺(tái)，就好比稱呼 Java 和 Python 為 Memoryless 語言一樣。

如果我們把目光放到今天云的時(shí)代，那么就不能狹義地把 Serverless 僅僅理解成為不用關(guān)心服務(wù)器。云上的資源除了服務(wù)器所包含的基礎(chǔ)計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)資源之外，還包括各種類別的更上層的資源，例如數(shù)據(jù)庫、緩存、消息等等。

2019年2月，UC 伯克利大學(xué)發(fā)表了一篇標(biāo)題為 《Cloud Programming Simplified: A Berkeley View on Serverless Computing》的論文，論文中也有一個(gè)非常清晰形象的比喻，文中這樣描述：

在云的上下文中，Serverful 的計(jì)算就像使用低級(jí)的匯編語言編程，而 Serverless 的計(jì)算就像使用 Python 這樣的高級(jí)語言進(jìn)行編程。例如如 c = a + b 這樣簡(jiǎn)單的表達(dá)式，如果用匯編描述，就必須先選擇幾個(gè)寄存器，把值加載到寄存器，進(jìn)行數(shù)學(xué)計(jì)算，再存儲(chǔ)結(jié)果。這就好比今天在云環(huán)境下 Serverful 的計(jì)算，開發(fā)首先需要分配或找到可用的資源，然后加載代碼和數(shù)據(jù)，再執(zhí)行計(jì)算，將計(jì)算的結(jié)果存儲(chǔ)起來，最后還需要管理資源的釋放。

論文中所謂的 Serverful 計(jì)算，是我們今天主流的使用云的方式，但不應(yīng)該是未來我們使用云的方式。我認(rèn)為 Serverless 的愿景應(yīng)該是 Write locally, compile to the cloud，即代碼只關(guān)心業(yè)務(wù)邏輯，由工具和云去管理資源?，F(xiàn)在我們對(duì) Serverless 有了一個(gè)比較總體但抽象的概念，下面我再具體介紹一下 Serverless 平臺(tái)的主要特點(diǎn)。

第一：不用關(guān)心服務(wù)器

管理一兩臺(tái)服務(wù)器可能不是什么麻煩的事情，管理數(shù)千甚至數(shù)萬臺(tái)服務(wù)器就沒那么簡(jiǎn)單了。任何一臺(tái)服務(wù)器都可能出現(xiàn)故障，如果自動(dòng)識(shí)別故障，摘除有問題的實(shí)例，這是 Serverless 平臺(tái)必須具備的能力；此外，操作系統(tǒng)的安全補(bǔ)丁升級(jí)，需要做到不影響業(yè)務(wù)，自動(dòng)完成；日志和監(jiān)控系統(tǒng)需要默認(rèn)打通；系統(tǒng)的安全策略需要自動(dòng)配置好以避免風(fēng)險(xiǎn)；當(dāng)資源不夠的時(shí)候，需要能夠自動(dòng)分配資源并安裝相關(guān)的代碼和配置，等等。

第二：自動(dòng)彈性

今天的互聯(lián)網(wǎng)應(yīng)用都被設(shè)計(jì)成能夠按可伸縮的架構(gòu)，當(dāng)業(yè)務(wù)有比較明顯的高峰和低谷的時(shí)候，或者業(yè)務(wù)有臨時(shí)的容量需求的時(shí)候（比如營銷活動(dòng)），Serverless 平臺(tái)都能夠及時(shí)且穩(wěn)定的實(shí)現(xiàn)自動(dòng)彈性。為了實(shí)現(xiàn)這個(gè)能力，平臺(tái)需要有非常強(qiáng)大的資源調(diào)度能力，以及對(duì)應(yīng)用各項(xiàng)指標(biāo)（如 load，并發(fā)）非常敏銳的感知能力。

第三：按實(shí)際資源使用計(jì)費(fèi)

Serverful 的方式使用云資源，是按占用而非使用計(jì)費(fèi)的，用戶在云上購買了三臺(tái) ECS，那么不管用戶實(shí)際使用了這三臺(tái) ECS 多少的 CPU 和內(nèi)存，他都需要支付這三臺(tái) ECS 整體的費(fèi)用。Serverless 模式下，用戶是按實(shí)際使用的資源付費(fèi)的，例如一個(gè)請(qǐng)求實(shí)際使用了一臺(tái) 1core2g 規(guī)格資源 100ms 的時(shí)間，那么用戶就只需要為該規(guī)格的單價(jià)乘以時(shí)間（即100ms）付費(fèi)。類似的，用戶如果用的是 Serverless 數(shù)據(jù)庫，那么就只需要為 query 實(shí)際消耗的資源，以及數(shù)據(jù)存儲(chǔ)的資源付費(fèi)。

第四：更少的代碼，更快的交付速度

基于 Serverless 架構(gòu)的代碼通常會(huì)重度使用后端的服務(wù)，將數(shù)據(jù)、狀態(tài)管理等內(nèi)容從代碼中分離出去；此外，更徹底的 FaaS 架構(gòu)則把代碼的 Runtime 也交給了平臺(tái)管理。這就意味著，同樣的應(yīng)用，Serverless 模式下的代碼相比 Serverful 模式會(huì)少很多，因此不論是從分發(fā)還是啟動(dòng)，都會(huì)更快。Serverless 平臺(tái)也通常提供非常成熟的代碼構(gòu)建發(fā)布，版本切換等特性，提升交付速度。

實(shí)現(xiàn) Serverless 面臨的挑戰(zhàn)

講了那么多 Serverless 的好處，但是實(shí)際要在主流的場(chǎng)景大規(guī)模的落地 Serverless，并不是一件容易的事情，面臨的挑戰(zhàn)有很多，下面我具體分析一下這些挑戰(zhàn)：

挑戰(zhàn)一：業(yè)務(wù)輕量化困難

要實(shí)現(xiàn)徹底的自動(dòng)彈性，按實(shí)際使用資源付費(fèi)，就意味著平臺(tái)需要能夠在秒級(jí)甚至毫秒級(jí)別擴(kuò)容出業(yè)務(wù)實(shí)例。這對(duì)基礎(chǔ)設(shè)施是一個(gè)挑戰(zhàn)，對(duì)業(yè)務(wù)，尤其是比較龐大的業(yè)務(wù)應(yīng)用來說，更提出了很高的要求。如果一個(gè)應(yīng)用的分發(fā)和啟動(dòng)需要十分鐘，那么自動(dòng)彈性的響應(yīng)能力就基本無法跟上業(yè)務(wù)流量的變化了。解決這個(gè)問題有很多方法，微服務(wù)化能夠把巨型應(yīng)用拆??；而 FaaS 就通過一種全新的應(yīng)用架構(gòu)，把應(yīng)用拆分成更細(xì)粒度的函數(shù)來做到輕量化，當(dāng)然，這種方法的缺點(diǎn)是需要業(yè)務(wù)做比較大的改造。對(duì)于 Java 語言來說，Java 9 引入的 modules，以及 GraalVM 的 native image 技術(shù)都能夠幫助 Java 應(yīng)用程序瘦身，降低啟動(dòng)時(shí)間。

挑戰(zhàn)二：基礎(chǔ)設(shè)施響應(yīng)能力不足

一旦 Serverless 的應(yīng)用或者函數(shù)的實(shí)例能夠?qū)崿F(xiàn)秒級(jí)，甚至毫秒級(jí)擴(kuò)容，相關(guān)基礎(chǔ)設(shè)施就很快會(huì)面臨巨大的壓力。最常見的基礎(chǔ)設(shè)施就是服務(wù)發(fā)現(xiàn)和日志監(jiān)控系統(tǒng)，原本整個(gè)集群實(shí)例的變化頻率可能是每小時(shí)幾次，現(xiàn)在這個(gè)頻率變成了每秒幾次；此外，如果這些系統(tǒng)的響應(yīng)能力跟不上實(shí)例變化的速度，例如對(duì)于業(yè)務(wù)來說，容器實(shí)例 2 秒就完成了擴(kuò)容，但還需要等待 10 秒服務(wù)發(fā)現(xiàn)才能完成同步，那么整個(gè)體驗(yàn)也就大打折扣了。

挑戰(zhàn)三：業(yè)務(wù)進(jìn)程生命周期與容器不一致

Serverless 平臺(tái)依賴標(biāo)準(zhǔn)化的應(yīng)用生命周期，才能實(shí)現(xiàn)完全自動(dòng)的容器騰挪，應(yīng)用自愈等特性。而在基于標(biāo)準(zhǔn)容器及 Kubenetes 的體系下，平臺(tái)能控制的生命周期就是容器的生命周期。因此就需要業(yè)務(wù)做到業(yè)務(wù)進(jìn)程的生命周期和容器的生命周期保持一致，具體包括啟動(dòng)、停止、以及 readiness probe 和 liveness probe 的規(guī)范等等。在實(shí)際情況中，很多業(yè)務(wù)雖然做了容器化改造，但實(shí)際上容器中除了包含業(yè)務(wù)主進(jìn)程之外，還包括很多輔助進(jìn)程，這也會(huì)導(dǎo)致業(yè)務(wù)進(jìn)程和容器的生命周期不一致。

挑戰(zhàn)四：可觀測(cè)能力需完善

在 Serverful 的模式下，如果生產(chǎn)環(huán)境出現(xiàn)任何問題，服務(wù)器是不會(huì)消失的，用戶會(huì)很自然的想到登陸到服務(wù)器上去，操作 linux 命令，搜索日志，分析進(jìn)程，甚至 dump 內(nèi)存來進(jìn)行問題分析。到了 Serverless 模式下，我們說用戶不需要關(guān)心服務(wù)器了，也就是說默認(rèn)情況下是看不到服務(wù)器了，那么這個(gè)時(shí)候如果系統(tǒng)出現(xiàn)異常了，而且平臺(tái)無法完成自愈怎么辦呢？用戶還是需要有豐富的排查診斷工具，能夠觀測(cè)到包括流量、系統(tǒng)指標(biāo)、依賴服務(wù)等等各方面綜合的狀態(tài)，以實(shí)現(xiàn)快速準(zhǔn)確的問題診斷。當(dāng)圍繞 Serverless 模式的全面可觀測(cè)能力不足的時(shí)候，用戶必然不會(huì)對(duì)此感到放心。

挑戰(zhàn)五：研發(fā)運(yùn)維心智需要改變

幾乎所有的研發(fā)，在職業(yè)生涯中第一次部署自己的應(yīng)用程序的時(shí)候，都是面向一臺(tái)服務(wù)器的，或者說是面向一個(gè) IP 的，這是一種非常強(qiáng)大的習(xí)慣。今天我們依然能看到很多的應(yīng)用程序還是有狀態(tài)的，無法做到自動(dòng)更換實(shí)例；也能看到很多的變更部署行為和 IP 綁定了起來，例如單獨(dú)選一臺(tái)特定的機(jī)器做 Beta 等等；還有許多發(fā)布系統(tǒng)，在做 Rolling Update 的時(shí)候，是不會(huì)更換實(shí)例的，相關(guān)的運(yùn)維系統(tǒng)也就基于這個(gè)假設(shè)建設(shè)能力了。在 Serverless 逐漸落地的過程中，研發(fā)需要轉(zhuǎn)換一些思維的模式，逐步地去適應(yīng) “IP 隨時(shí)可能會(huì)發(fā)生變化” 這樣一種心智，轉(zhuǎn)而更多的從服務(wù)版本，以及從流量的視角去運(yùn)維自己的系統(tǒng)。

小結(jié)

讓我們回到《Cloud Programming Simplified: A Berkeley View on Serverless Computing》論文中那個(gè)精彩的比喻：今天我們使用云就像是用匯編寫代碼。我認(rèn)為這種現(xiàn)狀會(huì)不斷地得以改觀，理想情況下，用戶交付給平臺(tái)部署的包中，應(yīng)該 100% 是用戶描述業(yè)務(wù)的代碼。雖然現(xiàn)狀遠(yuǎn)不是那樣，不過可以看到很多技術(shù)，如 Service Mesh，Dapr.io，cloudsteate.io，都在把與業(yè)務(wù)無關(guān)的，但是分布式架構(gòu)又必須的邏輯，從業(yè)務(wù)的運(yùn)行時(shí)中剝離出去，交給平臺(tái)管理。這種趨勢(shì)在最近一年中逐漸清晰和強(qiáng)烈，對(duì)此 Bilgin Ibryam 在 《Multi-Runtime Microservices Architecture》一文中做了很好的總結(jié)，一并推薦閱讀。

本文中我們看到 Serverless 的演進(jìn)對(duì)應(yīng)用架構(gòu)，到持續(xù)交付，服務(wù)治理、運(yùn)維監(jiān)控都提出了新的要求，其實(shí)除此之外，Serverless 也會(huì)對(duì)計(jì)算存儲(chǔ)網(wǎng)絡(luò)等更底層的技術(shù)設(shè)施提出更高的響應(yīng)能力要求。因此，這其實(shí)是一次貫穿應(yīng)用、平臺(tái)、基礎(chǔ)設(shè)施多個(gè)層面的，比較徹底的技術(shù)演進(jìn)，有幸參與其中，我覺得還是非常興奮的。

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計(jì)算的新范式——Serverless。

點(diǎn)擊即可免費(fèi)觀看課程： https://developer.aliyun.com/learning/roadmap/serverless

“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號(hào)?！?/p>