摘要:分布式鏈路追蹤現狀分布式鏈路追蹤的技術有很多,有開源的也有閉源的。個推的實踐個推的微服務是基于和進行部署的,每個微服務對應于中的一組。整體的架構如下圖所示個推基于的分布式鏈路追蹤系統的整體架構其中,也容器化部署在集群中,簡化了的搭建和部署。
作者:個推應用平臺基礎架構高級研發工程師 阿飛
01業務背景
隨著微服務架構的流行,系統變得越來越復雜,單體的系統被拆成很多個模塊,各個模塊通過輕量級的通信協議進行通訊,相互協作,共同實現系統功能。
單體架構時,一個請求的調用鏈路很清晰,一般由負載均衡器將用戶請求轉發到后端服務,由后端服務進行業務處理,需要的數據從外部的存儲中獲取,處理完請求后,再經由負載均衡器返回給用戶。
而在微服務架構中,一個請求往往需要多個模塊共同協作處理,不同模塊可能還依賴于不同的外部存儲,各個模塊的實現技術還不盡相同,一個請求是如何在整個系統不同模塊間進行流轉,整個調用鏈上的各個模塊之間的調用關系如何,每個微服務處理的時間長短,處理的結果是否正確,很難去進行追蹤,而這些信息對于整個系統運維、性能分析、故障追蹤都特別有幫助,也正因為此,才有了各種分布式鏈路追蹤的技術。
02分布式鏈路追蹤現狀
分布式鏈路追蹤的技術有很多,有開源的也有閉源的。開源的有Jaeger、PinPoint、Zipkin、SkyWalking、CAT等,閉源的有Google Dapper、淘寶的鷹眼Tracing、新浪的Watchman、美團的MTrace等。CNCF(Cloud Native Computing Foundation)為了解決業界分布式追蹤系統跨平臺兼容性問題,設計了trace的標準,提出了分布式跟蹤系統產品的統一范式-OpenTracing,Zipkin也部分支持OpenTracing標準。
03選擇Zipkin的原因
在實踐的過程中,基于以下原因選擇了Zipkin來進行鏈路追蹤:
? 開源,社區活躍
? 支持多種語言,Nodejs,Lua,Java都有開源實現,而我們的服務主要是這三種語言實現的
? 提供查詢API,方便二次開發
04Zipkin的架構介紹
Zipkin的整體架構如下圖所示:
Zipkin的整體架構
(引用自Zipkin官網:https://zipkin.io/pages/archi...)
其中:
? Instrumented client和Instrumented server需要集成在分布式系統的具體服務中,采集跟蹤信息,調用Transport,把跟蹤信息發送給Zipkin的Server。
? Transport是Zipkin對外提供的接口,支持HTTP、Kafka、Scribe等通信方式。
? Zipkin即Zipkin server,主要包括四個模塊:
Collector: 用于接收各個應用服務傳輸的追蹤信息;
Storage:Zipkin的后端存儲,支持In-Memory、MySql、Elasticsearch和Cassandra;
API:提供對外的查詢接口;
UI:提供對外的Web界面。
Http Tracing的時序圖
(引用自Zipkin官網:https://zipkin.io/pages/archi...)
以上是Http Tracing的時序圖,用戶的請求/foo首先被Trace Instrumentationlan攔截,記錄下Tags,時間戳,同時在Header里增加Trace信息,然后再流轉到后端服務進行處理,處理完成后,正常響應,Trace Instrumentationlan攔截響應,記錄處理延時后,將Response正常返回給調用方,同時異步地將Trace的Span發送給Zipkin Server。Span中的traceId是在整個調用鏈路上唯一的ID,用于唯一標識一條調用鏈。
05個推的Zipkin實踐
個推的微服務是基于Kubernetes和Docker進行部署的,每個微服務對應于Kubernetes中的一組Pod。
在整個微服務體系中,API網關是基于Openresty開發的,主要使用Lua進行開發;后端服務主要使用Node.js和Java進行開發實現。在對接Zipkin時,不同的微服務采用不同的方式進行實現。
API網關主要通過增加網關插件(主要參考了Kong的Zipkin插件實現)來實現與Zipkin的對接;Node.js實現的服務主要使用了中間件實現與Zipkin的對接;Java服務使用了spring-cloud-sleuth來與Zipkin對接。 整體的架構如下圖所示:
個推基于Zipkin的分布式鏈路追蹤系統的整體架構
其中,Zipkin也容器化部署在Kubernetes集群中,簡化了Zipkin的搭建和部署。如下圖所示,通過Zipkin可以很方便地追蹤請求的調用鏈路,整個調用鏈上各個服務的處理耗時,響應狀態,服務間的調用關系都可以方便地在Zipkin中進行查詢。Zipkin對于分析整個系統的性能瓶頸,定位故障也都有很大的幫助。
Zipkin的Web界面
06總結
Zipkin作為一個分布式鏈路追蹤系統,有著應用侵入較小、社區活躍度較高、支持多種語言等優勢,一般基于開源的實現稍做修改就可以實現與Zipkin的對接。因此個推在微服務架構中也引入了Zipkin,用Zipkin來追蹤微服務的調用關系,對微服務進行性能分析和故障診斷。未來,個推會基于Zipkin做二次開發,提供更為友好的界面。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/104272.html
摘要:一方面,網關是個推微服務體系對外的唯一入口另一方面,網關中實現了很多后端服務的共性需求,避免了重復建設。個推微服務網關的設計與實現個推微服務主要是基于和進行實踐的。下圖是個推微服務體系的架構圖。 作者:個推應用平臺基礎架構高級研發工程師 阿飛 在微服務架構中,不同的微服務可以有不同的網絡地址,各個微服務之間通過互相調用完成用戶請求,客戶端可能通過調用N個微服務的接口完成一個用戶請求。因...
摘要:個推針對服務場景,基于和搭建了微服務框架,提高了開發效率。三容器化在微服務落地實踐時我們選擇了,下面將詳細介紹個推基于的實踐。 2016年伊始Docker無比興盛,如今Kubernetes萬人矚目。在這個無比需要創新與速度的時代,由容器、微服務、DevOps構成的云原生席卷整個IT界。個推針對Web服務場景,基于OpenResty和Node.js搭建了微服務框架,提高了開發效率。在微服...
摘要:個推針對服務場景,基于和搭建了微服務框架,提高了開發效率。三容器化在微服務落地實踐時我們選擇了,下面將詳細介紹個推基于的實踐。 2016年伊始Docker無比興盛,如今Kubernetes萬人矚目。在這個無比需要創新與速度的時代,由容器、微服務、DevOps構成的云原生席卷整個IT界。個推針對Web服務場景,基于OpenResty和Node.js搭建了微服務框架,提高了開發效率。在微服...
摘要:一個客戶端請求從發出到被響應經歷了哪些組件哪些微服務請求總時長每個組件所花時長等信息我們有必要了解和收集,以幫助我們定位性能瓶頸進行性能調優,因此監控整個微服務架構的調用鏈十分有必要,本文將闡述如何使用搭建微服務調用鏈追蹤中心。 showImg(https://segmentfault.com/img/remote/1460000014553707); 概述 一個完整的微服務系統包含...
摘要:服務提供者提供一個接口,服務消費者通過消費服務。服務提供者服務提供者,對外提供一個,并向服務注冊中心注冊,這部分內容,不再講述,見源碼。 微服務架構是一個分布式架構,微服務系統按業務劃分服務單元,一個微服務系統往往有很多個服務單元。由于服務單元數量眾多,業務的復雜性較高,如果出現了錯誤和異常,很難去定位。主要體現在一個請求可能需要調用很多個服務,而內部服務的調用復雜性決定了問題難以定位...
閱讀 2895·2021-11-24 09:39
閱讀 1157·2021-11-02 14:38
閱讀 4141·2021-09-10 11:26
閱讀 2743·2021-08-25 09:40
閱讀 2303·2019-08-30 15:54
閱讀 477·2019-08-30 10:56
閱讀 2738·2019-08-26 12:14
閱讀 3211·2019-08-26 12:13