在介紹運(yùn)維之前，我們先簡單了解一下()的概念。 由于筆者的實(shí)戰(zhàn)經(jīng)驗(yàn)是在AWS平臺(tái)上進(jìn)行的，所以本文中的指的是使用AWS構(gòu)建的應(yīng)用。 特點(diǎn)是用戶不需要預(yù)先配置或管理服務(wù)器，他們只需要部署功能代碼，服務(wù)會(huì)在需要時(shí)執(zhí)行代碼并手動(dòng)擴(kuò)展，從每晚幾個(gè)請(qǐng)求到每秒數(shù)千個(gè)請(qǐng)求，輕松實(shí)現(xiàn) FaaS (asa)。 如右圖所示：

（圖片來自網(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í)間。 . 架構(gòu)將開發(fā)團(tuán)隊(duì)從維護(hù)服務(wù)器的工作中解放出來，讓他們可以更專注于功能代碼（如圖）。 在實(shí)際項(xiàng)目中，開發(fā)者只需要將功能代碼打包上傳到AWS，然后進(jìn)行少量配置（環(huán)境變量、觸發(fā)條件、顯存、超時(shí)時(shí)間等）即可啟動(dòng)應(yīng)用/服務(wù)。

以上就是架構(gòu)的基本概念。 接下來筆者將從日志、指標(biāo)、監(jiān)控上報(bào)、容災(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ù)器獲取日志信息。 這些方法操作起來略顯復(fù)雜，但是當(dāng)應(yīng)用服務(wù)器數(shù)量增加時(shí)，查找日志的效率會(huì)嚴(yán)重降低，因?yàn)樾枰日页鰧?dǎo)致錯(cuò)誤信息的服務(wù)器。

一種解決方案是 ELK(,,)。 這三個(gè)開源工具各司其職，負(fù)責(zé)日志推送和轉(zhuǎn)換，作為數(shù)據(jù)庫和搜索引擎，作為圖形界面。 優(yōu)點(diǎn)是易于搭建，擴(kuò)展性好，免費(fèi)。 但額外的代價(jià)是，獨(dú)立的日志服務(wù)還需要做好全方位的監(jiān)控（應(yīng)用狀態(tài)、硬盤、網(wǎng)絡(luò)等），防止因?yàn)榛A(chǔ)服務(wù)問題導(dǎo)致系統(tǒng)徹底掛掉。

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

指數(shù)

通常情況下，運(yùn)維工作會(huì)包括收集線上應(yīng)用的運(yùn)行指標(biāo)服務(wù)器運(yùn)維技術(shù)，反映應(yīng)用的健康狀況、故障率、性能、訪問量、訪問頻率等。 下面是一個(gè)使用Boot創(chuàng)建的API服務(wù)的例子，起到收集指標(biāo)的作用。 在默認(rèn)配置中，對(duì)于每個(gè) API，將手動(dòng)收集以下指標(biāo)：

其實(shí)我們可以通過實(shí)現(xiàn)一些來擴(kuò)展/自定義 ，這里就不展開了。 有了指標(biāo)數(shù)據(jù)，還需要相應(yīng)的報(bào)表或儀表盤工具，方便更好的查詢和展示。 您可以選擇像 .

那么AWS 架構(gòu)有沒有提供類似的指標(biāo)收集呢？ 答案是肯定的，AWS人工采集了以下四個(gè)指標(biāo)：

并取一段時(shí)間內(nèi)的總量，兩者結(jié)合得到應(yīng)用的錯(cuò)誤率，如下

平均數(shù)用來反映一段時(shí)間內(nèi)的表現(xiàn)。 在筆者的項(xiàng)目中，時(shí)長主要集中在SQL查詢上。 這個(gè)數(shù)字可以反映技術(shù)人員對(duì)查詢優(yōu)化的有效性。 其實(shí)在實(shí)際情況中服務(wù)器運(yùn)維技術(shù)，這種檢查是可以在預(yù)發(fā)布環(huán)境中進(jìn)行的。 這個(gè)例子只是為了便于理解。

在筆者目前的項(xiàng)目中，并沒有使用到。 默認(rèn)的并發(fā)限制是1000/s，最大劑量的調(diào)用頻率每分鐘只有150次，遠(yuǎn)遠(yuǎn)沒有超過限制。 但是，這個(gè)數(shù)據(jù)對(duì)于高并發(fā)的應(yīng)用來說是非常重要的。

不僅開箱即用的幾個(gè)指標(biāo)，還有可以組合的API，可以在相應(yīng)的功能代碼中嵌入點(diǎn)數(shù)，以多種方式收集指標(biāo)。 比如代碼中的一、三子任務(wù)，默認(rèn)提供只能體現(xiàn)整體的運(yùn)行效率。 如果需要統(tǒng)計(jì)每個(gè)任務(wù)的消耗，需要使用。

監(jiān)控與報(bào)告

監(jiān)控的意義在于全面了解應(yīng)用程序的資源使用情況、性能和運(yùn)行情況。 這些數(shù)據(jù)可以用來幫助團(tuán)隊(duì)及時(shí)做出調(diào)整，保證應(yīng)用的順利運(yùn)行。 這一般包括CPU使用率、數(shù)據(jù)傳輸、C盤使用率等。當(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ù)知壞事即將發(fā)生，提前未雨綢繆，未雨綢繆。

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

上報(bào)功能通常需要根據(jù)實(shí)際情況自行實(shí)現(xiàn)。 實(shí)現(xiàn)了Slack等第三方工具的集成。 如果只需要簡單的短信提醒，實(shí)現(xiàn)起來并不復(fù)雜，這里就不展開了。

隨著云上基礎(chǔ)設(shè)施的普及，上述的監(jiān)控和上報(bào)已經(jīng)是各個(gè)平臺(tái)的標(biāo)配，如何實(shí)現(xiàn)和維護(hù)已經(jīng)不是開發(fā)者操心的事情了。 運(yùn)營團(tuán)隊(duì)可以更專注于配置優(yōu)化。 去工作。

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

如前所述，當(dāng)出現(xiàn)錯(cuò)誤或性能下降時(shí)，需要根據(jù)各個(gè)關(guān)鍵指標(biāo)的變化發(fā)送警告通知。 筆者的項(xiàng)目是利用AWS和提供的告警通知功能。 您只需要先選擇指標(biāo)，然后設(shè)置觸發(fā)閾值和檢測(cè)間隔。 支持 HTTP、SMS、Email 等訂閱形式。 右圖顯示了如何設(shè)置在過去 5 分鐘內(nèi)錯(cuò)誤發(fā)生超過 5 次時(shí)發(fā)送通知。

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

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

真正需要使用容災(zāi)備份的情況，筆者有限的經(jīng)驗(yàn)還沒有發(fā)生過，如果不提前做好打算，真正發(fā)生時(shí)的后果將不堪設(shè)想。 筆者項(xiàng)目中使用的默認(rèn)開啟手動(dòng)備份，周期為7天。 此配置可以自動(dòng)調(diào)整或?qū)懭肽_本以構(gòu)建基礎(chǔ)設(shè)施。 如果真的發(fā)生了災(zāi)難，僅僅有數(shù)據(jù)備份是不夠的，還要能夠在應(yīng)用程序運(yùn)行時(shí)快速重建基礎(chǔ)設(shè)施。 作者團(tuán)隊(duì)（以下簡稱團(tuán)隊(duì)）分別使用AWS和重建了數(shù)據(jù)庫、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施。 重建數(shù)據(jù)庫時(shí)，通過持續(xù)集成管道，將環(huán)境變量方法傳遞到最近一次。 數(shù)據(jù)備份快照Id，15分鐘內(nèi)可重建產(chǎn)品環(huán)境。

總結(jié)

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

最后，讓我們談?wù)劤杀尽?俗話說，放棄商業(yè)化談技術(shù)是耍流氓。 大多數(shù)人在聽到功能強(qiáng)大且易于使用的工具時(shí)，都會(huì)下意識(shí)地認(rèn)為成本會(huì)很高。 事實(shí)上，情況并非如此。 我們粗略算了一下，選擇了四核CPU、8G顯存的M4服務(wù)器。 費(fèi)用是每月 72 美元。 Dev 和 prod 三個(gè)環(huán)境使用相同的配置，即每月 216 美元。 事實(shí)上，每月的支出包括所有環(huán)境，大約為 20 美元。 應(yīng)該注意的是，計(jì)費(fèi)是基于使用的。 我們的 API 訪問量大約為每月 150 萬次。 可以預(yù)見，當(dāng)訪問量達(dá)到一定數(shù)量時(shí)，支出將等于甚至大于使用服務(wù)器的支出，而且在金額較小時(shí)優(yōu)勢(shì)明顯。

得益于強(qiáng)大的AWS生態(tài)，只需極少配置或無需配置即可借助完整的應(yīng)用，以極低的價(jià)格獲得完整的運(yùn)維功能和體驗(yàn)。 相比借助開源工具構(gòu)建的形式，開發(fā)團(tuán)隊(duì)可以從繁瑣的運(yùn)維工作——尤其是基礎(chǔ)工程建設(shè)中解放出來，更專注于產(chǎn)品本身，大大提高軟件交付率和易用性，可靠性和可擴(kuò)展性也相當(dāng)有保證。 換來的代價(jià)是更高的遷移成本，個(gè)別功能的不多樣化可能成為兩難選擇，底層實(shí)現(xiàn)原理的屏蔽也可能對(duì)開發(fā)者的學(xué)習(xí)和成長產(chǎn)生影響。