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

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

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

以上就是架構(gòu)的基本概念。 接下來筆者將從日志、指標、監(jiān)控上報、容災(zāi)四個維度來介紹架構(gòu)下的運維。

日志

默認情況下，應(yīng)用運行時產(chǎn)生的日志會保存在應(yīng)用服務(wù)器上。 當需要查看日志時，運維人員需要遠程登錄服務(wù)器獲取日志信息。 這些方法操作起來略顯復(fù)雜，但是當應(yīng)用服務(wù)器數(shù)量增加時，查找日志的效率會嚴重降低，因為需要先找出導(dǎo)致錯誤信息的服務(wù)器。

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

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

指數(shù)

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

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

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

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

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

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

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

監(jiān)控與報告

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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