亞馬遜發布分布式跟蹤服務“AWS X-Ray”的預覽版本
英文原文：Microsoft Open-Sources P Language for Safe Async Event-Driven Programming
在美國拉斯維加斯舉行的 AWS re:Invent 2016 大會上，亞馬遜發布了一款名為 AWS X-Ray 的分布式跟蹤服務，它目前處于預覽版本，能夠在 AWS 的 12 個公開 Region 中使用。AWS X-Ray 類似于 Google 的 Dapper、推ter 的 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 是該項目的核心提交者，他在 推ter 上稱 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”的文章。
來自: InfoQ