初識雲函數

可訪問 誰明浪子心-ShiYi's Blog，得到更好的閱讀體驗。

什麼是雲函數

雲函數提供了一種直接在雲上運行，無狀態的、短暫的、由事件觸發的代碼的能力。

雲函數與輕服務的關係

ServerLess，即無服務器架構，也叫輕服務，它包含兩個部分，以下：

1. 函數即服務（FaaS: Function as a Service）

   函數即服務提供的是計算能力。原有的計算能力，不管是容器也好，虛擬機也好都承載在必定的操做系統之上，函數即服務把計算能力進行了進一步抽象。

2. 後端及服務（BaaS: Backend as a Service）

   後端即服務，好比對象存儲，數據庫應用，緩存服務，咱們也能夠稱之爲Serverless，由於這些服務也可以在雲上提供開通即服務，開通即便用的能力。在使用這些產品時一樣不須要關注它的服務器是什麼樣的，它的服務器部署在哪裏，而是服務開通就可使用了，後面的運維工做都交給了雲，因此不用感知它的最底層服務器。

雲函數，就是FaaS模式的具體實現。一樣，對象存儲、數據庫應用、緩存服務等，是BaaS模式的具體實現。對於輕服務，BaaS和FaaS缺一不可。

雲函數對比傳統服務

服務粒度

• Monolith：單體應用
• MicroService：微服務
• Function：雲函數

一個單體應用能夠按業務模塊拆分紅多個微服務，一個微服務也能夠按使用場景拆分紅多個雲函數。好比一個廣告微服務，至少能夠拆分出實時競價、展現計數、報表查詢等雲函數。也就是說，雲函數和微服務中的API是同一粒度的。但不一樣於API，每一個雲函數都是獨立部署，按需執行。

服務架構

雲函數的特色

• 零運維：再也不須要管理底層資源的服務器
• 秒級部署：運行無狀態，輕易實現快速迭代
• 自動觸發：徹底由事件觸發，空閒時沒有資源在運行
• 聚焦代碼邏輯：開發者只關心最核心的代碼片斷，跳過複雜的、無聊的其餘工做
• 無窮彈性計算能力：根據請求自動平行調整服務資源，擁有近乎無限的擴容能力

如何使用雲函數

微信雲函數功能的構成

1. 邏輯代碼（目前只支持js）
2. 觸發器：包含定時觸發、事件觸發（目前僅支持定時觸發）

3. 設置項

   • 運行環境（目前只有NodeJs 8.9）
   • 資源配置（根據指定的內存分配計算資源，CPU按比例自動分配）
   • 超時時間（函數超過該時間仍未結束時，將會被強制中斷，不能大於20s）
   • 環境變量（可使用鍵/值對的形式定義可從函數代碼訪問的環境變量。加強雲函數的可定製性）

4. 相關支持

   • 測試（即時在線測試，構造Json參數，獲取測試結果）
   • 日誌（包含請求ID，返回結果，運行時間，佔用內存）
   • 監控（能夠查看雲函數的調用次數、運行時間、錯誤次數）

常見使用架構

• 一個雲函數處理一個任務，高度解耦

• 嘗試將請求歸類，一個雲函數處理某一類的請求，好比有專門負責處理用戶的，或者專門處理支付的雲函數。

• 只有一個雲函數，雲函數裏有一個分派任務的路由管理，將不一樣的任務分配給不一樣的本地函數處理。也能夠是分配給其它的雲函數或是其它執行單元。

什麼場景能夠用

理論上，只要符合下列條件，任何現有業務模塊均可以改形成雲函數的方式：

• 觸發響應：雙向通訊的場景，本質均可以用一方輪詢來解決。
• 無狀態：全部的狀態，均可如下沉至BaaS。

能夠用 ≠ 適合用，須要衡量 -> 改造的代價 vs 雲函數帶來的收益。

什麼場景適合用

• 事件驅動及響應式架構
• 流量突發場景
• 請求對延時要求不高
• 低頻請求
• 單項任務資源要求低

微信雲函數使用的痛點

1. 報錯信息不夠友好；
2. 開發者不能設置閾值從而自動伸縮；
3. 觸發器不夠豐富。

爲何要用雲函數

使用雲函數的好處

1. 簡單易用：自動並快速擴縮容；
2. 穩定可靠：高可用部署、與其餘計算服務結合使服務更健壯；
3. 高效開發：加速開發，簡化運維；
4. 節省成本：不需爲空閒資源付費；
5. 簡化管理：可視化管理、簡化安全配置。

使用雲函數的缺陷

1. 須要對業務進行很細粒度的拆分，難以進行或成本過高；
2. 不適合長時間運行應用；
3. 對第三方服務依賴太高。

因爲這些侷限性，Serverless架構不會成爲複雜應用的架構首選，相反，它應該是後端小程序的將來。

參考資料

• 微信公衆平臺-小程序-雲開發
• Serverless架構詳解：開發者如何專一於業務代碼自己？
• 所謂Serverless，你理解對了嗎？
• 雲開發初探 —— 更簡便的小程序開發模式丨掘金
• 騰訊雲-無服務器雲函數-產品簡介-產品文檔
• 當咱們聊Serverless時你應該知道這些