無服務(wù)器架構(gòu)是一種趨勢軟件設(shè)計模式，它消除了開發(fā)人員對服務(wù)器軟件和硬件管理的需求。在無服務(wù)器架構(gòu)中，也稱為無服務(wù)器計算或功能即服務(wù) (FaaS)，第三方服務(wù)（稱為后端即服務(wù)或“BaaS”）托管應(yīng)用程序。顧名思義，它并不真正涉及在沒有服務(wù)器的情況下運行代碼。相反，擁有系統(tǒng)的人不需要購買、租用或配置服務(wù)器或虛擬機來運行后端代碼。

AWS Lambda 是無服務(wù)器架構(gòu)的最佳示例，它實現(xiàn)了云計算的功能即服務(wù)模型。無服務(wù)器計算確保了理想的、預(yù)算友好的業(yè)務(wù)實施的可能性。無服務(wù)器應(yīng)用程序在由云提供商管理的無狀態(tài)計算容器中實現(xiàn)，這些容器是事件觸發(fā)的、短暫的（可能持續(xù)一次調(diào)用）。定價取決于執(zhí)行次數(shù)，而不是傳統(tǒng)架構(gòu)中的預(yù)購計算能力。功能即服務(wù)允許開發(fā)人員執(zhí)行代碼以響應(yīng)事件，從而消除了開發(fā)和維護基礎(chǔ)設(shè)施的復(fù)雜性。

使用 FaaS 編寫的無服務(wù)器代碼可以與以傳統(tǒng)服務(wù)器風格編寫的代碼結(jié)合使用。FaaS 將應(yīng)用程序分解為功能和事件級別。Christos Matskas 為任何開發(fā)基于云的應(yīng)用程序的人提供了有用的總結(jié)。“Azure 為托管微服務(wù)提供了一個理想的平臺，因為它提供了許多托管服務(wù)，允許開發(fā)人員創(chuàng)建可以可靠和大規(guī)模運行的微服務(wù)。問題在于了解這些托管服務(wù)如何提供幫助以及哪種服務(wù)最適合該任務(wù)。”

無服務(wù)器 Java

可以使用 Java 構(gòu)建大型無服務(wù)器應(yīng)用程序。Java 方法在構(gòu)建各種可擴展、可進化和多 lambda 無服務(wù)器應(yīng)用程序方面非常有效。

實現(xiàn)無服務(wù)器功能

• 客戶端向無服務(wù)器計算平臺請求完成特定功能。
• 無服務(wù)器計算平臺最初會檢查該功能是否正在其任何服務(wù)器上運行。如果沒有，平臺從數(shù)據(jù)存儲加載函數(shù)。
• 然后將該函數(shù)部署到其中一臺服務(wù)器上，并預(yù)先配置了一個執(zhí)行環(huán)境來運行該函數(shù)。
• 執(zhí)行該函數(shù)以捕獲結(jié)果。
• 結(jié)果返回給客戶端。

無服務(wù)器架構(gòu)模式

Amazon Web Services的 Lambda 無服務(wù)器服務(wù)的五種主要使用模式包括：

1.事件驅(qū)動數(shù)據(jù)處理

• 在事件之后觸發(fā)動作，例如。觸發(fā) lambda 函數(shù)
• 非常適合混合趨勢
• 用于在更廣泛的托管環(huán)境中執(zhí)行請求的功能

2.網(wǎng)絡(luò)應(yīng)用

• 確定用戶上下文和個人元素的過程組合
• 靜態(tài)內(nèi)容用動態(tài)內(nèi)容增強并存儲為動態(tài)數(shù)據(jù)

3.移動和物聯(lián)網(wǎng)應(yīng)用

• 服務(wù)于用戶上下文目的
• 檢查用戶是否被適當授權(quán)
• 然后執(zhí)行功能，然后進行數(shù)據(jù)交互以滿足用戶要求。

4.應(yīng)用生態(tài)

• 應(yīng)用程序工作流是在無服務(wù)器環(huán)境中開發(fā)的
• 實施后，向用戶發(fā)送反饋

5. 活動工作流程

• 通過創(chuàng)建的決策樹的工作流分支操作

無服務(wù)器架構(gòu)的優(yōu)缺點

無服務(wù)器架構(gòu)的好處

1.降低運營成本：作為一種外包解決方案，它為管理服務(wù)器、數(shù)據(jù)庫甚至應(yīng)用程序邏輯的支付鋪平了道路。成本削減來自兩個方面，基礎(chǔ)設(shè)施成本收益和勞動力成本收益。您只需按執(zhí)行次數(shù)付費。

2.更簡單的運維管理：為Serverless架構(gòu)搭建各種環(huán)境非常簡單易行。它明確區(qū)分了基礎(chǔ)架構(gòu)服務(wù)和應(yīng)用程序。自動擴展功能降低了運營管理開銷。無服務(wù)器系統(tǒng)不需要持續(xù)集成、持續(xù)交付或容器化工具。零系統(tǒng)管理是無服務(wù)器系統(tǒng)的另一個優(yōu)勢。

3.更快的創(chuàng)新：無服務(wù)器架構(gòu)消除了系統(tǒng)工程問題、更快創(chuàng)新和更新技術(shù)以獲得高效結(jié)果的可能性。

4.降低打包和部署的復(fù)雜性

無服務(wù)器架構(gòu)的缺點

1.第三方API問題：

• 安全問題
• 多租戶問題
• 供應(yīng)商控制
• 供應(yīng)商鎖定

由于 API 的實施而放棄系統(tǒng)控制也可能導(dǎo)致系統(tǒng)停機、功能減少、成本變化、意外限制和強制 API 升級。切換供應(yīng)商也是一個非常復(fù)雜的問題。許多 API 使您的無服務(wù)器系統(tǒng)容易受到攻擊，每個 API 都會增加安全實現(xiàn)的數(shù)量。

2.缺乏操作工具：廠商負責提供調(diào)試和監(jiān)控工具。在無服務(wù)器架構(gòu)中，由于用戶請求由不透明的負載均衡器（如 AWS API 網(wǎng)關(guān)）處理，因此缺少訪問各種參數(shù)以確定根本原因的靈活性。

3.架構(gòu)復(fù)雜性：它們很復(fù)雜，需要很長時間才能構(gòu)建。評估、實施和測試以及決定功能應(yīng)該有多小需要花費大量時間。必須在函數(shù)數(shù)量和應(yīng)用程序調(diào)用之間保持平衡。管理如此多的功能變得乏味，而忽略粒度會導(dǎo)致產(chǎn)生不必要的混亂。

4.網(wǎng)絡(luò)：無服務(wù)器功能只能通過私有 API 訪問。因此，您無法通過通常的 IP 訪問它們。

5.超時：由于 300 秒的超時限制與無服務(wù)器系統(tǒng)相關(guān)，過于復(fù)雜和耗時的功能不適合。由于這種限制，某些任務(wù)也被發(fā)現(xiàn)是不可能的。因此，無服務(wù)器系統(tǒng)對于執(zhí)行時間可變的應(yīng)用程序變得不可用。

如果系統(tǒng)真的需要無服務(wù)器架構(gòu)，則可以實現(xiàn)它。進行詳細研究以了解它如何適合您的操作。無服務(wù)器系統(tǒng)仍處于初期階段，遵循無服務(wù)器系統(tǒng)的組織應(yīng)考慮過度依賴第三方 API 以及架構(gòu)復(fù)雜性的困難。