再谈服务调用关系可视化实现(12.4)

对于端到端流程监控，跨系统的服务链监控，在前面已经谈过好几篇文章，也给出了基于我们当前Solr关键字搜索加提前的业务流程关系建模结合，来实现关键端到端业务流的可视化调用关系监控。但是这种方式最大的问题就是灵活性较弱，需要实现进行流程建模设计，然后才能给进行可视化的交互关系展现。

今天谈服务调用关系的可视化，重点就是希望对关键字搜索功能的查询结果进行服务调用关系的自动化关系图展现。基于这个我们可以搜索到类似的文章：

社交关系图依赖展现： https://ruby-china.org/topics/26502

通过D3-Force来实现关系图： https://my.oschina.net/apdplat/blog/2218945

服务链监控： https://blog.csdn.net/wangyangzhizhou/article/details/53844668

以上文章都给了很好的思路，回过来分析，对于服务链监控，我们需要的仅仅是节点+矢量依赖关系线条，通过节点来代表系统，通过线条来代表系统间交互的服务。因此实际这种关系图并不需要太多的复杂功能，只是最简单的关系图呈现即可。

基于我们这个需求，发现百度Echart的Simple Graph就能给满足我们的需求。节点和内容标签都可以定制，同时节点间支持前后关系的箭头线条，同时支持曲线弧度。对于节点本身也可以自己制定位置进行精确定位，这样方便我们根据某种规则自动进行关系图的可视化呈现和排版。

今天谈可视化呈现，需要的就是通过关键字搜索后，自动对关系图进行展示，而不需要做任何提前的流程模型建模和配置，完全根据关键字检索到的服务运行实例进行可视化关系图展示。基于这个思路，我们来看下自动关系图展示时候关键的业务逻辑实现。

1.确定要展现的节点

对于关键字搜索到服务运行实例结果，按服务运行时间先后关系进行排序，确定每个服务的消费方和提供方，消费方排前，提供方排后。那么整个计算结果可能是：

A-》B || B-》A || B-》C || C-》A || C-》D

对于已经在前面出现的节点，那么就在后续计算中去重。最终计算的节点顺序就是A->B->C->D

2. 根据服务关系来确定节点间的矢量箭头展示

在确定了显示的节点和前后排序后，可以对节点进行精确的位置固定，在固定后再来考虑矢量箭头的展示。比如上个例子可以看到，在A和B之间存在双向箭头，同时C存在返回A的逆向箭头。注意，当存在逆行箭头的时候都需要考虑增加箭头的弧度，以避免和正向箭头的显示出现重叠。

3. 线条的粗细和颜色展示

注意两个系统间同一个服务也可能出现在关键字检索后调用多次的情况，因此可以考虑通过线条的粗细来表示实际的调用次数，越粗线条代表调用次数和流量越大。其次我们可以考虑线条的颜色，即首先计算调用失败率的情况，线条颜色有一个从绿色色到红色的渐变过程，如果全部调用失败则是红色，全部调用成功为绿色。这样可以更加形象的展示调用效果。

另外对于节点的形状，涉及到edgeSymbol对象，但是根据文档来看，暂时没有看到如何对这个节点形状进行定制。在上面一篇服务链监控文章里面可以看到，对节点形状定制为矩形并在里面进行配图或文件，整个展示效果会更加形象。

通过这种方式，即可以基本实现基于关键字搜索的结果，对查询到的服务实例按前面讲到的规则进行自动化的服务调用关系图展现。同时可以参考前面一篇文章说法，同时对服务调用次数，平均时长，错误率等其他关键数据进行配合展示。

这种方法唯一的缺点就是，如果没有产生服务实例调用，那么就没有想过的业务系统节点和箭头展示。但是如果我们是提前进行了调用关系可视化流程建模，我们就可以将所有的调用关系提前展示出来，对于没有实例调用部分显示为灰色即可。这样可以更加完整的了解到整个跨系统的业务交互关系和跨系统业务交互进展情况。