普元推出DevOps系列課程，5分鐘秒懂一個(gè)知識(shí)點(diǎn)，戳“閱讀原文”充電5分鐘，掌握黑科技。

轉(zhuǎn)載本文需注明出處：微信公眾號(hào)EAWorld，違者必究。

隨著分布式服務(wù)架構(gòu)的流行，特別是微服務(wù)等設(shè)計(jì)理念在系統(tǒng)中的應(yīng)用，系統(tǒng)規(guī)模也會(huì)變得越來(lái)越大，各微服務(wù)間的調(diào)用關(guān)系也變得越來(lái)越復(fù)雜。通常一個(gè)由客戶端發(fā)起的請(qǐng)求在后端系統(tǒng)中會(huì)經(jīng)過(guò)多個(gè)不同的微服務(wù)調(diào)用來(lái)協(xié)同產(chǎn)生最后的請(qǐng)求結(jié)果。

在復(fù)雜的微服務(wù)架構(gòu)系統(tǒng)中，幾乎每一個(gè)前端請(qǐng)求都會(huì)形成一個(gè)復(fù)雜的分布式服務(wù)調(diào)用鏈路。那么就帶來(lái)一系列問(wèn)題，在業(yè)務(wù)規(guī)模不斷增大、服務(wù)不斷增多以及頻繁變更的情況下，如何快速發(fā)現(xiàn)問(wèn)題？如何判斷故障影響范圍？如何梳理服務(wù)依賴以及依賴的合理性？如何分析鏈路性能問(wèn)題以及實(shí)時(shí)容量規(guī)劃？面對(duì)上面這些問(wèn)題，Spring Cloud Sleuth提供了分布式服務(wù)跟蹤解決方案。?

目錄：

一、為什么需要以及什么是分布式服務(wù)跟蹤系統(tǒng)

二、分布式服務(wù)跟蹤：SpringCloudSleuth

三、分布式服務(wù)跟蹤系統(tǒng)其他解決方案

一、為什么需要以及什么是

分布式服務(wù)跟蹤系統(tǒng)

• 為什么需要分布式服務(wù)跟蹤系統(tǒng)

隨著分布式服務(wù)架構(gòu)的流行，特別是微服務(wù)等設(shè)計(jì)理念在系統(tǒng)中的應(yīng)用，業(yè)務(wù)的調(diào)用鏈越來(lái)越復(fù)雜。

可以看到，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)規(guī)模也會(huì)變得越來(lái)越大，各微服務(wù)間的調(diào)用關(guān)系也變得越來(lái)越復(fù)雜。通常一個(gè)由客戶端發(fā)起的請(qǐng)求在后端系統(tǒng)中會(huì)經(jīng)過(guò)多個(gè)不同的微服務(wù)調(diào)用來(lái)協(xié)同產(chǎn)生最后的請(qǐng)求結(jié)果，在復(fù)雜的微服務(wù)架構(gòu)系統(tǒng)中，幾乎每一個(gè)前端請(qǐng)求都會(huì)形成一個(gè)復(fù)雜的分布式服務(wù)調(diào)用鏈路，在每條鏈路中任何一個(gè)依賴服務(wù)出現(xiàn)延遲過(guò)高或者錯(cuò)誤都有可能引起請(qǐng)求最后的失敗。同時(shí)，缺乏一個(gè)自上而下全局的調(diào)用id，如何有效的進(jìn)行相關(guān)的數(shù)據(jù)分析工作？對(duì)于大型網(wǎng)站系統(tǒng)，如淘寶、京東等電商網(wǎng)站，這些問(wèn)題尤其突出。

• 什么是分布式服務(wù)跟蹤系統(tǒng)

分布式服務(wù)跟蹤是整個(gè)分布式系統(tǒng)中跟蹤一個(gè)用戶請(qǐng)求的過(guò)程（包括數(shù)據(jù)采集、數(shù)據(jù)傳輸、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析、數(shù)據(jù)可視化），捕獲此類跟蹤讓我們構(gòu)建用戶交互背后的整個(gè)調(diào)用鏈的視圖，這是調(diào)試和監(jiān)控微服務(wù)的關(guān)鍵工具。Spring Cloud Sleuth是Spring Cloud為分布式服務(wù)跟蹤提供的解決方案，有了它，我們可以：

• 提供鏈路追蹤，故障快速定位：可以通過(guò)調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯(cuò)誤信息。

• 可視化各個(gè)階段耗時(shí)，進(jìn)行性能分析

• 各個(gè)調(diào)用環(huán)節(jié)的可用性、梳理服務(wù)依賴關(guān)系以及優(yōu)化

• 數(shù)據(jù)分析，優(yōu)化鏈路：可以得到用戶的行為路徑，匯總分析應(yīng)用在很多業(yè)務(wù)場(chǎng)景。

下面我們來(lái)看一個(gè)典型的分布式系統(tǒng)請(qǐng)求調(diào)用過(guò)程，如下圖所示：

• 分布式服務(wù)跟蹤系統(tǒng)的設(shè)計(jì)

• 分布式服務(wù)跟蹤系統(tǒng)設(shè)計(jì)目標(biāo)

低入侵性，應(yīng)用透明：即作為也業(yè)務(wù)組件，應(yīng)當(dāng)盡可能少入侵或者無(wú)入侵其他業(yè)務(wù)系統(tǒng)，對(duì)于使用方透明，減少開(kāi)發(fā)人員的負(fù)擔(dān)。

低損耗：服務(wù)調(diào)用埋點(diǎn)本身會(huì)帶來(lái)性能損耗，這就需要調(diào)用跟蹤的低損耗，實(shí)際中還會(huì)通過(guò)配置采樣率的方式，選擇一部分請(qǐng)求去分析請(qǐng)求路徑。

大范圍部署，擴(kuò)展性：作為分布式系統(tǒng)的組件之一，一個(gè)優(yōu)秀的調(diào)用跟蹤系統(tǒng)必須支持分布式部署，具備良好的可擴(kuò)展性。

• 埋點(diǎn)與生成日志

埋點(diǎn)即系統(tǒng)在當(dāng)前節(jié)點(diǎn)的上下文信息，可以分為客戶端埋點(diǎn)、服務(wù)端埋點(diǎn)，以及客戶端和服務(wù)端雙向型埋點(diǎn)。埋點(diǎn)日志通常要包含以下內(nèi)容traceId、spanId、調(diào)用的開(kāi)始時(shí)間，協(xié)議類型、調(diào)用方ip和端口，請(qǐng)求的服務(wù)名、調(diào)用耗時(shí)，調(diào)用結(jié)果，異常信息等，同時(shí)預(yù)留可擴(kuò)展字段，為下一步擴(kuò)展做準(zhǔn)備；

• 收集和存儲(chǔ)日志（主要支持分布式日志采集的方案，同時(shí)增加MQ作為緩沖）

• 分析和統(tǒng)計(jì)調(diào)用鏈路數(shù)據(jù)，以及時(shí)效性

• 展現(xiàn)以及決策支持

二、分布式服務(wù)跟蹤：

SpringCloudSleuth

• 快速入門

在引入Sleuth之前，我們需要做一些準(zhǔn)備工作，具體如下所示：

• 服務(wù)注冊(cè)中心（eureka-server）

• 微服務(wù)應(yīng)用分別為trace1和trace2（它們都有一個(gè)REST接口，其中trace1通過(guò)RestTemplate調(diào)用trace2的REST接口）

微服務(wù)應(yīng)用trace1和trace2項(xiàng)目基本一樣（除配置端口、應(yīng)用名稱和REST的Path），以trace1為示例：

• pom.xml文件增加依賴（如下所示）

• 主要代碼：

• 配置文件

• 運(yùn)行結(jié)果，日志沒(méi)有沒(méi)有跟蹤信息

我們?cè)跒g覽器或者postman通過(guò)http：//localhost:8080/trace1,可以返回trace2相應(yīng)接口的內(nèi)容，同時(shí)我們看到控制臺(tái)并沒(méi)有跟蹤信息打印，微服務(wù)應(yīng)用trace1和trace2的日志信息具體如下圖所示：

• 添加跟蹤依賴 ，日志信息存在跟蹤信息

如何為上面的trace1和trace2添加服務(wù)跟蹤功能呢？SpringCloudSleuth對(duì)于此進(jìn)行封裝，使得我們?yōu)閼?yīng)用增加服務(wù)跟蹤能力的操作非常簡(jiǎn)單，滿足前面所說(shuō)設(shè)計(jì)目標(biāo)（低入侵，應(yīng)用透明），只需在trace1和trace2的pom.xml依賴管理中增加Spring-cloud-starter-sleuth依賴即可，具體如下所示：

<dependency>

?????????<groupId>org.springframework.cloud</groupId>

?????????<artifactId>spring-cloud-starter-sleuth</artifactId>

???? </dependency>

添加sleuth依賴后，分別重啟trace1和trace2，再次通過(guò)瀏覽器或者postman調(diào)用http：//localhost:8080/trace1,可以返回trace2相應(yīng)接口的內(nèi)容，同時(shí)我們看到控制臺(tái)日志已經(jīng)存在跟蹤信息，微服務(wù)應(yīng)用trace1和trace2的日志信息具體如下圖所示：

從上面的控制臺(tái)輸出內(nèi)容中，我們看到多出了一些形如[trace1,454445a6a7d9ea44,912a7c66c17214e0,false]的日志信息，而這些元素正是實(shí)現(xiàn)分布式服務(wù)跟蹤的重要組成部分，它們的含義分別如下所示：

第一個(gè)值：trace1，它表示應(yīng)用的名稱，也就是配置文件spring.application.name的值。

第二個(gè)值：454445a6a7d9ea44，它是SpringCloudSleuth生成的一個(gè)ID，稱為Trace ID，它用來(lái)標(biāo)識(shí)一條請(qǐng)求鏈路，一條請(qǐng)求鏈路中包含一個(gè)Trace ID，多個(gè)Span ID。

第三個(gè)值：912a7c66c17214e0，它是SpringCloudSleuth生成的另外一個(gè)ID，稱為Span ID，它表示一個(gè)基本的工作單元，比如發(fā)送一個(gè)http請(qǐng)求。

第四個(gè)值：false，表示是否要將該信息輸出到Zipkin等服務(wù)中來(lái)收集和展示。

?

上面四個(gè)值中的Trace ID 和Span ID是SpringCloudSleuth實(shí)現(xiàn)分布式服務(wù)跟蹤的核心。在一次服務(wù)請(qǐng)求鏈路的調(diào)用過(guò)程中，會(huì)保持并傳遞同一個(gè)Trace ID，從而將整個(gè)分布于不同微服務(wù)進(jìn)程中的請(qǐng)求跟蹤信息串聯(lián)起來(lái)。例如，在一次前端請(qǐng)求鏈路中，上面trace1和trace2的Trace ID是相同的。

• 跟蹤原理

分布式服務(wù)跟蹤系統(tǒng)主要包括下面三個(gè)關(guān)鍵點(diǎn)：

（1）Trace：它是由一組有相同Trace ID的Span串聯(lián)形成一個(gè)樹狀結(jié)構(gòu)。為了實(shí)現(xiàn)請(qǐng)求跟蹤，當(dāng)請(qǐng)求請(qǐng)求到分布式系統(tǒng)的入口端點(diǎn)時(shí)，只需要服務(wù)跟蹤框架為該請(qǐng)求創(chuàng)建一個(gè)唯一的跟蹤標(biāo)識(shí)（即前文提到的Trace ID），同時(shí)在分布式系統(tǒng)內(nèi)部流轉(zhuǎn)的時(shí)候，框架始終保持傳遞該唯一標(biāo)識(shí)，直到返回請(qǐng)求為止，我們通過(guò)它將所有請(qǐng)求過(guò)程中的日志關(guān)聯(lián)起來(lái)；

（2）Span：它代表了一個(gè)基礎(chǔ)的工作單元，例如服務(wù)調(diào)用。為了統(tǒng)計(jì)各處理單元的時(shí)間延遲，當(dāng)前請(qǐng)求到達(dá)各個(gè)服務(wù)組件時(shí)，也通過(guò)一個(gè)唯一標(biāo)識(shí)（即前文提到的Span ID）來(lái)標(biāo)記它的開(kāi)始、具體過(guò)程以及結(jié)束。通過(guò)span的開(kāi)始和結(jié)束的時(shí)間戳，就能統(tǒng)計(jì)該span的時(shí)間延遲，除此之外，我們還可以獲取如事件名稱、請(qǐng)求信息等元數(shù)據(jù)。

（3）Annotation：它用于記錄一段時(shí)間內(nèi)的事件。內(nèi)部使用的最重要的注釋是：

• cs （Client Send）：客戶端發(fā)出請(qǐng)求，為開(kāi)始跨度

• sr （Server Received）：服務(wù)器已收到請(qǐng)求并開(kāi)始處理。timestampsr - timestampcs =網(wǎng)絡(luò)延遲。

• ss （Server Send）：服務(wù)器處理完畢準(zhǔn)備發(fā)送到客戶端。timestampss - timestampsr =服務(wù)器上的請(qǐng)求處理時(shí)間。

• cr （Client Received）：客戶端接收到服務(wù)器響應(yīng)，為跨度結(jié)束。客戶端已成功接收到服務(wù)器的響應(yīng)。timestampcr - timestampcs =請(qǐng)求的總時(shí)間。

以下是在使用Sleuth的兩個(gè)微服務(wù)之間的調(diào)用中請(qǐng)求的行為方式，除了生成唯一標(biāo)識(shí)符并將其添加到應(yīng)用程序日志之外，還需要在作為請(qǐng)求的一部分的微服務(wù)器之間正確傳播它們。

• 抽樣收集

我們?cè)趯?duì)接分析系統(tǒng)時(shí)就會(huì)碰到一個(gè)問(wèn)題：分析系統(tǒng)在收集跟蹤信息的時(shí)候，需要收集多少跟蹤信息才合適呢？生產(chǎn)環(huán)境與開(kāi)發(fā)環(huán)境跟蹤信息收集比例應(yīng)該不一致，我們是否可以調(diào)整呢？同時(shí)，不同業(yè)務(wù)系統(tǒng)收集比例可能也不一樣。

理論上來(lái)說(shuō)，我們收集的跟蹤信息越多就可以越好反映出系統(tǒng)的實(shí)際運(yùn)行情況，并給出更精確的預(yù)警和分析。但在高并發(fā)的分布式系統(tǒng)運(yùn)行時(shí)，大量的請(qǐng)求調(diào)用會(huì)產(chǎn)生海量的跟蹤日志信息，如果收集過(guò)多的跟蹤信息將會(huì)對(duì)整個(gè)分布式系統(tǒng)的性能造成一定的影響，同時(shí)保存大量的日志信息也需要不少的存儲(chǔ)開(kāi)銷。所以，在Sleuth中采用了抽象收集的方式來(lái)跟蹤信息打上標(biāo)記，也就是我們前面第四個(gè)布爾值，它代表了該信息是否要被后續(xù)的跟蹤信息收集器獲取和存儲(chǔ)。

默認(rèn)情況下，Sleuth會(huì)使用PercentageBasedSampler實(shí)現(xiàn)的抽樣策略，以請(qǐng)求百分比的方式配置和收集跟蹤信息，默認(rèn)值0.1（代表收集10%的請(qǐng)求跟蹤信息），可以通過(guò)配置spring.sleuth.sampler來(lái)修改收集的百分比。

• 與ELK整合

前面隨著已經(jīng)有了跟蹤信息，但是由于日志文件都分布在各個(gè)服務(wù)實(shí)例的文件系統(tǒng)上，如果鏈路上服務(wù)比較多，查看日志文件定位問(wèn)題是一件非常麻煩的事情，所以我們需要一些工具來(lái)幫忙集中收集、存儲(chǔ)和搜素這些跟蹤信息。引入基于日志的分析系統(tǒng)是一個(gè)不錯(cuò)的選擇，比如ELK平臺(tái)，SpringCloudSleuth在與ELK平臺(tái)整合使用時(shí)，實(shí)際上只需要與負(fù)責(zé)日志收集的Logstash完成數(shù)據(jù)對(duì)接即可，所以我們需要為logstash準(zhǔn)備Json格式的日志輸出（SpringBoot應(yīng)用默認(rèn)使用logback來(lái)記錄日志，而logstash自身也有對(duì)logback日志工具支持）。與ELK整合架構(gòu)圖如下所示：

• 與Zipkin整合

雖然通過(guò)ELK平臺(tái)提供的收集、存儲(chǔ)、搜索等強(qiáng)大功能，但是缺少對(duì)請(qǐng)求鏈路中各階段時(shí)間延遲的關(guān)注，而很多時(shí)候我們追溯請(qǐng)求鏈路的一個(gè)原因是為了找出整個(gè)鏈路中出現(xiàn)延遲過(guò)高的瓶頸源，或者找出問(wèn)題服務(wù)實(shí)例等監(jiān)控與時(shí)間消耗相關(guān)的需求，ELK就顯得乏力，反而引入Zipkin就能夠輕松解決。

Zipkin是Twitter的一個(gè)開(kāi)源項(xiàng)目，它基于Google Dapper實(shí)現(xiàn)。我們可以使用它來(lái)收集各個(gè)服務(wù)器上請(qǐng)求鏈路的跟蹤數(shù)據(jù)，并通過(guò)它提供的Rest API接口來(lái)輔助查詢跟蹤數(shù)據(jù)以分布式系統(tǒng)的監(jiān)控程序，通過(guò)UI組件幫助我們及時(shí)發(fā)現(xiàn)系統(tǒng)中出現(xiàn)的延遲升高問(wèn)題以及系統(tǒng)性能瓶頸根源。下面展示Zipkin的基礎(chǔ)架構(gòu)，它主要由4個(gè)核心組件構(gòu)成：

Collector（收集器組件）：主要負(fù)責(zé)收集外部系統(tǒng)跟蹤信息，轉(zhuǎn)化為Zipkin內(nèi)部的Span格式。

Storage（存儲(chǔ)組件）：主要負(fù)責(zé)收到的跟蹤信息的存儲(chǔ)，默認(rèn)為內(nèi)存，同時(shí)支持存儲(chǔ)到Mysql、Cassandra以及Elasticsearch。

Restful API（API組件）：提供接口，方便外部系統(tǒng)進(jìn)行集成。

Web UI（展示組件）：基于API開(kāi)發(fā)的自帶展示界面，方便進(jìn)行跟蹤信息的查看以及查詢，同時(shí)進(jìn)行相關(guān)的分析。

與zipkin整合——HTTP收集

sleuth收集跟蹤信息通過(guò)http請(qǐng)求發(fā)送給zipkin server，zipkinserver進(jìn)行跟蹤信息的存儲(chǔ)以及提供Rest API即可，Zipkin UI調(diào)用其API接口進(jìn)行數(shù)據(jù)展示。其大體路流程如下圖所示：

代碼如何實(shí)現(xiàn)呢？主要有兩個(gè)部分：搭建Zipkin Server、為應(yīng)用引入zipkin依賴和配置，具體如下所示：

（1）搭建Zipkin Server

添加Pom依賴

主要代碼

配置文件

（2）為應(yīng)用引入zipkin依賴和配置

添加Pom依賴

為應(yīng)用增加配置文件

啟動(dòng)Zipkin Server以及分別重啟trace1和trace2，再次通過(guò)瀏覽器或者postman調(diào)用http：//localhost:8080/trace1,可以返回trace2相應(yīng)接口的內(nèi)容，同時(shí)我們看到控制臺(tái)日志已經(jīng)存在跟蹤信息，然后通過(guò)瀏覽器訪問(wèn)http：//localhost:9411/,我們可以看到Zipkin對(duì)于跟蹤信息分析與展示，可以看到請(qǐng)求鏈路，以及每個(gè)span的具體耗時(shí)，就能分析進(jìn)行鏈路優(yōu)化、依賴分析等操作，其界面具體如下所示：

與zipkin整合——消息中間件收集

Spring Cloud Sleuth在整合Zipkin時(shí)，不僅實(shí)現(xiàn)了以Http的方式收集，還實(shí)現(xiàn)了通過(guò)消息中間件來(lái)對(duì)跟蹤信息進(jìn)行異步收集。通過(guò)結(jié)合Spring Cloud Stream，我們可以非常輕松地讓應(yīng)用客戶端將跟蹤信息輸出到消息中間件，同時(shí)Zipkin服務(wù)端從消息中間件上異步獲取這些跟蹤信息，具體如下所示：

代碼如何實(shí)現(xiàn)呢？主要有兩個(gè)部分：搭建Zipkin Server、為應(yīng)用引入zipkin依賴和配置，具體如下所示：

（1）搭建Zipkin Server

添加Pom依賴

主要代碼（使用注解@EnableZipkinStreamServer）

配置文件

（2）為應(yīng)用引入zipkin依賴和配置

添加Pom依賴

為應(yīng)用增加配置文件

與Zipkin整合——數(shù)據(jù)存儲(chǔ)

默認(rèn)情況下，Zipkin Server會(huì)將跟蹤信息存儲(chǔ)在內(nèi)存中，但是這樣就會(huì)出現(xiàn)我們重啟Zipkin Server時(shí)之前收集的跟蹤信息丟失的問(wèn)題。為了解決此問(wèn)題，Zipkin提供了多種存儲(chǔ)方式，比如Mysql、Cassandra以及Elasticsearch，以Mysql為例，我們能夠很輕松地為Zipkin Server增加Mysql存儲(chǔ)功能。主要有三個(gè)步驟即可：第一步，在Mysql中創(chuàng)建數(shù)據(jù)庫(kù)并且運(yùn)行其數(shù)據(jù)腳本；第二步，為pom添加數(shù)據(jù)庫(kù)依賴；第三步，修改配置更換存儲(chǔ)方式。更多內(nèi)容請(qǐng)我另一篇博客《微服務(wù)之分布式跟蹤系統(tǒng)（springboot+zipkin）》。

（博客地址：http://blog.csdn.net/qq_21387171/article/details/53787019）

與Zipkin整合——API接口

Zipkin不僅提供了Web UI方便用戶進(jìn)行跟蹤信息查看與查詢，同時(shí)還提供了Rest API，方便第三方系統(tǒng)進(jìn)行集成進(jìn)行跟蹤信息的展示和監(jiān)控，其提供的API列表如下所示：

三、分布式服務(wù)跟蹤系統(tǒng)其他解決方案

OpenTracing通過(guò)提供平臺(tái)無(wú)關(guān)、廠商無(wú)關(guān)的API，使得開(kāi)發(fā)人員能夠方便的添加（或更換）追蹤系統(tǒng)的實(shí)現(xiàn)。 OpenTracing提供了用于運(yùn)營(yíng)支撐系統(tǒng)的和針對(duì)特定平臺(tái)的輔助程序庫(kù)。下面為其相應(yīng)的成員以及提供的產(chǎn)品：

分布式服務(wù)跟蹤系統(tǒng)其他解決方案：Jaeger

Jaeger（https://github.com/jaegertracing/jaeger）受到Dapper和Zipkin的啟發(fā)，從開(kāi)始就建立了OpenTracing支持，是由Uber Technologies作為開(kāi)源發(fā)布的分布式跟蹤系統(tǒng)。它可用于監(jiān)控基于微服務(wù)的體系結(jié)構(gòu)：分布式上下文傳播、分布式事務(wù)監(jiān)控、根本原因分析、服務(wù)依賴性分析以及性能/延遲優(yōu)化。其架構(gòu)圖如下所示：

分布式服務(wù)跟蹤系統(tǒng)其他解決方案： Sky Walking

Skywalking （https://github.com/wu-sheng/sky-walking）全鏈路監(jiān)控開(kāi)源項(xiàng)目，也是唯一的國(guó)內(nèi)團(tuán)隊(duì)開(kāi)源的APM監(jiān)控項(xiàng)目。其架構(gòu)圖如下所示：

最后，附上文章所講內(nèi)容的源碼下載地址（源碼地址：https://github.com/dreamerkr/SpringCloudSleuthExample.git ），需要可以進(jìn)行下載與交流。

關(guān)于作者：

王召

現(xiàn)任普元信息資深開(kāi)發(fā)工程師，為普元新一代數(shù)字化企業(yè)云平臺(tái)開(kāi)發(fā)團(tuán)隊(duì)一員，負(fù)責(zé)新一代SPM（軟件產(chǎn)品管理）與MKT（軟件市場(chǎng)）領(lǐng)域系統(tǒng)的開(kāi)發(fā)。曾在百度西北營(yíng)銷自主研發(fā)中心、格林談?wù)効萍嫉然ヂ?lián)網(wǎng)公司從事開(kāi)發(fā)經(jīng)理工作，曾主導(dǎo)開(kāi)發(fā)過(guò)多款電商和社交項(xiàng)目，并獲得風(fēng)險(xiǎn)基金的投資。平時(shí)喜歡旅游，騎行，爬山等活動(dòng)。

關(guān)于EAWorld

微服務(wù)，DevOps，元數(shù)據(jù)，企業(yè)架構(gòu)原創(chuàng)技術(shù)分享，EAii（Enterprise?Architecture?Innovation?Institute）企業(yè)架構(gòu)創(chuàng)新研究院旗下官方微信公眾號(hào)。

微信號(hào)：eaworld，長(zhǎng)按二維碼關(guān)注

普元推出DevOps系列課程，5分鐘秒懂一個(gè)知識(shí)點(diǎn)，戳“閱讀原文”充電5分鐘，掌握黑科技↓↓↓