好大夫在線已經(jīng)收錄了超過69萬(wàn)醫(yī)生信息，其中有24萬(wàn)醫(yī)生在平臺(tái)上實(shí)名注冊(cè)，服務(wù)用戶累計(jì)6700萬(wàn)。隨著業(yè)務(wù)快速發(fā)展，伴隨而來(lái)的系統(tǒng)復(fù)雜性和多樣性也越來(lái)越多，我們發(fā)現(xiàn)原先的服務(wù)架構(gòu)已經(jīng)跟不上業(yè)務(wù)的迭代速度了。All-in-one發(fā)版時(shí)間過長(zhǎng)，服務(wù)耦合在一起，一出問題很容易波及全站。2018年公司開始推進(jìn)微服務(wù)拆分，由php轉(zhuǎn)向java，前端開始轉(zhuǎn)型node，迎來(lái)了服務(wù)快速增長(zhǎng)的階段，目前我們有350多個(gè)微服務(wù)，每隔幾周會(huì)上線一個(gè)新服務(wù)。隨著服務(wù)的逐漸增多，我們發(fā)現(xiàn)編織的微服務(wù)大網(wǎng)越來(lái)越大，面臨微服務(wù)治理的挑戰(zhàn)也越來(lái)越多。微服務(wù)治理包含范圍非常廣，主要有服務(wù)發(fā)現(xiàn)，服務(wù)注冊(cè)，服務(wù)編排，服務(wù)配置，服務(wù)網(wǎng)關(guān)，服務(wù)監(jiān)控預(yù)警，日志分析等等等等。其中遇到問題最多的是圍繞服務(wù)的穩(wěn)定性和可用性，比如如何快速定位問題和評(píng)估影響范圍。接下來(lái)就針對(duì)服務(wù)的穩(wěn)定性和可用性聊一下我們的應(yīng)對(duì)措施，主要是日志分析和應(yīng)用畫像平臺(tái)化。

主要從應(yīng)用，中間件的穩(wěn)定性和可用性兩個(gè)方面分析。解決方案：構(gòu)建平臺(tái)，包括日志全息分析、實(shí)時(shí)告警，應(yīng)用畫像、配置管理。隨著業(yè)務(wù)日趨復(fù)雜，All-in-one笨重的系統(tǒng)很難適應(yīng)敏捷開發(fā)的節(jié)奏，應(yīng)用按不同的維度進(jìn)行微服務(wù)架構(gòu)拆分成為趨勢(shì)。然而龐雜的業(yè)務(wù)系統(tǒng)由不同語(yǔ)言開發(fā)，不同團(tuán)隊(duì)維護(hù)，微服務(wù)治理也迅速帶來(lái)新的挑戰(zhàn)。

曾經(jīng)的痛

曾幾何時(shí)，幾個(gè)人關(guān)在“小黑屋”排查問題的場(chǎng)景歷歷在目。記得2019年初夏，一個(gè)周五，馬上就要?dú)g度周末了，臨近下班的時(shí)候，有用戶反饋支付失敗，緊接著越來(lái)越多的用戶開始投訴，醫(yī)患交流失敗，很多方向的業(yè)務(wù)開發(fā)圍到系統(tǒng)組，我們?nèi)缗R大敵，大家一起找個(gè)會(huì)議室排查問題。一開始我們覺得是網(wǎng)絡(luò)抖動(dòng)，因?yàn)槌鰡栴}就在那一分鐘內(nèi)，有接口超時(shí)，有接口失敗。各種查登錄機(jī)器，各種猜測(cè)，最后定位到一臺(tái)mq節(jié)點(diǎn)內(nèi)存有波動(dòng)，導(dǎo)致部分生產(chǎn)者被夯住。最后發(fā)現(xiàn)是是新加的一臺(tái)mq沒有切割日志，導(dǎo)致程序內(nèi)存使用過高。從開始排查問題到最后定位出問題，足足花了一晚上。這種痛只有經(jīng)歷過才知道，也促進(jìn)我們成長(zhǎng)，這就是所謂成長(zhǎng)總是痛苦的。我們開始整合中間件日志，讓應(yīng)用和中間件產(chǎn)生聯(lián)動(dòng)。諸如此類的還有很多很多。

我們面臨的問題到底是什么

1. 如何快速定位故障？告警事件爆炸，如何判斷業(yè)務(wù)方異常，還是中間件異常，亦或是某個(gè)機(jī)器異常？

2. 如何追蹤調(diào)用鏈路？一條調(diào)用鏈路涉及幾十個(gè)應(yīng)用，異步處理的請(qǐng)求如何溯源？

3. 如何評(píng)估應(yīng)用容量？機(jī)器資源配比多少合適，產(chǎn)品推廣落地頁(yè)如何規(guī)劃各應(yīng)用容量？

4. 如何分析應(yīng)用潛在風(fēng)險(xiǎn)？應(yīng)用慢接口，循環(huán)調(diào)用，依賴不合理，找出潛在的風(fēng)險(xiǎn)SQL？

應(yīng)用的可用性和穩(wěn)定性越來(lái)越重要，如何降低排查問題的成本越來(lái)越重要，我們需要一雙眼睛幫忙觀察，一個(gè)大腦幫我們分析。

如何衡量服務(wù)的穩(wěn)定性和可用性？

衡量服務(wù)穩(wěn)定性，首要任務(wù)就是尋找合適的SLI，設(shè)置合理的SLO。選擇衡量的標(biāo)準(zhǔn)至關(guān)重要：監(jiān)控項(xiàng)太多，圖表看不過來(lái)，出問題了不知道看哪個(gè)圖表，大部分時(shí)候一出問題就蒙圈，能查問題的也就那么幾個(gè)人。因此指標(biāo)設(shè)計(jì)原則一定要精簡(jiǎn)精簡(jiǎn)直到無(wú)法精簡(jiǎn)。配合全局畫像讓大家一眼就能知道哪個(gè)環(huán)節(jié)出了問題。我們主要參考的是《Google的SRE運(yùn)維揭秘》，和借鑒蘑菇街趙誠(chéng)老師的經(jīng)驗(yàn)，從以下五個(gè)方面設(shè)置SLO：

1. 應(yīng)用的容量；

2. 可用性；

3. 時(shí)延；

4. 錯(cuò)誤率；

5. 人工介入次數(shù)。

還有花哨的圖表也只是輔助，大原則還是監(jiān)控告警明確，快速定位出異常應(yīng)用或故障節(jié)點(diǎn)，嘗試自動(dòng)故障轉(zhuǎn)移或及時(shí)止損，最后通過分析畫像或分析日志尋找根因。

我們來(lái)一起看一下這五條黃金法則是如何指導(dǎo)我們?cè)O(shè)計(jì)SLO的：

這五條法則是指導(dǎo)意見，希望能幫助大家。

平臺(tái)構(gòu)建最初的愿景，主要是隨著微服務(wù)的推進(jìn)，服務(wù)穩(wěn)定性越來(lái)越重要，服務(wù)間調(diào)用出的問題越來(lái)越難以定位，排查的次數(shù)多了，各種工具腳本/Dashboard/小系統(tǒng)越來(lái)越多，這些經(jīng)驗(yàn)很難傳承，定制化高，推廣成本大，更新迭代也不及時(shí)，普及度也是非常的低，能查問題的就那么幾個(gè)人。

為了提高效率，面向全公司開發(fā)、測(cè)試全員，因此我們開始打造服務(wù)治理平臺(tái)：

• 方便開發(fā)快速定位問題；

• 風(fēng)險(xiǎn)前移，對(duì)潛在風(fēng)險(xiǎn)生成任務(wù)，打造開發(fā)->測(cè)試->線上驗(yàn)證的閉環(huán)，后面會(huì)重點(diǎn)介紹；

• 打通數(shù)據(jù)流，告警與畫像結(jié)合，能大大提高排查效率；

• 配置統(tǒng)一管理，設(shè)置熔斷限流，配置故障轉(zhuǎn)移策略，設(shè)置告警閾值，處理中間件事件等等，讓開發(fā)能有一個(gè)統(tǒng)一的平臺(tái)進(jìn)行操作。

我們服務(wù)治理平臺(tái)化演進(jìn)，也經(jīng)歷了：人工 -> 工具化 -> 系統(tǒng)化 -> 平臺(tái)化：

1、調(diào)研

• 面向虛擬機(jī)，物理機(jī)機(jī)器資源的監(jiān)控有zabbix，面向容器的有prometheus；

• 針對(duì)鏈路分析的主要有基于ELK體系的APM，開源的還有韓國(guó)的pinpoint，Twitter的Zipkin，國(guó)內(nèi)阿里有ARMS，騰訊的有天機(jī)閣等等，他們大多都受2010年谷歌發(fā)表了Dapper論文的影響；

• 中間件層大部分中間件都提供了自己的一套監(jiān)指標(biāo)，或者配備自己的監(jiān)控報(bào)表，有些呢還得提供了相關(guān)的API。

  2、我們當(dāng)時(shí)的情形

   應(yīng)用層

• 我們應(yīng)用有多種語(yǔ)言開發(fā)，鏈路分析開源的方案不能直接滿足我們的需求，大部分具有代碼侵入性，對(duì)接開源軟件，我們依然需要二次開發(fā)；

• 我們當(dāng)時(shí)是有一些日志nginx日志/鏈路日志，只是日志不夠精細(xì)，中間件用戶側(cè)日志缺少，如中間件的連接耗時(shí)，執(zhí)行耗時(shí)，mq發(fā)布成功狀態(tài)等，我們需要細(xì)化補(bǔ)全；

• 我們?nèi)肟诔薍ttp協(xié)議以外，還有AMQP協(xié)議入口，以及分布式任務(wù)調(diào)度入口，我們需要進(jìn)行打通，生成全局唯一TraceID。

 中間件

• 已有的自研的shell腳本，基于zabbix調(diào)度，比較笨重，維護(hù)成本比較高，部署比較麻煩；

• 各個(gè)中間件都是高度定制化，隨著中間件的升級(jí)兼容性問題也很多；

• Prometheus生態(tài)的完善，很多中間件官方支持對(duì)接Prometheus，這樣的話減少了我們的維護(hù)成本，對(duì)接也非常的方便。

 我們的解決方案

• 機(jī)器資源監(jiān)控依托Prometheus生態(tài)，逐漸由Zabbix向Prometheus遷移；

• 應(yīng)用間調(diào)用鏈分析基于已有的日志收集流程，自研一個(gè)分析大腦；

• 中間件指標(biāo)收集我們提供統(tǒng)一的接口和數(shù)據(jù)格式，方便統(tǒng)一對(duì)接；

• 中間件的維護(hù)管理，如熔斷限流設(shè)置，告警閾值設(shè)置，告警規(guī)則設(shè)置等都收攏到統(tǒng)一平臺(tái)。

  3、技術(shù)選型

我們的平臺(tái)采用分布式前后端分離架構(gòu)，可視化前臺(tái)Dany是基于vue(element-ui/element-admin)，后端主要基于Golang和Python，目前已監(jiān)控352個(gè)業(yè)務(wù)應(yīng)用，1200多個(gè)節(jié)點(diǎn)，鏈路日志量級(jí)30億左右。主要模塊如下：

 應(yīng)用運(yùn)行時(shí)畫像：

數(shù)據(jù)源主要包括Promethues、Elasticsearch和Clickhouse，展示基于Grafana。數(shù)據(jù)存儲(chǔ)正逐步從Elasticsearch遷移到Clikhouse，基本流程是Gohangout訂閱Kafka清洗后持久化到Clickhouse。

 應(yīng)用機(jī)器資源使用畫像：

目前大部分服務(wù)依然部署在虛擬機(jī)上，有些指標(biāo)我們通過寫shell腳本讓zabbix觸發(fā)。隨著容器化的推進(jìn)，Prometheus的生態(tài)更加適合我們，因此我們逐漸用prometheus替代原有的zabbix職責(zé)。

 日志全息分析：

主要分析應(yīng)用潛在風(fēng)險(xiǎn)，應(yīng)用異常診斷 采用Golang自研系統(tǒng)（Snow）流式分析Kafka數(shù)據(jù)持久化到Mysql。

 APM鏈路分析：

鏈路追蹤日志埋點(diǎn)我們集成到服務(wù)框架(php/node/java)中。記錄所有http協(xié)議和amqp協(xié)議的請(qǐng)求，記錄上下游，請(qǐng)求耗時(shí)，機(jī)器信息等，日志信息落盤本地，基于ELK持久化。

 實(shí)時(shí)告警：

告警事件判定，記錄告警事件處理工作流，告警應(yīng)答(Ack)升級(jí)，我們基于Python開發(fā)了Dolphin系統(tǒng)。

4、拓?fù)鋱D

1、APM鏈路分析

 應(yīng)用場(chǎng)景：

• 生成的風(fēng)險(xiǎn)任務(wù)需要配合鏈路分析，如循環(huán)調(diào)用，在最近的一次鏈路中被調(diào)用了幾次，請(qǐng)求耗時(shí)是怎樣，上下游依賴是怎樣等；

• 在排查故障的時(shí)候，開發(fā)根據(jù)自己感興趣的trace_id分析整條鏈路的情況，方便快速定位問題；

• 應(yīng)用QPS異常波動(dòng)的時(shí)候分析上下游接口調(diào)用量,可以分析出是入口流量激增還是命中特殊數(shù)據(jù)產(chǎn)生了循環(huán)調(diào)用

 設(shè)計(jì)思路：

我們目前記錄鏈路的入口采用AOP模式植入到已有的框架中(php/node/java)，業(yè)內(nèi)還有無(wú)侵入解決方案類似sidecar模式，代理請(qǐng)求記錄全鏈路。隨著微服務(wù)的演進(jìn)，為了加速請(qǐng)求，鏈路會(huì)同時(shí)并發(fā)請(qǐng)求，需要識(shí)別和準(zhǔn)確標(biāo)記時(shí)間線，推動(dòng)著APM鏈路分析的演進(jìn)。

2、應(yīng)用風(fēng)險(xiǎn)分析

微服務(wù)架構(gòu)帶來(lái)鏈路越來(lái)越深，隨著業(yè)務(wù)增長(zhǎng)慢接口，循環(huán)調(diào)用，雙向依賴，慢SQL成為應(yīng)用四大殺手，令無(wú)數(shù)開發(fā)聞風(fēng)喪膽，血的教訓(xùn)迫使我們不能放過這些殺手。微服務(wù)架構(gòu)另外的一個(gè)問題就是產(chǎn)生海量的日志，目前我們大約每天30億次內(nèi)網(wǎng)請(qǐng)求日志。為了分析四大殺手的特征，我們訂閱Kafka日志流，分析過濾。得益于Golang的協(xié)程(goroutine)能力，每秒分析5w+日志，目前只有兩臺(tái)虛擬機(jī)在分析，可以水平擴(kuò)展分析能力。應(yīng)用開發(fā)負(fù)責(zé)人會(huì)收到風(fēng)險(xiǎn)任務(wù)推送，通過給風(fēng)險(xiǎn)任務(wù)打上優(yōu)先級(jí)，及時(shí)跟進(jìn)解決，測(cè)試進(jìn)行線上驗(yàn)證環(huán)節(jié)，最終平臺(tái)會(huì)驗(yàn)證風(fēng)險(xiǎn)是否解除。分析后生成任務(wù)展示效果如下：

3、風(fēng)險(xiǎn)任務(wù)報(bào)告

 應(yīng)用場(chǎng)景：

• 培養(yǎng)風(fēng)險(xiǎn)意識(shí)，開發(fā)、測(cè)試都能直觀感受各自應(yīng)用面臨的風(fēng)險(xiǎn)情況；

• 風(fēng)險(xiǎn)趨勢(shì)，能縱向看單應(yīng)用的風(fēng)險(xiǎn)趨勢(shì)，也能橫向看整個(gè)公司其他事業(yè)部的風(fēng)險(xiǎn)趨勢(shì) ：

4、容量評(píng)估

 應(yīng)用場(chǎng)景：

• 自然增長(zhǎng)流量的線性預(yù)測(cè)，對(duì)核心服務(wù)，繁忙的服務(wù)壓測(cè)，計(jì)算出單機(jī)QPS峰值，設(shè)置預(yù)警水位線；

• 針對(duì)推廣的頁(yè)面，產(chǎn)品預(yù)估流量，我們對(duì)當(dāng)前鏈路分析依賴的應(yīng)用容量，評(píng)估是否需要擴(kuò)容 設(shè)計(jì)思路：全鏈路壓測(cè)實(shí)施與驗(yàn)證順序 單接口壓測(cè)->單應(yīng)用壓測(cè)->全鏈路壓測(cè)，壓測(cè)系統(tǒng)目前還在孵化中，前期我們通過調(diào)節(jié)單應(yīng)用的機(jī)器流量分布模擬壓測(cè)。 

5、業(yè)務(wù)自定義分析

• 輔助應(yīng)用精細(xì)化運(yùn)營(yíng)，如分析推送到達(dá)率，推送落地頁(yè)點(diǎn)擊率等；

• A/B測(cè)試，業(yè)務(wù)可以分析不同的頁(yè)面的轉(zhuǎn)化率，或頁(yè)面區(qū)域按鈕點(diǎn)擊事件；

• 業(yè)務(wù)打點(diǎn)標(biāo)記自己領(lǐng)域事件，異常標(biāo)記等；

• 抽樣分析接口的參數(shù)等

設(shè)計(jì)思路：整體流程依然是基于日志收集模式，業(yè)務(wù)方通過模板定義數(shù)據(jù)格式記錄到日志，采集程序分析日志，映射到數(shù)據(jù)表中。

6、實(shí)時(shí)告警

觸發(fā)預(yù)設(shè)的告警規(guī)則后，按優(yōu)先級(jí)提供不同告警形式：郵件，微信群機(jī)器人，短信，電話。

兜底監(jiān)控規(guī)則的確定

由于目前大部分開發(fā)還處于監(jiān)控意識(shí)培養(yǎng)的初期階段，目前核心應(yīng)用規(guī)模還是可控的，于是我們基于全應(yīng)用做了兜底監(jiān)控。如每秒全站請(qǐng)求異常狀態(tài)，消費(fèi)者處理異常，mysql提交事務(wù)異常等。系統(tǒng)組默默的承擔(dān)著全站SRE的職責(zé)。

業(yè)務(wù)方主動(dòng)訂閱與兜底規(guī)則復(fù)寫

為了告警的及時(shí)響應(yīng)和快速處理，我們基于應(yīng)用給出告警規(guī)則通用模板，業(yè)務(wù)設(shè)置相應(yīng)的閾值即可，如每分鐘請(qǐng)求異常數(shù)，應(yīng)用程序產(chǎn)生的sentry異常數(shù)，MQ發(fā)布、消費(fèi)異常數(shù)等。

主/副O(jiān)nCall機(jī)制

隨著業(yè)務(wù)工程師逐漸加入，需要處理各種不同優(yōu)先級(jí)的告警，一有告警就全員All-in排查。為了優(yōu)化告警響應(yīng)機(jī)制，引入主副值班on-call機(jī)制，按應(yīng)用模塊每周設(shè)置一個(gè)主值班， 主值班必須及時(shí)應(yīng)答告警(ACK)，嘗試定位分析問題，必要的時(shí)候進(jìn)行告警升級(jí)，通知團(tuán)隊(duì)負(fù)責(zé)人或請(qǐng)求其他團(tuán)隊(duì)協(xié)作。

我們監(jiān)控核心指標(biāo)，觸發(fā)實(shí)時(shí)告警，推出趨勢(shì)截圖。精簡(jiǎn)的指標(biāo)能比較客觀的反映應(yīng)用運(yùn)行情況。畫像數(shù)據(jù)來(lái)源Clickhouse,大部分SQL執(zhí)行都能在1s內(nèi)返回。

• 流量飽和度，每個(gè)應(yīng)用能承載的峰值流量是不一樣的，我們需要監(jiān)控每個(gè)應(yīng)用節(jié)點(diǎn)的QPS波動(dòng)及增長(zhǎng)趨勢(shì)；

• 響應(yīng)耗時(shí)p95線，RPC請(qǐng)求耗時(shí)符合長(zhǎng)尾效應(yīng)，越慢的接口越有可能拖垮整個(gè)應(yīng)用，我們采用耗時(shí)百分位第95的時(shí)間作為應(yīng)用健康衡量的指標(biāo)；

• 異常監(jiān)控，主要監(jiān)控RPC請(qǐng)求錯(cuò)誤率，業(yè)務(wù)系統(tǒng)自定義異常(sentry)，依賴的中間件異常等；

• 核心接口監(jiān)控，這部分是業(yè)務(wù)主動(dòng)訂閱核心接口每秒請(qǐng)求成功率。 

2、機(jī)器資源畫像

3、中間件客戶端畫像

除了RPC請(qǐng)求入口，還有基于APMQ協(xié)議的請(qǐng)求，分布式任務(wù)調(diào)度中心的請(qǐng)求。應(yīng)用依賴的中間件使用不規(guī)范，或者執(zhí)行異常我們都能通過畫像系統(tǒng)反映出來(lái)，給出優(yōu)化意見。 

4、中間件服務(wù)端畫像

中間件自身的穩(wěn)定性也是非常重要的，可用性考核需要達(dá)到四個(gè)9。大部分我們依賴Prometheus生態(tài)，如Mysql-exporter,RabbitMQ 3.8版本以后官方支持prometheus指標(biāo)。針對(duì)Mysql/MongoDB等我們采用了percona的pmm2。

2、Prometheus和Zabbix的抉擇

我們從蘑菇街趙誠(chéng)老師那取了不少經(jīng)，主要還是從應(yīng)用的容量，可用性，時(shí)延，錯(cuò)誤率，人工介入次數(shù)幾個(gè)方面設(shè)計(jì)SLO。關(guān)于SLO選定可以參考Google的設(shè)定模板。

4、SRE落地離不開公司上層的加持

大部分互聯(lián)網(wǎng)公司，產(chǎn)品迭代速度是非常快的，應(yīng)用技術(shù)質(zhì)量和迭代速度相互競(jìng)爭(zhēng)，代碼質(zhì)量有時(shí)候能決定產(chǎn)品的生死，越來(lái)越慢的接口會(huì)拖垮應(yīng)用服務(wù)質(zhì)量。從遇到故障問題才關(guān)心，慢慢關(guān)注點(diǎn)往前移，從代碼壞味道，潛在風(fēng)險(xiǎn)分析，告警響應(yīng)處理時(shí)長(zhǎng)，應(yīng)用穩(wěn)定性和中間件穩(wěn)定性都設(shè)置考核指標(biāo)。好大夫?qū)崟r(shí)監(jiān)控告警大屏也逐漸成為一道風(fēng)景線。

• 平臺(tái)可用性：畫像和日志分析界面整合，提供統(tǒng)一的平臺(tái)入口；

• 熔斷限流：熔斷限流管理平臺(tái)化；

• 全鏈路壓測(cè)：模型識(shí)別更加精準(zhǔn)，更精準(zhǔn)的瓶頸判斷；

• 智能容量評(píng)估：應(yīng)用節(jié)點(diǎn)自動(dòng)擴(kuò)縮容。

如有意愿加入好大夫團(tuán)隊(duì)，可訪問以下鏈接：

https://mp.weixin.qq.com/s/zi7SQ7UI-2Ro6qAogsSIsQ

你也「在看」嗎？??