前言

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

（圖片來自網(wǎng)絡）

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

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

日志

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

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

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

指數(shù)

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

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

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

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

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

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

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

監(jiān)控和報警

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

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

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

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

AWS 默認提供非常完整的監(jiān)控數(shù)據(jù)，也允許自定義監(jiān)控。通過在創(chuàng)建的指標中添加一系列重要指標，應用程序的運行狀態(tài)可以一目了然。

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

災難備份與恢復

在系統(tǒng)鏡像、構(gòu)建工具和容器技術(shù)越來越普及的今天，災難備份的意義在很大程度上是為了有效保護重要數(shù)據(jù)。通常的做法是設置一些周期性的任務，將數(shù)據(jù)傳輸?shù)疆惖厝轂闹行模晕锢淼钟豢煽沽Φ臑碾y。如果數(shù)據(jù)量太大，網(wǎng)絡傳輸效率跟不上，可以參考AWS用卡車拉數(shù)據(jù)的方案。

災難備份的實際需求在筆者有限的經(jīng)驗中并沒有發(fā)生，但如果不提前計劃，一旦發(fā)生，后果將難以想象。作者項目中使用的AWS RDS默認開啟自動備份，周期為7天。可以手動調(diào)整此配置或?qū)⑵鋵懭肽_本以構(gòu)建基礎架構(gòu)。在發(fā)生災難時，僅僅備份數(shù)據(jù)是不夠的，您還需要一個能夠快速重建應用程序運行時的基礎架構(gòu)。筆者所在的團隊（以下簡稱團隊）使用AWS和，分別對數(shù)據(jù)庫、網(wǎng)絡等基礎設施進行重建，在重建數(shù)據(jù)庫時，通過持續(xù)集成管道，

總結(jié)

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

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

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

文/王智