InfoQ近期採訪了Ben Sigelman，探討在“深層系統”（deep system）中管理微服務所面對的挑戰性問題。在“深層系統”中，服務的擁有者需要與大量不屬於該服務擁有者的其他服務進行交互。Sigelman是LightStep的CEO，也是OpenTracing和OpenTelemetry項目的創始人。
Sigelman最近在Systems@Scale大會上做主題演講時指出，問題主要在於如何區分控制和責任，以及團隊如何準確地判定每個服務內部及相互之間的作用情況。開發團隊通常控制着多個服務，這些服務需要調用其他的服務，或是被其他服務調用。儘管相互關聯的服務通常並不屬於同一團隊，但是它們爲連接的服務繼承責任。隨着服務間的相互調用，調用關係鏈趨向於更加深入，團隊難以快速診斷導致故障或運行性能降低等問題的原因。
不同於標準的性能監控，微服務間通信模式的變化會潛在地影響微服務的性能。例如，監控顯示某個服務使用設定參數運行時，性能發生了降低，但是問題的根源卻可能是由不同的服務調用方式使得服務需求顯著增加而導致的。
解決微服務問題的關鍵，是需要在服務內部啓用可觀察性（observability）和控制，快速定位存在性能問題之處，是位於微服務內部，還是位於微服務之間，消除一切的不確定性。Sigelman指出，“數據不明晰，責任就會互相推諉。對於出現的問題，可使用一種稱爲MTTI（即平均解決問題時間，Mean-Time-To-Innocence）的度量指標。數據明晰，MTTI值就會很低。如果數據缺失，或是不明晰，那麼MTTI值就會變大”。MTTI值變大，就需要相關人員做長時間的協商，分析導致問題和故障的根本原因，進而導致運維代價增大。
“可觀察性”指無需更改服務就能快速發現服務內部及相互之間存在問題的能力，“控制”指對所發現問題的處理能力。可觀察性的目標是獲取控制。OpenTelemetry項目爲實現可觀察性和控制提供了標準化工具。該項目支持多種工具，以正確的方式抽取正確的度量和KPI，由此每個團隊可採取相應的行動。
下面給出InfoQ與Ben Sigelman的訪談記錄：
InfoQ：OpenTracing和OpenTelementry項目兩者間是什麼關係？
Ben Sigelman: OpenTelemetry提供了一個標準，定義了遙測數據和結構及其要採集的內容。可以說OpenTelemetry爲此打開了一扇大門。OpenTracing的功能類似，但針對更細分的領域，專門設計爲一種分佈式追蹤工具。對於新上手的用戶，我推薦關注OpenTelemetry。其功能更爲豐富，並推動着OpenTracing向前發展。
InfoQ：您在主題演講中提出了“深層系統”（deep system）這一概念。爲什麼系統會演化爲“深層”的？深層系統解決了哪些問題，又會引入哪些新問題？
Sigelman：當人們談及微服務時，通常考慮的是服務本身，而非整個大系統的全貌。系統中如果存在大量的微服務，那麼就會演變爲一種深層系統。系統不僅是多個服務，而且存在多個層面。對於500個服務，問題不僅僅是一個路由或API網關需要與其它499個服務通信，而是500個服務相互之間的通信。服務的性能，取決於依賴關係中性能最低的服務。每增加一個層面，出錯的方式也會相應地增加。
業界轉向微服務，究其根本是爲了促進各開發團隊相互間的自治性和獨立性。但事與願違，系統通常會在深層領域產生摩擦和低效，導致整體性能降低。這是因爲微服務相互間的問題難以追蹤，相互間的複雜依賴方式難以爲人所理解，並且難以確定恢復SLO（服務等級目標，Service Level Objective）所需調整的服務。
InfoQ：控制和責任應如何納入到微服務中？
Sigelman：在任一系統中，都需要掌控層層嵌套的依賴調用關係，但開發人員只能掌控自身可構建和部署的服務。在深層的系統中，隨着系統深度的增加，依賴關係樹的規模會呈幾何級別增長，同時度量標準和日誌記錄數據多到無法使用常規工具篩選。解決此問題的唯一方法，就是利用作爲可觀察性系統核心功能的數據追蹤特性。追蹤數據是唯一能夠提供系統各層相關上下文的數據。
InfoQ：對於Java，OpenJDK團隊近期開源了Flight Recorder/Mission Control，它們實現了低開銷的JVM性能監控。與之相比，OpenTelemetry具有哪些過人之處？
Sigelman：Flight Recorder/Mission Control非常適合查看單個給定的JVM。但對於微服務，問題則有所不同。大多數企業內部發生的技術災難（technical fires），都是由代碼或配置推送所導致的。例如，上游團隊會將服務調用方式從1次提高到100次（儘管他們不應該這樣做）。這時，性能剖析工具會給出顯示，代碼正處於頻繁運行狀態。但此類性能剖析工具無法給出導致代碼頻繁運行的原因，以及這段代碼與其它服務的關聯關係。但如果用戶的確只需分析單個JVM，那麼此類工具完全勝任。
InfoQ：OpenTelemetry在深層服務中獲取可觀察性方面，團隊需要注意哪些關鍵方面？
Sigelman：服務的成功與否，判定權應在服務的消費者。這意味着，需要建立衡量成功的SLI/SLO，例如響應時間、錯誤預算等度量。服務開發者應該瞭解服務消費者的關注點，並據此制定準確的目標。如果從SLI/SLO着手開展調查，那麼一個可觀察性系統就能知悉開發人員需要去解決的問題。這將大大縮減查找潛在問題根源的規模和範圍。
InfoQ：如果由團隊去定義消費者的需求，那麼存在哪些聽上去很誘人的但實際上會帶來麻煩的概念？
Sigelman：首先，追蹤CPU、RAM等系統基礎指標，通常無法指示問題根源所在。其次，微服務團隊常認爲鬆耦合意味着完全獨立和自治，可做出完全不同的決策。例如，Netflix提供了運行良好的工具和框架，爲此“鋪平了道路”。一旦人們選擇這些現成工具時，就將獲得受支持的編程語言、軟件庫、安全檢查等一系列幫助。如果採取完全自主開發這條路，另闢蹊徑會增加控制難度，因爲其他團隊難以立刻提供幫助。
InfoQ：對於需要分析複雜微服務的人而言，您可否推薦一些特定的工具？
Sigelman：OpenTelemetry是推進現代可觀測性的先行者，它支持集成到已有系統中，收集高質量的遙測數據。團隊可藉助Auto Instrumentation Agent，無需更改任何代碼實現上述功能。該Agent支持數據訪問，但不提供任何分析工具。對於需要遙測數據分析和可視化的用戶，我個人推薦使用免費的LightStep tier。
我和Honeycomb的Liz Fong-Jones都會定期在Twitter上深度探討微服務管理相關的話題。
原文鏈接：