Serverless 只是未來 IT 形態的一部分 | 技術的盲從與清醒

嘉賓丨陳威采編丨木環InfoQ 的使命是促進軟體開發領域知識與創新的傳播。對於 Serverless 這個技術概念，我們有必要給大家做更加細緻、深入的科普。

Serverless 通常被直譯成「無伺服器」，乍一看來，會讓人立刻警覺到：這是不是一個「危險」的顛覆性技術？新技術的愛好者們會感到興奮，而保守派可能會隱隱地擔憂著是不是雲計算的新炒作。在 Serverless 呼聲漸起之時，InfoQ 採訪了在雲領域深耕十載的陳威，請他談談他對 serverless 的觀點看法。

在陳威看來，Serverless 並非銀彈，它只是雲計算在逐漸成熟之後的一個細分技術。新的技術層出不窮，但是技術人不能狂熱鼓吹也不要盲目跟從，要始終清醒地牢記「技術始終是為人服務的」。認知水平決定了一個技術人是能成為真正有效的推動者還是低效疲憊的跟風人。

陳威， Pivotal 雲計算資深架構師。加入 Pivotal 之前，曾先後就職於 IBM 研發中心，IBM 軟體集團信息管理部。擁有超過 10 年的經驗，熟悉主機平台、開放平台和三個世代的雲平台。擅長大數據和應用雲平台融合領域，參與設計過包括金融、電信、公共醫療等行業的大企業方案落地。各擁有一項 published 和 documented 的個人專利。

Serverless 一詞於 2012 年提出，AWS 在 2014 年推出了 Lamda 的 serverless 服務，2016 年倫敦舉辦了首屆 Serverless 大會。在這幾年的發展中，業界對 Serverless 的概念定義也逐漸清晰穩定下來。

最開始，Serverless 意在幫助開發者擺脫運行後端應用程序所需的伺服器設備的設置和管理工作。Serverless 通常被直譯成「無伺服器」，其實並不是真的沒有伺服器，而是後端伺服器的相關工作都交給第三供應商負責。彼時，大家對這個概念的認知是後端即服務（Backend-as-a-Service，BaaS），或移動後端即服務（Mobile Backend-as-a-service，MBaaS）。甚至有一種觀點是，只要使用了第三方雲服務就是 serverless 的一種。

但是，其實當初這種看法已經不準確了。第三方雲服務的範疇很廣，包含 IaaS, SaaS, PaaS 等三種，單純認為使用第三方雲服務就是 serverless 是錯誤的看法，serverless 是更精細化的一個方向，而不是更大的範疇。

Pivotal 雲計算資深架構師陳威認同現在業界的觀點，即 Serverless 是微服務更進一步的形式。現在看來，Serverless 處在技術曲線的早期階段，尚未達到炒作期的峰值，市場應用上還處於初級階段。但是，大則如同雲、小則如同微服務，Serverless 將會是技術的未來趨勢。雲的進化有很多種方向，serverless 更是應用層面的進化方向。

Serverless 是 PaaS 的一種特殊情況，通常而言 Serverless 的主流表現形式是 FaaS，FaaS 也是一種平台，只不過處理的專門是 Function 類型。

下面是一張圖片，可以幫助大家釐清 FaaS 與 PaaS 的關係

如圖所示，這是我們理想中的 Serverless 的一種抽象架構，從左至右來看：

1、最左邊實際上是客戶端的應用開發框架，例如 Spring Cloud Function 等相關體系，客戶使用 Serverless 開發框架研發的應用應該和開發本地應用沒有形式上的區別，也就是說具體後端使用哪個雲服務提供商的 Serverless 服務對於應用邏輯開發是完全透明的

2、中間部分是廣義上的 PaaS，在 PaaS 之中，function as service，也即我們通常意義上的 FaaS 作為 PaaS 的一個 platform 提供給用戶，比如 function 的註冊，發現，容錯，調度，數據流銜接，監控，日誌處理等機制。當 Serverless 應用部署到 PaaS 平台上面，綁定 FaaS 服務之後，具體後端是用哪種中間件平台實現，就和最左端的應用開發沒有關係了，具體的自動適配都由 FaaS 和 PaaS 解決。

例如排序這個基本的操作，究竟是基於 JVM 的應用級別實現，還是分配到 RDBMS 裡面，甚至是到 Hadoop 裡面，這個數據的流轉以及任務的調度，理想情況下是無需應用開發人員關心的。

3、最右邊的部分，則是提供底層基礎設施的雲服務商，也就是我們傳統意義上的 IaaS，包括他們也有可能提供整套的 Serverless 服務。接著上面第二點的描述，究竟這個 JVM 應用，或者 RDBMS 服務，是對接 AWS 的，還是 Azure 或者 Google GCP 的，這個就由 PaaS 層面來進行無縫的對接和運維管理等等了。

由此可見，將其視為 Backend-as-a-Service 是最早的定義，但是這個範疇太廣了；現在已經更細化了，可以看成是後端基於事件的輕量級服務，而不是說只要 backend 就叫 Serverless。現在看來，當年的定義過於籠統。

比微服務更誘人

Serverless 還是繼承了微服務的優勢，並且適用於無狀態的、基於事件的處理，這是兩者共同點。但是 Serverless 的粒度更細，彈性更好：微服務的迭代發布一般以天或周為單位，每個微服務代碼量在幾百行左右；如果採用了容器化微服務，可能秒或分鐘量級。而對於 Serverless 業界一般會定義為毫秒級別的彈性指標，大部分都是基於內存存儲或者事件處理。

但是 Serverless 不是普適的

相比於虛擬機等底層技術具有普適性，Serverless 靠近使用者、偏上層，這也就意味著 Serverless 有一定的局限性和適用範疇。Serverless 適用於輕量、事件驅動的技術框架，比如 Java 9 中類似與 React 的方式。傳統三層架構，如大量文件處理、傳統關係資料庫的操作，體現不出來太多的優勢。

那麼，Serverless 適合什麼？

對於新興的、事件驅動性的，類似於 IoT 等感測設備、金融交易類型等場景，比較適合 serverless。

Serverless 將會使得運維更加複雜化

Serverless 比微服務更細化了，管控起來會更麻煩，因此是不可能依靠人工去執行的，進行一個個函數的管理，一定需要藉助平台，這也是為什麼 Serverless 的落地最終要通過 FaaS，因為微服務要通過類似 Spring Cloud 的框架加上平台技術，例如 Pivotal Cloud Foundry 才能實現。

Serverless 也算作雲原生的範疇。如果採用公有雲 FaaS 服務（比如 Pivotal Web Service），就是將運維工作交出去了，這種做法很難界定是價錢更便宜還是更貴；而如果採用私有雲 FaaS 服務，則需要藉助程序框架、依賴 PaaS 平台。目前已經有一些先進的雲計算廠商提供了 Serverless 服務能力，Pivotal 就是其中之一，他的公有雲服務是 Pivotal Web Service，私有雲服務基於 Cloud Foundry 平台，後者是其在國內落地次數最多、落地規模最大的平台。

Serverless 與 Docker 有很多相像的技術特色，但是兩者所處的層面不同。Serverless 是從上往下看問題，而 Docker 還是處在基礎架構層面。但是，即便兩者有如此多的相同點，也沒有強調說上層的 serverless 需要下層一定 Docker 實現，目前並沒有哪家雲廠商宣稱其 serverelss 平台是基於 Docker 實現的。在陳威看來通過容器實現 Serverless 還是更重一些，容器更像是封裝的一個簡版操作系統；但是 serverless 的操作對象不是 Cgroups 或 LC 的方式，Serverless 涉及到的是進程、線程級別的開發，所以容器和 Serverless 不是很好的搭配。

那麼怎樣實現 Serverless 呢？陳威給出的答案是可以通過 Spring 的 serverless 編程框架。IT 界有目共睹的是，相比於略顯疲態的 J2EE，Spring 技術派系的崛起並不斷發展壯大。陳威認為目前 Pivotal 很重要的貢獻是研發和推進了當今業界的微服務標準框架 Spring Cloud。而對於 serverless 的實現，Pivotal 也沒有袖手旁觀。Spring 框架中有一些項目可以為 Serverless 計算添磚加瓦，如 Cloud Foundry Tasks, Spring Cloud Task, Spring Cloud Data Flow,Spring Cloud Function 等，Spring Cloud Function 是 Serverless 的主要編程框架，已經研發半年多，由一支不足十人的精英團隊負責，基本框架和路線圖均已完成，初版還在研發磨合階段。與 Spring 框架中已經存在的其他項目一樣，Spring Cloud Function 也完全開源。

Spring Cloud Function 目前還屬於孵化階段，Pivotal 已經將其託管至 github，地址如下：

目前由 Spring Cloud 的創始項目人 Dave Syer 負責 lead 各位技術人員可以直接登錄到上述的地址去查看相應的源代碼，示例等等。

目前，Spring Cloud Function 有如下的幾個設計原則

1、Promote the implementation of business logic via Functions.

推行基於 Function 的業務邏輯實現的理念

2、Decouple the development lifecycle of business logic from any specific runtime target so that the same code can run as a web endpoint, a stream processor, or a task.

將業務邏輯的開發生命周期與任何運行時平台解耦，使得代碼能夠以 web endpoint, 流處理器，或者 task 等的方式運行

3、Support a uniform programming model across serverless providers, as well as the ability to run standalone (locally or in a PaaS).

支持統一的，跨各種 serverless 提供商的，統一的編程模型，同時也支持本地化的運行模式 (本地化或者在 PaaS 中)

4、Enable Spring Boot features (auto-configuration, metrics, tracing) on serverless providers..

在 serverless 提供商的平台上啟用 Spring Boot 的能力 (auto-configuration,metrics,tracing)

Spring Cloud Function 有如下的幾個主要的功能：

1、Wrappers for @Beans of type Function, Consumer and Supplier, exposing them to the outside world as either HTTP endpoints and/or message stream listeners/publishers with RabbitMQ, Kafka etc.

將以 @Beans 形式封裝的 Function, Consumer, Supplier 暴露給外界環境，具體表現為 HTTP 端點，或者使用 RabbitMQ,Kafka 等以 listeners/publisher 實現的消息流的方式

2、Compiling strings which are Java function bodies into bytecode, and then turning them into @Beans that can be wrapped as above.

將純字元串方式編寫的 Java Function 編譯成位元組流，並轉換成為 1 裡面的 @Bean 封裝

3、Deploying a JAR file containing such an application context with an isolated classloader, so that you can pack them together in a single JVM.

使用隔離的 classloader 部署上面步驟形成的 jar 包與相應應用上下文環境，打包到一個單獨的 JVM 裡面

4、Adapters for AWS Lambda, Apache OpenWhisk and possibly other "serverless" service providers.

適配 AWS Lambda, Apache OpenWhisk 或者有可能其他的「serverless」服務提供商

當然除了框架的採用，由於 serverless 粒度比微服務還細，因此其實施和落地意味著更多的挑戰，這需要雲服務商和用戶的深度協作，比如 pair programming 的方式行一行一行代碼編寫。，技術文檔可能會略顯單薄，如果能有人力的參與會更加高效。

如果單純談 IoT，陳威告訴 InfoQ 其實 Pivotal 已經有很多落地的客戶案例了，均是通過 Pivotal Cloud Foundry 的 PaaS 平台和容器技術去實現的，比如賓士的車聯網、GE 工業互聯網和西門子的工業聯網平台。不過，坦白而言，相比容器和微服務技術，由於 Serverless 尚且比較新興，Pivotal 內部尚無物聯網領域的落地案例。

那麼物聯網是否適宜 serverless 呢？陳威認為主要是看是否基於事件，比如高速公路 ETC，事件觸發頻率可能很高，可以承受高併發、使用輕量並且彈性要求高的場景。公開場合中對人群人臉進行檢測，工作量的多少與人群數量之間相關，因此需要彈性很好。還有如環境檢測（空氣、水），生產製造等情景會應用到大量感測器。傳統的嵌入式系統軟體可以在前端進行及時的處理，但是這些端要求高可靠，只執行簡單工作（比如數據的採集），而 Serverless、PaaS 等技術則是在雲端進行分析，進行真正的智能化、大規模分析。

雲方面的技術近年是層出不窮，各種概念、框架令人眼花繚亂，但作為一個親歷了從 mainframe 主機時代到容器時代都變革技術人，其實已經沒有了過多的新鮮感，也褪去了年少時接觸新事物的興奮激動。

正所謂陽光之下沒有什麼新鮮事物一樣。IT 領域的技術或者發展一樣遵循這個世界的基本發展規律，例如守恆定律與哲學邏輯。從上述的角度而言分析新生的事物或者技術而言，都會遵循一個哲學的規律和終極問題，我是誰，我從哪兒來，我要去哪兒。這些問題對應地「翻譯」成六個技術的認識問題就是：

• 這是什麼技術？

• 什麼背景、什麼問題促使這個技術的產生和發展？

• 它有什麼好處，有什麼弊端？

• 使用了它我會變成什麼樣子？

• 我該怎麼使用？怎麼具體落地到我這裡？怎麼揚長避短與現有能力進行融合？

• 它將會發展成什麼樣子，我會據此有什麼發展和規劃？

新的技術層出不窮，但是要知道技術始終是為人服務的。不解決人的問題，技術無法成長壯大，要正確地認識到上述六個問題都有哪些都到了解答，；對於不同的具體客戶而言，技術又處在怎樣的認知階段。認清形勢，有所為而有所不為至關重要。

就 Serverless 的目前發展而言，我認為第二個問題都還沒有得到完全切實的答案，其他幾個問題或多或少有一些偏技術層面的解釋。我認識太多的客戶或者專家，執著於研究和對比一個平台或者技術的某些不太重要細節參數，而 Serverlesss 技術對於業務、人的層面有什麼價值卻一無所知，只是人云亦云的跟風與追趕潮流，對於這樣的人而言，認知水平決定了他永遠只能是跟隨從眾的角色和級別。

其實，用簡單的比喻而言，雲就是一台龐大的機器，IaaS 是它的 BIOS，PaaS 是它的操作系統 OS，SaaS 是它的應用。

1、在單機時代，為了跨 OS 平台不用重新開發應用，JVM 孕育而生，JVM 虛擬機作為各種 OS 的抽象機器，實現了應用的跨平台運行與一致性運維。

2、但是後來單機的性能無法滿足應用業務的需求，後來就誕生了各種強大的應用伺服器與中間件平台能夠支持有限度的集群應用管理與運維，例如大家熟知的 WebLogic, WebSphere，Oracle RAC 等，基於這些平台，應用做適當的改造，適配和配置就能夠做到集群化運行。

而在雲的時代，各種以 IaaS 為基礎的服務商也紛紛演進出自己的 PaaS 平台技術，你可以理解為市面上也出現了很多種的雲操作系統 OS。

那麼，在當年 JVM 誕生的年代的上述兩個問題又再一次的出現：

• 我的應用如何跨不同雲 OS？

• 我的應用如何在雲上集群化分散式處理?

我的答案是，Spring Cloud 即是為了解決雲時代的第一個問題而設計，包括我們推出的 Spring Cloud Function，藉由 Spring 的普適、整合與抽象能力，做到應用也能夠跨不同的 PaaS 而無需做不同的開發。對於第二個問題，分為兩個層面來應對，第一個層面是應用開發指導原則與最佳實踐層面，例如十二要素、DDD、微服務等等。

第二個層面是技術中間件層面，Pivotal 推出了 Spring Cloud Netflix 為代表的一系列服務管控中間件，以及服務、微服務的運行管控雲平台 Pivotal Cloud Foundry，為了最大程度簡化應用的分散式處理架構以及之上的分散式應用開發。這也是技術守恆定律的體現，整體的 IT 複雜性不會因為使用了微服務、容器、或者 Serverless 而降低。我們只不過是將複雜性轉移到了這些 PaaS/FaaS 的基礎設施里，這些業務邏輯無關的純 IT 架構部分。引用一句話「哪有什麼歲月靜好，只不過是有人替你負重前行」。

所以，就 Serverless 和 Spring Cloud Function 而言，對於大家的建議我歸納成一句話就是：積極關注與跟進，謹慎結合自己的實際需求使用，避免純技術導向的盲目嘗試。

STUQDevOps 作為幫助開發者提升工作效率和幫助團隊提升協作質量的一種新型技能，近幾年來受到了技術圈的狂熱追捧，許多公司也紛紛對外宣稱開始向 DevOps 轉型，相關崗位的薪水一路水漲船高。 那麼，DevOps 工程師究竟是一個什麼崗位？成為一名 DevOps 工程師需要具備什麼能力？ 報名 StuQ 的 DevOps 工程師課程，我們帶你在一個月時間內掌握 DevOps 常用的七種武器，從一名普通的開發或運維成長為一名合格的 DevOps 工程師。

添加小助手微信諮詢課程並領取 200 元優惠券。點擊閱讀原文了解課程詳情。