前言

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

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

日志

默認(rèn)情況下，應(yīng)用運(yùn)行時產(chǎn)生的日志會保存在應(yīng)用服務(wù)器本機(jī)，在需要查看日志的時候，需要運(yùn)維人員遠(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)的日志組，即可進(jìn)行查詢搜索，不需要任何配置，也沒有任何維護(hù)成本。

指標(biāo)

通常情況下，運(yùn)維工作會包含采集線上應(yīng)用的運(yùn)行指標(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)一些接口來擴(kuò)展/自定義采集指標(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)境下進(jì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只能反映總體的運(yùn)行效率，如果需要統(tǒng)計每個task的消耗，就需要用到AWS CloudWatch metrics API。

監(jiān)控&報警

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

同上，這里還是以一個Spring Boot應(yīng)用為例，在上一小節(jié)指標(biāo)數(shù)據(jù)的采集中提到過Actuator，事實上Actuator除了可以記錄上面提到的指標(biāo)，還可以用來收集監(jiān)控數(shù)據(jù)。這里我們只需要設(shè)置一個Spring Boot Admin應(yīng)用，給需要進(jìn)行監(jiān)控的應(yīng)用加上Spring Boot Admin client配置，監(jiān)控數(shù)據(jù)就會通過Actuator暴露的API傳遞給Spring Boot Admin。

報警功能一般則要根據(jù)實際情況自行實現(xiàn)。Spring Boot Admin中實現(xiàn)了對Pagerduty，Slack等第三方工具的集成，如果只是需要簡單的郵件提醒，實現(xiàn)起來也不復(fù)雜，這里就不展開了。

隨著云上基礎(chǔ)設(shè)施的普及，上面提到的監(jiān)控和報警早已是各個平臺的標(biāo)準(zhǔn)配置，根本輪不到開發(fā)者去操心如何實現(xiàn)及維護(hù)，運(yùn)營團(tuán)隊可以把更多的精力放在配置優(yōu)化的工作中去。

AWS默認(rèn)提供了非常完備的監(jiān)控數(shù)據(jù)，也允許自定義監(jiān)控dashboard，通過把一系列重要的指標(biāo)添加到創(chuàng)建好的dashboard中，應(yīng)用的運(yùn)行狀況一目了然。

前面已經(jīng)提到過，在出現(xiàn)錯誤，或性能底下時，根據(jù)某些關(guān)鍵指標(biāo)的變動情況發(fā)送警告通知非常必要。筆者所在的項目的做法是使用AWS CloudWatch和AWS SNS提供的告警通知功能，只需要先選擇指標(biāo)然后設(shè)定觸發(fā)閾值和檢查間隔時間即可，AWS SNS支持HTTP、SMS、Email等多種訂閱方式。下圖展示了如何設(shè)定當(dāng)某個Lambda在過去5分鐘內(nèi)發(fā)生了5次以上錯誤的時候發(fā)送通知。

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

在系統(tǒng)鏡像，構(gòu)建工具還有容器技術(shù)越來越普及的今天，災(zāi)難備份的意義很大程度上是為了有效保護(hù)重要數(shù)據(jù)。通常的做法是設(shè)定一些定期任務(wù)，將數(shù)據(jù)傳輸?shù)竭h(yuǎn)端的災(zāi)備中心，從物理上抵御不可抗災(zāi)難。如果數(shù)據(jù)量過大，出現(xiàn)網(wǎng)絡(luò)傳輸效率跟不上的情況，可以參考AWS用卡車?yán)瓟?shù)據(jù)的解決辦法。

真正需要用到災(zāi)難備份的情況在筆者有限的經(jīng)歷中還沒有發(fā)生過，但是如果不未雨綢繆，真正發(fā)生時的后果將難以設(shè)想。筆者項目中用到的AWS RDS默認(rèn)啟用了以7天為周期的自動備份，這個配置可以手動調(diào)整也可以將配置寫入構(gòu)建基礎(chǔ)設(shè)施的腳本中去。 如果災(zāi)難真的發(fā)生，光有數(shù)據(jù)備份是不夠的，還需要能夠快速重建應(yīng)用運(yùn)行時的基礎(chǔ)設(shè)施。筆者所在的團(tuán)隊(下文簡稱團(tuán)隊)分別使用了AWS CloudFormation和Serverless framework，CloudFormation用來重建數(shù)據(jù)庫、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施，Serverless framework用來重建Lambda function，在重建數(shù)據(jù)庫的時候，通過持續(xù)集成流水線，以環(huán)境變量的方式傳入最近一次數(shù)據(jù)備份快照的Id，15分鐘以內(nèi)即可重建一套產(chǎn)品環(huán)境。

總結(jié)

筆者所在的團(tuán)隊是10個人左右的配置，采用結(jié)對編程的方式，3對pair，包含web端、業(yè)務(wù)層、數(shù)據(jù)層。從產(chǎn)品原型確定到第一次上線(MVP)耗時30天，每周至少發(fā)布一次新版本，story的平均交付時間(cycle time，從需求確定到上線)為8天。這樣的速度也許不能算快，但是如果沒有Serverless架構(gòu)在運(yùn)維端提供的支持，我們想要在交付速度上有更高的突破會困難得多。

最后來談一下成本，俗話說拋開商業(yè)化談技術(shù)都是耍流氓，大部分人看到一個強(qiáng)大易用的工具都會下意識里覺得開銷會很大。實際上并不是這樣，我們做了一個粗算，選用雙核CPU，8G內(nèi)存的M4型服務(wù)器，開銷是$72每月。dev，staging，prod三個環(huán)境都用同樣的配置就是$216每月，而實際上Lambda每個月的開銷包含所有環(huán)境在$20左右，需要注意的是Lambda的計費是根據(jù)使用量來的，我們的API訪問大約在150萬每月的量級。可以預(yù)見到當(dāng)訪問達(dá)到一定數(shù)量的時候Lambda的開銷會和使用服務(wù)器的方案持平甚至更大，但是在量小的時候優(yōu)勢明顯。

得益于強(qiáng)大的AWS生態(tài)，利用Lambda構(gòu)建的無服務(wù)器應(yīng)用經(jīng)過少量甚至無需任何配置，即可以極低的價格獲得完整的運(yùn)維功能和體驗。與自己利用開源工具進(jìn)行搭建的方式相比，研發(fā)團(tuán)隊可以從繁瑣的運(yùn)維工作——特別是基礎(chǔ)工程搭建——中解脫出來，更加專注于產(chǎn)品本身，極大的提高軟件交付速度，可用性、可靠性和可擴(kuò)展性也相當(dāng)有保障。換來的代價是更高的遷移成本，某些功能的不可定制化可能成為瓶頸，以及對底層實現(xiàn)原理的屏蔽也可能對開發(fā)者的學(xué)習(xí)和成長有影響。

審核編輯：湯梓紅