無服務器環境中的基本單位是任務或作業，它是圍繞特定工作負載處理的實例化和執行。 任務處理自從編程開始就存在，所以它也不是一個全新的事物。 但是考慮到這些工作負載處理的高度分布的性質和抽象的方式，因此跨過具體的實現層次，并有廣泛的理解是必要的。

 

同步與異步

 

雖然處理任務的性質 - 無論是同步還是異步 - 通常是一個平臺問題，但它也是在任務級別需要考慮的一個重要因素。 傳統的工作和作業處理系統在很大程度上是異步的，這意味著調用進程不保持與執行任務處理組件的持久連接。 作業將排隊，因此，它們可能不會立即運行。 調用函數和處理器之間唯一的特定連接將任務排隊等待運行。 (注意，某些平臺可以允許對任務獲得狀態，但是通過API調用而不是直接/持久連接)。

 

許多新的無服務器平臺允許同步處理，從而保持連接并且客戶端在功能正在處理時等待。 同步處理的優點是可以直接從處理平臺獲得結果，而在異步處理中，獲得結果必須作為獨立的調用來完成。 我將在平臺部分討論更多細節，雖然一般的規則是同步處理適用于輕量級函數(類似于API調用獲得天氣信息)，而異步處理更多的涉及處理作業(音頻轉錄或作為小批量處理作業的一組事件的處理)，以及啟動處理的應用/組件/功能不是處理結果的應用/組件/功能的地方。

 

無狀態

 

無論處理方法如何，開發微服務和/或無服務器功能的核心原則之一是每個服務或方法應被視為無狀態。(小編：無狀態也反復在在高可用架構群討論及分享中提及)。 無狀態是指每個任務是一個單獨且不同的處理請求，其包含足夠的信息來滿足該請求。 服務和方法不應存儲任何唯一的軟件配置或狀態。 任何配置數據都應來自方法外部，通常作為任務的一部分或通過平臺內的配置服務。 該方法應該僅用于其計算資源，僅用于處理單個工作負載。

 

另外，應當有明顯的開始狀態和結束狀態，并且服務或方法應以相同的方式處理每個任務。 借用一個 principles of clean code, bad code — and bad microservices and serverless functions [1] 一文中的觀點，我們應該聚焦并使用單一責任原則(SRP)[2] 。 思考無服務器函數的一個好方法是每個函數應該有一個且只有一個維度或向量的變化。 換句話說，如果有多種方式可以擴展函數(例如，將檢查多個特征的圖像分析)，則對于每個向量應當存在兩個或更多個不同的函數。

 

在我們使用的用例中，每個電子郵件是一個單獨的事件，因此每個電子郵件都有一個單獨的任務序列。每個任務將承載為相應的任務或方法提供處理的數據。以上就是我們的今日分享，希望對您有所幫助。