基础设施 | Tony Bai

在“云”盛行的今天，分布式系统已不是什么新鲜的玩意儿。用脚也能想得出来：Google、baidu、淘宝、亚马逊、twitter等IT巨头背后的巨型计算平台都是分布式系统了，甚至就连一个简单的微信公众号应用的后端也都分布式了，即便仅有几台机器而已。分布式让系统富有弹性，面对纷繁变化的需求，可以伸缩自如。但分布式系统也给开发以及运维人员带来了难题：如何监控和优化分布式系统的行为。

以google为例，想象一下，用户通过浏览器发起一个搜索请求，Google后端可能会有成百上千台机器、多种编程语言实现的几十个、上百个应用服务开始忙碌起来，一起计算请求的返回结果。一旦这个过程中某一个环节出现问题/bug，那么查找和定位起来是相当困难的，于是乎分布式系统跟踪系统出炉了。Google在2010年发表了著名论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》(中文版在这里)。Dapper是google内部使用的一个分布式系统跟踪基础设施，与之前的一些跟踪系统相比，Dapper以低消耗、对应用透明以及良好的扩展性著称。并且 Google Dapper更倾向于性能数据方面的收集和调查，可以辅助开发人员和运维人员发现分布式系统的性能瓶颈并着手优化。Dapper出现后，各大巨头开始跟风，比如twitter的Zipkin（开源）、淘宝的“鹰眼”、eBay的Centralized Activity Logging (CAL)等，它们基本上都是参考google的dapper论文设计和实现的。

而本文将要介绍的Appdash则是sourcegraph开源的一款用Go实现的分布式系统跟踪工具套件，它同样是以google的 dapper为原型设计和实现的，目前用于sourcegraph平台的性能跟踪和监控。

一、原理

Appdash实现了Google dapper中的四个主要概念：

【Span】

Span指的是一个服务调用的跨度，在实现中用SpanId标识。根服务调用者的Span为根span（root span)，在根级别进行的下一级服务调用Span的Parent Span为root span。以此类推，服务调用链构成了一棵tree，整个tree构成了一个Trace。

Appdash中SpanId由三部分组成：TraceID/SpanID/parentSpanID，例如： 34c31a18026f61df/aab2a63e86ac0166/592043d0a5871aaf。TraceID用于唯一标识一次Trace。traceid在申请RootSpanID时自动分配。

在上面原理图中，我们也可以看到一次Trace过程中SpanID的情况。图中调用链大致是：

frontservice:
        call serviceA
        call serviceB
                call serviceB1
        … …
        call serviceN

对应服务调用的Span的树形结构如下：

frontservice: SpanId = xxxxx/nnnn1，该span为root span：traceid=xxxxx, spanid=nnnn1，parent span id为空。
serviceA: SpanId = xxxxx/nnnn2/nnnn1，该span为child span：traceid=xxxxx, spanid=nnnn2，parent span id为root span id:nnnn1。
serviceB: SpanId = xxxxx/nnnn3/nnnn1，该span为child span：traceid=xxxxx, spanid=nnnn3，parent span id为root span id:nnnn1。
… …
serviceN: SpanId = xxxxx/nnnnm/nnnn1，该span为child span：traceid=xxxxx, spanid=nnnnm，parent span id为root span id:nnnn1。
serviceB1: SpanId = xxxxx/nnnn3-1/nnnn3，该span为serviceB的child span，traceid=xxxxx, spanid=nnnn3-1，parent span id为serviceB的spanid：nnnn3

【Event】

个人理解在Appdash中Event是服务调用跟踪信息的wrapper。最终我们在Appdash UI上看到的信息，都是由event承载的并且发给Appdash Server的信息。在Appdash中，你可以显式使用event埋点，吐出跟踪信息，也可以使用Appdash封装好的包接口，比如 httptrace.Transport等发送调用跟踪信息，这些包的底层实现也是基于event的。event在传输前会被encoding为 Annotation的形式。

【Recorder】

在Appdash中，Recorder是用来发送event给Appdash的Collector的，每个Recorder会与一个特定的span相关联。

【Collector】

从Recorder那接收Annotation（即encoded event）。通常一个appdash server会运行一个Collector，监听某个跟踪信息收集端口，将收到的信息存储在Store中。

二、安装

appdash是开源的，通过go get即可得到源码并安装example：

go get -u sourcegraph.com/sourcegraph/appdash/cmd/…

appdash自带一个example，在examples/cmd/webapp下面。执行webapp，你会看到如下结果：

$webapp
2015/06/17 13:14:55 Appdash web UI running on HTTP :8700
[negroni] listening on :8699

这是一个集appdash server, frontservice, fakebackendservice于一身的example，其大致结构如下图：

通过浏览器打开:localhost:8700页面，你会看到appdash server的UI，通过该UI你可以看到所有Trace的全貌。

访问http://localhost:8699/，你就触发了一次Trace。在appdash server ui下可以看到如下画面：

从页面上展示的信息可以看出，该webapp在处理用户request时共进行了三次服务调用，三次调用的耗时分别为：201ms，202ms， 218ms，共耗时632ms。

一个更复杂的例子在cmd/appdash下面，后面的应用实例也是根据这个改造出来的，这里就不细说了。

三、应用实例

这里根据cmd/appdash改造出一个应用appdash的例子，例子的结构如下图：

例子大致分为三部分：
appdash — 实现了一个appdash server，该server带有一个collector，用于收集跟踪信息，收集后的信息存储在一个memstore中；appdash server提供ui，ui从memstore提取信息并展示在ui上供operator查看。
backendservices — 实现两个模拟的后端服务，供frontservice调用。
frontservice — 服务调用的起始端，当用户访问系统时触发一次跟踪。

先从backendservice这个简单的demo service说起，backendservice下有两个service: ServiceA和ServiceB，两个service几乎一模一样，我们看一个就ok了：

//appdash_examples/backendservices/serviceA.go
package main

import (
    "fmt"
    "net/http"
    "time"
)

func handleRequest(w http.ResponseWriter, r *http.Request) {
    var err error
    if err = r.ParseForm(); err != nil {
        fmt.Println("Http parse form err:", err)
        return
    }
    fmt.Println("SpanId =", r.Header.Get("Span-Id"))

time.Sleep(time.Millisecond * 101)
w.Write([]byte("service1 ok"))
}

func main() {
http.HandleFunc("/", handleRequest)
http.ListenAndServe(":6601", nil)
}

这是一个"hello world"级别的web server。值得注意的只有两点：
1、在handleRequest中我们故意Sleep 101ms，用来模拟服务的耗时。
2、打印出request头中的"Span-Id"选项值，用于跟踪Span-Id的分配情况。

接下来我们来看appdash server。appdash server = collector +store +ui。

//appdash.go
var c Server

func init() {
    c = Server{
        CollectorAddr: ":3001",
        HTTPAddr:      ":3000",
    }
}

type Server struct {
CollectorAddr string
HTTPAddr string
}

func main() {
    var (
        memStore = appdash.NewMemoryStore()
        Store    = appdash.Store(memStore)
        Queryer = memStore
    )

    app := traceapp.New(nil)
    app.Store = Store
    app.Queryer = Queryer

    var h http.Handler = app
    var l net.Listener
    var proto string
    var err error
    l, err = net.Listen("tcp", c.CollectorAddr)
    if err != nil {
        log.Fatal(err)
    }
    proto = "plaintext TCP (no security)"
    log.Printf("appdash collector listening on %s (%s)",
                c.CollectorAddr, proto)
    cs := appdash.NewServer(l, appdash.NewLocalCollector(Store))
    go cs.Start()

    log.Printf("appdash HTTP server listening on %s", c.HTTPAddr)
    err = http.ListenAndServe(c.HTTPAddr, h)
    if err != nil {
        fmt.Println("listenandserver listen err:", err)
    }
}

appdash中的Store是用来存储收集到的跟踪结果的，Store是Collector接口的超集，这个例子中，直接利用memstore(实现了 Collector接口)作为local collector，利用store的Collect方法收集trace数据。UI侧则从store中读取结果展示给用户。

最后我们说说：frontservice。frontservice是Trace的触发起点。当用户访问8080端口时，frontservice调用两个backend service：

//frontservice.go
func handleRequest(w http.ResponseWriter, r *http.Request) {
    var result string
    span := appdash.NewRootSpanID()
    fmt.Println("span is ", span)
    collector := appdash.NewRemoteCollector(":3001")

    httpClient := &http.Client{
        Transport: &httptrace.Transport{
            Recorder: appdash.NewRecorder(span, collector),
            SetName: true,
        },
    }

    //Service A
    resp, err := httpClient.Get("http://localhost:6601")
    if err != nil {
        log.Println("access serviceA err:", err)
    } else {
        log.Println("access serviceA ok")
        resp.Body.Close()
        result += "access serviceA ok\n"
    }

    //Service B
    resp, err = httpClient.Get("http://localhost:6602")
    if err != nil {
        log.Println("access serviceB err:", err)
        return
    } else {
        log.Println("access serviceB ok")
        resp.Body.Close()
        result += "access serviceB ok\n"
    }
    w.Write([]byte(result))
}

func main() {
http.HandleFunc("/", handleRequest)
http.ListenAndServe(":8080", nil)
}

从代码看，处理每个请求时都会分配一个root span，同时traceid也随之分配出来。例子中没有直接使用Recorder埋点发送event，而是利用了appdash封装好的 httptrace.Transport，在初始化httpClient时，将transport实例与span和一个remoteCollector想关联。后续每次调用httpClient进行Get/Post操作时，底层代码会自动调用httptrace.Transport的RoundTrip方法，后者在Request header上添加"Span-Id"参数，并调用Recorder的Event方法将跟踪信息发给RemoteCollector：

//appdash/httptrace/client.go
func (t *Transport) RoundTrip(req *http.Request) (*http.Response, error) {
    var transport http.RoundTripper
    if t.Transport != nil {
        transport = t.Transport
    } else {
        transport = http.DefaultTransport
    }

… …
req = cloneRequest(req)

    child := t.Recorder.Child()
    if t.SetName {
        child.Name(req.URL.Host)
    }
    SetSpanIDHeader(req.Header, child.SpanID)

e := NewClientEvent(req)
e.ClientSend = time.Now()

// Make the HTTP request.
resp, err := transport.RoundTrip(req)

    e.ClientRecv = time.Now()
    if err == nil {
        e.Response = responseInfo(resp)
    } else {
        e.Response.StatusCode = -1
    }
    child.Event(e)

return resp, err
}

这种方法在一定程度上实现了trace对应用的透明性。

你也可以显式的在代码中调用Recorder的Event的方法将trace信息发送给Collector，下面是一个fake SQLEvent的跟踪发送：

// SQL event
traceRec := appdash.NewRecorder(span, collector)
traceRec.Name("sqlevent example")

    // A random length for the trace.
    length := time.Duration(rand.Intn(1000)) * time.Millisecond
    startTime := time.Now().Add(-time.Duration(rand.Intn(100)) * time.Minute)
    traceRec.Event(&sqltrace.SQLEvent{
        ClientSend: startTime,
        ClientRecv: startTime.Add(length),
        SQL:        "SELECT * FROM table_name;",
        Tag:        fmt.Sprintf("fakeTag%d", rand.Intn(10)),
    })

不过这种显式埋点需要程序配合做一些改造。

四、小结

目前Appdash的资料甚少，似乎只是其东家sourcegraph在production环境有应用。在github.com上受到的关注度也不算高。

appdash是参考google dapper实现的，但目前来看appdash只是实现了“形”，也许称为神器有些言过其实^_^。

首先，dapper强调对应用透明，并使用了Thread LocalStorage。appdash实现了底层的recorder+event机制，上层通过httptrace、sqltrace做了封装，以降低对应用代码的侵入性。但从上面的应用来看，透明性还有很大提高空间。

其次，appdash的性能数据、扩展方案sourcegraph并没有给出明确说明。

不过作为用go实现的第一个分布式系统跟踪工具，appdash还是值得肯定的。在小规模分布式系统中应用对于系统行为的优化还是会有很大帮助的。

BTW，上述例子的完整源码在这里可以下载到。

生活中永远不缺少大道理，缺的是一颗善于思考和发现它们的心。
– Tony Bai

晚上回到家，家人端上来热腾腾的饭菜。吃了几口，感觉味道较为普通。盘子里那些被加工过的食材是昨天刚刚买到的，又好又新鲜。顿然一种可惜的赶脚油然而生。为什么这么上好新鲜的食材经过家人的烹制就变得这么普通了呢，仅仅是变成了充饥之用。而这些食材在大厨手下却能妙笔生花，做出让人流连忘返的精美菜肴。我不是很懂厨艺，但总觉的大厨烹制菜肴的过程与领导团队做一个项目或开发一款产品有着相似的内涵。小小厨房中蕴含着某些大道理，值得我在这里深思一番。

* 角色定义

既然将大厨烹制菜肴比作领导团队做事，那么我们先来熟悉一下厨房里的各个角色：

    厨房 – 工作间
    厨子 – Leader
    食材、调料 – 团队成员
    厨房用品 – 基础设施
    食客 – 使用者，客户
    营养、口感、档次 – 主要Feature
    味道 – 用户体验

任务目标 – 制作一道色香味俱佳的菜肴。

* 好厨善选材

选材是作出上好菜肴的关键。好厨都是善选材的，就好比好领导知道应该选择什么样的组员加入团队。

主食材（团队主力）决定菜肴的基本品质，比如：档次、外观、营养、口味等。

选择食材要主次分明，相辅相成。有红花争艳，也要有绿叶陪衬，否则烧成的菜品就会内斗严重，主次不明，类别不清，让人迷惑。

选择食材切忌相声相克。一旦这样，很可能会彻底毁掉这道菜。即便做成，也可能给食客带来损害。

调料，好比美工、前端设计师，专攻用户体验。虽然主食材实现了菜肴的核心营养和口感（核心Feature），但如果没有调料的作用，就缺少了味道这一决定性的用户体验。没有好的用户体验，结果一样是失败，至少产品或结果算不上一流。

* 火候儿甚重要

大厨的另外一个特长就是对烹饪过程中火候的把握极其到位。对于不同菜肴，不同食材，大厨会选择不同的火候烹制，让食材保持最佳状态，适当吸收汤汁味道。用错了火候，将是灾难性的。本该用文火慢炖入味的，却用了旺火，结果食不入味，对食客来说毫无吸引力；本来用旺火快速炒制的，却用了文武火，导致菜肴制作时间较长，营养成分流失。滥用火候甚至可能将食材烧焦烧糊，使得菜肴制作彻底失败。

这就好比团队Leader对团队工作节奏、进度以及压力的控制，要让团队成员在适宜的环境下发挥出最大的潜力、进行最高效的工作。过大的压力，过紧的进度都可能会压跨团队，无法达成团队目标。

* 装备，装备，事半功倍！

厨子烹制佳肴离不开厨房用具，虽说厨房用具的好坏对于菜肴的最终烹制结果不起决定性的作用，但精良全面的厨房用具会使得大厨烹制菜肴的过程事半功倍。

从古至今均有美酒佳肴，但非要论一下到底什么时候的菜更好吃，相信没人能给出结论，也许古代人做的菜更好吃也不一定。但能够确定的是现代大厨所使用的厨具肯定要比古代人更加齐全和精良，这使得现代人可以快速制作出大量精美的菜肴，可以在一定程度上缩短了菜肴制作的周期。通过这些现代化的厨具，可以更加精确量化菜肴的营养成分，也可以将菜肴的制作工序程式化，以供复用。

另外不同的厨师团队使用的装备各有不同，无所谓新老，找到最适宜的才是最好。

* 厨房里的创新

中华饮食文化源远流长，创新菜品层出不穷。从厨师的角度来看，这些创新无非是创新的食材、创新的调料以及创新的烹制方法。映射的团队管理来看，领导者应善于引进创新的人才，并敢于进行组织、管理以及过程方法创新，这样才能有创新的产品、创新的文化和氛围。