终于见到你了－－代码定义拓扑

业务拓扑视图是运维人的心病，想得到却又得不到！

前几周UC小伙伴跟我说，“老王，给你看两张图，看看你的心愿实现了”，发来看了之后，还是蛮激动的呢（文后放出）。

在日常的运维过程中，我们都知道拓扑视图非常重要，一度成为CMDB里面的必要功能，然后就业务拓扑视图的实现方法来说，无外乎以下几种：

1、人工维护拓扑

应该说目前大部分的方式都是如此，我们知道这种方式在一个频繁变更的业务架构中根本没法完成，因此也就形成一种怪圈－－这个数据价值很大，可就是维护不起来。这种靠人来闭环的维护就是徒劳，当一个系统中服务的数量越来越大的时候，这个维护就更痛苦了，完全是一种负担。

2、配置生成拓扑

这个要强烈依赖配置的标准化，否则生成的拓扑图也是没法看的，但这个拓扑图依然是两者服务组件之间的拓扑图，没法生成全局的拓扑图。

在早期的确吧所有的配置都标准化了，分成数据库服务／缓存类服务／外部系统配置服务／fdfs服务等等，根据这样的配置标准化，可以说生成组件之间的拓扑关系。

3、软件定义拓扑

既然大家都不愿意做，做不好，为什么不换一个思路呢？让运行的软件来告诉我们拓扑视图是什么样的？原理很简单，就是要Dev阶段多做一点工作就好了，把服务之间的访问关系从代码中上报上来，剩下的就是运维数据化平台的事情了。上报的数据结构如下：

至于上报的原理有两种，一种是异步调用本地的一个采集agent数据接口；另外一种是写日志，本地的采集agent主动去采集log日志。我的建议是前者，这样的话，可以做采样处理，同时降低IO消耗。

在早期我给大家讲数据化运维的时候，分享过一些图，展示我们实现了整个数据流染色，但当时没法给大家看更直观的数据表现，只能看到如下的效果图。

这张图可以看到服务的链路调用关系，这就是服务染色，一条完整的服务链路。

• 收益：这个服务链路的数据进一步加工，可以把业务拓扑自动生成出来；故障定位很容易，看一眼就知道哪儿出问题了。

这张图可以看到服务访问链路上每个接口的服务调用延时和正确率情况，服务监控多么简单啊。

• 收益：你可以做接口性能评估和接口的状态监测了。

正向统计和反向统计，可以看到一个服务的扇出是什么样的，也可以看到一个服务的扇人是什么样的。

• 收益：有了这两个数据，完全可以自动评估模块或者服务的重要性，未来和监控系统联动，自动生成服务告警等级，无须人工在cmdb维护等级。

这里需要增加一条，对于微服务来说，我想评估它的重要性和复杂度不应该由人来完成。早前有代码级的扇入和扇出静态评估机制，现在上升到微服务级别，用一种程序自动生成的机制，动态评估。

注：扇入：是指直接调用该模块的上级模块的个数；扇出：是指该模块直接调用的下级模块的个数。

接下来谈谈具体的实现吧

1、业界的方案

业界的最早期就是google的Dapper方案，后来twitter根据其论文做了一个开源实现zipkin。不再详细描述，大家可以找点信息看看。

2、UC的方案

首先声明，必须要有一个标准化的协议框架或者数据上报框架。前者确保所有的业务调用行为一致，染色流的数据生成机制也是一致的，否则各个产品线各自上报，成本高，效率低。我们的很多RPC请求都是标准的HTTP协议，其次我们封装了统一的调度框架－－HTTPSF（Http Service Framework）。下图显示了原始请求和sf请求的不同。

• 普通请求。普通请求产生的request 对象有个重要的问题，依赖的是底层DNS的能力，抛弃DNS的问题不说，DNS是轮询的机制，特别是内网出去的请求的，一定只能访问某个链路的地址，还造成请求不均衡。核心问题：当DNS出现问题的时候，必须要运维来解决，合理不？显然是不合理的。
• SF请求。我们把Request请求一分为二，分成服务名和接口名。服务名对应的是http请求中的域名，接口名对应的是URI。但是服务名的IP地址解析，是根据名字服务中心来完成。DNS的域名仅仅是为了放在Request请求的header的HOST中。如此便平滑的完成了就的HTTP调度方式切向了新的服务框架。服务的染色统一由SF框架在http header中完成，无须业务做任何改造！

其实数据还是那个数据，只不过数据重新做了可视化的呈现，便有了下面的服务拓扑图。有了这个服务拓扑视图之后，数据呈现的效果立马不同（可视化的魅力）。文章开始说的两张图如下：

这张图完整的展示了全局服务之间的依赖关系（线路），服务的健康状态（颜色），服务的重要性（线的多少和访问量）等等。当然有人说服务太多的，是不是没法看？是的。不过UI上是可以优化的，当你鼠标点击某个服务的时候，和这个访问无关的服务自动浅色处理就好了。

备注：我们把服务名和应用包的名称也统一了，这样便实现了运维从构建代码到打包到应用发布到服务运行到持续反馈都是一个完整的闭环。

这张图可以看出一个服务的访问出流向了哪些服务，服务访问之间的占比关系是什么样的，服务的健康状况是什么样的等等。在向下深入，可以到接口级别的访问关系，那就是更精确的访问展现。

3、优维的方案

同样，在优维的创业产品EasyOps的智能监控中也有实现（http://console.easyops.cn），体现在两个方面：一方面，我们把自身EasyOps平台所有的内部服务都抽象成名字服务，并且把其接口调用结果全部上报，对于PHP的调用，我们都封装成SO扩展，方便接入服务中心；其次我们还把这个服务能力抽象成一准标准的监控能力－－服务链路监控向客户提供，更是把它作为分布式系统的核心监控能力，一则去除日志监控带来的滞后性和高成本；其次让他产生更多的收益（如前文所述）。实现的界面如下：

其他详细界面，我就不贴了。

其实想法很简单，要把想法变成现实，运维人就需要一次煽风点火的行动，你需要把研发／架构／运维变成一致的行动。一句话：分布式系统需要新的思维和新的方法，对研发和运维都是如此！