在介紹運維之前，大家先來快速了解一下無服務(wù)器(serverless)的概念。由于筆者的實戰(zhàn)經(jīng)驗是在AWS平臺上，本文中出現(xiàn)的無服務(wù)器均指使用AWS Lambda構(gòu)建的serverless應(yīng)用。Serverless的特點是用戶無需預(yù)配置或管理服務(wù)器，只需要部署功能代碼，服務(wù)會在需要的時候執(zhí)行代碼并自動伸縮，從每天幾個請求到每秒數(shù)千個請求，輕松地實現(xiàn)FaaS(Function as a Service)。如下圖所示：

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

在傳統(tǒng)的應(yīng)用中，開發(fā)團隊除了需要編寫功能代碼，還要監(jiān)控實時負(fù)載，并相應(yīng)地對應(yīng)用進行伸縮，還要處理一些因非功能性故障導(dǎo)致的停機(硬盤、內(nèi)存等)。而無服務(wù)器架構(gòu)則將開發(fā)團隊從服務(wù)器維護的工作中解放出來，繼而能更專注在功能代碼上(圖中的Function)。在實際的項目里，開發(fā)者只需將功能代碼打包上傳到AWS Lambda，再進行少量配置(環(huán)境變量，觸發(fā)條件，內(nèi)存，超時時間等)即可將應(yīng)用/服務(wù)上線。

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

日志

默認(rèn)情況下，應(yīng)用運行時產(chǎn)生的日志會保存在應(yīng)用服務(wù)器本機，在需要查看日志的時候，需要運維人員遠(yuǎn)程登錄到這臺服務(wù)器獲取日志信息。這種方式操作起來稍顯繁瑣，而且當(dāng)應(yīng)用服務(wù)器的數(shù)量增多后，由于需要先找出產(chǎn)生錯誤信息的那臺服務(wù)器，會嚴(yán)重降低查找日志的效率。

一種解決辦法是ELK(ElasticSearch, Logstash, Kibana)，這三個開源工具各司其職，Logstash負(fù)責(zé)日志的推送和轉(zhuǎn)換，ElasticSearch作為數(shù)據(jù)庫與搜索引擎，Kibana作為圖形界面。好處是搭建容易，良好的伸縮性，以及免費。但帶來的額外成本是，獨立出來的日志服務(wù)也需要做好全方位的監(jiān)控(應(yīng)用狀態(tài)，硬盤，網(wǎng)絡(luò)等)，避免因為基礎(chǔ)服務(wù)的問題導(dǎo)致系統(tǒng)全面故障。

AWS無服務(wù)器架構(gòu)中的日志是一個開箱即用的服務(wù)，所有日志自動采集到AWS CloudWatch Logs中，只要根據(jù)服務(wù)名稱找到對應(yīng)的日志組，即可進行查詢搜索，不需要任何配置，也沒有任何維護成本。

指標(biāo)

通常情況下，運維工作會包含采集線上應(yīng)用的運行指標(biāo)，來反映應(yīng)用的健康狀況，故障率，性能，訪問量，訪問頻率等。這里以一個使用Spring Boot構(gòu)建的API服務(wù)來舉例，Spring Boot中的Actuator扮演了采集指標(biāo)的角色。默認(rèn)配置下，云主機，對于每個API，Actuator會自動采集以下幾個指標(biāo)：

uri，例如/api/person/{id} method，例如GET或POST status，例如200或500

當(dāng)然我們可以通過實現(xiàn)一些接口來擴展/自定義采集指標(biāo)，這里就不展開了。有了指標(biāo)數(shù)據(jù)，還需要對應(yīng)的報表或儀表盤工具，以便更好地查詢和展示，可以選擇像Prometheus，Grafana這樣的工具。

那么AWS無服務(wù)器架構(gòu)是否提供了類似的指標(biāo)采集呢?答案是肯定的，AWS CloudWatch Metrics自動采集了Lambda function的以下四個指標(biāo)：

Invocations(實際調(diào)用量) Errors Duration(執(zhí)行時間) Throttles(超過并行限制而被阻止的調(diào)用的數(shù)量)

Invocations和Errors取一段時間的總數(shù)，結(jié)合二者可以得出應(yīng)用的錯誤率，如下

Duration則通過取平均數(shù)來反映一段時間的性能表現(xiàn)，在筆者的項目中Lambda function的耗時主要集中在SQL的查詢上，這個數(shù)字可以相應(yīng)地反映技術(shù)人員對查詢優(yōu)化的效果。當(dāng)然，在實際情況中，這些檢驗都可以在預(yù)發(fā)布環(huán)境下進行，這個例子只是為了方便理解。

在筆者目前的項目中，Throttle并未被使用到，默認(rèn)的并發(fā)限制是1000/秒，而用量最大的Lambda function的調(diào)用頻率也不過每分鐘150次，距離超限差得很遠(yuǎn)，不過這一數(shù)據(jù)對于并發(fā)高的應(yīng)用有很重要的意義。

除了開箱即用的幾個指標(biāo)以外，還可以結(jié)合CloudWatch metrics的API，在相應(yīng)的功能代碼中埋點，定制化采集指標(biāo)。例如，對于一個Lambda function，代碼里三個子task，默認(rèn)提供的Duration只能反映總體的運行效率，如果需要統(tǒng)計每個task的消耗，就需要用到AWS CloudWatch metrics API。

監(jiān)控&報警

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