【開發者成長】喧譁的背後：Serverless 的挑戰

雲棲號資訊：【 點擊查看更多行業資訊】 在這裏您能夠找到不一樣行業的第一手的上雲資訊，還在等什麼，快來！

---

導讀：本文做者做爲阿里集團 Serverless 研發運維平臺負責人，從應用架構的角度去分析 Serverless 爲什麼會讓那麼多人着迷，它的核心概念到底是什麼，並總結了一些落地 Serverless 必然會面臨的問題。

前言

我曾在《Serverless 的喧譁與騷動》一文中對 Serverless 今天在行業中所處的狀態作了一個比喻，這個比喻是這麼說的：

雖然距離寫那篇文章已通過去了半年的時間，可是這種狀態在我看來其實沒有發生太大的變化，有不少的一線研發或者管理者對 Serverless 技術的理解是很是片面的，有些甚至是錯誤的。若是缺少對應用架構演進的理解，缺少對於雲基礎設施能力的理解，缺少對風險的判斷，盲目的上新技術可能不只沒法兌現業務價值，浪費精力，然而會引入無謂的技術風險。

本文嘗試從應用架構的角度，去分析 Serverless 爲什麼會讓那麼多人着迷，它的核心概念到底是什麼，以及從我我的的實際經驗出發，總結一些落地 Serverless 必然會面臨的問題。

應用架構的演進

爲了能更好的理解 Serverless，讓咱們先來回顧一下應用架構的演進方式。十多年前主流的應用架構都是單體應用，部署形式就是一臺服務器加一個數據庫，在這種架構下，運維人員會當心翼翼地維護這臺服務器，以保證服務的可用性。隨着業務的增加，這種最簡單的架構很快會面臨兩個問題。首先，這裏只有一臺服務器，若是這臺服務器出現故障，例如硬件損壞，那麼整個服務就會不可用；其次，業務量變大以後，一臺服務器的資源很快會沒法承載全部流量。解決這兩個問題的最直接方法就是在流量入口加一個負載均衡器，同時單體應用同時部署到多臺服務器上，這樣服務器的單點問題就解決了，同時這個單體應用也具有了水平伸縮的能力。

業務進一步增加，更多的研發人員加入到團隊，一塊兒在單體應用上開發特性。這個時候因爲單體應用內的代碼沒有明確的物理邊界，你們很快就會遇到各類衝突，須要人工的協調，以及大量的 conflict merge 操做，研發效率直線降低。這個時候你們就開始把單體應用拆分紅一個個能夠獨立開發、獨立測試、獨立部署的微服務應用，服務和服務之間經過 API 通信，如 HTTP，GRPC 或者 DUBBO。基於領域驅動設計中 Bounded Context 拆分的微服務架構可以大幅提高中大型團隊的研發效率，若是想了解關於 Bounded Context 的更多內容，推薦你們閱讀領域驅動設計相關的書籍。

應用從單體架構演進到微服務架構，從物理的角度看，分佈式就成了默認選項了，這個時候應用架構師就不得不面對分佈式帶來的新挑戰。在這個過程當中你們都會開始使用一些分佈式服務和框架，例如緩存服務 Redis，配置服務 ACM，狀態協調服務 ZooKeeper，消息服務 Kafka，還有通信框架如 GRPC 或者 DUBBO，以及分佈式追蹤系統等等，這裏就不逐一羅列了。除了分佈式環境帶來的挑戰以外，微服務架構給運維帶來的新的挑戰。研發人員原來只須要運維一個應用，如今可能就須要十個甚至更多的應用的，這意味着安全 patch 升級，容量評估，故障診斷等事務工做量成倍的增加，這個時候，應用分發的標準，生命週期的標準，觀測的標準，自動化彈性等能力的重要性就凸顯出來。

如今讓咱們談下「雲原生」這個詞，簡單的理解，一個架構是不是雲原生，就是看這個架構是不是長在雲上的。這個「長在」雲上的理解不是簡單的說用雲的 IaaS 層服務，好比簡單的 ECS，OSS 這些基本的計算存儲；而是應該理解成有沒有使用雲上的分佈式服務，好比 Redis，Kafka 等等，這些服務纔是直接會直接影響到業務架構的。前面咱們說到，微服務架構下，分佈式服務是必要的，原來你們都是本身研發這樣的服務，或者基於開源版本本身運維這樣的服務，而到了雲原生的時代，業務就直接使用雲服務了。

另外兩個不得不提的技術就是 Docker 和 Kubenetes，其中前者標準化了應用分發的標準，不管是 Spring Boot 寫的應用，仍是 NodeJS 寫的應用，都以鏡像的方式分發；然後者在前者的技術上又定義了應用生命週期的標準，一個應用從啓動到上線，到健康檢查，下線，有了統一的標準。有了應用分發的標準和生命週期的標準，雲就能提供標準化的應用託管服務。包括應用的版本管理，發佈，上線後的觀測，自愈等等。例如對於無狀態的應用來講，一個底層物理節點的故障根本就不會影響到研發，由於應用託管服務基於標準化應用生命週期能夠自動完成騰挪工做，在故障物理節點上將應用的容器下線，在新的物理節點上啓動同等數量的應用容器。咱們看到，雲原生進一步的釋放了價值紅利。

在此基礎上，因爲應用託管服務可以感知到應用運行期的數據，例如業務流量的併發，cpu load，內存佔用等等，業務就能夠配置基於這些指標的伸縮規則，由平臺執行這些規則，根據業務流量的實際狀況增長或者減小容器數量，這就是最基本的 auto scaling，自動伸縮。這就可以幫助用戶避免在業務低峯期限制資源，節省成本，提高運維效率。

在架構的演進過程當中，研發運維人員在逐漸的把關注點從機器上移走，但願更多地由平臺系統管理機器，而不是由人去管理，這就是一個很樸素的 Serverless 理解。

Serverless 的核心概念

其實咱們都知道，雖說是 Serverless，但 Server（服務器）是不可能真正消失的，Serverless 裏這個 less 更確切的說是開發不用關心的意思。這就比如現代編程語言 Java 和 Python，開發就不用手工分配和釋放內存了，但內存還在哪裏，只不過交給垃圾收集器管理了。稱一個能幫助你管理服務器的平臺爲 Serverless 平臺，就比如稱呼 Java 和 Python 爲 Memoryless 語言同樣。

若是咱們把目光放到今天雲的時代，那麼就不能狹義地把 Serverless 僅僅理解成爲不用關心服務器。雲上的資源除了服務器所包含的基礎計算、網絡、存儲資源以外，還包括各類類別的更上層的資源，例如數據庫、緩存、消息等等。

2019年2月，UC 伯克利大學發表了一篇標題爲《Cloud Programming Simplified: A Berkeley View on Serverless Computing》的論文，論文中也有一個很是清晰形象的比喻，文中這樣描述：

在雲的上下文中，Serverful 的計算就像使用低級的彙編語言編程，而 Serverless 的計算就像使用 Python 這樣的高級語言進行編程。例如如 c = a + b 這樣簡單的表達式，若是用匯編描述，就必須先選擇幾個寄存器，把值加載到寄存器，進行數學計算，再存儲結果。這就比如今天在雲環境下 Serverful 的計算，開發首先須要分配或找到可用的資源，而後加載代碼和數據，再執行計算，將計算的結果存儲起來，最後還須要管理資源的釋放。

論文中所謂的 Serverful 計算，是咱們今天主流的使用雲的方式，但不該該是將來咱們使用雲的方式。我認爲 Serverless 的願景應該是 Write locally, compile to the cloud，即代碼只關心業務邏輯，由工具和雲去管理資源。如今咱們對 Serverless 有了一個比較整體但抽象的概念，下面我再具體介紹一下 Serverless 平臺的主要特色。

第一：不用關心服務器

管理一兩臺服務器可能不是什麼麻煩的事情，管理數千甚至數萬臺服務器就沒那麼簡單了。任何一臺服務器均可能出現故障，若是自動識別故障，摘除有問題的實例，這是 Serverless 平臺必須具有的能力；此外，操做系統的安全補丁升級，須要作到不影響業務，自動完成；日誌和監控系統須要默認打通；系統的安全策略須要自動配置好以免風險；當資源不夠的時候，須要可以自動分配資源並安裝相關的代碼和配置，等等。

第二：自動彈性

今天的互聯網應用都被設計成可以按可伸縮的架構，當業務有比較明顯的高峯和低谷的時候，或者業務有臨時的容量需求的時候（好比營銷活動），Serverless 平臺都可以及時且穩定的實現自動彈性。爲了實現這個能力，平臺須要有很是強大的資源調度能力，以及對應用各項指標（如 load，併發）很是敏銳的感知能力。

第三：按實際資源使用計費

Serverful 的方式使用雲資源，是按佔用而非使用計費的，用戶在雲上購買了三臺 ECS，那麼無論用戶實際使用了這三臺 ECS 多少的 CPU 和內存，他都須要支付這三臺 ECS 總體的費用。Serverless 模式下，用戶是按實際使用的資源付費的，例如一個請求實際使用了一臺 1core2g 規格資源 100ms 的時間，那麼用戶就只須要爲該規格的單價乘以時間（即100ms）付費。相似的，用戶若是用的是 Serverless 數據庫，那麼就只須要爲 query 實際消耗的資源，以及數據存儲的資源付費。

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

基於 Serverless 架構的代碼一般會重度使用後端的服務，將數據、狀態管理等內容從代碼中分離出去；此外，更完全的 FaaS 架構則把代碼的 Runtime 也交給了平臺管理。這就意味着，一樣的應用，Serverless 模式下的代碼相比 Serverful 模式會少不少，所以不管是從分發仍是啓動，都會更快。Serverless 平臺也一般提供很是成熟的代碼構建發佈，版本切換等特性，提高交付速度。

實現 Serverless 面臨的挑戰

講了那麼多 Serverless 的好處，可是實際要在主流的場景大規模的落地 Serverless，並非一件容易的事情，面臨的挑戰有不少，下面我具體分析一下這些挑戰：

挑戰一：業務輕量化困難

要實現完全的自動彈性，按實際使用資源付費，就意味着平臺須要可以在秒級甚至毫秒級別擴容出業務實例。這對基礎設施是一個挑戰，對業務，尤爲是比較龐大的業務應用來講，更提出了很高的要求。若是一個應用的分發和啓動須要十分鐘，那麼自動彈性的響應能力就基本沒法跟上業務流量的變化了。解決這個問題有不少方法，微服務化可以把巨型應用拆小；而 FaaS 就經過一種全新的應用架構，把應用拆分紅更細粒度的函數來作到輕量化，固然，這種方法的缺點是須要業務作比較大的改造。對於 Java 語言來講，Java 9 引入的 modules，以及 GraalVM 的 native image 技術都可以幫助 Java 應用程序瘦身，下降啓動時間。

挑戰二：基礎設施響應能力不足

一旦 Serverless 的應用或者函數的實例可以實現秒級，甚至毫秒級擴容，相關基礎設施就很快會面臨巨大的壓力。最多見的基礎設施就是服務發現和日誌監控系統，本來整個集羣實例的變化頻率多是每小時幾回，如今這個頻率變成了每秒幾回；此外，若是這些系統的響應能力跟不上實例變化的速度，例如對於業務來講，容器實例 2 秒就完成了擴容，但還須要等待 10 秒服務發現才能完成同步，那麼整個體驗也就大打折扣了。

挑戰三：業務進程生命週期與容器不一致

Serverless 平臺依賴標準化的應用生命週期，才能實現徹底自動的容器騰挪，應用自愈等特性。而在基於標準容器及 Kubenetes 的體系下，平臺能控制的生命週期就是容器的生命週期。所以就須要業務作到業務進程的生命週期和容器的生命週期保持一致，具體包括啓動、中止、以及 readiness probe 和 liveness probe 的規範等等。在實際狀況中，不少業務雖然作了容器化改造，但實際上容器中除了包含業務主進程以外，還包括不少輔助進程，這也會致使業務進程和容器的生命週期不一致。

挑戰四：可觀測能力需完善

在 Serverful 的模式下，若是生產環境出現任何問題，服務器是不會消失的，用戶會很天然的想到登錄到服務器上去，操做 linux 命令，搜索日誌，分析進程，甚至 dump 內存來進行問題分析。到了 Serverless 模式下，咱們說用戶不須要關心服務器了，也就是說默認狀況下是看不到服務器了，那麼這個時候若是系統出現異常了，並且平臺沒法完成自愈怎麼辦呢？用戶仍是須要有豐富的排查診斷工具，可以觀測到包括流量、系統指標、依賴服務等等各方面綜合的狀態，以實現快速準確的問題診斷。當圍繞 Serverless 模式的全面可觀測能力不足的時候，用戶必然不會對此感到放心。

挑戰五：研發運維心智須要改變

幾乎全部的研發，在職業生涯中第一次部署本身的應用程序的時候，都是面向一臺服務器的，或者說是面向一個 IP 的，這是一種很是強大的習慣。今天咱們依然能看到不少的應用程序仍是有狀態的，沒法作到自動更換實例；也能看到不少的變動部署行爲和 IP 綁定了起來，例如單獨選一臺特定的機器作 Beta 等等；還有許多發佈系統，在作 Rolling Update 的時候，是不會更換實例的，相關的運維繫統也就基於這個假設建設能力了。在 Serverless 逐漸落地的過程當中，研發須要轉換一些思惟的模式，逐步地去適應 「IP 隨時可能會發生變化」 這樣一種心智，轉而更多的從服務版本，以及從流量的視角去運維本身的系統。

小結

讓咱們回到《Cloud Programming Simplified: A Berkeley View on Serverless Computing》論文中那個精彩的比喻：今天咱們使用雲就像是用匯編寫代碼。我認爲這種現狀會不斷地得以改觀，理想狀況下，用戶交付給平臺部署的包中，應該 100% 是用戶描述業務的代碼。雖然現狀遠不是那樣，不過能夠看到不少技術，如 Service Mesh，Dapr.io，cloudsteate.io，都在把與業務無關的，可是分佈式架構又必須的邏輯，從業務的運行時中剝離出去，交給平臺管理。這種趨勢在最近一年中逐漸清晰和強烈，對此 Bilgin Ibryam 在《Multi-Runtime Microservices Architecture》一文中作了很好的總結，一併推薦閱讀。

本文中咱們看到 Serverless 的演進對應用架構，到持續交付，服務治理、運維監控都提出了新的要求，其實除此以外，Serverless 也會對計算存儲網絡等更底層的技術設施提出更高的響應能力要求。所以，這實際上是一次貫穿應用、平臺、基礎設施多個層面的，比較完全的技術演進，有幸參與其中，我以爲仍是很是興奮的。

爲了更多開發者可以享受到 Serverless 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。

【雲棲號在線課堂】天天都有產品技術專家分享！ 課程地址： https://yqh.aliyun.com/live 當即加入社羣，與專家面對面，及時瞭解課程最新動態！ 【雲棲號在線課堂 社羣】 https://c.tb.cn/F3.Z8gvnK

原文發佈時間：2020-05-06 本文做者：阿里巴巴雲原生 本文來自：「掘金」，瞭解相關信息能夠關注「掘金」