隨著以函數(shù)即服務（Function as a Service）為代表的無服務器計算（Serverless）的廣泛使用，很多用戶遇到了涉及多個函數(shù)的場景，需要組合多個函數(shù)來共同完成一個業(yè)務目標，這正是微服務“分而治之，合而用之”的精髓所在。本文以阿里云函數(shù)計算為例，試圖全面介紹函數(shù)組合的常見模式和使用場景，希望有助于選擇合適的解決方案。

雖然本文主要介紹的是函數(shù)組合，但是基本思想也可用于服務組合。

函數(shù)同步調用函數(shù)

在這種模式里，函數(shù)直接調用 InvokeFunction 同步 API 執(zhí)行一個或者多個函數(shù)，等待被調用函數(shù)返回結果，然后繼續(xù)執(zhí)行。這是一個有些爭議的模式，不使用同步調用通常有以下原因：

從費用的角度：由于函數(shù)計算按照函數(shù)實際執(zhí)行時間收費，調用者在等待被調用函數(shù)返回前也會產(chǎn)生一定費用。

執(zhí)行時長限制：由于函數(shù)最長執(zhí)行10分鐘，這就決定了調用的其它函數(shù)執(zhí)行時間之和有限。

從容錯的角度：被調用者出錯會直接影響調用者，如果這個調用鏈很長，則這種錯誤會一直蔓延到最初的調用者，容錯性較差。同時由于執(zhí)行時長限制，調用者通常不容易針對錯誤做長時間重試。

上面的理由是在有些場景下成立的，但是微服務最經(jīng)典最常見的組合方式就是同步調用，函數(shù)作為微服務的一種實現(xiàn)方式，這種同步調用的需求是不可回避的，在有些場景下采用同步調用模式是值得考慮的，這些場景包括：

調用者函數(shù)需要被調用函數(shù)執(zhí)行結果做后續(xù)處理或者返回給客戶端。

函數(shù)執(zhí)行時間較短，最好在毫秒到秒級別。

調用者是無狀態(tài)的，不需要針對被調用者的錯誤做復雜重試。

在這種模式里，調用者通常不需要做復雜的計算，主要時間花在調用函數(shù)和等待返回上，因此調用者函數(shù)可以設置較小的內存，以減少費用；調用者還可以根據(jù)業(yè)務需求緩存調用結果，減少對其它函數(shù)的調用，從而節(jié)約費用和增強容錯性。

函數(shù)通過 API 網(wǎng)關調用函數(shù)

與函數(shù)直接調用函數(shù)不同，這里被調用函數(shù)在 API 網(wǎng)關后面，使它看起來更像一個微服務。這種模式的限制和使用場景跟上面的直接調用模式類似，不同之處是 API 網(wǎng)關提供了一些額外的能力，比如認證和限流等。如果被調用者要根據(jù)某些業(yè)務信息對請求做處理，則使用 API 網(wǎng)關是一個好的選擇。當然，使用 API 網(wǎng)關也帶來了額外的延遲和費用，如果不需要使用 API 網(wǎng)關提供的能力，則讓函數(shù)直接調用函數(shù)是一個更好的選擇。

函數(shù)異步調用函數(shù)

在這種模式里，函數(shù)執(zhí)行完自身業(yè)務邏輯后，調用 InvokeFunction 異步 API 通知其它函數(shù)執(zhí)行并退出，它不關心被調用函數(shù)是否執(zhí)行完成。函數(shù)計算的 InvokeFunction 異步 API 是通過隊列實現(xiàn)的，異步請求首先被寫入隊列，然后有一個組件從隊列里消費請求，執(zhí)行相應函數(shù)。這種模式的優(yōu)勢和使用場景有：

對執(zhí)行延遲不敏感的場景，適合削峰填谷，減輕對依賴服務的壓力。函數(shù)計算會根據(jù)用戶的資源使用情況動態(tài)的調整隊列的處理速度，平滑請求對系統(tǒng)的壓力，當然這種平滑也可能會導致一些請求被延緩執(zhí)行。

調用者可以較容易的觸發(fā)多個被調用者執(zhí)行，實現(xiàn) Fan-Out 模式。比如一個視頻處理函數(shù)可以異步調用多個函數(shù)來分別將視頻轉換成不同格式。

由于每個函數(shù)所花時間都用在執(zhí)行業(yè)務邏輯，而非等待其它函數(shù)返回上，沒有產(chǎn)生不必要的費用。

這種模式有如下局限性：

調用者顯然無法知道被調用者的執(zhí)行結果。

被調用者之間最好是獨立執(zhí)行的，不需要相互協(xié)調，否則通過數(shù)據(jù)庫來協(xié)調執(zhí)行會增加復雜度。例如，上面提到的視頻處理函數(shù)調用多個函數(shù)分別將視頻轉換成不同格式，如果需要在所有的視頻轉換完成后發(fā)郵件通知用戶，這就需要等待所有的轉換函數(shù)執(zhí)行結束。這種等待多個事件發(fā)生的模式叫做 Fan-In，不適合通過這種異步調用模式實現(xiàn)。

基于消息主題的函數(shù)調用

與上面的模式需要指定被調用函數(shù)不同，基于事件觸發(fā)模式讓調用者只需要發(fā)布消息，不關心誰去消費消息。在消息服務（MNS）中，主題是發(fā)布消息的目的地，發(fā)布者可以通過 PublishMessage API 向主題發(fā)布消息, 主題的訂閱者會接收到發(fā)布到主題上的消息，MNS 與函數(shù)計算服務的集成讓函數(shù)可以直接作為訂閱者，簡化了消息處理應用的開發(fā)和運維代價。

和上面的異步調用模式相比，基于消息主題的調用模式有以下優(yōu)勢：

進一步解耦函數(shù)調用。調用者無需知道被調用者的信息，只需要約定消息的格式。

得益于一個主題可以對應多個訂閱者，更容易實現(xiàn) Fan-Out 模式。發(fā)布者只需要發(fā)布一條消息就能觸發(fā)多個函數(shù)。在上面的異步調用方式中，調用者仍需要顯式調用一個或者多個函數(shù)來觸發(fā)執(zhí)行。

雖然主題模式本質上是消息服務推送消息給訂閱者，不會考慮訂閱者的承載能力，但是由于阿里云消息服務是通過 InvokeFunction 異步 API 調用函數(shù)，因此這種模式也具備基于消息隊列模式的削峰填谷能力。

這種模式的局限性跟異步調用函數(shù)類似：

很難支持等待多個事件觸發(fā)一個函數(shù)的場景（Fan-In）。

需要做一定工作才能跟蹤多個函數(shù)執(zhí)行狀態(tài)。

很難限制單個函數(shù)的執(zhí)行時間或者所有函數(shù)的總執(zhí)行時間。

無法針對函數(shù)執(zhí)行錯誤定義重試策略。

基于對象存儲服務的函數(shù)調用

函數(shù)計算服務除了集成了消息主題以外，還集成了對象存儲服務 （OSS)，表格存儲等其它事件源，這些事件源服務同樣可以作為連接函數(shù)的渠道。比如，一個非函數(shù)應用對 OSS 對象操作（創(chuàng)建，刪除等）后，通常需要其它渠道（比如消息服務）通知其它應用做后續(xù)處理，而由于 OSS 和函數(shù)計算的集成，只需簡單配置，這些事件就可以直接傳遞給自定義函數(shù)，而不需要額外渠道再傳遞信息，簡化了數(shù)據(jù)處理流水線的開發(fā)和運維代價。

基于日志庫的函數(shù)調用

日志服務的日志庫是一個流（Stream）存儲，生產(chǎn)者寫入數(shù)據(jù)到日志庫，消費者讀出數(shù)據(jù)并處理。日志服務和函數(shù)計算的集成，使得消費者可以是函數(shù)，從而實現(xiàn)了通過流存儲來協(xié)調函數(shù)調用。上面所有模式都是調用者顯式或者隱式的觸發(fā)一個或多個被調用函數(shù)執(zhí)行，而這里生產(chǎn)者函數(shù)寫入的數(shù)據(jù)不一定會立刻被消費者函數(shù)處理，日志服務會根據(jù)用戶配置將多個數(shù)據(jù)批量推送給消費者函數(shù)。

這種模式有以下優(yōu)勢：

日志服務會針對每個分區(qū)（Shard）并行調用函數(shù)，如果數(shù)據(jù)吞吐較大，可以通過擴展分區(qū)來提高消費吞吐能力。

日志服務給函數(shù)推送的同一分區(qū)數(shù)據(jù)是串行的和嚴格保序的，在老的數(shù)據(jù)沒有消費成功前不會推送新的數(shù)據(jù)。

日志服務會持續(xù)推送相同數(shù)據(jù)到函數(shù)直到函數(shù)消費數(shù)據(jù)后返回正常。

基于函數(shù)工作流的函數(shù)組合

函數(shù)工作流（Function Flow，簡稱 FnF）是一個用來協(xié)調多個分布式任務執(zhí)行的全托管 Serverless 云服務，簡化了開發(fā)和運行業(yè)務流程所需要的任務協(xié)調、狀態(tài)管理以及錯誤處理等繁瑣工作，讓用戶更好的專注業(yè)務邏輯開發(fā)。可以說函數(shù)工作流是轉為函數(shù)組合而生，有效的解決了上面幾種異步組合模式的局限性。

上面的所有模式都是通過點對點的方式來組合函數(shù)，而函數(shù)工作流是一個集中的協(xié)調者，函數(shù)之前不再直接或者間接通信，所有的觸發(fā)都是由函數(shù)工作流發(fā)起，不同函數(shù)的輸入和輸出是通過函數(shù)工作流來傳遞。因此，這種方式下的函數(shù)代碼全是業(yè)務邏輯相關，沒有上面模式里的發(fā)送主題消息，或者調用其它函數(shù)的邏輯，實現(xiàn)更加清晰。

函數(shù)工作流有以下優(yōu)勢：

服務編排能力：可以將流程邏輯與任務執(zhí)行分開，支持多種控制原語，比如順序執(zhí)行多個函數(shù)，根據(jù)函數(shù)執(zhí)行結果選擇執(zhí)行其它函數(shù)，讓多個函數(shù)并行處理數(shù)據(jù)，或者讓一個函數(shù)并行處理一組數(shù)據(jù)等，以及上面的 Fan-In 模式。函數(shù)工作流還內置了錯誤重試和捕獲能力，節(jié)省了編寫編排代碼的時間。

支持長流程：無論是毫秒級還是長達一年的業(yè)務流程，FnF 都可以跟蹤整個流程，確保流程執(zhí)行完成。

流程狀態(tài)管理：FnF 會管理流程執(zhí)行中的所有狀態(tài)，包括跟蹤它所處的執(zhí)行步驟，以及存儲在步驟之間的輸入輸出。您無需自己管理流程狀態(tài)，也不必將復雜的狀態(tài)管理構建到任務中。

協(xié)調分布式組件：FnF 能夠協(xié)調運行在不同架構，不同網(wǎng)絡，不同語言實現(xiàn)的分布式應用。無論是私有云、專有云的應用想要平滑過渡到混合云、公共云，還是單體架構的應用想要演進到微服務架構，FnF 都能在其中發(fā)揮協(xié)調作用。函數(shù)工作流通過集成消息隊列，讓任何可以訪問消息隊列的應用也可以作為流程一部分，相互協(xié)作，共同完成業(yè)務目標。

可視化監(jiān)控：FnF 提供了可視化界面來協(xié)助定義流程和查看執(zhí)行狀態(tài)，方便您快速識別故障位置，并快速排除故障問題。

運維全托管和按需付費：FnF 讓您從基礎設施維護中解放出來，提供了安全的、高可用的、高容錯的彈性服務。用戶只需支付步驟轉換費用，不使用不產(chǎn)生費用。

函數(shù)工作流目前還不支持同步調用方式，如果您有同步調用需求，歡迎聯(lián)系我們（見文章最后釘釘客戶群）。

總結

總的來說，上面的組合模式可以分為同步和異步兩種，在場景適合的情況下優(yōu)先選擇異步模式，享受異步模式帶來的松耦合，高容錯等特性，否則使用同步模式。在異步模式中，如果需要編寫復雜的組合邏輯，支持可靠的重試，把控整個流程，則推薦使用函數(shù)工作流，否則使用消息主題或者其它事件源服務來組合函數(shù)。

上面的模式也不是割裂的，它們在有些場景下可以搭配使用，比如有時候基于對象存儲服務的調用需要觸發(fā)多個函數(shù)，這就可以結合使用 OSS 的事件觸發(fā)和函數(shù)工作流；又比如函數(shù)工作流通過消息隊列將任務發(fā)送給更廣泛的消費者，觸達函數(shù)計算無法觸達的地方。

最后，歡迎加入函數(shù)工作流和函數(shù)計算客戶群。

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術圈。”

總結

以上是生活随笔為你收集整理的函数组合的 N 种模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。