前言

在介紹運維之前，我們先來快速了解一下 () 的概念。由于筆者的實戰經驗是在AWS平臺上，所以本文中的指的是使用AWS搭建的應用。特點是用戶無需預先配置或管理服務器，只需要部署功能代碼，服務會在需要時執行代碼并自動伸縮，從每天幾個請求到每秒幾千個請求，輕松實現FaaS（作為一個）。如下所示：

（圖片來自網絡）

在傳統的應用程序中，除了編寫功能代碼外，開發團隊還需要監控實時負載，相應地擴展應用程序，并處理由于非功能故障（硬盤、內存等）導致的一些停機時間。另一方面，無服務器架構將開發團隊從服務器維護工作中解放出來，然后可以更多地專注于功能代碼（如圖）。在實際項目中，開發者只需將功能代碼打包上傳到AWS，然后進行少量配置（環境變量、觸發條件、內存、超時等），即可使應用/服務上線。

這些是無服務器架構的基本概念。接下來，筆者將從日志、指標、監控告警、容災四個維度來介紹架構下的運維。

日志

默認情況下，應用程序運行時產生的日志會保存在應用服務器上。當需要查看日志時，運維人員需要遠程登錄服務器獲取日志信息。這種方式操作起來略顯繁瑣，而且當應用服務器數量增加時，查找日志的效率會嚴重降低，因為需要先找到產生錯誤信息的服務器。

一種解決方案是ELK(, , )，這三個開源工具執行各自的功能，負責日志的推送和轉換，作為數據庫和搜索引擎，作為圖形界面。好處是易于構建、良好的可擴展性和免費。但額外的代價是獨立的日志服務還需要做全方位的監控（應用狀態、硬盤、網絡等），避免因基礎服務出現問題而導致系統整體故障。

AWS 無服務器架構中的日志是一種開箱即用的服務。所有日志都會自動收集到 AWS 日志中。只要根據服務名稱找到對應的日志組，就可以查詢搜索，無需任何配置或維護。成本。

指數

通常，運維工作會包括收集在線應用的運行指標，以反映應用的健康狀態、故障率、性能、訪問量、訪問頻率等。這里舉一個用Boot構建的API服務的例子，起到收集指標的作用。默認情況下，對于每個 API，會自動收集以下指標：

當然，我們可以通過實現一些接口來擴展/自定義集合指標，這里不再展開。有了指標數據，還需要相應的報表或儀表盤工具服務器運維，才能更好的查詢和展示。您可以選擇像 .

那么 AWS 無服務器架構是否提供類似的指標收集？答案是肯定的，AWS 會自動收集以下四個指標：

并取總時間，將兩者結合得到應用程序的錯誤率，如下

平均值用于反映一段時間內的表現。在筆者的項目中，耗時主要集中在SQL查詢上。這個數字可以相應地反映技術人員對查詢優化的效果。當然，在實踐中，這些檢查可以在預發布環境中進行，這個例子只是為了便于理解。

在作者目前的項目中，并沒有使用過。默認并發限制為 1000 次/秒，最常用的調用頻率僅為每分鐘 150 次，遠未超出限制。但是，這個數據很重要，對于并發高的應用程序來說是很重要的。

除了幾個開箱即用的指標外，您還可以結合API在相應的功能代碼中埋點，自定義指標的集合。比如代碼中的一、三個子任務服務器運維，默認提供的只能反映整體的運行效率。如果需要統計每個任務的消耗，需要使用AWS API。

監控和報警

監控的意義在于全面了解應用程序的資源使用、性能和運行情況。這些數據可以用來幫助團隊及時進行調整，以確保應用程序的順利運行。這通常包括 CPU 使用率、數據傳輸、磁盤使用率等。當突發事件導致系統不可用時，團隊的響應速度往往取決于監控和報警的及時性、全面性和準確性。如果能夠根據歷史數據的分析合理配置監控系統，團隊甚至可以預測不好的事情會發生，提前防備，未雨綢繆。

同上，這里以一個Boot應用為例，在上一節指標數據的收集中提到過。其實除了記錄上面提到的指標外，還可以用來采集監控數據。這里我們只需要設置一個Boot Admin應用，將Boot Admin配置添加到需要監控的應用中，監控數據就會通過暴露的API傳遞給Boot Admin。

報警功能一般需要根據實際情況自行實現。在 Boot Admin 中實現了 Slack 和 Slack 等第三方工具的集成。如果你只需要一個簡單的郵件提醒，并且實現不復雜，這里就不展開了。

隨著云基礎設施的普及，上面提到的監控報警早已是各個平臺的標準配置。輪到開發人員擔心如何實現和維護它。運營團隊可以更加專注于配置優化。去工作。

AWS 默認提供非常完整的監控數據，也允許自定義監控。通過在創建的指標中添加一系列重要指標，應用程序的運行狀態可以一目了然。

如前所述，在發生錯誤或性能低下時，根據某些關鍵指標的變化發送警告通知是非常必要的。筆者項目的做法是使用AWS和AWS SNS提供的告警通知功能。您只需選擇指標，然后設置觸發閾值和檢查間隔。AWS SNS 支持 HTTP、SMS、Email 和其他訂閱方式。下圖顯示了如何配置在過去 5 分鐘內發生超過 5 次特定錯誤時發送通知。

災難備份與恢復

在系統鏡像、構建工具和容器技術越來越普及的今天，災難備份的意義在很大程度上是為了有效保護重要數據。通常的做法是設置一些周期性的任務，將數據傳輸到異地容災中心，以物理抵御不可抗力的災難。如果數據量太大，網絡傳輸效率跟不上，可以參考AWS用卡車拉數據的方案。

災難備份的實際需求在筆者有限的經驗中并沒有發生，但如果不提前計劃，一旦發生，后果將難以想象。作者項目中使用的AWS RDS默認開啟自動備份，周期為7天。可以手動調整此配置或將其寫入腳本以構建基礎架構。在發生災難時，僅僅備份數據是不夠的，您還需要一個能夠快速重建應用程序運行時的基礎架構。筆者所在的團隊（以下簡稱團隊）使用AWS和，分別對數據庫、網絡等基礎設施進行重建，在重建數據庫時，通過持續集成管道，

總結

筆者所在的團隊有一個10人左右的配置，采用結對編程的方式，3對結對，包括web端、業務層、數據層。從產品原型確認到首次發布（MVP）需要30天，每周至少發布一次新版本。故事的平均交付時間（周期時間，從需求確認到發布）為 8 天。這個速度可能算不上快，但是如果沒有運維側架構提供的支持，我們要在交付速度上實現更高的突破會困難很多。

最后，讓我們談談成本。俗話說，談技術不商業化是流氓。大多數人看到一個功能強大且好用的工具時，都會下意識地覺得成本會非常大。事實上，情況并非如此。我們粗略計算了一下，使用了雙核 CPU、8G 內存的 M4 服務器，費用為每月 72 美元。dev、 和 prod 三個環境都使用相同的配置，每月 216 美元。事實上，每月的開銷包括大約 20 美元的所有環境。應該注意的是，計費是基于使用情況的。我們的 API 訪問量約為每月 150 萬次。可以預見，當訪問量達到一定數量時，開銷將與使用服務器的方案相同甚至更大，但在數量較少時優勢明顯。

得益于強大的 AWS 生態，使用它構建的 應用可以以極低的價格獲得完整的運維功能和體驗，幾乎不需要配置。與使用開源工具構建的方式相比，研發團隊可以從繁瑣的運維工作——尤其是基礎工程建設——中解脫出來，更加專注于產品本身，大大提高了軟件交付速度、可用性、可靠性和可擴展性也得到了相當的保證。代價是更高的遷移成本，部分功能的非定制化可能成為瓶頸，底層實現原理的屏蔽也可能對開發者的學習和成長產生影響。

文/王智