隨著以函式即服務（Function as a Service）為代表的無伺服器計算（Serverless）的廣泛使用，很多使用者遇到了涉及多個函式的場景，需要組合多個函式來共同完成一個業務目標，這正是微服務“分而治之，合而用之”的精髓所在。本文以阿里雲[函式計算](https://statistics.functioncompute.com/?title=%E5%87%BD%E6%95%B0%E7%BB%84%E5%90%88%E7%9A%84N%E7%A7%8D%E6%A8%A1%E5%BC%8F&author=hongqi&src=article&url=https%3A%2F%2Fcn.aliyun.com%2Fproduct%2Ffc)為例，試圖全面介紹函式組合的常見模式和使用場景，希望有助於選擇合適的解決方案。

___雖然本文主要介紹的是函式組合，但是基本思想也可用於服務組合。___

## 函式同步呼叫函式

![746005ab344914991609f2d30e065701](https://yqfile.alicdn.com/5968a3c1be4c151d55d22664c7ecbb38bcb25054.png)

在這種模式裡，函式直接呼叫 InvokeFunction 同步 API 執行一個或者多個函式，等待被呼叫函式返回結果，然後繼續執行。這是一個有些爭議的模式，不使用同步呼叫通常有以下原因：

1. 從費用的角度：由於函式計算按照函式實際執行時間收費，呼叫者在等待被呼叫函式返回前也會產生一定費用。
2. 執行時長限制：由於函式最長執行10分鐘，這就決定了呼叫的其它函式執行時間之和有限。
3. 從容錯的角度：被呼叫者出錯會直接影響呼叫者，如果這個呼叫鏈很長，則這種錯誤會一直蔓延到最初的呼叫者，容錯性較差。同時由於執行時長限制，呼叫者通常不容易針對錯誤做長時間重試。

上面的理由是在有些場景下成立的，但是微服務最經典最常見的組合方式就是同步呼叫，函式作為微服務的一種實現方式，這種同步呼叫的需求是不可迴避的，在有些場景下采用同步呼叫模式是值得考慮的，這些場景包括：

1. 呼叫者函式需要被呼叫函式執行結果做後續處理或者返回給客戶端。
2. 函式執行時間較短，最好在毫秒到秒級別。
3. 呼叫者是無狀態的，不需要針對被呼叫者的錯誤做複雜重試。

在這種模式裡，呼叫者通常不需要做複雜的計算，主要時間花在呼叫函式和等待返回上，因此呼叫者函式可以設定較小的記憶體，以減少費用；呼叫者還可以根據業務需求快取呼叫結果，減少對其它函式的呼叫，從而節約費用和增強容錯性。

## 函式透過 API 閘道器呼叫函式

![b805552a8de08160fe1852fb2fdb1c10](https://yqfile.alicdn.com/9b6bf35fdf3bc810e56726db790ece99e6ffd582.png)

與函式直接呼叫函式不同，這裡[被呼叫函式在 API 閘道器後面](https://help.aliyun.com/document_detail/54788.html)，使它看起來更像一個微服務。這種模式的限制和使用場景跟上面的直接呼叫模式類似，不同之處是 API 閘道器提供了一些額外的能力，比如認證和限流等。如果被呼叫者要根據某些業務資訊對請求做處理，則使用 API 閘道器是一個好的選擇。當然，使用 API 閘道器也帶來了額外的延遲和費用，如果不需要使用 API 閘道器提供的能力，則讓函式直接呼叫函式是一個更好的選擇。

## 函式非同步呼叫函式

![be45bc3b11d5822a224b6f2da7778a43](https://yqfile.alicdn.com/16cb43294e0f5aa62a8821b93fbea9cbb7652706.png)

在這種模式裡，函式執行完自身業務邏輯後，呼叫 InvokeFunction 非同步 API 通知其它函式執行並退出，它不關心被呼叫函式是否執行完成。函式計算的 InvokeFunction 非同步 API 是透過佇列實現的，非同步請求首先被寫入佇列，然後有一個元件從佇列裡消費請求，執行相應函式。這種模式的優勢和使用場景有：

1. 對執行延遲不敏感的場景，適合削峰填谷，減輕對依賴服務的壓力。函式計算會根據使用者的資源使用情況動態的調整佇列的處理速度，平滑請求對系統的壓力，當然這種平滑也可能會導致一些請求被延緩執行。
2. 呼叫者可以較容易的觸發多個被呼叫者執行，實現 Fan-Out 模式。比如一個影片處理函式可以非同步呼叫多個函式來分別將影片轉換成不同格式。
3. 由於每個函式所花時間都用在執行業務邏輯，而非等待其它函式返回上，沒有產生不必要的費用。

這種模式有如下侷限性：

1. 呼叫者顯然無法知道被呼叫者的執行結果。
2. 被呼叫者之間最好是獨立執行的，不需要相互協調，否則透過資料庫來協調執行會增加複雜度。例如，上面提到的影片處理函式呼叫多個函式分別將影片轉換成不同格式，如果需要在所有的影片轉換完成後發郵件通知使用者，這就需要等待所有的轉換函式執行結束。這種**等待多個事件發生**的模式叫做 Fan-In，不適合透過這種非同步呼叫模式實現。

## 基於訊息主題的函式呼叫

![a81b47c9c3e73fdff6e3e41c035cfb23](https://yqfile.alicdn.com/77f9b5c85b9a8f736031eb1a19357f19693f1cb4.png)

與上面的模式需要指定被呼叫函式不同，基於事件觸發模式讓呼叫者只需要釋出訊息，不關心誰去消費訊息。在訊息服務（MNS）中，主題是釋出訊息的目的地，釋出者可以透過 PublishMessage API 向主題釋出訊息, 主題的訂閱者會接收到釋出到主題上的訊息，[MNS 與函式計算服務的整合](https://help.aliyun.com/document_detail/97032.html)讓函式可以直接作為訂閱者，簡化了訊息處理應用的開發和運維代價。

和上面的非同步呼叫模式相比，基於訊息主題的呼叫模式有以下優勢：

1. 進一步解耦函式呼叫。呼叫者無需知道被呼叫者的資訊，只需要約定訊息的格式。
2. 得益於一個主題可以對應多個訂閱者，更容易實現 Fan-Out 模式。釋出者只需要釋出一條訊息就能觸發多個函式。在上面的非同步呼叫方式中，呼叫者仍需要顯式呼叫一個或者多個函式來觸發執行。
3. 雖然主題模式本質上是訊息服務**推送**訊息給訂閱者，不會考慮訂閱者的承載能力，但是由於阿里雲訊息服務是透過 InvokeFunction 非同步 API 呼叫函式，因此這種模式也具備基於訊息佇列模式的削峰填谷能力。

這種模式的侷限性跟非同步呼叫函式類似：

1. 很難支援等待多個事件觸發一個函式的場景（Fan-In）。
2. 需要做一定工作才能跟蹤多個函式執行狀態。
3. 很難限制單個函式的執行時間或者所有函式的總執行時間。
4. 無法針對函式執行錯誤定義重試策略。

## 基於物件儲存服務的函式呼叫

![97c87db6ed57833eebdab5aa2f578574](https://yqfile.alicdn.com/246441bf27b697b9689040cdba118be6643ff83c.png)

函式計算服務除了整合了訊息主題以外，還整合了物件儲存服務 （OSS)，表格儲存等其它事件源，這些事件源服務同樣可以作為連線函式的渠道。比如，一個非函式應用對 OSS 物件操作（建立，刪除等）後，通常需要其它渠道（比如訊息服務）通知其它應用做後續處理，而由於 [OSS 和函式計算的整合](https://help.aliyun.com/document_detail/62922.html)，只需簡單配置，這些事件就可以直接傳遞給自定義函式，而不需要額外渠道再傳遞資訊，簡化了資料處理流水線的開發和運維代價。

## 基於日誌庫的函式呼叫

![05bbc670f1354950ad39f6465112c673](https://yqfile.alicdn.com/5a73d549e0b4dbc10359e0ff945de7ddbcb5a06b.png)

日誌服務的[日誌庫](https://help.aliyun.com/document_detail/48874.html)是一個流（Stream）儲存，生產者寫入資料到日誌庫，消費者讀出資料並處理。[日誌服務和函式計算的整合](https://help.aliyun.com/document_detail/60781.html)，使得消費者可以是函式，從而實現了透過流儲存來協調函式呼叫。上面所有模式都是呼叫者顯式或者隱式的觸發一個或多個被呼叫函式執行，而這裡生產者函式寫入的資料不一定會立刻被消費者函式處理，日誌服務會根據使用者配置將多個資料批次推送給消費者函式。

這種模式有以下優勢：

1. 日誌服務會針對每個分割槽（Shard）並行呼叫函式，如果資料吞吐較大，可以透過擴充套件分割槽來提高消費吞吐能力。
2. 日誌服務給函式推送的同一分割槽資料是序列的和嚴格保序的，在老的資料沒有消費成功前不會推送新的資料。
3. 日誌服務會持續推送相同資料到函式直到函式消費資料後返回正常。

## 基於函式工作流的函式組合

![9bad3110cdaf618492064cde03723413](https://yqfile.alicdn.com/898c69eaaa3f7d1e669787f90d079a5ed238a9ae.png)

[函式工作流](https://statistics.functioncompute.com/?title=%E5%87%BD%E6%95%B0%E7%BB%84%E5%90%88%E7%9A%84N%E7%A7%8D%E6%A8%A1%E5%BC%8F&author=hongqi&src=article&url=https%3A%2F%2Faliyun.com%2Fproduct%2Ffnf)（Function Flow，簡稱 FnF）是一個用來協調多個分散式任務執行的全託管 Serverless 雲服務，簡化了開發和執行業務流程所需要的任務協調、狀態管理以及錯誤處理等繁瑣工作，讓使用者更好的專注業務邏輯開發。可以說函式工作流是轉為函式組合而生，有效的解決了上面幾種非同步組合模式的侷限性。

上面的所有模式都是透過點對點的方式來組合函式，而函式工作流是一個集中的協調者，函式之前不再直接或者間接通訊，所有的觸發都是由函式工作流發起，不同函式的輸入和輸出是透過函式工作流來傳遞。因此，這種方式下的函式程式碼全是業務邏輯相關，沒有上面模式裡的傳送主題訊息，或者呼叫其它函式的邏輯，實現更加清晰。

函式工作流有以下優勢：

1.	服務編排能力：可以將流程邏輯與任務執行分開，支援多種控制原語，比如順序執行多個函式，根據函式執行結果選擇執行其它函式，讓多個函式並行處理資料，或者讓一個函式並行處理一組資料等，以及上面的 Fan-In 模式。函式工作流還內建了錯誤重試和捕獲能力，節省了編寫編排程式碼的時間。
2.	支援長流程：無論是毫秒級還是長達一年的業務流程，FnF 都可以跟蹤整個流程，確保流程執行完成。
3.	流程狀態管理：FnF 會管理流程執行中的所有狀態，包括跟蹤它所處的執行步驟，以及儲存在步驟之間的輸入輸出。您無需自己管理流程狀態，也不必將複雜的狀態管理構建到任務中。
4.	協調分散式元件：FnF 能夠協調執行在不同架構，不同網路，不同語言實現的分散式應用。無論是私有云、專有云的應用想要平滑過渡到混合雲、公共雲，還是單體架構的應用想要演進到微服務架構，FnF 都能在其中發揮協調作用。函式工作流透過整合訊息佇列，讓任何可以訪問訊息佇列的應用也可以作為流程一部分，相互協作，共同完成業務目標。
5.	視覺化監控：FnF 提供了視覺化介面來協助定義流程和檢視執行狀態，方便您快速識別故障位置，並快速排除故障問題。
6.	運維全託管和按需付費：FnF 讓您從基礎設施維護中解放出來，提供了安全的、高可用的、高容錯的彈性的服務。使用者只需支付步驟轉換費用，不使用不產生費用。

函式工作流目前還不支援同步呼叫方式，如果您有同步呼叫需求，歡迎聯絡我們（見文章最後釘釘客戶群）。

## 總結

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

上面的模式也不是割裂的，它們在有些場景下可以搭配使用，比如有時候基於物件儲存服務的呼叫需要觸發多個函式，這就可以[結合使用 OSS 的事件觸發和函式工作流](https://github.com/awesome-fnf/oss-copy)；又比如[函式工作流透過訊息佇列將任務傳送給更廣泛的消費者](https://help.aliyun.com/document_detail/139379.html)，觸達函式計算無法觸達的地方。

最後，歡迎加入函式工作流和函式計算客戶群。

![1571936661683](https://yqfile.alicdn.com/42dc42416905742de83302226b644dd868531f42.jpeg)
![1571970520181](https://yqfile.alicdn.com/b7e269244242426dea6183fd6fe30ef4707ad20d.jpeg)

>“[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

函式組合的 N 種模式

相關文章