Serverless 2.0，雞蛋仍是銀彈？

做者 | Harry Chen
來源 | Serverless 公衆號

導讀：本篇旨在介紹 Serverless 現在應用到應用（非病句）的各類困境，以及幫助用戶如何去規避一些問題，提早了解方向。

浪潮

從 2014 年 Serverless 冒頭至今，已經有無數的勇士在前面探路，阿里、騰訊、亞馬遜、百度、華爲等都不斷推出本身的雲服務，想要在這一浪潮中分一杯羹。除了最先的亞馬遜，國內的戰爭一直在不溫不火地進行，除了搶佔市場外，還在不斷尋求新的解決方案，期待有朝一日，可以憑着新方案，吸引大波用戶。

從全球來看，Serverless 總體的趨勢還算不錯，特別是國內騰訊阿里的推進，熱潮不斷。對比其餘的關鍵字，咱們發現 Serverless 和微服務都在持續增加中，整體說，輕量化、分佈式、可維護是一個趨勢，這符合當下的編碼習慣。

▲數據來源於 Google Trends

阿里雲藉由原有的首發優點，同時，加上首個支持預留/按量實例混合伸縮和預付費模式這些能力，不斷擴大用戶基數，同時在每一年的雙十一雙十二活動中應用落地，使得穩定性總體又上了一個臺階。同時在 2020 年 7 月信通院可信雲大會上，阿里雲函數計算 FC 以 21 項測試所有滿分的成績首批經過可信雲函數即服務認證。

▲圖片來自阿里雲 2020 線上峯會

騰訊藉由現有的小程序體系，結合小程序雲開發，和 Serverless 綁定，讓用戶迅速增加起來，這步棋仍是下得恰到好處，能讓不少開發者無縫地享受到雲的能力，既便利又能擴大影響力。

▲圖片來源於騰訊雲

在一年的營銷和推廣之下，不斷有人嘗試和使用，在國內激起了不小的水花，其中不乏有總體將業務遷移到 Serverless 體系的，也有膽小的，在遠處觀望。

好在有大公司的不斷推進，阿里淘寶、飛豬、高德、考拉，以及京東、滴滴、字節等等，愈來愈多的企業開始逐步嘗試把業務遷移到 Serverless 環境，一方面給其餘觀望的人打了樣，也促進了整個生態的正循環。

拋開這些大企業，中小型企業、我的開發者依舊是科技領域的大多數，除開觀望的，剩下的，都是躍躍欲試，想用可是摸不着門道的人羣，如今各家雲廠商在發力爭取的，也正是這部分人。而現有問題最大的，正也是這部分用戶。

困境

好久以前，咱們開發的軟件由 C/S 和 MVC 的架構，轉變爲 SOA，從單體架構，到服務化，再到更細粒度的微服務化，應用開發之初就是爲了應對業務特有的高併發、容錯等特性，須要很高的性能及可擴展性。

幾十年前（1975 年）Fred Brooks 就在 The Mythical Man-Month 中就寫到了這句話。

那麼，Serverless 會是解決軟件開發複雜度和效率之間的那顆銀彈嗎？

從 CNCF Cloud Native Interactive Landscape 中，咱們能夠發現，作基建（託管平臺）的企業有很多，咱們瞭解的阿里雲、騰訊、華爲、Amazon 等都在其中，而 Framework 以及更上層的業務工具場景其實不算不少，拋開 aws 的幾個工具，只有 Python、JavaScript 和 Java 的工具，比較出名的 Serverless Framework 加上 Spring Cloud Fucntion，基本上能涵蓋全球的很大一部分場景。

對於 Python、JavaScript 這種天生支持 Lambda 的開發語言，和 FaaS 簡直是完美結合。Serverless Framework 的調研報告也很好地說明了這一點。NodeJS、Python 是 FaaS 使用率前二的語言。

▲圖片來源於阿里雲技術博客

咱們知道，由於 JVM 佔用的內存比較大，因此 Java 應用的啓動會有點慢，不太適合 FaaS 這個場景，這也是 Java 在使用率上偏低的緣由。

因此在整個 Serverless 架構上，語言適合度佔了很是大的部分。這也帶來了一個最大的問題：用戶人羣和基數。
身爲前端，大部分的場景都在前臺頁面展現、渲染，跟 JavaScripts/HTML/CSS 打交道，不多涉及服務端的部分，惟一有交集的則是 Node.js 開發者，在先後端領域都有着不錯的輸出。

而 JavaScript 在各家雲平臺佔優的趨勢下，是否在使用的，正是這部分人羣。這部分人羣隸屬於前端，自前端分化而來，可是基數相比傳統後端，仍是難以快速增長。

如何儘量知足原有已經知足的人的需求，同時還要擴大使用人羣，收割市場，這正是各家雲平臺爭相角逐之處，也是當前的困境之處。

抉擇

爲了解決當前的人羣問題，只有不斷地嘗試，至少國內的雲廠商在這一方面一直在突破。咱們能看到的，這一年，一直在作的：

• 知足不一樣層面，不一樣場景的用戶需求；
• 嘗試用新技術，打破現有的語言困境。

阿里雲上的 Serverless 產品更是幫助微博、石墨文檔、跟誰學、Timing、聯合利華等數萬家企業客戶成功落地 Serverless，覆蓋前端全棧、小程序、新零售、遊戲互娛、在線教育等全行業應用場景。能夠看到，在企業的業務落地方面，阿里雲仍是很是快速的。

除了函數計算 FC 和 SAE 兩款產品以外，阿里雲 Serverless 產品矩陣還包括面向容器編排的 Serverless Kubernetes、以及面向容器實例的 ECI 等，它們構成了當前全部雲廠商中最完整的 Serverless 產品家族。

基本上，阿里雲已經將現有各類場景遷移到 Serverless 的路子打通，從應用遷移、容器化、函數化等幾個方面都包含了，同時也在彈性的角度，用實際的商業價值（錢）來吸引客戶。很明顯，阿里雲已經認識到當前的桎梏，在嘗試不一樣場景、不一樣語言的突破。

相對的，騰訊雲在這個層面，更偏向於體驗，一站式，極速部署，讓用戶以極低的成本切入，以體驗爲粘度去吸引用戶。下面的廣告咱們在訪問公衆號/網站時常常會看到。

這一年，咱們收到騰訊雲的培訓推送不少，從年初的 Serverless Framework 集成，到後面的 Serverless Days，以及 CloudBase Serverless 雲端一體化產品方案等等。

從容器層 Custom Runtime 方案，到應用層平臺方案，騰訊雲也都有一一對應，甚至在去年末，還發布了國內首個 Serverless Mysql 數據庫（有意思）。

這些林林總總的變化，都是源自於不一樣用戶層面的需求，都是在爭一個用戶羣，以及將來的商業化體系。

雲計算正在各領域持續深化其影響力，一樣，各領域下日益變化的需求，也在倒逼雲計算不斷進行自我優化。
反觀用戶側，除了下定決心吃螃蟹的企業們，剩下的更多的是聽着免費就來入場的羊毛黨（別小看他們，只要是不花錢，什麼奇怪的事情都會作），以及抱着學習的心態和部署我的服務的用戶。

雲平臺更想吸引的是後者。這部分人羣的問題依舊沒有解決。咱們會發現，現有的雲平臺，還處在一個吸引用戶，讓用戶自行摸索的階段，並無作出對比，或是 Serverless 和傳統的區別之處。

棒槌

去年一年，阿里雙促使用 Serverless 扛下了大流量，也有其餘公司紛紛使用 Serverless 應用到業務的案例，這些，其實都是創建在足夠強的保障體系下的實踐，如何應用到本身或者企業的業務身上，纔是真正的難點。

對一個企業很簡單的事情，好比要求提供幾臺虛擬機，對我的開發者可能就是很是困難的。大公司有各類緩存服務，有各類兜底的能力，而小公司或是我的開發者，只能聽聽，一笑而之。以前 Netflix 實行業務微服務化，拆開了很是多的接口模型，並作了足夠的分佈式架構和管理體系，也不是全部的公司都能學習並落地的。沉澱下來的只有經驗。

對於用戶來講，在這些紛繁的宣傳中，須要去選擇最適合本身的方案，實際上是比較困難的，通常會先行熟悉，而後從本身比較瞭解的平臺入手。核心會有幾個疑問：

• 我有一個應用，我怎麼用上 Serverless？
• 我有一個應用，是否要變爲函數才能上 Serverless？
• 上了 Serverless 以後，個人業務如何保持穩定？
• 最關鍵的，Serverless，個人業務怎麼付錢？

好比傳統應用如何上 Serverless，現有平臺提供的遷移已存在的業務上 Serverless 方案，基本使用的是 Custom Runtime 方案，經過 HTTP 協議通訊完成事件的響應處理（即開發一個特定端口，由容器內部作轉發的方案）。

▲圖片來自於阿里雲 Custom Runtime 方案

這樣將應用遷移到 Serverless 平臺是如今的主流方式，也是雲平臺推薦的方式。可是這樣作，是否真的沒有後遺症？

答案確定是有的，最明顯的就是啓動時間。容器的冷啓動 + 業務的啓動時間，若是是函數，那麼基本能在 2s 內啓動完畢，提供服務，而應用包含了太多的邏輯，致使啓動時間可能長達 2~10s，這仍是咱們使用 Node.js 業務估算的平均時間，若是是其餘語言，時間還要大幅增長。

函數的總體可訪問時間會控制在比較小的範圍，而應用啓動，通常會比較久。

這就致使了，總體應用的體驗若是純使用彈性的模式，是不太能接受的。固然，咱們能夠用預留模式（固定一些容器）來解決冷啓動的問題，不過你們能夠去算算價格，是否 ECS 會更便宜一些。

第二個問題是包大小，現有函數部署，雲平臺通常控制在 50M，這不只僅是由於存儲的問題，也是由於函數在啓動時會下載包，解壓，爲了極速啓動，減小網絡開銷，必然是但願包越小越好。應用的包，若是是純 Node.js 應用還好，資源每每能卡在 100M 內，可是加上前端資源（傳統的服務端渲染等），整個包體積就會上到幾百 M，要知道前端可能不太關心引入包的大小（畢竟 webpack 打包會自動剔除），可是這多是上到 Serverless 環境的較大隱患。

第三個問題是開發方式，不少因爲 Serverless 自己的限制致使業務代碼的寫法須要一些變化，這不只須要理解 Serverless 環境的運做機制，也須要有相應的解法。好比文件上傳，傳統應用能夠完成表單上傳，可是在 Serverless 網關的攔截下，須要經過不一樣的方式來作，這使得傳統應用開發和 Serverless 應用開發的代碼不夠統一，致使一些維護成本。

還有固定的網絡環境可能會致使網絡隔離，沒法鏈接特定的服務。定製的容器環境，以往的修改 nginx 支持特定協議，路由轉發都沒法實現了。乃至 Serverless 最爲美好的彈性行爲，也會使得代碼跟原先預想的不一致，好比本地的緩存、固定 ip 代理等等，這些都是和原有應用不一樣的。

種種可能的問題，你是否還能簡單地將業務遷移到 Serverless ？

冷靜下來，通過咱們總體的實踐，Serverless 的確能帶給咱們好處。上個月有個客戶跟我講，之前純用阿里雲 ECS，每月要花好幾千，如今上了 Serverless，每月只要 8 塊錢（真實場景），能夠說，這個吸引力是很是巨大的。

這點，對於我的用戶，特別是學生/獨立開發者特別有吸引力，可以以極低的價格，來完成功能交付。

雖然 Serverless 有一些問題，可是，真的省錢，只要業務沒有狀態，也沒什麼嚴苛的啓動要求（能夠有必定優化減小啓動時間），能理解 Serverless 基礎的原理，就能規避我上面描述的問題。

那，Serverless 必定是當前最省錢的方式，是你錢包最棒的夥伴。

趨勢

在過去的一年裏，咱們發現了一個特色，前端用戶分化爲兩極，一邊是但願面向雲原生更進一步，全配置的方式將編寫代碼的機會變的更低（nocode）；另外一邊但願以原有的應用模式逐步演進而來，以及但願以一個大而全的應用進行開發部署，從而減小開發協做成本。

好比 Serverless Framework，騰訊去年改了三個不一樣的 yml 版本，用來支持純函數，面向場景的業務。

▲Serverless Framework 的 yml 配置

而下半年推出的騰訊云云開發，也有着相似的方式，只是配置從 yml 變成了 JSON，可是核心沒有太多變化。

{
  "envId": "fx",
  "framework": {
    "plugins": {
      "server": {
        "use": "@cloudbase/framework-plugin-node",
        "inputs": {
          "entry": "./api/index.js",
          "path": "/api",
          "name": "github-stats-api",
          "wrapExpress": true
        }
      },
      "pin": {
        "use": "@cloudbase/framework-plugin-node",
        "inputs": {
          "entry": "./api/pin.js",
          "path": "/api/pin",
          "name": "github-stats-pin",
          "wrapExpress": true
        }
      }
    }
  }
}

▲騰訊雲開發的全配置 JSON

阿里雲的 template.yml  多年也變化不大。

卻是年末推出的 Serverless Devs 吸引了一波眼球，逐步把本地工具鏈的中心，慢慢移動到配套的管理平臺，想必將來會有不一樣的變化。

和單獨售賣的阿里雲不一樣是，騰訊雲開發出爐了打包售賣的方式（函數 + 存儲 + 數據庫資源）來知足用戶。這點在小程序開發上有很是大的優點，工具 + 資源的整合上，騰訊作得很不錯。

就像以前說的那樣，雲廠商在逐步彌補自身的不足，利用不一樣場景的來作差別化競爭，這是用戶樂於看到的。

而用戶的心智，則沒有太多的變化，因爲平臺包裹得足夠好（美好），咱們發現，後一半人（應用開發）逐步佔據了上風，業務無論如何上手，都是以應用的模式來進行開發，以應用開發的思路在開發、部署、調試，儼然只是把 Serverless 容器看成原有的服務器，充其量只是在原有的服務器上增長了一些限制，好比不能登陸等等。

從方案的選擇中，咱們也發現，前端更但願以一體化開發的方式（先後端在一塊兒）去開發業務，這就使得整個體系，和原來的設想偏離得很是之多。

不過這是阿里內部的狀況，不得不說，這是一個復古的趨勢（可能也是一個國內的趨勢），可能也是一個最容易被開發者接受的將來。

但願

在此前 InfoQ 報道的一篇《2019 年 Serverless 應用報告：三分之二的落地實踐都成功了？》的文章，其中提到了對於企業和開發者來講，促使他們使用 Serverless 最直接的因素有如下三點：

• 首先，「減小運營成本」是你們採用 Serverless 的第一大緣由，應用 Serverless 以後，就無需爲潛在的流量高峯購買大部分時間處於空閒狀態的服務器機架；

• 第二，「自動按需擴展」，採用 Serverless 以後，能夠隨時擴展到當前的使用量，消除了意外或者季節性流量高峯的困擾；

• 第三，「無服務器維護」，因爲企業中大部分開發人員都是軟件工程師，並非系統管理員，因此對於軟件的修復、保護和管理並不擅長，而使用 Serverless 以後，這些工做均可以交給供應商，他們只需專一於軟件開發。

每一點都足夠吸引人，但在這蜜糖之中，有刺也有糖，在使用以前，咱們最好能想想，到底怎麼用纔是最好的。

但願將來的 Serverless 形態，可以足夠知足業務的訴求，無論是函數態，仍是應用態，都能在其之上賦予更強大的場景和能力，Serverless 國內廠商的首創能力，也能領先全球，爲技術界添磚加瓦。

此文只是拋磚引玉，僅表明我的觀點，不對平臺作我的喜愛選擇。