簡介： 本篇旨在介紹 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 國內廠商的獨創能力，也能領先全球，為技術界添磚加瓦。
此文只是拋磚引玉，僅代表個人觀點，不對平臺做個人喜好選擇。
作者：Harry Chen
本文為阿里雲原創內容，未經允許不得轉載