![](https://hfnxjk.com/statics/images/logo.png)
在美國拉斯維加斯舉行的AWS re:Invent 2016大會上,亞馬遜發布了一款名為AWS X-Ray的分布式跟蹤服務,它目前處于預覽版本,能夠在AWS的12個公開Region中使用。AWS X-Ray類似于Google的Dapper、Twitter的Zipkin以及OpenTracing API,它能夠幫助開發人員分析和調試分布式應用,比如使用微服務架構風格所構建的應用。它提供了一個基于Web的UI,能夠展現拓撲化的“服務地圖”、圖形化格式的分布式跟蹤以及所有跟蹤記錄的可查詢列表。
正如Jeff Barr在AWS博客上所討論的那樣,在過去的幾年間,軟件應用的設計和部署發生了一些變化,轉向了創建復雜的分布式“基于服務”的系統。因此,軟件應用的調試行為也隨之發生了變化,當我們要查看應用擴展的行為模式時更是如此。
通過組合使用云計算、微服務以及基于通知的異步架構,系統會被拆分為成百上千的組成部分,而且這些組成部分還會處于不斷的變化之中。在這樣復雜的系統中,識別和解決性能問題會變得更加具有挑戰性,同時面臨的挑戰的還要將單個服務級別的監測結果合成為有意義的高層級結果。
這些分布式系統都是基于云的,系統的執行過程會遍歷應用服務、容器、計算實例、數據庫即服務(database-as-a-service)和消息即服務(messaging-as-a-service),因此對于構建人員和運維人員來說最主要的挑戰在于“跟蹤線程(following-the-thread)”。
當請求在部署于AWS環境中的整個系統中遍歷時,AWS X-Ray會對請求進行跟蹤。應用會由多個服務和資源組成,AWS X-Ray會將單個服務和資源生成的數據集合起來,從而提供“系統如何運行的端到端視圖”。AWS X-Ray的跟蹤特性能夠跟蹤任意的請求路徑,從而定位系統中的哪一部分出現了性能問題。AWS X-Ray還提供了注解,能夠在跟蹤上附加元數據,從而能夠為跟蹤數據添加標簽并對其進行過濾。
根據發布AWS X-Ray的AWS博客文章描述,AWS X-Ray能夠與Amazon EC2、Amazon EC2 Container Service (Amazon ECS)、AWS Elastic Beanstalk和Amazon API Gateway協同工作。AWS X-Ray SDK可以用于Java、Node.js和.NET所編寫的應用中,應用需要基于上述的服務進行部署,這樣的話,就能跟蹤針對應用所發起的請求,應用可能會跨多個AWS賬號、AWS Regions和Availability Zones。針對AWS Lambda的支持很快也會發布。
AWS X-Ray在實現“跟蹤線程”時,如果請求上沒有特定的HTTP頭信息(包含一個唯一ID)的話,就會增加一個這樣的頭信息,然后將這個頭信息傳遞到請求處理的其他層中。在每個點收集到的數據稱為segment(類似于OpenTracing API規范中的Span),會存儲為一段JSON數據。segment代表了一個工作單元,其中包含了請求和響應的計時,另外還會有子segment來代表更小的工作單元。OpenTracing倡議是由CNCF支持的,Adrian Cole是該項目的核心提交者,他在Twitter上稱AWS X-Ray segment數據格式具有“很小巧的結構”。
據AWS X-Ray的文檔所述,具有“統計意義”的segment樣本會傳送到X-Ray上。AWS X-Ray SDK不會將跟蹤數據直接發送到服務上,而是將跟蹤數據發送到一個AWS X-Ray daemon上,daemon必須運行在相關的EC2實例或者位于每個ECS容器中。daemon會收集多個請求的segment并采用批處理的方式進行上傳。所收集到的跟蹤數據可以在AWS X-Ray基于Web的UI中進行查看,也可以通過AWS X-Ray API和AWS CLI進行訪問。
關于AWS X-Ray的更多信息,可以參考AWS博客上名為“AWS X-Ray——洞悉分布式應用”的文章、AWS X-Ray產品頁面以及AWS X-Ray的文檔。關于AWS re:Invent宣布的其他信息和產品發布消息可以參考InfoQ上名為“AWS re:Invent Recap”的文章。
查看英文原文:Microsoft Open-Sources P Language for Safe Async Event-Driven Programming