前言

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

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

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

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

日志

默認(rèn)情況下，應(yīng)用程序運(yùn)行時(shí)產(chǎn)生的日志會(huì)保存在應(yīng)用服務(wù)器上。當(dāng)需要查看日志時(shí)，運(yùn)維人員需要遠(yuǎn)程登錄服務(wù)器獲取日志信息。這種方式操作起來略顯繁瑣，而且當(dāng)應(yīng)用服務(wù)器數(shù)量增加時(shí)，查找日志的效率會(huì)嚴(yán)重降低，因?yàn)樾枰日业疆a(chǎn)生錯(cuò)誤信息的服務(wù)器。

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

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

指數(shù)

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

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

那么 AWS 無服務(wù)器架構(gòu)是否提供類似的指標(biāo)收集？答案是肯定的，AWS 會(huì)自動(dòng)收集以下四個(gè)指標(biāo)：

并取總時(shí)間，將兩者結(jié)合得到應(yīng)用程序的錯(cuò)誤率，如下

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

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

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

監(jiān)控和報(bào)警

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

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

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

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

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

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

災(zāi)難備份與恢復(fù)

在系統(tǒng)鏡像、構(gòu)建工具和容器技術(shù)越來越普及的今天，災(zāi)難備份的意義在很大程度上是為了有效保護(hù)重要數(shù)據(jù)。通常的做法是設(shè)置一些周期性的任務(wù)，將數(shù)據(jù)傳輸?shù)疆惖厝轂?zāi)中心，以物理抵御不可抗力的災(zāi)難。如果數(shù)據(jù)量太大，網(wǎng)絡(luò)傳輸效率跟不上，可以參考AWS用卡車?yán)瓟?shù)據(jù)的方案。

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

總結(jié)

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

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

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

文/王智