隨著多年微服務(wù)的發(fā)展，分布式追蹤系統(tǒng)已經(jīng)成為云原生技術(shù)棧中非常引人注目的一個(gè)領(lǐng)域。隨著該技術(shù)的出現(xiàn)，你可以非常容易的去定位分布式系統(tǒng)中潛在的一些問(wèn)題。在這篇文章之中，我會(huì)詳細(xì)為大家介紹什么是分布式追蹤系統(tǒng)，以及如何存儲(chǔ)分布式追蹤系統(tǒng)產(chǎn)生的數(shù)據(jù)。

　　我首先會(huì)沿著歷史的脈絡(luò)，介紹經(jīng)典的大數(shù)據(jù)方案來(lái)解決分布式追蹤系統(tǒng)的數(shù)據(jù)存儲(chǔ)與分析的問(wèn)題，而后會(huì)繼續(xù)分析目前業(yè)界常用的混合方案來(lái)解決相關(guān)問(wèn)題。最后面向未來(lái)，我將提出一種混合的一體化方案來(lái)解決此類(lèi)問(wèn)題。

　　什么是分布式追蹤系統(tǒng)

　　在我們正式介紹分布式追蹤系統(tǒng)之前，我們需要探究一下分布式對(duì)于整個(gè)業(yè)界到底意味著什么。我們可以下這樣一個(gè)矛盾的結(jié)論：分布式把事情變得非常的簡(jiǎn)單，同時(shí)也把它變得很復(fù)雜。我們聽(tīng)過(guò)越來(lái)越多的案例，在使用分布式系統(tǒng)之后，雖然整個(gè)系統(tǒng)看起來(lái)結(jié)構(gòu)清晰，路徑明確，并帶來(lái)了一定效率的提升。但越來(lái)越復(fù)雜的分布式結(jié)構(gòu)增加了系統(tǒng)的復(fù)雜程度，同時(shí)給運(yùn)維、管理、架構(gòu)等等幾乎所有方面帶來(lái)了非常大的挑戰(zhàn)。

　　我們傾向于將越來(lái)越多的組件引入到已經(jīng)很復(fù)雜的分布式系統(tǒng)之中來(lái)解決以上這些問(wèn)題。這些組件和管理它們的組件一起組成了更加復(fù)雜的分布式系統(tǒng)。這些系統(tǒng)最終會(huì)反噬我們，并給我們帶來(lái)意想不到的問(wèn)題。甚至于是非常重大的一些災(zāi)難。

　　如圖是一個(gè)典型的電商類(lèi)的系統(tǒng)。從這個(gè)結(jié)構(gòu)圖上看，這個(gè)系統(tǒng)東西向和南北向都是非常的復(fù)雜的。它由一個(gè)前端的系統(tǒng)來(lái)承接用戶(hù)的訪問(wèn)，其中包含了移動(dòng)端和瀏覽器過(guò)來(lái)的流量。這些流量通過(guò)API的網(wǎng)關(guān)到達(dá)了賬戶(hù)系統(tǒng)、庫(kù)存系統(tǒng)和快遞系統(tǒng)。前端系統(tǒng)同時(shí)與后端系統(tǒng)進(jìn)行相連，后端系統(tǒng)由各個(gè)子域所組成，它們共同構(gòu)成了一個(gè)非常復(fù)雜的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

　　在如此復(fù)雜的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，我們不能單單以傳統(tǒng)的運(yùn)維方案去做監(jiān)控，管理和觀測(cè)。而是需要引入一定的現(xiàn)代技術(shù)，特別是跟蹤技術(shù)，來(lái)將一條完整的調(diào)用鏈呈現(xiàn)到管理者和運(yùn)維者面前。

　　通過(guò)跟蹤技術(shù)，我們可以觀測(cè)到系統(tǒng)的兩個(gè)重要的指標(biāo)，一個(gè)是請(qǐng)求失敗，我們可以發(fā)現(xiàn)系統(tǒng)在哪個(gè)部分存在比較致命的問(wèn)題，鏈路從何處斷開(kāi)的。另一個(gè)就是延遲。它是無(wú)處不在的，即使你花費(fèi)巨大的代價(jià)，也不可以避免延遲。

　　現(xiàn)在，讓我們深入到追蹤系統(tǒng)的內(nèi)部，觀察追蹤數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。如圖所示追蹤系統(tǒng)所產(chǎn)生的是一些點(diǎn)，這些點(diǎn)可以代表一個(gè)時(shí)間片段，它的英文是Span。Span描述的就是一次調(diào)用所跨越的一個(gè)時(shí)間范圍。

　　那么Span與Span之間是組成一個(gè)這樣的樹(shù)形的結(jié)構(gòu)，這棵樹(shù)反映的是服務(wù)之間的一個(gè)調(diào)用過(guò)程。而另一張圖我們習(xí)慣于成為瀑布圖，它更加能夠反映Span之間的一個(gè)對(duì)應(yīng)關(guān)系。

　　它與樹(shù)型圖最顯著的區(qū)別是，瀑布圖可以體現(xiàn)Span之間的隸屬關(guān)系。我們看到其中 SpanA是一個(gè)父節(jié)點(diǎn)，其包含其他三個(gè)Span。而其他Span之間有一定的并行關(guān)系。我們從中可以看到SpanB與SpanC之間是并行的，與SpanD也是并行的。而SpanE與其他Span之間是個(gè)串行關(guān)系。這張圖不僅可以告訴我們Span之間的對(duì)應(yīng)關(guān)系，而且可以顯示這次調(diào)用它到底是一種并行調(diào)用還是串行調(diào)用。

　　既然Span是跟蹤系統(tǒng)的核心數(shù)據(jù)，同時(shí)這篇文章主要的目的是要探究如何去存儲(chǔ)跟蹤數(shù)據(jù)，那么探究如何去存儲(chǔ)Span就是我們需要研究的必要課題。

　　讓我們看看Span的一些具體結(jié)構(gòu)，經(jīng)典的Dapper論文所描述Span結(jié)構(gòu)包括SpanId，父SpanId，還有它的Trace Id。而后是一組labels，這是一些key-value結(jié)構(gòu)，類(lèi)似于我們傳統(tǒng)的數(shù)據(jù)表的一行數(shù)據(jù)，它與傳統(tǒng)數(shù)據(jù)表不同點(diǎn)是：傳統(tǒng)數(shù)據(jù)表的列是預(yù)定義的，而這種key-value結(jié)構(gòu)是根據(jù)數(shù)據(jù)動(dòng)態(tài)定義的，所以它的整個(gè)長(zhǎng)度是任意的，這一點(diǎn)對(duì)存儲(chǔ)來(lái)說(shuō)是比較大的挑戰(zhàn)。

　　另外Span中還要存儲(chǔ)一些非結(jié)構(gòu)化數(shù)據(jù)，所以它又帶有NoSQL數(shù)據(jù)的特點(diǎn)。同時(shí)它又具有典型的時(shí)間維度的特征，而這又是典型的時(shí)間序列數(shù)據(jù)的特點(diǎn)。這就是跟蹤數(shù)據(jù)的特點(diǎn)：一種混合的多模式結(jié)構(gòu)。

　　經(jīng)典的大數(shù)據(jù)存儲(chǔ)方案

　　經(jīng)典的跟蹤系統(tǒng)存儲(chǔ)其實(shí)就來(lái)自經(jīng)典的跟蹤系統(tǒng)論文：Dapper。這篇論文中還詳細(xì)描述了Google所采用的一種跟蹤系統(tǒng)的實(shí)現(xiàn)方案。這篇經(jīng)典論文不僅描述了經(jīng)典的以annotation為基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)，而且它同時(shí)還提出了使用BigTable來(lái)作為整個(gè)跟蹤系統(tǒng)的存儲(chǔ)底層。

　　既然提到了BigTable，那就讓我們一起去探究目前BigTable的一些特性，看看為什么早期的跟蹤系統(tǒng)采用這種存儲(chǔ)結(jié)構(gòu)。目前該產(chǎn)品已經(jīng)云化了，我們可以很容易的去購(gòu)買(mǎi)這個(gè)服務(wù)，去體驗(yàn)它的功能特性。

　　BigTable有三種比較主要的特性：

　　l 第一個(gè)它是NoSQL數(shù)據(jù)庫(kù)。在上一節(jié)中我們提到，由于跟蹤系統(tǒng)內(nèi)部存在著大量的非結(jié)構(gòu)數(shù)據(jù)，而這些數(shù)據(jù)來(lái)源于用戶(hù)自定義。這里的用戶(hù)其實(shí)包括兩類(lèi)，第一類(lèi)就是跟蹤系統(tǒng)的設(shè)計(jì)者，它會(huì)增加多種字段來(lái)構(gòu)成數(shù)據(jù)的底層。再此之上就是跟蹤系統(tǒng)的使用者，他們會(huì)根據(jù)自己的業(yè)務(wù)場(chǎng)景再添加另外一些動(dòng)態(tài)的字段進(jìn)來(lái)。故一個(gè)天然的NoSQL的非結(jié)構(gòu)化數(shù)據(jù)庫(kù)是對(duì)這種任意字段類(lèi)型的數(shù)據(jù)結(jié)構(gòu)是有益的。

　　l 第二個(gè)特性就是存儲(chǔ)要支持高吞吐。在一個(gè)微服務(wù)場(chǎng)景之中，每一個(gè)子Span的粒度是代表一個(gè)服務(wù)內(nèi)部的一個(gè)調(diào)用。但是這個(gè)調(diào)用可大可小，可以是對(duì)這個(gè)服務(wù)進(jìn)程的調(diào)用，也可以是進(jìn)程內(nèi)部一個(gè)函數(shù)的調(diào)用?？梢哉f(shuō)，一次外部的業(yè)務(wù)調(diào)用可以產(chǎn)生海量的跟蹤數(shù)據(jù)。這就是跟蹤系統(tǒng)面臨的典型挑戰(zhàn)—數(shù)據(jù)放大。跟蹤系統(tǒng)需要極大的帶寬，同時(shí)對(duì)延遲也有非常敏感。綜上，一個(gè)可以支持大數(shù)據(jù)的數(shù)據(jù)庫(kù)對(duì)跟蹤系統(tǒng)是非常有利的。

　　l 第三個(gè)特性性能線性增長(zhǎng)。由于業(yè)務(wù)系統(tǒng)是逐步接入到跟蹤系統(tǒng)之中的，就需要存儲(chǔ)方案支持系統(tǒng)平滑的提高吞吐量和存儲(chǔ)空間。不能因?yàn)樾聰?shù)據(jù)的接入，造成現(xiàn)有數(shù)據(jù)的寫(xiě)入和查詢(xún)出現(xiàn)性能的劇烈下降。

　　以上就是BigTable作為第一代非常經(jīng)典的分布式跟蹤存儲(chǔ)解決方案所提供的主要特性。

　　如圖所示一個(gè)跟蹤結(jié)構(gòu)是如何進(jìn)入到BigTable之中。第一個(gè)過(guò)程，跟蹤系統(tǒng)會(huì)生成一個(gè)本地的日志文件，日志文件包括了所有的Span，而后由一個(gè)搜集器將這些數(shù)據(jù)拉取到一個(gè)與之最近的BigTable節(jié)點(diǎn)之中。而后由Dapper的寫(xiě)入器，將數(shù)據(jù)寫(xiě)入到 Big Table的每個(gè)Cell中。其中，每行代表一個(gè)Trace ，也就是一次調(diào)用產(chǎn)生的全部Span可以一次性提取出來(lái)。

　　我們都知道BigTable是個(gè)商用的云數(shù)據(jù)庫(kù)。如果想自己去打造一個(gè)面向跟蹤場(chǎng)景的經(jīng)典存儲(chǔ)方案，開(kāi)源界也提供了有很多的選擇，比如說(shuō)Cassandra，HBase等。

　　但是經(jīng)典的分布式跟蹤系統(tǒng)非常大的問(wèn)題就是投入產(chǎn)出比較低。因?yàn)槲覀冎栏櫹到y(tǒng)屬于二線系統(tǒng)，也是監(jiān)控系統(tǒng)的一個(gè)延伸。雖然隨著微服務(wù)的產(chǎn)生，此類(lèi)系統(tǒng)的地位有了比較顯著的提高，但其重要性依然低于一線生產(chǎn)系統(tǒng)。

　　那么采用這種經(jīng)典的大數(shù)據(jù)方案的性?xún)r(jià)比是非常低的。你會(huì)投入很多的資源在跟蹤系統(tǒng)中，但是產(chǎn)生的效果并不能夠與你投入的資源相對(duì)稱(chēng)。甚至是說(shuō)你投入的非常多，產(chǎn)生效果是非常差的。這個(gè)時(shí)候你會(huì)對(duì)它的可用性和實(shí)際作用產(chǎn)生深深的懷疑。

　　現(xiàn)代的混合方案

　　這部分讓我們了解現(xiàn)代混合存儲(chǔ)方案。相比于傳統(tǒng)的大數(shù)據(jù)結(jié)構(gòu)，現(xiàn)代混合存儲(chǔ)結(jié)構(gòu)更強(qiáng)調(diào)于性?xún)r(jià)比和易用性。目前主流的有兩種典型的存儲(chǔ)方案：

　　第一種就是關(guān)系型數(shù)據(jù)庫(kù)，以MySQL為代表。

　　第二種就是搜索引擎，以ElasticSearch為主。

　　那么，首先讓我們了解一下MySQL。當(dāng)然這其中包括其他的一些關(guān)系型數(shù)據(jù)庫(kù)。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)是面向于查詢(xún)優(yōu)化的，所以它的寫(xiě)入性能相較于查詢(xún)性能是較低的。故傳統(tǒng)上它并不適合于做跟蹤類(lèi)的存儲(chǔ)方案。

　　但是我們可以把關(guān)系數(shù)據(jù)庫(kù)進(jìn)行一些改造。這里有兩個(gè)改造方面，第一點(diǎn)是使用一些Sharding中間件來(lái)增強(qiáng)MySQL吞吐量。如Apache ShardingSphere。

　　這樣就滿(mǎn)足了上文所提到的兩個(gè)關(guān)鍵點(diǎn)：高的吞吐和性能線性。

　　高吞吐很容易理解，這是sharding的主要策略。那么性能線性如何理解呢？

　　一個(gè)Trace 內(nèi)部的Span是有一定的關(guān)聯(lián)關(guān)系的，但是Trace 和Trace 之間是相對(duì)于獨(dú)立的。那么通過(guò)sharding策略，整體的數(shù)據(jù)會(huì)較為離散的。這就可以滿(mǎn)足對(duì)性能線性增長(zhǎng)的需求。因?yàn)槲覀冎烙绊憇harding效果的一個(gè)最重要的原因就是關(guān)系的耦合。如果數(shù)據(jù)之間關(guān)系特別的緊密，那么你很難做到數(shù)據(jù)寫(xiě)入性能的線性增長(zhǎng)。

　　最后，對(duì)于數(shù)據(jù)的任寫(xiě)入，我們可以通過(guò)預(yù)設(shè)冗余字段的方式來(lái)解決。當(dāng)然任意數(shù)據(jù)并不能像大數(shù)據(jù)的存儲(chǔ)方案一樣可以無(wú)限寫(xiě)入任意數(shù)據(jù)。但這種預(yù)設(shè)方案在性能上反而有更大的優(yōu)勢(shì)。

　　剛才提到了兩種增強(qiáng)關(guān)系數(shù)據(jù)結(jié)構(gòu)的方案，那么我們?yōu)槭裁匆欢ㄒx擇這種關(guān)系數(shù)據(jù)庫(kù)作為跟蹤數(shù)據(jù)的存儲(chǔ)方案呢？

　　第一點(diǎn)就是像這種數(shù)據(jù)庫(kù)有大量的dba支持。所以我們很容易的將它的性能提到一個(gè)非常驚人的地步。甚至于有一些組織，比如說(shuō)像TimeScale，就是利用關(guān)系數(shù)據(jù)庫(kù)來(lái)做時(shí)序數(shù)據(jù)庫(kù)的存儲(chǔ)跟蹤數(shù)據(jù)的。他們就是看中了這種關(guān)系數(shù)據(jù)庫(kù)優(yōu)秀的成熟度。

　　那么如果要用MySQL去存儲(chǔ)關(guān)系數(shù)據(jù)，需要做額外哪些調(diào)整呢？

　　l 第一點(diǎn)，增強(qiáng)寫(xiě)入性能。最簡(jiǎn)單的方式是要增加buffer的大小。同時(shí)，對(duì)數(shù)據(jù)庫(kù)Engine做一相關(guān)的優(yōu)化。比如增加buffer pool的一個(gè)大小，然后我們需要對(duì)數(shù)據(jù)塊的刷入策略進(jìn)行一些調(diào)節(jié)。

　　l 第二點(diǎn)，增加數(shù)據(jù)的生命周期管理功能。因?yàn)橐恍├蠑?shù)據(jù)會(huì)出現(xiàn)隨著時(shí)間的流逝而價(jià)值降低的現(xiàn)象。需要增加數(shù)據(jù)生命周期管理功能來(lái)釋放磁盤(pán)空間。

　　l 第三點(diǎn)，分離流量。因?yàn)槲覀儗?xiě)入量是巨大的，但讀取是相對(duì)少的。這與經(jīng)典的關(guān)系數(shù)據(jù)庫(kù)場(chǎng)景是非常不同的，我們需要把寫(xiě)入流量和讀取流量進(jìn)行分離，以免讀取流量影響寫(xiě)入流量。

　　第二個(gè)常用的存儲(chǔ)結(jié)構(gòu)也是搜索引擎。以Elasticsearch為代表的搜索引擎對(duì)于日志搜集有比較好的支持，所以有相當(dāng)一部分的跟蹤系統(tǒng)都會(huì)采用這種搜索引擎來(lái)存儲(chǔ)跟蹤數(shù)據(jù)。那么跟蹤數(shù)據(jù)本質(zhì)上與log是非常相似的。因?yàn)閘og具有體量巨大，字段任意等跟蹤數(shù)據(jù)的顯著特點(diǎn)。它唯一與跟蹤數(shù)據(jù)的區(qū)別是 log沒(méi)有很強(qiáng)的關(guān)聯(lián)性。故如Elasticsearch和Loki這類(lèi)系統(tǒng)都可以滿(mǎn)足存儲(chǔ)跟蹤數(shù)據(jù)的要求。

　　此類(lèi)數(shù)據(jù)庫(kù)具有兩個(gè)相對(duì)優(yōu)勢(shì)的特性：

　　l 第一，支持大量的非結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)。因?yàn)檫@種系統(tǒng)天生就是一個(gè)分布式數(shù)據(jù)庫(kù)，它不像關(guān)系數(shù)據(jù)庫(kù)需要一些中間件的加持。這種數(shù)據(jù)庫(kù)天然可以存儲(chǔ)大量的數(shù)據(jù)。而且他們對(duì)寫(xiě)入有特殊優(yōu)化，這樣就可以快速的存儲(chǔ)數(shù)據(jù)。

　　l 第二，高效的數(shù)據(jù)分析。數(shù)據(jù)之間的關(guān)系可以很容易的在此類(lèi)系統(tǒng)中進(jìn)行分析。因?yàn)樗鼊?dòng)態(tài)產(chǎn)生索引結(jié)構(gòu)，非常適合于這種交互式的跟蹤數(shù)據(jù)分析場(chǎng)景。

　　如果你要使用Elasticsearch來(lái)存儲(chǔ)跟蹤數(shù)據(jù)。需要進(jìn)行以下優(yōu)化：

　　l 第一，需要實(shí)時(shí)的監(jiān)控磁盤(pán)的使用情況。因?yàn)樗饕龑?xiě)到一定程度，Elastcsearch就會(huì)將一些索引轉(zhuǎn)化為只讀索引，這樣的話(huà)會(huì)導(dǎo)致你的最新的高價(jià)值數(shù)據(jù)寫(xiě)不進(jìn)去。

　　l 第二，由于你的寫(xiě)入量是非常大的，你要像關(guān)系數(shù)據(jù)庫(kù)一樣去增加它的Buffer，同時(shí)增加寫(xiě)入的隊(duì)列的大小。

　　l 第三，Elasticsearch是分布式的數(shù)據(jù)庫(kù)，它自帶數(shù)據(jù)復(fù)制的功能。但是對(duì)于跟蹤數(shù)據(jù)，數(shù)據(jù)復(fù)制往往是多余的。因?yàn)檫@是一個(gè)寫(xiě)多讀少的一個(gè)場(chǎng)景，所以你不需要通過(guò)副本來(lái)提高讀取性能。同時(shí)，跟蹤數(shù)據(jù)本身的價(jià)值也而且隨著時(shí)間流失而降低。故你也不需要對(duì)數(shù)據(jù)做高可用處理。綜合以上原因，經(jīng)典的優(yōu)化方案都會(huì)關(guān)閉它的復(fù)制功能。

　　以上就是兩種現(xiàn)代混合方案。之所以稱(chēng)為混合，就是當(dāng)代的跟蹤系統(tǒng)，如Apache SkyWalking，Zipkin等等都支持多種存儲(chǔ)方案。用戶(hù)必須根據(jù)自己的情況進(jìn)行選擇，且每個(gè)方案都各有利弊，而并沒(méi)有一個(gè)一勞永逸的一體化解決方案。

　　面向未來(lái)的一體化方案

　　至此我們探究了什么是分布式跟蹤系統(tǒng)，經(jīng)典的跟蹤系統(tǒng)數(shù)據(jù)存儲(chǔ)的方案，以及現(xiàn)代這種混合的跟蹤系統(tǒng)存儲(chǔ)方案。我們會(huì)發(fā)現(xiàn)目前并沒(méi)有一個(gè)非常完美的最佳實(shí)踐來(lái)解決跟蹤系統(tǒng)的存儲(chǔ)問(wèn)題。其主要原因就是并沒(méi)有一個(gè)專(zhuān)用的跟蹤系統(tǒng)存儲(chǔ)的引擎，來(lái)幫助我們?nèi)ネ瑫r(shí)解決那三個(gè)問(wèn)題。

　　本文介紹的每種方案實(shí)際上只僅僅解決了部分的問(wèn)題。傳統(tǒng)的經(jīng)典結(jié)構(gòu)，貌似解決了所有的問(wèn)題，但是其代價(jià)是非常高的。所以我們需要的一個(gè)最佳跟蹤系統(tǒng)存儲(chǔ)方案，除了典型的三個(gè)特點(diǎn)之外，還需要加上性?xún)r(jià)比這個(gè)非技術(shù)特性。只有高性?xún)r(jià)比的跟蹤系統(tǒng)方案才能在生產(chǎn)實(shí)踐中得到廣泛的使用。

　　除了性?xún)r(jià)比之外，另一個(gè)附加特性也就是自我運(yùn)維。跟蹤系統(tǒng)本質(zhì)是一個(gè)運(yùn)維工具，它的存儲(chǔ)系統(tǒng)如果需要運(yùn)維人員花費(fèi)更多的時(shí)間和精力來(lái)去管理和調(diào)優(yōu)，那么必然會(huì)降低系統(tǒng)的使用率。因?yàn)閷?zhuān)業(yè)的運(yùn)維人員不希望特別關(guān)心工具自身的運(yùn)維問(wèn)題。但跟蹤系統(tǒng)本身會(huì)產(chǎn)生大量的數(shù)據(jù)，造成它的維護(hù)難度并不亞于高流量的業(yè)務(wù)系統(tǒng)。所以一個(gè)典型的或完美的跟蹤系統(tǒng)存儲(chǔ)方案，要能夠去自動(dòng)識(shí)別和處理常見(jiàn)的運(yùn)維問(wèn)題，其最低限度是，保證系統(tǒng)能以一定的健康度來(lái)運(yùn)行，而不至于完全的掛掉。

　　所以我們寄望存在一個(gè)從底層開(kāi)始設(shè)計(jì)的面相跟蹤場(chǎng)景的數(shù)據(jù)庫(kù)。它應(yīng)該從數(shù)據(jù)結(jié)構(gòu)層到模型層完全按照跟蹤系統(tǒng)的特點(diǎn)進(jìn)行構(gòu)建的，并符合我們本文描述的此類(lèi)數(shù)據(jù)庫(kù)的所有特點(diǎn)。很慶幸的是在我們這個(gè)時(shí)代有越來(lái)越多的獨(dú)立的底層引擎所涌現(xiàn)出來(lái)，我們可以利用它們?nèi)?gòu)建這么一個(gè)數(shù)據(jù)庫(kù)，而不需要完全從0開(kāi)始。

　　同時(shí)由于RUM假說(shuō)的出現(xiàn)，我們可以采用不同的數(shù)據(jù)庫(kù)訪問(wèn)策略來(lái)實(shí)現(xiàn)跟蹤這個(gè)特定領(lǐng)域的數(shù)據(jù)庫(kù)。而這樣一款兼?zhèn)涓鞣N跟蹤數(shù)據(jù)存儲(chǔ)所需要特點(diǎn)的數(shù)據(jù)庫(kù)其實(shí)也正在路上。

　　作者：

　　高洪濤——美國(guó)servicemesh服務(wù)商tetrate創(chuàng)始工程師。原華為軟件開(kāi)發(fā)云技術(shù)專(zhuān)家，對(duì)云原生產(chǎn)品有豐富的設(shè)計(jì)，研發(fā)與實(shí)施經(jīng)驗(yàn)。對(duì)分布式數(shù)據(jù)庫(kù)，容器調(diào)度，微服務(wù)，ServicMesh等技術(shù)有深入的了解。前當(dāng)當(dāng)網(wǎng)系統(tǒng)架構(gòu)師，開(kāi)源達(dá)人，曾參與Elastic-Job等知名開(kāi)源項(xiàng)目。目前為Apache ShardingSphere和Apache SkyWalking核心貢獻(xiàn)者，參與該開(kāi)源項(xiàng)目在軟件開(kāi)發(fā)云的商業(yè)化進(jìn)程。