摘要
對大型分布式系統進行監視，可視化和故障排除是一項重大挑戰。當今使用的一種常見工具是分布式跟蹤系統（例如Google Dapper）[1]，它基于跟蹤資料檢測拓撲和度量。當今拓撲檢測的一大局限性在于，隻能根據給定的時間視窗的跟蹤資料來推斷服務之間的依賴關系。這會導緻更多的延遲和記憶體使用，因為在高度分布式的系統中，每個用戶端和服務端追蹤資訊都必須在數百萬個随機RPC請求中進行比對。更重要的是，如果用戶端和伺服器之間的RPC持續時間長于先前的設定時間視窗或跨越兩個視窗，則它可能無法比對。
在本論文中，我們提出了STAM(流拓撲分析方法)。在STAM中，我們可以使用自動檢測或手動檢測機制在用戶端和伺服器端截取和操縱RPC。對于自動檢測，STAM在runtime處理應用程式代碼，例如Java代理。是以，此監視系統不需要應用程式開發團隊或RPC架構開發團隊修改任何源代碼。STAM将用戶端使用的RPC網絡位址，服務名稱和服務執行個體名稱注入RPC上下文，并将伺服器端服務名稱和服務執行個體名稱綁定為用戶端使用的該網絡位址的别名 。将依賴性分析從導緻阻塞和延遲的機制中解放出來，
STAM已在Apache Software Foundation的一個開源APM（應用程式性能監視系統）項目Apache SkyWalking [2]中實施，該項目已在許多大型企業中廣泛使用[3]，其中包括阿裡巴巴，華為，騰訊，滴滴，小米，中國移動和其他企業（航空公司，金融機構等）在生産環境中支援其大型分布式系統。它具有更好的水準擴充能力，進而顯着降低了負載和記憶體成本。
介紹
監控高度分布式的系統（尤其是使用微服務體系結構）非常複雜。許多RPC，包括HTTP，gRPC，MQ，緩存和資料庫通路，都在單個用戶端請求之後。讓IT團隊了解數千個服務之間的依賴關系是整個分布式系統可觀察性的關鍵特征和第一步。分布式跟蹤系統能夠收集跟蹤，包括所有分布式請求路徑。邏輯上已将依賴關系包括在跟蹤資料中。分布式跟蹤系統，例如Zipkin [4]或Jaeger Tracing [10]，提供了内置的依賴關系分析功能，而且有許多分析功能都基于此。這種分析至少存在兩個局限性：實時性和一緻的準确性。
服務級别和服務執行個體級别的依賴分析過程中，由于分布式應用程式系統依賴關系的可變性，需要很強大的實時性保障。
服務是具有相同功能或代碼的執行個體的邏輯組。
服務執行個體通常是作業系統級别的程序，例如JVM程序。服務和執行個體之間的關系是可變的，具體取決于配置，代碼和網絡狀态。依賴關系可能會随着時間而改變。
圖1，在傳統的基于Dapper的跟蹤系統中生成的span。
Dapper論文中的span模型和現有的跟蹤系統（例如Zipkin儀器模式[9]）隻是将span id傳播到伺服器端。由于這種模型，依賴性分析需要一定的時間視窗。關系分析同時依賴從用戶端和服務端收集到的追蹤資料。是以，分析過程必須等待用戶端和伺服器span在同一時間視窗中比對，才能輸出結果Service A依賴于Service B。是以，RPC請求持續時間必須在時間視窗内；否則，将無法分析出服務關系資料。在生産中，有時必須将視窗持續時間設定為3-5分鐘，使得拓撲分析無法在秒級做出反應。另外，由于基于時間視窗的設計，如果一側涉及到長時間任務，它不能輕易達到一緻的精度。因為，為了使分析盡可能快，是以分析時間少于5分鐘。但是，如果分析不完整或跨越兩個時間視窗，則某些span将無法與其父級或子級比對。即使我們添加了一種機制來處理前一階段剩餘的span，仍然必須放棄一些機制以保持資料集大小和記憶體使用合理。
在STAM中，我們使用新的分析方法介紹了新的span和上下文傳播模型。這種新模型将用戶端使用的對端網絡位址（IP或主機名），同時，用戶端将自己的服務執行個體名稱和用戶端服務名稱添加到上下文傳播模型中。然後，依托RPC調用從用戶端傳遞到伺服器，就像現有跟蹤系統中的傳遞原始Trace ID和Span ID一樣，并将其收集在伺服器端span中。新的分析方法可以輕松地直接生成用戶端-伺服器關系，而無需等待用戶端span。它還将用戶端使用的對端網絡位址設定為服務端服務的一個别名。在跨叢集節點資料同步後，用戶端span分析也可以使用此别名中繼資料直接生成用戶端-伺服器關系。通過在Apache SkyWalking中使用這些新模型和方法，我們不再依賴基于時間視窗的分析方法，在低于5秒延遲的條件下，準備地進行拓撲圖分覅。
Span Model(新的跨度模型)和Context Mode(上下文模型)
跟蹤系統的傳統範圍包括以下字段[1] [6] [10]。
Trace ID，代表整個跟蹤。
Span ID,代表目前span。
一個operation name，描述此span執行的操作。
start timestamp(開始時間戳)。
finish timestamp(完成時間戳)。
目前Span的Service和Service Instance名稱。
一組零個或多個鍵值對組成的的span tag。
一組零個或多個span日志，每個span日志本身就是與時間戳配對的key：value映射。
引用零個或多個因果相關的span。參考包括parent span id和trace id。
在STAM的新span模型中，我們在span中添加以下字段。
Span type(跨度類型): 枚舉類型,Exit，Local和Entry。Entry和Local适用于網絡相關的庫中。輸入範圍代表伺服器端網絡庫，例如Apache Tomcat [7]。Exit spans代表用戶端網絡庫，例如Apache HttpComponents [8]。
Peer Network Address:(對端網絡位址): 遠端“Address”，适用于exit和entry的span。在“Exit spans”中，對端網絡位址是用戶端庫通路伺服器的位址。通常，這個字段通常在許多跟蹤系統中是可選的。但是在STAM中，我們在所有RPC情況下都需要它們。
Context Model(上下文模型):用于将用戶端資訊傳播到原始RPC調用所攜帶的伺服器端，通常在header（例如HTTP header或MQ header）中傳播。在舊的設計中，它帶有用戶端span的Trace ID和Span ID。在STAM中，我們增強了此模型，添加了父服務名稱，parent service instance name(父服務執行個體名稱)和peer of exit span.(出口範圍的對等點)。名稱可以是文字字元串。所有這些額外的字段将有助于消除流分析的障礙。與現有的上下文模型相比，它使用更多的帶寬，但是可以對其進行優化。在Apache SkyWalking中，我們設計了一種注冊機制來交換代表這些名稱的唯一ID。結果，在RPC上下文中僅添加了3個整數，是以在生産環境中帶寬的增加至少小于1％。
兩種模型的變化可以消除分析過程中的時間視窗。Server-side span分析增強了上下文感覺能力。
新的拓撲分析方法
STAM核心的新拓撲分析方法是以流模式處理span。server-side span（也稱為entry span）的分析針對包括parent service name(父服務名稱)，parent service instance name(父服務執行個體名稱)和exit span的peer資訊。是以，分析過程可以得出以下結果。
使用exit span的peer做為目前服務和執行個體的别名。建立Peer network address <-> service name和peer network address <-> Service instance name别名。這兩個将與所有分析節點同步并儲存在存儲中，進而允許更多分析處理者擁有此别名資訊。
生成parent service name -> current service name和parent service instance name -> current service instance name兩種關系資料，除非發現目前已經存在還有另外一個不同的Peer network address <-> Service Instance Name映射關系。在這種情況下，僅生成peer network address <-> service name的關系和peer network address <-> Service instance name的關系。
為了分析client-side span（exit span），可能存在三種可能性。
exit span中的對等方已經具有從步驟（1）進行的伺服器端範圍分析所建立的别名。然後使用别名來代替peer資訊，并産生的流量current service name -> alias service name和current service instance name -> alias service instance name。
如果找不到别名，那麼隻需為current service name -> peer和current service instance name -> peer生成流量。
如果peer network address <-> Service Instance Name可以找到的多個别名，則繼續為current service name -> peer network address和current service instance name -> peer network address生成流量。
圖2，Apache SkyWalking使用STAM來檢測和可視化分布式系統的拓撲。
評價
在本節中，我們将在幾種典型情況下評估新模型和分析方法，在這些情況下，舊方法會失去及時性和一緻的準确性。
線上新服務或自動擴充
新的服務可以由開發團隊随機地添加到整個拓撲中，也可以通過某種擴充政策自動将容器操作平台添加到整個拓撲中，例如Kubernetes [5]。在任何情況下都無法手動通知監視系統。通過使用STAM，我們可以自動檢測新節點，并保持分析過程暢通無阻，并與檢測到的節點保持一緻。在這種情況下，将使用新的服務和網絡位址（可以是IP，端口或兩者）。peer network address <-> service映射不存在，将首先生成client service -> peer network address的流量并将其持久化在存儲中。生成映射後，可以在分析平台中識别，生成和聚合用戶端服務到伺服器服務的其他流量。為了在生成映射之前填補一些流量的空白，我們要求在查詢階段再次進行peer network address <-> service映射轉換，以将client service->peer network address和client-service合并到server-service。在生産中，整個SkyWalking分析平台部署的VM數量少于100，在它們之間的同步将完成少于10秒，在大多數情況下僅需要3-5秒。在查詢階段，資料至少要在幾分鐘或幾秒鐘内彙總。查詢合并性能與生成映射之前發生的流量無關，僅受同步持續時間的影響，此處僅3秒。是以，在分鐘級别的聚合拓撲中，它僅在整個拓撲關系資料集中添加1或2個關系記錄。考慮到每分鐘有500多個關系記錄的100多個服務拓撲，此查詢合并的有效負載增加非常有限且負擔得起。該功能在大型高負載分布式系統中非常重要，因為我們無需擔心其擴充能力。在某些fork版本中，為了永久地消除查詢階段的額外負載，在檢測到新的對等映射後，他們選擇更新現有的client service->peer network address到client-service到server-service，以便永久消除查詢階段的額外負載。
圖3，使用新的拓撲分析方法進行span分析
現有未配置節點
在這種情況下，每種拓撲檢測方法都必須起作用。在許多情況下，生産環境中存在無法被監控的節點。其原因可能包括：（1）技術限制。在某些使用golang或C ++編寫的應用程式中，Java或.Net中沒有簡單的方法來由代理進行自動檢測。是以，可能不會自動檢測代碼。（2）MQ，資料庫伺服器等中間件未采用跟蹤系統。分布式追蹤這些中間件是非常耗時或者時間困難的。（3）第三方服務或雲服務不支援目前跟蹤系統的工作。（4）缺乏資源：例如，開發人員或操作團隊缺乏時間完成探針安裝或者修改代碼。
即使用戶端或伺服器端沒有探針，STAM也可以正常工作。它仍然保持拓撲盡可能準确。
如果未安裝用戶端探針，則server-side span将不會通過RPC上下文獲得任何引用，是以，它将僅使用peer來生成流量，如圖4所示。
圖4，沒有用戶端探針時的STAM流量生成
如圖5所示，在另一種情況下，由于沒有server-side span，是以client span分析不需要處理這種情況。STAM分析核心隻是簡單地不斷生成client service->peer network address。由于沒有生成的peer network address的映射，是以沒有合并。
圖5，沒有伺服器端探針時的STAM流量生成
具有報頭轉發能力的未配置節點
除了我們在（2）未配置節點中評估的情況外，還有一種複雜而特殊的情況：被檢測的節點具有将header從下遊傳播到上遊的能力，通常在所有代理中，例如Envoy [11]，Nginx [12] ]，Spring Cloud Gateway [13]。作為代理，它具有将所有header從下遊轉發到上遊的功能，以将某些資訊保留在header中，包括tracing上下文，身份驗證資訊，浏覽器資訊和路由資訊，以使它們可被位于proxy後面的業務服務通路，例如Envoy路由配置[14]。當無論什麼原因，某些代理無法安裝探針時，它都不應該會影響拓撲檢測。
在這種情況下， proxy address在用戶端使用，并通過RPC上下文作為peer network address，并且代理将其轉發到其他上遊服務。然後，STAM可以檢測到這種情況并生成代理作為推測節點。在STAM中，應為此網絡位址生成多個别名。在檢測到這兩個并同步到分析節點之後，分析核心知道用戶端和伺服器之間至少有一個未配置的服務。是以，它将生成client service->peer network address，peer->server service B和peer network address->server service C的關系，如圖6所示。。
圖6，代理無法被監控時，STAM流量的生成
結論
這個論文介紹了STAM，據我們所知，STAM是分布式跟蹤系統的最佳拓撲檢測方法。它取代了基于時間視窗的拓撲分析方法，用于基于跟蹤的監視系統。它永久和完全地消除了，使用基于時間視窗分析方法中的磁盤和記憶體資源成本，并消除了水準擴充的障礙。Apache SkyWalking是一個STAM實作，被廣泛用于監視生産中的數百個應用程式。其中一些每天生成超過100 TB的跟蹤資料，并為200多種服務實時生成拓撲。