信用卡在微服務架構下的監控平臺架構實踐

1、背景介紹

51 信用卡的技術架構是基於 Spring Cloud 所打造的微服務體系，隨着業務的飛速發展，不斷增多的微服務以及指標給監控平臺帶來了極大的挑戰。監控團隊在開源 vs 自研，靈活 vs 穩定等問題上須要不斷作出權衡，以應對飛速發展的需求。本次將會分享咱們在微服務下的白盒監控思考，以及如何將時下社區流行的 Spring Cloud，K8S，Prometheus 等開源技術在企業落地。

此次主要講的是關於微服務的監控，微服務看起來很美話，但實踐起來卻有不少坑，但願此次的分享能給你們一些收穫或者思考。

2、傳統的監控分層

傳統的監控通常會將監控分層，好比咱們經常使用的分層方式是將監控分紅基礎設施、系統、應用、業務和用戶端這幾層，分完層後將每層的監控作到位。

而在傳統的監控裏，zabbix 是最經常使用的開源軟件，zabbix 的優勢主要是成熟可靠，社區很是強大，幾乎你的需求，社區都有一套對應的解決方案，但 zabbix 的缺點也很明顯，就是太難用，不少監控配置加起來成本很高，甚至不少運維用了好久的 zabbix，還沒學會怎麼配置 HTTP 監控，這在應用較少的時候，還不是很明顯的問題，可是到了微服務時代，這個問題就暴露得很是明顯了，並且 zabbix 以機器爲維度的監控也沒法適用微服務時代的理念。

3、以服務爲維度的監控

微服務監控比起傳統應用的監控，最明顯的改變就是視角的改變，咱們把監控從分層 + 機器的視角轉換成以服務爲中心的視角，在微服務的視角下，咱們的監控能夠分爲指標監控、鏈路監控和日誌監控，在開源社區，這些監控也都有對應的解決方案，好比指標監控有 prometheus、influxdb，鏈路監控有 zipkin、pinpoint，日誌則有 elk。

在 51 信用卡發展起步的時候，咱們也一樣使用這些開源方案來解決咱們的監控問題，但當咱們業務快速發展的時候，咱們開始不斷碰到監控上的挑戰，其中有部分是互聯網金融特有的，另外一部分是微服務所帶給咱們的。

微服務監控有什麼特色？用一句話歸納就是服務特別多，服務間的調用也變得很是複雜。咱們實際上是微服務的受害者，其實業內不少人作的架構只是服務化，並不夠「微」，而咱們作的比較完全，咱們線上不少服務都只有一個 API，但這樣形成線上指標很是多，告警也很是多，讀和寫的壓力都很是大。

互聯網金融是一個跟錢息息相關的行業，因此互聯網金融對監控也有本身的要求。首先是對故障的容忍程度很低，監控的有效性須要被反覆確認，其次是對監控的覆蓋度，黑盒監控在互聯網金融裏很難行得通，白盒監控變得愈來愈重要，開發們迫切須要對本身的應用有全面的瞭解。而後是對告警的及時以及快速診斷有更高的需求，告警以及診斷信息在 10 分鐘內發出與 5 分鐘內發出有很大的差異，舉個例子，若是有個活動有個漏洞被黑產行業抓住，若是能早一分鐘肯定問題關閉後門，就能給公司挽回巨大的損失。

4、Prometheus 下的監控

51 信用卡在早期也一樣使用 Prometheus，其實 Prometheus 是個很棒的產品，白盒監控的理念也很先進，自帶告警以及 PromQL，稍微學習以後便能上手，做爲 CNCF 的項目與 K8S 等開源產品結合得也很好。

在隨着服務的增加，咱們開始不斷地踩坑，首先突出的問題就是 Prometheus 沒有現成的分佈式方案，性能遇到單機瓶頸以後只能手動給業務劃分集羣而且之間的數據不能共享，而後拉模式在兼容多數據源上也顯得力不從心，好比咱們有場景須要指定精確的時間，還有好比咱們有些數據是從日誌來的或是從 Kafka 來的，這些都沒有現成的方案。

微服務的指標增加其實比想像得要快不少，由於微服務架構下，咱們老是迫切想要把應用的每一個細節都搞清楚，好比主機指標、虛擬機指標、容器指標、應用性能指標、應用間調用指標、日誌指標以及自定義的業務指標等等，甚至在這些指標下，咱們還會給指標打上更多的標籤，好比是哪一個進程，哪一個機房，咱們大體算過一筆帳，一個服務即便開發什麼都不作，他經過基礎框架就自帶了 5000 個指標。

咱們內部也討論過爲何指標會這麼多，能不能把一些指標去掉，但很快咱們就否決了去指標的想法，咱們以爲業界的趨勢是白盒監控會變得愈來愈重要，APM 的概念會變得愈來愈重要，devops 會和白盒監控不斷髮生化學反應，變成一種潮流。

而在 51 信用卡，咱們是怎麼解決的呢，其實很簡單，用三個字概況就是「平臺化」，平臺化的好處不少，最直觀的好處就是提供了一個統一的平臺去處理監控問題，並給開發帶來了統一的使用體驗。

5、基於 Prometheus 的架構改進

咱們首先要解決的問題是如何構建對上層統一的存儲，一開始咱們基於 Prometheus 的生態作了一些架構改進，將底層換成分佈式的列式存儲 Cassandra，並開發了推送服務和拉取服務來兼容原先的數據模型，在上層，咱們開發了兼容 PromQL 的界面提供給開發使用。

但很快，咱們就碰到了新的問題。

首先是 labels 的匹配效率問題，當指標名相同的時候，因爲 label 是自由組合的，在匹配部分 label 的時候，咱們須要先將 labels 的元數據所有讀出來，而後進行過濾，這樣的效率會顯得很低，咱們的作法是在 label 元數據上面加上倒排索引，由於咱們是分佈式方案，倒排索引自己也須要分佈式，因此咱們直接使用 ES 來幫咱們構建元數據。

第二個問題是預聚合，好比咱們只想看 API 的總體訪問量，但作這個查詢的時候，咱們會在底層讀到 4 份數據，而後再聚合再顯示出來，這樣無疑也是一種浪費。咱們的作法是引入預聚合機制，在縱向，咱們須要捨棄維度，在橫向，咱們須要聚合時間軸。對於分佈式而言，預聚合會顯得比較麻煩，由於咱們須要考慮的東西比較多，好比須要在內存裏完成，須要合理將數據分批分配到不一樣機器，須要有一個窗口機制保證數據的及時有效又高性能。業內經常使用的作法是引入一個 Storm 這樣的流式計算或者 Spark Streaming 這樣的微批計算，而後將計算完的結果推入緩存或者內存供告警來使用。

第三個問題是 Metric 的長度，由於在列式存儲的底層，咱們直接借鑑 Kairosdb 的存儲格式，兼容 UTF8 的 Metric 而直接講 Metric 轉換成二進制存儲在數據庫裏，若是指標不多，這個問題不大，但若是指標很是多，這會形成底層存儲的存儲浪費，並且影響索引的效率，這個問題的解決辦法也很簡單，直接引入一個 Bitmap 機制就能夠解決。分享Java架構資源，因資料太多，請加高級架構資源裙：948368769 羣裏面會分享（有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等等）

第四個問題是維度重複，好比咱們有三個指標，這三個指標的維度都同樣，但這三個指標徹底不一樣，表明不一樣的值，但存儲在數據庫的時候，它會佔用三個 series 的空間，查找的時候也不夠高效，由於每每三個指標會同時查詢同時展現。這個解決辦法是將數據庫裏本來的 value 定義成多類型支持，不僅是雙精度浮點或是整型，增長 Map 的支持類型，並在數據庫的上層作兼容。

當初咱們在解決這些問題的時候，咱們發現社區已經有一個比較好的解決方案了，就是 Druid，不是阿里那個數據庫鏈接池 Druid，而是 druid.io。它比較好地知足了 Bitmap、預聚合、複合類型、倒排索引、冷熱數據這些需求。

咱們將拉服務和收服務作了進一步的改進，能夠自動將數據作轉換，兼容原先數據模型的同時，將數據也投遞一份到 Druid 裏。

至此咱們基本完成了一個可以知足需求的存儲架構改進。

最後限於時間關係，和你們分享兩個很是有用又容易實踐的告警智能診斷：

第一個是和日誌監控的聯動，當一個告警發生的時候，咱們以時間、服務爲維度去匹配 ERROR 或是 Exception 日誌，並以 simhash 之類的類似算法排序日誌，就會很是快速地找到問題的直接緣由，不必定是 Root Cause，但告警的時候若是附上這個日誌，對開發排查問題的效率會有很大的幫助。

第二個是和鏈路監控的聯動，當一個告警發生的時候，咱們一樣以時間、服務查詢鏈路監控，並從日誌監控裏排名靠前的日誌提取 trace id 後進行過濾，能很快發現故障的關聯緣由，這一樣不必定是 Root Cause（頗有多是），但一樣對開發排查問題頗有幫助。

6、將來

最後展望一下將來，咱們會繼續在 3 個方向發力。

第一個是更好的底層存儲，Cassandra 畢竟是一個通用的列式數據庫，對時序數據來講，有不少很差優化的地方，咱們指望可以自研一個時序數據庫來知足咱們的業務需求。

第二個是智能化的監控和告警，運用合適的算法並加上機器學習或是深度學習，探索出無閾值的告警體系，並自動分析出告警之間的關聯關係，給出根因。

第三個是 APM 和監控的更緊密結合，將鏈路監控、日誌監控和指標監控直接合並，更深度地診斷系統，系統沒有沒法探查的祕密。

點擊這裏獲取更多資源

點擊這裏獲取更多資源