儘管無服務器技術近年來迅速流行，但仍然存在許多與之相關的誤解和恐懼。 供應商依賴性、工具、成本管理、冷啟動、監控和開發生命週期都是無服務器技術的熱門話題。 在本文中，我們將探討提到的一些主題，並分享提示和有用信息來源的鏈接，以幫助初學者創建功能強大、靈活且經濟高效的無服務器應用程序。
關於無服務器技術的誤解
許多人認為無服務器和無服務器處理（, FaaS) 幾乎是一回事。 這意味著差異並不太大，值得引入一個新意。 儘管 AWS Lambda 是無服務器全盛時期的明星之一，也是無服務器架構中最受歡迎的元素之一，但是，這種架構遠不止 FaaS。
無服務器技術背後的基本原則是您不必擔心管理和擴展基礎架構，您只需為使用的內容付費。 許多服務都符合這些標準——AWS DynamoDB、S3、SNS 或 SQS、Graphcool、Auth0、Now、Netlify、Firebase 等等。 一般來說，無服務器意味著使用雲計算的全部功能，而無需管理基礎設施並優化它以進行擴展。 這也意味著您不再關心基礎架構級別的安全性，考慮到滿足安全標準的難度和復雜性，這是一個巨大的好處。 最後，您不必購買提供給您的基礎設施。
Serverless 可以被認為是一種“心態”：設計解決方案時的某種心態。 避免需要維護任何基礎設施的方法。 通過無服務器方法，我們花時間解決直接影響項目並為我們的用戶帶來好處的任務：我們創建可持續的業務邏輯，開髮用戶界面，並開發自適應和可靠的 API。
例如，如果可以避免管理和維護自由文本搜索平台，那麼我們就會這樣做。 這種構建應用程序的方法可以大大加快上市時間，因為您不再需要考慮管理複雜的基礎架構。 消除基礎架構管理的責任和成本，專注於構建客戶需要的應用程序和服務。 Patrick Debois 稱這種方法為 ，該術語在無服務器社區中被採用。 函數應該被視為作為可部署模塊的服務鏈接（而不是部署整個庫或 Web 應用程序）。 這為管理應用程序的部署和更改提供了令人難以置信的粒度。 如果您不能以這種方式部署功能，那麼可能表明這些功能執行的任務太多，需要重構。
有些人對開發雲應用程序時對供應商的依賴感到困惑。 無服務器技術也是如此，這不是誤解。 根據我們的經驗，在 AWS 上構建無服務器應用程序，結合 AWS Lambda 將其他 AWS 服務捆綁在一起的能力，是無服務器架構優勢的一部分。 這是協同作用的一個很好的例子，組合的結果不僅僅是各項的總和。 試圖避免依賴供應商可能會遇到更多問題。 使用容器時，在雲提供商之間管理自己的抽象層會更容易。 但是當談到無服務器解決方案時，這種努力不會得到回報，尤其是如果從一開始就考慮成本效益的話。 請務必了解供應商如何提供服務。 一些專門的服務依賴於與其他供應商的集成點，並且可能提供開箱即用的即插即用連接。 從網關 API 端點提供 Lambda 調用比將請求代理到某個容器或 EC2 實例更容易。 Graphcool 使用 Auth0 提供簡單的配置，這比使用第三方身份驗證工具更容易。
為您的無服務器應用程序選擇合適的供應商是一個架構決策。 當您創建一個應用程序時，您不會期望有一天返回管理服務器。 選擇雲供應商與選擇使用容器或數據庫，甚至是編程語言沒有什麼不同。
考慮：
- 您需要什麼服務以及為什麼。
- 雲提供商提供哪些服務以及如何將它們與您選擇的 FaaS 解決方案相結合。
- 支持什麼編程語言（動態類型還是靜態類型，編譯還是解釋，基準是什麼，冷啟動性能如何，開源生態系統是什麼等等）。
- 您的安全要求是什麼（SLA、2FA、OAuth、HTTPS、SSL 等）。
- 如何管理您的 CI/CD 和軟件開發週期。
- 您可以利用哪些基礎架構即代碼解決方案。
如果您擴展現有應用程序並逐步添加無服務器功能，這可能會在一定程度上限制可用功能。 但是，幾乎所有無服務器技術都提供某種 API（通過 REST 或消息隊列），允許您創建獨立於應用程序核心且易於集成的擴展。 尋找具有清晰 API、良好文檔和強大社區的服務，您不會出錯。 易於集成通常是一個關鍵指標，這可能是 AWS 自 2015 年發布 Lambda 以來如此成功的主要原因之一。
什麼時候無服務器好
無服務器技術幾乎可以應用到任何地方。 然而，它們的優勢並不僅限於一種應用方式。 由於無服務器技術，如今雲計算的進入門檻非常低。 如果開發人員有一個想法，但他們不知道如何管理雲基礎設施和優化成本，那麼他們就不需要找某種工程師來做。 如果一家初創公司想要構建一個平台，但擔心成本可能失控，他們可以輕鬆轉向無服務器解決方案。
由於成本節約和易於擴展，無服務器解決方案同樣適用於內部和外部系統，直至擁有數百萬受眾的 Web 應用程序。 賬戶不是以歐元計算，而是以美分計算。 租用最簡單的 AWS EC2 (t1.micro) 實例一個月將花費 15 歐元，即使您什麼都不做（誰從來沒有忘記關閉它？！）。 相比之下，要在同一時間段內達到此支出水平，您需要運行 512 MB Lambda 1 秒約 3 萬次。 如果您不使用此功能，則無需支付任何費用。
因為無服務器主要是事件驅動的，所以向舊系統添加無服務器基礎設施相當容易。 例如，使用 AWS S3、Lambda 和 Kinesis，您可以為可以通過 API 接收數據的舊零售系統創建分析服務。
大多數無服務器平台都支持多種語言。 最常見的是 Python、JavaScript、C#、Java 和 Go。 通常所有語言的庫都沒有使用限制，所以你可以使用你喜歡的開源庫。 但是，建議不要濫用依賴關係，以便您的功能以最佳方式執行，並且不會抵消無服務器應用程序的巨大可擴展性帶來的好處。 需要裝入容器的包越多，冷啟動時間就越長。
冷啟動是指在使用之前首先需要初始化容器、運行時和錯誤處理程序。 因此，功能執行的延遲最多可達 3 秒，對於不耐煩的用戶而言，這不是最佳選擇。 然而，冷啟動發生在空閒函數幾分鐘後的第一次調用中。 許多人認為這是一個小麻煩，可以通過定期 ping 函數以使其保持空閒來解決。 或者他們完全忽略了這一方面。
雖然 AWS 發布了但是，SQL 數據庫並不適合此應用程序，因為它們依賴於連接來執行事務，這會很快成為 AWS Lambda 上的大流量瓶頸。 是的，開發人員正在不斷改進 Serverless Aurora，您應該嘗試一下，但今天的 NoSQL 解決方案如. 不過，毫無疑問，這種情況很快就會發生改變。
該工具包還施加了很多限制，尤其是在本地測試領域。 儘管有 Docker-Lambda、DynamoDB Local 和 LocalStack 等解決方案，但它們需要艱苦的工作和大量的配置。 然而，所有這些項目都在積極開發中，因此工具包達到我們需要的水平只是時間問題。
無服務器技術對開發週期的影響
因為您的基礎架構只是一種配置，所以您可以使用腳本（例如 shell 腳本）來定義和部署代碼。 或者您可以求助於配置即代碼類解決方案，例如 . 雖然此服務不提供所有區域的配置，但它確實允許您定義特定資源以用作 Lambda 函數。 也就是說，如果 CloudFormation 無法滿足您的要求，您可以編寫自己的資源（Lambda 函數）來彌補這一差距。 這樣您就可以做任何事情，甚至可以在您的 AWS 環境之外配置依賴項。
因為這只是配置，所以您可以針對特定環境、區域和用戶自定義部署腳本，尤其是在您使用 CloudFormation 等基礎架構即代碼解決方案時。 例如，您可以為存儲庫中的每個分支部署基礎架構的副本，以便您可以在開發期間完全隔離地測試它們。 當開發人員想要了解他們的代碼是否在實時環境中充分工作時，這大大加快了他們的反饋速度。 管理人員無需擔心部署多個環境的成本，因為他們只需為實際使用付費。
DevOps 不用擔心，因為他們只需要確保開發人員擁有正確的配置。 您不再需要管理實例、平衡器或安全組。 因此，術語 NoOps 被越來越多地使用，儘管能夠配置基礎設施仍然很重要，尤其是在涉及 IAM 配置和雲資源優化時。
有非常強大的監控和可視化工具，如 Epsagon、Thundra、Dashbird 和 IOPipe。 它們允許您監控無服務器應用程序的當前狀態、提供日誌記錄和跟踪、捕獲性能指標和架構瓶頸、執行成本分析和預測等。 它們不僅為 DevOps 工程師、開發人員和架構師提供應用程序性能的全面視圖，還允許管理人員實時監控情況，以及每秒資源成本和成本預測。 使用託管基礎設施組織起來要困難得多。
設計無服務器應用程序要容易得多，因為您不必部署 Web 服務器、管理虛擬機或容器、補丁服務器、操作系統、互聯網網關等。通過抽象所有這些職責，無服務器架構可以專注於核心 -解決方案、業務和客戶需求。
雖然工具包可能會更好（每天都在變得更好），但開發人員可以專注於實現業務邏輯並在架構內的不同服務之間最好地分配應用程序的複雜性。 無服務器應用程序管理基於事件並由雲提供商抽象（例如 SQS、S3 事件或 DynamoDB 流）。 因此，開發者只需要編寫業務邏輯來響應某些事件，而不必擔心如何最好地實現數據庫和消息隊列，或者如何在特定的硬件存儲中組織最佳的數據工作。
與任何開發過程一樣，代碼可以在本地運行和調試。 單元測試保持不變。 使用自定義堆棧配置部署整個應用程序基礎架構的能力使開發人員能夠快速獲得重要反饋，而無需考慮測試成本或對昂貴的託管環境的影響。
用於構建無服務器應用程序的工具和技術
沒有特定的方法來構建無服務器應用程序。 以及用於此任務的一組服務。 AWS 是當今強大的無服務器解決方案中的領導者，但也可以看看 , и . 如果您使用的是 AWS，則推薦的收集應用程序的方法是 (SAM)，尤其是在使用 C# 時，因為 Visual Studio 具有出色的工具。 SAM CLI 可以做 Visual Studio 可以做的所有事情，所以如果您切換到另一個 IDE 或文本編輯器，您不會丟失任何東西。 當然，SAM 也適用於其他語言。
如果您使用其他語言編寫，Serverless Framework 是一個優秀的開源工具，它允許您使用非常強大的 YAML 配置文件來配置任何東西。 Serverless Framework 還支持各種雲服務，因此我們推薦給那些正在尋找多雲解決方案的人。 它有一個龐大的社區，已經為任何需要創建了一堆插件。
對於本地測試，開源工具 Docker-Lambda、Serverless Local、DynamoDB Local 和 LocalStack 非常適合。 無服務器技術仍處於開發的早期階段，適用於它們的工具也是如此，因此在設置複雜的測試場景時，您將不得不努力工作。 然而，簡單地在一個環境中部署堆棧並在那裡進行測試的成本非常低。 而且您不需要製作雲環境的精確本地副本。
使用 AWS Lambda Layers 減少已部署包的大小並加快下載速度。
為特定任務使用正確的編程語言。 不同的語言各有優缺點。 基準測試有很多，但 JavaScript、Python 和 C#（.NET Core 2.1+）在 AWS Lambda 性能方面處於領先地位。 AWS Lambda 最近推出了 Runtime API，它允許您指定所需的語言和運行時環境，因此請進行試驗。
保持較小的包大小以便部署。 它們越小，加載速度越快。 避免使用大型庫，尤其是當您使用其中的一些功能時。 如果您使用 JavaScript 進行編程，請使用 Webpack 等構建工具來優化您的構建，並且只包含您真正需要的內容。 .NET Core 3.0 具有 QuickJit 和分層編譯，可提高性能並對冷啟動有很大幫助。
無服務器函數對事件的依賴使得一開始很難協調業務邏輯。 在這方面，消息隊列和狀態機非常有用。 Lambda 函數可以相互調用，但只有在您不期望響應（“即發即棄”）時才這樣做——您不想因為等待另一個函數完成而被計費。 消息隊列對於隔離部分業務邏輯、管理應用程序瓶頸和處理事務（使用 FIFO 隊列）很有用。 AWS Lambda 函數可以分配給 SQS 隊列作為卡住的消息隊列，跟踪失敗的消息以供以後分析。 AWS Step Functions（狀態機）對於管理需要函數鏈的複雜流程非常有用。 不同於調用另一個函數的 Lambda 函數，Step 函數可以協調狀態轉換、在函數之間傳遞數據以及管理函數的全局狀態。 這允許您定義重試條件，或者當特定錯誤發生時要做什麼 - 在某些條件下是一個非常強大的工具。
結論
近年來，無服務器技術一直在以前所未有的速度發展。 這種範式轉變存在某些誤解。 通過抽象化基礎架構和擴展管理，無服務器解決方案提供了顯著的優勢，從簡化的開發和 DevOps 流程到大幅降低運營成本。
雖然無服務器方法並非沒有缺點，但有一些健壯的設計模式可用於構建健壯的無服務器應用程序或將無服務器元素集成到現有架構中。
來源： www.habr.com