作者 | Harry Chen
2021，新年快樂。
本篇旨在介紹 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 在各家雲平台占優的趨勢下，是否在使用的，正是這部分人群。這部分人群隸屬于前端，自前端分化而來，但是基數相比傳統後端，還是難以快速增加。
如何盡可能滿足原有已經滿足的人的需求，同時還要擴大使用人群，收割市場，這正是各家雲平台争相角逐之處，也是目前的困境之處。
抉擇
為了解決目前的人群問題，隻有不斷的嘗試，至少國内的雲廠商在這一方面一直在突破。我們能看到的，這一年，一直在做的：
- 1、滿足不同層面，不同場景的使用者需求
- 2、嘗試用新技術，打破現有的語言困境
阿裡雲上的 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 實行業務微服務化，拆開了非常多的接口模型，并做了足夠的分布式架構和管理體系，也不是所有的公司都能學習并落地的。沉澱下來的隻有經驗。
對于使用者來說，在這紛繁的宣傳中，需要去選擇最适合自己的方案，其實是比較困難的，一般會先行熟悉，然後從自己比較了解的平台入手。核心會有幾個疑問：
- 1、我有一個應用，我怎麼用上 Serverless。
- 2、我有一個應用，是否要變為函數才能上 Serverless。
- 3、上了 Serverless 之後，我的業務如何保持穩定。
- 4、最關鍵的，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 國内廠商的獨創能力，也能領先全球，為技術界添磚加瓦。
此文隻是抛磚引玉，僅代表個人觀點，不對平台做個人喜好選擇。
關注「Alibaba F2E」
把握阿裡巴巴前端新動态