作者 ｜ 陳亦帥，中國移動云能力中心PaaS產品部

近年來，“云原生”頻繁出現在人們的視野中。隨著云原生成為下一代云計算的技術“內核”，業(yè)界正在從關注“云原生概念”轉變到關注“云原生落地實踐”。云原生技術發(fā)展勢不可擋，依然會是未來云計算領域的熱門話題。

我們知道，現代”云原生”是一套符合云計算發(fā)展趨勢的應用設計理念方法論，其關鍵技術中包含了微服務架構、容器、容器化編排、服務網格等技術。那么當我們把大型系統(tǒng)拆解成一個個獨立部署的模塊，進行容器化部署，得益于此團隊可以更加快速、持續(xù)、規(guī)模快的進行開發(fā)和交付系統(tǒng)。但事物都有兩面性，我們從方案或者技術“好”的一面中“獲利”的同時，必須同時規(guī)避解決“壞”的一面帶來的風險和后果，其中比較大一項就是微服務化后系統(tǒng)復雜性的成倍上升而帶來運維和問題排查難度陡增的巨大挑戰(zhàn)。

01微服務架構演進歷史

在真正進入微服務可觀測性這個話題之前，我們有必要了解下微服務架構的演進歷史。從整體上看，整體架構的演變過程大致經歷了單體應用架構、垂直應用架構、分布式SOA架構、微服務架構的演變。我們以一個電商系統(tǒng)舉例(以下圖片均來自網上)，主要比較下各個架構之間在運維方面的區(qū)別。

舉例的電商系統(tǒng)大致分為三個主體模塊：主體業(yè)務模塊(用戶管理、商品管理、訂單管理)、內容管理模塊(CMS管理)、系統(tǒng)管理模塊(后臺管理)。

單體應用架構

如圖所示，單體應用架構把所有模塊都揉進了一個應用內，所有模塊均耦合在一起。系統(tǒng)的健康狀況通常“所見即所得”(整體功能可用便表示應用處于健康狀態(tài))，監(jiān)測和告警指標通常由JVM的一些參數進行反饋，應用日志產生和收集比較統(tǒng)一集中，排查問題的鏈路通常比較短(大多問題可由日志直接定位到應用內的某行代碼進而分析原因)，維護和監(jiān)控起來難度不大。但通常一個子模塊的問題會導致整體項目出現不可用，無法水平擴展，過于臃腫無法適配大型項目和應用。之后便逐漸演變?yōu)榇怪睉眉軜嫛?/p>

垂直應用架構

相比較于單體應用架構，我們對整體系統(tǒng)進行了拆分，優(yōu)點是可以根據實際情況對某個子系統(tǒng)進行水平擴展，一個系統(tǒng)發(fā)生故障可以避免對其他系統(tǒng)產生影響。缺點是拆分后系統(tǒng)比較獨立無法相互調用(不同于微服務，只是獨立拆分)也導致了重復業(yè)務的開發(fā)，如圖中箭頭所示的訂單管理、商品管理、用戶管理部分，后期維護成本較高。運維方面，難度提升的地方主要在于日志的管理和問題發(fā)生點的增加，例如一個問題的發(fā)生可能同時由CMS和后臺管理系統(tǒng)導致，需要同時解決兩個系統(tǒng)的故障。但業(yè)務規(guī)模的擴大，會導致重復代碼和重復修復工作的激增，我們需要將該部分的邏輯進行抽取，繼而慢慢過渡到分布式SOA架構。

分布式SOA架構

分布式SOA架構也可認為是微服務架構的雛形，其中展示層對應我們通常所說的消費者或者Controller層，負責控制頁面操作需要調用服務層的哪些服務(例如：下單操作使用到用戶、訂單、商品三個服務，而這三個服務又是抽象在服務層獨立存在的)，而服務層是具體的業(yè)務邏輯實現供表現層調用，上圖的服務層模塊應該包括用戶管理、商品管理、訂單管理、CMS管理、后臺管理等所有模塊，并且基于SOA的分布式通常還會包含一個注冊中心(例如：圖中的ESB總線或者類似DUBBO這樣的框架)。

作為微服務架構的雛形，在解決了水平擴展問題的同時，注冊中心的加入既解決了服務之間的注冊發(fā)現和調用，也使公共模塊和邏輯服務得到了抽取獨立。但同時也開始讓運維監(jiān)測壓力有了比較大的增加，性能和告警關注的服務變多，同時還需要關注注冊中心的健康，日志分布更加散亂，業(yè)務發(fā)生故障時，排查鏈路變得冗長，對于復雜業(yè)務問題我們通常需要同時獲取從展示層、注冊中心到服務層的日志，并分析其關系才能比較好的定位出問題，這無論對運維還是應用性能提升都是一個挑戰(zhàn)。并且服務之間的依賴與調用關系復雜，服務提供方與調用方接口耦合，業(yè)務切分不夠細的問題也讓微服務架構登上舞臺。

微服務架構

現在我們所屬的微服務架構通常由一個網關以及各個功能獨立的微小服務構成，服務之間的可以相互調用，它們的可用性可由容器和容器編排的能力提供。服務劃分的更細、職責更加明確，服務之間可使用RPC、REST進行相互調用，同時為前端提供HTTP接口。

由于服務的徹底拆分，服務的開發(fā)可以分發(fā)給各個小團隊進行獨立開發(fā)、部署和升級。并且每個微服務可以根據業(yè)務實際運行情況進行水平擴容，但同時微服務過多，服務治理成本變得更高，同時還要考慮分布式事務、容錯等技術。從運維方面看，服務日志變得更加分散，怎么對全局的微服務進行監(jiān)控和告警難度更大了，最后出現業(yè)務問題進行排查時，鏈路變得非常冗長，若沒有一個全局追蹤id，只通過日志的時間戳，無論是業(yè)務性能優(yōu)化還是故障排除都會變得十分困難。即業(yè)界不斷在討論研究的問題，微服務的可觀測性。

02什么是微服務的可觀測性

從上一節(jié)的架構的演變過程中，我們可以看出隨著服務越拆越細，越拆越獨立，運維的難度以及系統(tǒng)的復雜度都成倍的提升，我們不得不面對以下幾個問題：

• 隨著模塊之間的調用關系由進程內函數的調用變?yōu)檫M程間通過網絡的調用，如何檢測和保證網絡的可靠。
• 調用鏈路的時間越來越長，流量的走向變得越發(fā)不可控，如何高效的排查問題或者提升應用的性能。
• 現代微服務的實踐和部署往往結合Kubernetes、Docker、Service Mesh等云原生技術，開發(fā)團隊更加難感知其下的基礎設施的狀態(tài)了。

傳統(tǒng)對于系統(tǒng)的監(jiān)控，我們往往關注諸如CPU、內存、網絡、應用接口的請求量、接口的響應量等，但這對于微服務系統(tǒng)來說，并不能幫助我們掌握整體系統(tǒng)的運行情況。這就像一條輪胎、一個水箱、一箱油，這些事物分開獨立放置時我們能夠比較簡單的判定其狀態(tài)，但當這些東西被組合進一個“系統(tǒng)”，例如一輛汽車后，如何在汽車運行過程中，觀測到其狀態(tài)，就變成了影響汽車穩(wěn)定性的重要一環(huán)，這對微服務系統(tǒng)來說同樣適用。

微服務的可觀測性即是要解決數據流在客戶端輸入后，透明的知曉其在各個服務間進行采集、傳輸、存儲的狀態(tài)，進而解決預測系統(tǒng)運行過程中出現故障的問題。

為了保證這些數據流的狀態(tài)被感知，業(yè)界普遍認為有幾類數據可作為可觀測性的支柱：Metrics、Logging、Tracing。

其中Metrics是在一段時間內組成單個邏輯測量、計數器或直方圖的原子，例如，服務調用的QPS、響應時間、錯誤請求發(fā)生率，目的是為了創(chuàng)建集中式度量系統(tǒng)，側重于技術指標的收集與觀測;Logging用于記錄離散的事件，例如，應用程序的調試信息或錯誤信息，目的是搭建集中式日志系統(tǒng)，側重于統(tǒng)一采集、存儲與檢索各個微服務的日志;Tracing處理請求范圍內的信息，例如，一次遠程方法調用的執(zhí)行過程和耗時，目的是形成分布式追蹤系統(tǒng)，側重于串聯請求在微服務間的調用情況、繼而進行追蹤與APM分析。

通過以上信息，我們可以對已有的系統(tǒng)進行分類。例如，ZipKin、Jaeger專注于Tracing領域，Prometheus專注于Metrics領域，ELK、Loki專注于Logging領域。但是各個系統(tǒng)也都在不斷的集成其他領域的特性到自身系統(tǒng)中來，例如，Jaeger遵循的一些OpenTracing規(guī)范，但CNCF已經開始把OpenTracing和OpenCensus合并成 OpenTelemetry 項目，以后的會有更多即包含了一定Tracing能力同時又有Metrics的系統(tǒng)出現，Prometheus雖然一開始專注于指標的收集和管理，但也在開始集成一些Tracing的能力。

現在業(yè)界對于微服務可觀測性的一種解決方案既是，首先使用loki + Grafana進行分布日志的統(tǒng)一收集與管理，使用Prometheus和Grafana對 Metrics 進行存儲和展示，最后再使用諸如類似Jaeger的追蹤系統(tǒng)做分布式追蹤的存儲和展示。基于此，我們可以大致獲得如下的一個問題分析鏈路：

首先，我們通過Email或者某種方式收到一個告警信息，接著去Grafana的圖表中看查看某一段時間的指標異常情況，再下鉆就可以在Prometheus中查看到某一個異常指標的詳細情況，就可以獲得對應某個異常發(fā)生的時間或節(jié)點，根據時間和節(jié)點以及服務標簽從Loki中撈取日志信息中的request id或者一個全局的trace id，然后再根據這個trace id去類似Jaeger這種滿足OpenTelemetry 規(guī)范的系統(tǒng)中查找調用鏈，獲得某個服務的異常或者性能響應詳情，最終排除出問題記錄issue。這是一個比較常規(guī)的微服務問題排查方法，雖然一定程度上解決了可觀測性的問題，但是仍然比較冗長。業(yè)界也已經出現了類似exemplar這樣的組件，能夠串聯各個割裂的組件，或者各個廠商也在嘗試推出類似Erda Cloud這樣的一站式解決方法，使上文提到的Logging、Tracing、Metrics不斷的向中心圓靠攏。

03總結

微服務架構和云原生的發(fā)展使我們能夠更加從容的面對大數據時代大型系統(tǒng)的開發(fā)，同時系統(tǒng)運維排查過程中問題鏈路追蹤、應用日志的管理、故障的監(jiān)控告警等也變得越發(fā)復雜，業(yè)界起初出現了針對各個問題的對應的獨立解決方案，但慢慢也趨于集中提供能夠串聯和一站式的平臺系統(tǒng)。微服務的可觀測性問題一直都是困擾著整體應用穩(wěn)定性的一環(huán)，在之后的文章中，我們也期待與大家分享更多相關技術細節(jié)和實戰(zhàn)文章。