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

 

同步與異步

 

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

 

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

 

無狀態(tài)

 

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

 

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

 

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