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

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

函數(shù)同步調(diào)用函數(shù)

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

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

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

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

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

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

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

調(diào)用者是無(wú)狀態(tài)的，不需要針對(duì)被調(diào)用者的錯(cuò)誤做復(fù)雜重試。

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

函數(shù)通過(guò) API 網(wǎng)關(guān)調(diào)用函數(shù)

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

函數(shù)異步調(diào)用函數(shù)

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

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

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

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

這種模式有如下局限性：

調(diào)用者顯然無(wú)法知道被調(diào)用者的執(zhí)行結(jié)果。

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

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

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

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

進(jìn)一步解耦函數(shù)調(diào)用。調(diào)用者無(wú)需知道被調(diào)用者的信息，只需要約定消息的格式。

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

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

這種模式的局限性跟異步調(diào)用函數(shù)類(lèi)似：

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

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

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

無(wú)法針對(duì)函數(shù)執(zhí)行錯(cuò)誤定義重試策略。

基于對(duì)象存儲(chǔ)服務(wù)的函數(shù)調(diào)用

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

基于日志庫(kù)的函數(shù)調(diào)用

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

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

日志服務(wù)會(huì)針對(duì)每個(gè)分區(qū)（Shard）并行調(diào)用函數(shù)，如果數(shù)據(jù)吞吐較大，可以通過(guò)擴(kuò)展分區(qū)來(lái)提高消費(fèi)吞吐能力。

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

上面的模式也不是割裂的，它們?cè)谟行﹫?chǎng)景下可以搭配使用，比如有時(shí)候基于對(duì)象存儲(chǔ)服務(wù)的調(diào)用需要觸發(fā)多個(gè)函數(shù)，這就可以結(jié)合使用 OSS 的事件觸發(fā)和函數(shù)工作流；又比如函數(shù)工作流通過(guò)消息隊(duì)列將任務(wù)發(fā)送給更廣泛的消費(fèi)者，觸達(dá)函數(shù)計(jì)算無(wú)法觸達(dá)的地方。

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

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)圈?！?/p>

總結(jié)

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

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