雲函數提供了一種 直接在雲上運行，無狀態的、短暫的、由事件觸發的代碼 的能力。
雲函數與輕服務的關系
ServerLess，即無服務器架構，也叫輕服務，它包含兩個部分，如下：
-
函數即服務（FaaS: Function as a Service）
函數即服務提供的是計算能力。原有的計算能力，無論是容器也好，虛擬機也好都承載在一定的操作系統之上，函數即服務把計算能力進行了進一步抽象，我們在后文再繼續進行展開。
-
后端及服務（BaaS: Backend as a Service）
后端即服務，比如對象存儲，數據庫應用，緩存服務，我們也可以稱之為 Serverless，因為這些服務也能夠在雲上提供開通即服務，開通即使用的能力。在使用這些產品時同樣不需要關注它的服務器是什么樣的，它的服務器部署在哪里，而是服務開通就可以使用了，后面的運維工作都交給了雲，所以不用感知它的最底層服務器。
雲函數，就是 FaaS 模式的具體實現。同樣，對象存儲、數據庫應用、緩存服務等，是 BaaS 模式的具體實現。
對於輕服務，BaaS 和 Faas 缺一不可。
雲函數對比傳統服務
服務粒度
- Monolith：單體應用
- Microservice：微服務
- Function：雲函數
一個單體應用可以按業務模塊拆分成多個微服務，一個微服務也可以按使用場景拆分成多個雲函數。比如一個廣告微服務，至少可以拆分出實時競價、展示計數、報表查詢等雲函數。也就是說，雲函數和微服務中的 API 是同一粒度的。但不同於 API，每個雲函數都是獨立部署，按需執行。
服務架構
雲函數的特點
- 零運維 ：不再需要管理底層資源的服務器
- 秒級部署 ：運行無狀態，輕易實現快速迭代
- 自動觸發 ：完全由事件觸發，空閑時沒有資源在運行
- 聚焦代碼邏輯 ：開發者只關心最核心的代碼片段，跳過復雜的、無聊的其他工作
- 無窮彈性計算能力 ：根據請求自動平行調整服務資源，擁有近乎無限的擴容能力
如何使用雲函數
微信雲函數功能的構成
- 邏輯代碼（目前只支持 js）==雲函數並非只能是一個函數，而是指以類函數的方式被外界調用執行的無狀態代碼段。可以有常量可以是多個函數，關鍵點在於無狀態，再進一步說，你的代碼是否符合無狀態，沒關系，雲函數的運行機制就是按照無狀態進行的==
- 觸發器：包含定時觸發、事件觸發（目前僅支持定時觸發）==什么是事件，API 網關觸發、客戶端調用 SDK 觸發，其它諸如 cos、cdn、mq==
- 設置項
- 運行環境（目前只有 Nodejs 8.9）
- 資源配置（根據指定的內存分配計算資源，CPU 按比例自動分配）
- 超時時間（函數超過該時間仍未結束時，將會被強制中斷，不能大於 20s）
- 環境變量（可以使用鍵/值對的形式定義可從函數代碼訪問的環境變量。增強雲函數的可定制性）
- 相關支持
- 測試（即時在線測試，構造 Json 參數，獲取測試結果）
- 日志（包含請求 ID，返回結果，運行時間，占用內存）
- 監控（可以查看雲函數的調用次數、運行時間、錯誤次數）
常見使用架構
- 一個雲函數處理一個任務，高度解耦
- 嘗試將請求歸類，一個雲函數處理某一類的請求，比如有專門負責處理用戶的，或者專門處理支付的雲函數。
- 只有一個雲函數，雲函數里有一個分派任務的路由管理，將不同的任務分配給不同的本地函數處理。也可以是分配給其它的雲函數或是其它執行單元。
什么場景可以用
理論上，只要符合下列條件，任何現有業務模塊都可以改造成雲函數的方式：
- 觸發響應：雙向通信的場景，本質都可以用一方輪詢來解決。
- 無狀態：所有的狀態，都可以下沉至 BaaS。
可以用 ≠ 適合用，需要衡量 -> 改造的代價 vs 雲函數帶來的收益。
什么場景適合用
- 事件驅動及響應式架構
- 流量突發場景
- 請求對延時要求不高
- 低頻請求
- 單項任務資源要求低
資源搜索網站大全 https://www.renrenfan.com.cn 廣州VI設計公司https://www.houdianzi.com
為什么要用雲函數
微信雲函數使用的痛點
- 報錯信息不夠友好；
- 開發者不能設置閾值從而自動伸縮；
- 觸發器不夠豐富。
使用雲函數的好處
- 簡單易用：自動並快速擴縮容；
- 穩定可靠：高可用部署、與其他計算服務結合使服務更健壯；
- 高效開發：加速開發，簡化運維；
- 節省成本：不需為空閑資源付費；
- 簡化管理：可視化管理、簡化安全配置。
使用雲函數的缺陷
==// 缺陷，不包含雲函數在不合適的場景下應用帶來的問題==
==// 列出來的是圍繞着其本身可能在使用時把控不好的地方==
- 需要對業務進行很細粒度的拆分，難以進行或成本太高；
- 延遲較高，特別是一定時間間隔后的第一次訪問；
- 對第三方服務依賴過高。
由於這些局限性，Serverless 架構不會成為復雜應用的架構首選，相反，它應該是后端小程序的未來。