事務
map
jvm
大佬對下面的說法是否同意呢
能否比較下zipkin,pinpoint,以及skywalking。該如何選型
回答：
他們都提供了分布式服務跟蹤的能力，pinpoint以及skywalking不僅僅提供了分布式服務跟蹤的能力，
還提供了其他性能監控，是一個APM解決方案。zipkin主要是分布式服務跟蹤，同時與SpringCloud進行有效的集成。
個人覺得pinpoint以及skywalking部署相對麻煩一些。
江湖上都推薦pingpoint
zipkin的監控易於搭建，但是監控的東西很簡單
pinpoint偏向於中等的分布式規模，拓撲和關系不會做的很深，會限制深度。
優勢是做的時間比較長，理論上穩定一些。
缺點是hbase本身就是一個重度運維中間件，要考慮自身情況
skywalking會傾向於微服務的分布式系統，為自研的探針提供了完善的接入支持，我們目前就在給當當做這個接入當時的支持。
同時我們會着重比如服務的依賴關系，服務的統計指標。
我們對於應用，只需要配置應用id，不需要實例id，對容器環境畢竟k8，linkerd友好
zipkin強在生態和范圍，國外的絕大多數組件都提供了集成方案，只需要少量修改代碼或者配置就可以。
比如linkerd原生就支持zipkin
部署上如果你容量不大，pinpoint負擔最大，因為hbase，zipkin和skywalking差不多。存儲都可以用es
另外，zipkin和skywalking屬於opentracing規范體系下，可以共享相同的手動埋點api，skywalking針對非rpc埋點，甚至只需要標注就可以，零開發成本。
而pinpoint是必須學習開發插件的。
這基本上是目前的情況。
不算自己的東西，相對pinpoint，我肯定會喜歡zipkin。我能說不喜歡棒子和他們不靠譜的社區行為么…
還是feign的作者。opentracing起草者之一。
現在數據庫水平分片有用mycat的么。。。大部分都是使用sharding-jdbc么。。。
mycat坑太多
坑的你生不如死
隨着分布式服務架構的流行，特別是微服務等設計理念在系統中的應用，系統規模也會變得越來越大，各微服務間的調用關系也變得越來越復雜。通常一個由客戶端發起的請求在后端系統中會經過多個不同的微服務調用來協同產生最后的請求結果。
在復雜的微服務架構系統中，幾乎每一個前端請求都會形成一個復雜的分布式服務調用鏈路。那么就帶來一系列問題，在業務規模不斷增大、服務不斷增多以及頻繁變更的情況下，如何快速發現問題？如何判斷故障影響范圍？如何梳理服務依賴以及依賴的合理性？如何分析鏈路性能問題以及實時容量規划？面對上面這些問題，Spring Cloud Sleuth提供了分布式服務跟蹤解決方案。
目錄：
一、為什么需要以及什么是分布式服務跟蹤系統
二、分布式服務跟蹤：SpringCloudSleuth
三、分布式服務跟蹤系統其他解決方案
一、為什么需要以及什么是
分布式服務跟蹤系統
-
為什么需要分布式服務跟蹤系統
隨着分布式服務架構的流行，特別是微服務等設計理念在系統中的應用，業務的調用鏈越來越復雜。
可以看到，隨着業務的發展，系統規模也會變得越來越大，各微服務間的調用關系也變得越來越復雜。通常一個由客戶端發起的請求在后端系統中會經過多個不同的微服務調用來協同產生最后的請求結果，在復雜的微服務架構系統中，幾乎每一個前端請求都會形成一個復雜的分布式服務調用鏈路，在每條鏈路中任何一個依賴服務出現延遲過高或者錯誤都有可能引起請求最后的失敗。同時，缺乏一個自上而下全局的調用id，如何有效的進行相關的數據分析工作？對於大型網站系統，如淘寶、京東等電商網站，這些問題尤其突出。
-
什么是分布式服務跟蹤系統
分布式服務跟蹤是整個分布式系統中跟蹤一個用戶請求的過程（包括數據采集、數據傳輸、數據存儲、數據分析、數據可視化），捕獲此類跟蹤讓我們構建用戶交互背后的整個調用鏈的視圖，這是調試和監控微服務的關鍵工具。Spring Cloud Sleuth是Spring Cloud為分布式服務跟蹤提供的解決方案，有了它，我們可以：
-
提供鏈路追蹤，故障快速定位：可以通過調用鏈結合業務日志快速定位錯誤信息。
-
可視化各個階段耗時，進行性能分析
-
各個調用環節的可用性、梳理服務依賴關系以及優化
-
數據分析，優化鏈路：可以得到用戶的行為路徑，匯總分析應用在很多業務場景。
下面我們來看一個典型的分布式系統請求調用過程，如下圖所示：
-
分布式服務跟蹤系統的設計
-
分布式服務跟蹤系統設計目標
低入侵性，應用透明：即作為也業務組件，應當盡可能少入侵或者無入侵其他業務系統，對於使用方透明，減少開發人員的負擔。
低損耗：服務調用埋點本身會帶來性能損耗，這就需要調用跟蹤的低損耗，實際中還會通過配置采樣率的方式，選擇一部分請求去分析請求路徑。
大范圍部署，擴展性：作為分布式系統的組件之一，一個優秀的調用跟蹤系統必須支持分布式部署，具備良好的可擴展性。
-
埋點與生成日志
埋點即系統在當前節點的上下文信息，可以分為客戶端埋點、服務端埋點，以及客戶端和服務端雙向型埋點。埋點日志通常要包含以下內容traceId、spanId、調用的開始時間，協議類型、調用方ip和端口，請求的服務名、調用耗時，調用結果，異常信息等，同時預留可擴展字段，為下一步擴展做准備；
-
收集和存儲日志（主要支持分布式日志采集的方案，同時增加MQ作為緩沖）
-
分析和統計調用鏈路數據，以及時效性
-
展現以及決策支持
二、分布式服務跟蹤：
SpringCloudSleuth
-
快速入門
在引入Sleuth之前，我們需要做一些准備工作，具體如下所示：
-
服務注冊中心（eureka-server）
-
微服務應用分別為trace1和trace2（它們都有一個REST接口，其中trace1通過RestTemplate調用trace2的REST接口）
微服務應用trace1和trace2項目基本一樣（除配置端口、應用名稱和REST的Path），以trace1為示例：
-
pom.xml文件增加依賴（如下所示）
-
主要代碼：
-
配置文件
-
運行結果，日志沒有沒有跟蹤信息
我們在瀏覽器或者postman通過http：//localhost:8080/trace1,可以返回trace2相應接口的內容，同時我們看到控制台並沒有跟蹤信息打印，微服務應用trace1和trace2的日志信息具體如下圖所示：
-
添加跟蹤依賴 ，日志信息存在跟蹤信息
如何為上面的trace1和trace2添加服務跟蹤功能呢？SpringCloudSleuth對於此進行封裝，使得我們為應用增加服務跟蹤能力的操作非常簡單，滿足前面所說設計目標（低入侵，應用透明），只需在trace1和trace2的pom.xml依賴管理中增加Spring-cloud-starter-sleuth依賴即可，具體如下所示：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
添加sleuth依賴后，分別重啟trace1和trace2，再次通過瀏覽器或者postman調用http：//localhost:8080/trace1,可以返回trace2相應接口的內容，同時我們看到控制台日志已經存在跟蹤信息，微服務應用trace1和trace2的日志信息具體如下圖所示：
從上面的控制台輸出內容中，我們看到多出了一些形如[trace1,454445a6a7d9ea44,912a7c66c17214e0,false]的日志信息，而這些元素正是實現分布式服務跟蹤的重要組成部分，它們的含義分別如下所示：
第一個值：trace1，它表示應用的名稱，也就是配置文件spring.application.name的值。
第二個值：454445a6a7d9ea44，它是SpringCloudSleuth生成的一個ID，稱為Trace ID，它用來標識一條請求鏈路，一條請求鏈路中包含一個Trace ID，多個Span ID。
第三個值：912a7c66c17214e0，它是SpringCloudSleuth生成的另外一個ID，稱為Span ID，它表示一個基本的工作單元，比如發送一個http請求。
第四個值：false，表示是否要將該信息輸出到Zipkin等服務中來收集和展示。
上面四個值中的Trace ID 和Span ID是SpringCloudSleuth實現分布式服務跟蹤的核心。在一次服務請求鏈路的調用過程中，會保持並傳遞同一個Trace ID，從而將整個分布於不同微服務進程中的請求跟蹤信息串聯起來。例如，在一次前端請求鏈路中，上面trace1和trace2的Trace ID是相同的。
-
跟蹤原理
分布式服務跟蹤系統主要包括下面三個關鍵點：
（1）Trace：它是由一組有相同Trace ID的Span串聯形成一個樹狀結構。為了實現請求跟蹤，當請求請求到分布式系統的入口端點時，只需要服務跟蹤框架為該請求創建一個唯一的跟蹤標識（即前文提到的Trace ID），同時在分布式系統內部流轉的時候，框架始終保持傳遞該唯一標識，直到返回請求為止，我們通過它將所有請求過程中的日志關聯起來；
（2）Span：它代表了一個基礎的工作單元，例如服務調用。為了統計各處理單元的時間延遲，當前請求到達各個服務組件時，也通過一個唯一標識（即前文提到的Span ID）來標記它的開始、具體過程以及結束。通過span的開始和結束的時間戳，就能統計該span的時間延遲，除此之外，我們還可以獲取如事件名稱、請求信息等元數據。
（3）Annotation：它用於記錄一段時間內的事件。內部使用的最重要的注釋是：
-
cs （Client Send）：客戶端發出請求，為開始跨度
-
sr （Server Received）：服務器已收到請求並開始處理。timestampsr - timestampcs =網絡延遲。
-
ss （Server Send）：服務器處理完畢准備發送到客戶端。timestampss - timestampsr =服務器上的請求處理時間。
-
cr （Client Received）：客戶端接收到服務器響應，為跨度結束。客戶端已成功接收到服務器的響應。timestampcr - timestampcs =請求的總時間。
以下是在使用Sleuth的兩個微服務之間的調用中請求的行為方式，除了生成唯一標識符並將其添加到應用程序日志之外，還需要在作為請求的一部分的微服務器之間正確傳播它們。
-
抽樣收集
我們在對接分析系統時就會碰到一個問題：分析系統在收集跟蹤信息的時候，需要收集多少跟蹤信息才合適呢？生產環境與開發環境跟蹤信息收集比例應該不一致，我們是否可以調整呢？同時，不同業務系統收集比例可能也不一樣。
理論上來說，我們收集的跟蹤信息越多就可以越好反映出系統的實際運行情況，並給出更精確的預警和分析。但在高並發的分布式系統運行時，大量的請求調用會產生海量的跟蹤日志信息，如果收集過多的跟蹤信息將會對整個分布式系統的性能造成一定的影響，同時保存大量的日志信息也需要不少的存儲開銷。所以，在Sleuth中采用了抽象收集的方式來跟蹤信息打上標記，也就是我們前面第四個布爾值，它代表了該信息是否要被后續的跟蹤信息收集器獲取和存儲。
默認情況下，Sleuth會使用PercentageBasedSampler實現的抽樣策略，以請求百分比的方式配置和收集跟蹤信息，默認值0.1（代表收集10%的請求跟蹤信息），可以通過配置spring.sleuth.sampler來修改收集的百分比。
-
與ELK整合
前面隨着已經有了跟蹤信息，但是由於日志文件都分布在各個服務實例的文件系統上，如果鏈路上服務比較多，查看日志文件定位問題是一件非常麻煩的事情，所以我們需要一些工具來幫忙集中收集、存儲和搜素這些跟蹤信息。引入基於日志的分析系統是一個不錯的選擇，比如ELK平台，SpringCloudSleuth在與ELK平台整合使用時，實際上只需要與負責日志收集的Logstash完成數據對接即可，所以我們需要為logstash准備Json格式的日志輸出（SpringBoot應用默認使用logback來記錄日志，而logstash自身也有對logback日志工具支持）。與ELK整合架構圖如下所示：
-
與Zipkin整合
雖然通過ELK平台提供的收集、存儲、搜索等強大功能，但是缺少對請求鏈路中各階段時間延遲的關注，而很多時候我們追溯請求鏈路的一個原因是為了找出整個鏈路中出現延遲過高的瓶頸源，或者找出問題服務實例等監控與時間消耗相關的需求，ELK就顯得乏力，反而引入Zipkin就能夠輕松解決。
Zipkin是Twitter的一個開源項目，它基於Google Dapper實現。我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據，並通過它提供的Rest API接口來輔助查詢跟蹤數據以分布式系統的監控程序，通過UI組件幫助我們及時發現系統中出現的延遲升高問題以及系統性能瓶頸根源。下面展示Zipkin的基礎架構，它主要由4個核心組件構成：
Collector（收集器組件）：主要負責收集外部系統跟蹤信息，轉化為Zipkin內部的Span格式。
Storage（存儲組件）：主要負責收到的跟蹤信息的存儲，默認為內存，同時支持存儲到Mysql、Cassandra以及Elasticsearch。
Restful API（API組件）：提供接口，方便外部系統進行集成。
Web UI（展示組件）：基於API開發的自帶展示界面，方便進行跟蹤信息的查看以及查詢，同時進行相關的分析。
與zipkin整合——HTTP收集
sleuth收集跟蹤信息通過http請求發送給zipkin server，zipkinserver進行跟蹤信息的存儲以及提供Rest API即可，Zipkin UI調用其API接口進行數據展示。其大體路流程如下圖所示：
代碼如何實現呢？主要有兩個部分：搭建Zipkin Server、為應用引入zipkin依賴和配置，具體如下所示：
（1）搭建Zipkin Server
添加Pom依賴
主要代碼
配置文件
（2）為應用引入zipkin依賴和配置
添加Pom依賴
為應用增加配置文件
啟動Zipkin Server以及分別重啟trace1和trace2，再次通過瀏覽器或者postman調用http：//localhost:8080/trace1,可以返回trace2相應接口的內容，同時我們看到控制台日志已經存在跟蹤信息，然后通過瀏覽器訪問http：//localhost:9411/,我們可以看到Zipkin對於跟蹤信息分析與展示，可以看到請求鏈路，以及每個span的具體耗時，就能分析進行鏈路優化、依賴分析等操作，其界面具體如下所示：
與zipkin整合——消息中間件收集
Spring Cloud Sleuth在整合Zipkin時，不僅實現了以Http的方式收集，還實現了通過消息中間件來對跟蹤信息進行異步收集。通過結合Spring Cloud Stream，我們可以非常輕松地讓應用客戶端將跟蹤信息輸出到消息中間件，同時Zipkin服務端從消息中間件上異步獲取這些跟蹤信息，具體如下所示：
代碼如何實現呢？主要有兩個部分：搭建Zipkin Server、為應用引入zipkin依賴和配置，具體如下所示：
（1）搭建Zipkin Server
添加Pom依賴
主要代碼（使用注解@EnableZipkinStreamServer）
配置文件
（2）為應用引入zipkin依賴和配置
添加Pom依賴
為應用增加配置文件
與Zipkin整合——數據存儲
默認情況下，Zipkin Server會將跟蹤信息存儲在內存中，但是這樣就會出現我們重啟Zipkin Server時之前收集的跟蹤信息丟失的問題。為了解決此問題，Zipkin提供了多種存儲方式，比如Mysql、Cassandra以及Elasticsearch，以Mysql為例，我們能夠很輕松地為Zipkin Server增加Mysql存儲功能。主要有三個步驟即可：第一步，在Mysql中創建數據庫並且運行其數據腳本；第二步，為pom添加數據庫依賴；第三步，修改配置更換存儲方式。更多內容請我另一篇博客《微服務之分布式跟蹤系統（springboot+zipkin）》。
（博客地址：http://blog.csdn.net/qq_21387171/article/details/53787019）
與Zipkin整合——API接口
Zipkin不僅提供了Web UI方便用戶進行跟蹤信息查看與查詢，同時還提供了Rest API，方便第三方系統進行集成進行跟蹤信息的展示和監控，其提供的API列表如下所示：
三、分布式服務跟蹤系統其他解決方案
OpenTracing通過提供平台無關、廠商無關的API，使得開發人員能夠方便的添加（或更換）追蹤系統的實現。 OpenTracing提供了用於運營支撐系統的和針對特定平台的輔助程序庫。下面為其相應的成員以及提供的產品：
分布式服務跟蹤系統其他解決方案：Jaeger
Jaeger（https://github.com/jaegertracing/jaeger）受到Dapper和Zipkin的啟發，從開始就建立了OpenTracing支持，是由Uber Technologies作為開源發布的分布式跟蹤系統。它可用於監控基於微服務的體系結構：分布式上下文傳播、分布式事務監控、根本原因分析、服務依賴性分析以及性能/延遲優化。其架構圖如下所示：
分布式服務跟蹤系統其他解決方案： Sky Walking
Skywalking （https://github.com/wu-sheng/sky-walking）全鏈路監控開源項目，也是唯一的國內團隊開源的APM監控項目。其架構圖如下所示：
最后，附上文章所講內容的源碼下載地址（源碼地址：https://github.com/dreamerkr/SpringCloudSleuthExample.git ），需要可以進行下載與交流。
https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660396033&idx=1&sn=e4274bb41d68633f1c4838b15ec14dc7&chksm=f7424ee7c035c7f1aa902a54d1dd53ca4d4084e3c08aec908b94eabc6b74839922dccc9be847&mpshare=1&scene=1&srcid=0929y6Jby8qF8lKExFmexHzg#rd