首先我應該提到，“無(wú)服務(wù)器”技術(shù)肯定有服務(wù)器涉及。 我只是使用這個(gè)術(shù)語(yǔ)來(lái)描述這種方法和技術(shù)，它將任務(wù)處理和調度抽象為與服務(wù)器管理無(wú)關(guān)。 在 2012 年為 ReadWrite 撰寫(xiě)的有關(guān)軟件和應用程序未來(lái)的文章中，我將“無(wú)服務(wù)器”描述如下。

短語(yǔ)“無(wú)服務(wù)器”并不意味著(zhù)服務(wù)器不再涉及。 它只是意味著(zhù)開(kāi)發(fā)人員不再需要對它們有太多的關(guān)注。 計算資源被用作服務(wù)，而不必管理物理容量或限制。 服務(wù)提供商越來(lái)越多地承擔管理服務(wù)器，數據存儲和其他基礎設施資源的責任...無(wú)服務(wù)器架構允許開(kāi)發(fā)人員將重點(diǎn)從服務(wù)器級別轉移到任務(wù)級別。 無(wú)服務(wù)器解決方案允許開(kāi)發(fā)人員通過(guò)消除后端基礎架構的復雜性來(lái)專(zhuān)注于其應用程序或系統需要做什么。

在那篇文章的時(shí)候，“無(wú)服務(wù)器”這個(gè)術(shù)語(yǔ)并沒(méi)有受到好評，當時(shí)在 Hacker News 的評論中也可以看到。但隨著(zhù)一些無(wú)服務(wù)器平臺的誕生和微服務(wù)和事件驅動(dòng)架構發(fā)揮越來(lái)越重要地位，這些質(zhì)疑很幸運的逐漸得到了消退。

無(wú)服務(wù)器架構使用場(chǎng)景示例

為了更好理解這個(gè)技術(shù)，最好基于一個(gè)實(shí)際使用場(chǎng)景的示例來(lái)討論，因此假設我們要使用無(wú)服務(wù)器管道來(lái)處理電子郵件以及檢測垃圾郵件。 它是事件驅動(dòng)的，因為當電子郵件進(jìn)來(lái)時(shí)，它將產(chǎn)生一系列的工作或功能，旨在專(zhuān)門(mén)操作該電子郵件。

在此管道中，您可能具有執行電子郵件中的文本，圖像，鏈接，郵件屬性和其他項目或嵌入對象的解析的任務(wù)。 每個(gè)項目或元素可能具有不同的處理要求，這又要求一個(gè)或多個(gè)單獨的任務(wù)以及甚至其自己的處理流水線(xiàn)或序列。 例如，可以跨越幾個(gè)不同的處理向量來(lái)分析圖像鏈接，以確定圖像的內容和真實(shí)性。 根據消息評分和結果（是否是垃圾郵件），將采取各種行動(dòng)，這可能反過(guò)來(lái)涉及其他無(wú)服務(wù)器功能。

無(wú)服務(wù)器架構分析

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

同步與異步

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

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

無(wú)狀態(tài)

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

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

在我們使用的用例中，每個(gè)電子郵件是一個(gè)單獨的事件，因此每個(gè)電子郵件都有一個(gè)單獨的任務(wù)序列。 每個(gè)任務(wù)將承載為相應的任務(wù)或方法提供處理的數據。

短生命周期

無(wú)服務(wù)器功能也是短暫的 - 意味著(zhù)它們持續有限的一段時(shí)間。 無(wú)服務(wù)器應用程序的基礎主要圍繞事件處理和為這些事件服務(wù)時(shí)發(fā)生的任務(wù)處理。 強大的容器技術(shù)的出現使得任務(wù)可以在分布式環(huán)境中處理，并且決定在運行時(shí)在何處運行。

換句話(huà)說(shuō)，任務(wù)處理基本上變成容器處理，其中容器在任務(wù)的基礎上建立和移除。作為示例，電子郵件處理示例中的每個(gè)任務(wù)僅持續對特定電子郵件執行特定動(dòng)作。 完成后，任務(wù)和容器應該終止。

可能存在需要持久或長(cháng)時(shí)間運行的進(jìn)程的情況，如實(shí)現應用服務(wù)器或API服務(wù)器，這些場(chǎng)景我們通常放在無(wú)服務(wù)器范例之外。 在大多數情況下，你覺(jué)得可能需要長(cháng)時(shí)間運行的任務(wù)，很可能有辦法避免這種開(kāi)銷(xiāo)。 例如，無(wú)服務(wù)器平臺，消息隊列或其他組件可能能夠適應任何路由需求。 同樣，計劃任務(wù)可能能夠提供定期狀態(tài)檢查或處理周期。這里的示例是整合和處理來(lái)自各種數量的IoT設備的流數據。 如果數據被收集在一個(gè)或多個(gè)隊列或數據庫中，則調度作業(yè)可以在周期性（和頻繁）基礎上運行，查看隊列中或數據庫中的數據，并啟動(dòng)一個(gè)或多個(gè)子任務(wù)以執行每個(gè)數據的合并和處理片。

注意，在實(shí)際處理場(chǎng)景中，容器可能不會(huì )在每個(gè)任務(wù)之后終止，主要是出于性能原因。 容器可以從任務(wù)持續到下一個(gè)任務(wù)，但是它們的狀態(tài)和存儲將被擦除和重置，使得每個(gè)任務(wù)或事件處理循環(huán)被隔離并且短周期的。

冪等

冪等是構建到微服務(wù)和無(wú)服務(wù)器函數的關(guān)鍵屬性（小編：在高可用架構群討論及分享中，這一術(shù)語(yǔ)也被反復提及）。 在基本級別，能夠運行重復的任務(wù)并獲得相同的結果。它也能夠使多個(gè)重復的請求具有與單個(gè)請求相同的效果。 這是第二個(gè)定義，對于任務(wù)以高度并發(fā)和異步方式操作時(shí)的設計至關(guān)重要。 在任何作業(yè)處理環(huán)境中，任務(wù)可能由于多種原因（服務(wù)器崩潰，資源限制，第三方服務(wù)超時(shí)，任務(wù)超時(shí)等）而無(wú)法完成。

在其他情況下，任務(wù)可以完成，但是可能已經(jīng)調用了針對相同的重復處理請求。 這樣的一個(gè)示例是注冊消息的超時(shí)的隊列，因為任務(wù)可能仍然在處理請求（并且因此沒(méi)有及時(shí)刪除或取消保留消息）。 結果，隊列可能觸發(fā)對該消息的另一處理請求。

如果只是簡(jiǎn)單繼續處理這些任務(wù) - 將其放在隊列上或將其寫(xiě)入數據庫，可能會(huì )有不良影響，尤其是在事務(wù)情況下。 例如，會(huì )產(chǎn)生兩個(gè)重復的訂單。 這是最重要的，然后確保只有一個(gè)請求處理相同的任務(wù)。 正是由于這個(gè)原因，在無(wú)服務(wù)器平臺（如大多數其他處理領(lǐng)域）中，開(kāi)發(fā)人員需要在處理之前和/或在寫(xiě)入或輸出結果之前，執行重復任務(wù)的檢查。

以一個(gè)開(kāi)發(fā)者朋友的話(huà)來(lái)說(shuō)，另一種思考方式是“想象一下，如果服務(wù)器崩潰，而任務(wù)正在中間處理并且任務(wù)被重試。 或者，如果它只是排隊或安排兩次。 你需要做什么，以確保你不會(huì )覆蓋數據，添加重復的事務(wù)，因為它可能會(huì )多次運行�！� 因此在處理周期中，在適當點(diǎn)檢查和驗證，以確保尚未執行工作。

多語(yǔ)言編程（Polyglot）

Polyglot是指以多種語(yǔ)言編程。 在無(wú)服務(wù)器編程的情況下，它指的是以多種語(yǔ)言編寫(xiě)和執行任務(wù)的能力。 雖然每個(gè)功能可能只是一種語(yǔ)言，正確的無(wú)服務(wù)器平臺應該能夠處理多種語(yǔ)言。 這意味著(zhù)它還應該提供一個(gè)重要級別的代碼獨立性，使開(kāi)發(fā)人員可以透明地工作，而不必關(guān)心操作系統和服務(wù)器級依賴(lài)關(guān)系。

多語(yǔ)言的優(yōu)點(diǎn)是能夠在不同的任務(wù)中使用合適的工具。 或者，為對應的團隊使用適合他們使用的工具。 在實(shí)際情況中經(jīng)常發(fā)生的是，如果你擁有一把錘子，你看到一切都像釘子。使用單一語(yǔ)言，常常會(huì )約束解決問(wèn)題的方法。 開(kāi)發(fā)人員可能艱難的適應那種語(yǔ)言的代碼包來(lái)完成他們的需要，而事實(shí)上，其他語(yǔ)言的其他庫也許可以更好地服務(wù)于目的。

為了計算貝葉斯統計或進(jìn)行機器學(xué)習，您可能希望使用用C，C ++，Python或Java編寫(xiě)的包。 同樣，與您合作的開(kāi)發(fā)團隊可能精通特定的網(wǎng)絡(luò )爬行包，它是為特定語(yǔ)言編寫(xiě)的（例如以Ruby編寫(xiě)的Nokogiri）。 能夠利用這種知識和經(jīng)驗可以消除開(kāi)發(fā)周期，以及降低項目延遲或失敗的風(fēng)險。

請注意，許多較新的無(wú)服務(wù)器平臺目前僅支持少數幾種語(yǔ)言，但我希望在今年內能夠快速改變。 （例如，IronWorker可以處理大多數常用語(yǔ)言和可執行代碼。）

兼容性

無(wú)服務(wù)器任務(wù)需要考慮兩個(gè)兼容性順序。 第一個(gè)是任務(wù)之間，第二個(gè)是版本之間。 當你分解任務(wù)時(shí)候，你需要強大的服務(wù)契約和組件之間的規范。 規范的API格式可以通過(guò)常用的身份驗證和傳輸協(xié)議解決部分問(wèn)題，但是使用自定義函數和服務(wù)，開(kāi)發(fā)人員仍然需要定義有意義且易于理解的輸入和輸出模式。

除了干凈的接口，開(kāi)發(fā)人員需要解決版本控制需求。 例如，假設函數X在平臺內運行，并且它調用函數Y，如果函數Y已經(jīng)被更新而沒(méi)有讓函數X知道并被正確設計，則它可能在處理時(shí)失敗或者它可能產(chǎn)生不正確的結果（或者它導致期望原始結果的任務(wù)中的下游故障）。

與代碼包一樣，無(wú)服務(wù)器任務(wù)中的更改和更新可以通過(guò)應用程序發(fā)布。 在代碼包的情況下，這些沖突可能會(huì )通過(guò)打包和編譯工具早期發(fā)現。 然而，使用微服務(wù)和無(wú)服務(wù)器編程，它可能只是通過(guò)運行服務(wù)（最好在測試或仿真環(huán)境），問(wèn)題才會(huì )被發(fā)現。

這意味著(zhù)，所有這些無(wú)狀態(tài)性和任務(wù)和服務(wù)獨立性，團隊需要注意不僅設計良好構建的接口，而且解決向后兼容性的意識。 一個(gè)幫助可以是在描述/版本化無(wú)服務(wù)器任務(wù)中使用語(yǔ)義版本[3] 。 它不是萬(wàn)能的，但隨著(zhù)這個(gè)版本化約定的傳播，它為可能正在使用您創(chuàng )建的任務(wù)的其他開(kāi)發(fā)人員提供了一些基礎。