在最初做trace系统的时候就想着要画一个NB的服务拓扑图，于是经过我们的努力，终于画了一个又酷、又炫、又骚气的图，就像下面这个样子：当然，这个图是有动态效果的，如下所示：要解决什么问题我们知道，微服务开发面临的一个很大的问题是服务数量的暴增，然后随之而来的是服务间混乱的调用关系和依赖管理，我们很难明确的知道自己的服务依赖了哪些服务或者被哪些服务依赖，自己提供的接口调用频率以及分别被哪些服务调用。如何思考解决这个问题其实，在文章的开始我们已经给出了这个问题的答案，那就是画一张描述服务关系的拓扑图，或者我们可以更形象的称之为“实时流量服务交通拓扑图”。同时，我们希望在这个图上能够尽可能的展示更多的细节，所以我们加了很多的动态效果，从当前的实现上来看，我们实现了如下的基础特性：根据节点图标的不同，可以知道分别是哪种类型的服务根据连线上点的移动方向可以知道调用与被调用的关系根据连线的颜色可以知道是否有异常出现根据连线的粗细可以知道通过的流量大小根据节点的大小，可以知道哪些是热点服务点击连线可以下探到具体的调用，精确到方法级别我们可以选择时间范围查看某个时间范围的真实接口请求统计数据，我们可以知道哪些服务是热点服务，哪些连线的流量比较大，哪些节点连线出现了异常，哪些节点连线出现了拥堵请求响应变慢了。那么这个图是怎么画出来的呢？最重要的当然是数据，巧妇难为无米之炊，没有数据我们很难实现上层的效果。那我们需要什么样的数据？如果要实现上面的目标，至少我们需要记录每个服务每个接口的调用情况，我们可以很容易地想到trace日志是可以满足我们的需求的，trace日志记录了每个请求详细的调用日志，而且可以跨系统，而一般的调用链系统也确实是基于trace日志来实现拓扑图的，比如zipkin、skywalking等，但是通常使用这个日志会有如下几个问题：trace日志通常非常大，所以通过这个日志计算关系非常的消耗内存和计算资源，所以zipkin写了一个spark的离线任务来处理，依然很慢很消耗资源。trace日志通常是采样输出的，所以我们不能精确获取某段时间两个节点之间的调用次数、成功次数等详细信息。所以，还有其他办法么？针对于trace日志量大，分析慢的问题，那么我们应该想到一种办法，可以用较少的数据量来分析，针对于trace日志采样的问题，我们需要找到一种办法使我们收集的数据不丢失信息。其实我们只需要基于trace日志做一些优化就可以了，基于本文提出的问题，我们的关注点在“关系”上，我们并不需要关心每一次详细的调用，我们可以只关心如下的基础信息：什么时间从A服务调用了B服务的T接口，本次调用的耗时，成功或失败的状态。由于我们关心的是统计数据，所以为了减少数据量，我们可以进一步将数据汇总变成一种Metric数据，比如如下格式：时间戳，源项目名，当前项目名，当前服务方法名，总调用次数，成功次数，请求body大小，返回body大小，耗时所以我们可以将trace系统的数据分成两类，一类是trace的调用链数据，一类是调用的metric数据，我们内部的分布式链路跟踪系统是基于 SOFATracer 构建的，它内部把这两种数据分别称为“摘要”日志和“统计”日志。SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。当然，我们内部基于SOFATracer做了一些改造，它原始的设计是每个组件打印的日志格式可以不一样，我们改成了所有组件打印一个统一格式的日志，这样做的好处是可以统一存储分析，简化了对数据的处理过程，使数据更方便使用，当然也牺牲了一些数据的优雅性。理论上，有了这个trace的Metric数据我们便可以最终画出上面的拓扑图了，这个地方我们使用了阿里的 G6 来实现前端的效果展示。G6 是一个简单、易用、完备的图可视化引擎，它在高定制能力的基础上，提供了一系列设计优雅、便于使用的图可视化解决方案。能帮助开发者搭建属于自己的图可视化、图分析、或图编辑器应用。G6 提供了很丰富的API接口来定制图的展示和交互效果，所以很适合用来画这种复杂的效果图。或许从一张大图上面显示所有的服务和项目会显得特别凌乱，我们还可以提供单个项目的依赖关系图，放到单服务的展现视图中去，比如下图是一个平台服务的依赖关系图。后记这篇文章没有给出太多的技术细节，主要是提供了一种解决问题的思路，其实实现起来并不是特别复杂，相信感兴趣的同学可以结合自己公司的技术现状实现自己的方案。