作者 ｜ 陳亦帥，中國移動云能力中心PaaS產(chǎn)品部

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

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

01微服務(wù)架構(gòu)演進歷史

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

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

單體應(yīng)用架構(gòu)

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

垂直應(yīng)用架構(gòu)

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

分布式SOA架構(gòu)

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

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

微服務(wù)架構(gòu)

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

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

02什么是微服務(wù)的可觀測性

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

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

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

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

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

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

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

現(xiàn)在業(yè)界對于微服務(wù)可觀測性的一種解決方案既是，首先使用loki + Grafana進行分布日志的統(tǒng)一收集與管理，使用Prometheus和Grafana對 Metrics 進行存儲和展示，最后再使用諸如類似Jaeger的追蹤系統(tǒng)做分布式追蹤的存儲和展示?；诖耍覀兛梢源笾芦@得如下的一個問題分析鏈路：

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

03總結(jié)

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