函數組合的 N 種模式

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

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

函數同步調用函數

746005ab344914991609f2d30e065701

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

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

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

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

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

函數通過 API 網關調用函數

b805552a8de08160fe1852fb2fdb1c10

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

函數異步調用函數

be45bc3b11d5822a224b6f2da7778a43

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

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

這種模式有如下局限性:

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

基于消息主題的函數調用

a81b47c9c3e73fdff6e3e41c035cfb23

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

和上面的異步調用模式相比,基于消息主題的調用模式有以下優勢:

  1. 進一步解耦函數調用。調用者無需知道被調用者的信息,只需要約定消息的格式。
  2. 得益于一個主題可以對應多個訂閱者,更容易實現 Fan-Out 模式。發布者只需要發布一條消息就能觸發多個函數。在上面的異步調用方式中,調用者仍需要顯式調用一個或者多個函數來觸發執行。
  3. 雖然主題模式本質上是消息服務推送消息給訂閱者,不會考慮訂閱者的承載能力,但是由于阿里云消息服務是通過 InvokeFunction 異步 API 調用函數,因此這種模式也具備基于消息隊列模式的削峰填谷能力。

這種模式的局限性跟異步調用函數類似:

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

基于對象存儲服務的函數調用

97c87db6ed57833eebdab5aa2f578574

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

基于日志庫的函數調用

05bbc670f1354950ad39f6465112c673

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

這種模式有以下優勢:

  1. 日志服務會針對每個分區(Shard)并行調用函數,如果數據吞吐較大,可以通過擴展分區來提高消費吞吐能力。
  2. 日志服務給函數推送的同一分區數據是串行的和嚴格保序的,在老的數據沒有消費成功前不會推送新的數據。
  3. 日志服務會持續推送相同數據到函數直到函數消費數據后返回正常。

基于函數工作流的函數組合

9bad3110cdaf618492064cde03723413

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

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

函數工作流有以下優勢:

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

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

總結

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

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

最后,歡迎加入函數工作流和函數計算客戶群。

1571936661683
1571970520181

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

posted @ 2020-01-19 15:11  阿里巴巴云原生  閱讀(169)  評論(1編輯  收藏
最新chease0ldman老人