应用拓扑的特点
应用或服务级监控中有一个非常重要的概念–拓扑，拓扑反映了应用内多个服务之间的调用关系，这种拓扑与传统的网络拓扑存在明显区别，什么样的应用拓扑才是运维监控领域最有价值的拓扑呢？
传统网络拓扑的特点
- 节点间关系较为固定，变化的场景较少，只有在网络发生变更时才会出现变化
- 节点间的关系主要为两两之间的关系，由于拓扑关注的层面在网络层，基本不会关注事务在多台设备之间的流转，也就是说网络拓扑只关心两台设备之间的状态，而不会关心A设备发起的流量，在经过B设备后到达C设备的情况。简单来说，在应用流量存在A->B->C时，网络拓扑只会分别关心A->B和B->C的情况，而不会端到端的分析A->B->C的情况
- 也会有部分网络分析型工具（如NPM）会关心应用流量的端到端过程，但这种分析其实已经是应用和业务级别的了
应用拓扑需要满足的几个需求
- 与网络拓扑类似，反应节点间的调用关系，但需要注意的是这种关系可能变化比较频繁
- 与网络拓扑不同，需体现事务流在多个节点之间的流转，需端到端的体现业务的执行过程，而不仅仅是点到点之间的
- 除调用关系外，类似于网络流量，需体现调用次数、响应时间、错误率等指标
设计一个完善的应用拓扑
那么我们如何来设计一个完善的应用拓扑呢?在开始之前我们先分析几种各具特色的应用拓扑。
pinpoint应用拓扑
pinpoint应用拓扑
可以发现，pinpoint应用拓扑与网络拓扑类似，关注的仍旧只是点与点之间的关系，没有体现事务的端到端处理过程，举个例子，从这个拓扑图中我们无法了解由FRONT-WEB经BACKEND-API调用Mysql的情况，我们只知道Mysql被BACKEND-API调用了79次，而不知道这79次的业务来源是FRONT-WEB还是BACKEND-WEB。如果我们需要这种粒度的分析，pinpoint应用拓扑就不能帮助到我们了。但同时我们需要注意到，这种拓扑逻辑简单，用户学习成本非常低，符合用户的一般认知。
dynatrace应用拓扑
dynatrace应用拓扑
dynatrace应用拓扑
与pinpoint应用拓扑相比，dynatrace应用拓扑从外观上有一个很明显的区别，它不再像是一个“拓扑图”，而像是一个“流程图”，事实上这正是因为dynatrace应用拓扑以端到端体现业务执行过程为核心而做的颠覆性设计，从名称上它也不在将至称为“map”或“topo”，而是“serviceFlow”。dynatrace应用拓扑有如下几个重要特点：
- 拓扑内节点不是唯一的，我们从图中可以发现“easyTravelBusiness”和“JourneyService”出现了多次，它们其实是同一个应用服务，只是由于在调用过程中所处的位置不同而进行了区别
- 由于上一点的限制，拓扑内任何一个几点只会存在一个调用者，不会出现多个节点对应一个节点的情况，就像一条只会分叉而不会汇聚的水流
- 以上两点共同作用，使得你选择任何一个节点进行分析时都能准确的知道业务执行过程的来源和归宿，这对于应用级监控是很有价值的
- 在这个基础上，dynatrace甚至提供了事务过滤的功能，通过过滤可以快速掌握哪些具体事务经过了这样的调用过程，有助于异常问题的深入分析
两种方式的优劣对比
pinpoint应用拓扑和dynatrace应用拓扑代表了两种典型的拓扑逻辑，各有优劣：
| 类别 | pinpoint应用拓扑 | dynatrace应用拓扑 |
|---|---|---|
| 直观性 | 符合用户一般认知，学习成本非常低 | 逻辑略复杂，有一定的学习成本 |
| 端到端分析 | 很弱，仅能反映节点与节点之间的关系 | 强，便于分析完整的业务调用过程 |
| 事务快照下钻分析 | 很弱，仅能从应用服务级别跳转至对应的事务快照 | 强，能够在拓扑调用关系的基础上针对性查找符合特定调用逻辑的快照，易于深入分析与调用相关的异常现象 |
| 总览性 | 强，能够在一个拓扑内组合多个应用服务形成全局拓扑 | 弱，由于拓扑关系只能分叉不能汇聚的特性，不能简单的形成全局拓扑。每个拓扑都是以特定应用服务为入口，向后的调用过程分析。 |
综上，可以发现dynatrace这种类型的应用拓扑更加贴合应用或服务级监控，但其复杂度的提升导致其不适合简单的作为总览界面，如果采用该方式，仍需一个总览界面来全局的展示各个应用服务的整体状态。同时需要注意的是，dynatrace的这种应用拓扑大大增加了平台数据处理的复杂度，尤其是在数据量很大的情况下。
