APM（应用性能管理）在中国前景如何

为了支撑日益增长的庞大业务量，微服务架构在业务系统中落地规模不断扩大，随着子系统不断拆分，整体业务上下游依赖和关联就会愈发复杂。

在这种背景下APM系统所关注的重点从单个系统的性能逐渐转向在微服务架构下整体系统可观测性。目前包括阿里、腾讯、网易在内的很多大厂内部都在使用APM系统，主要完成以下几个目标
1、服务依赖梳理
在业务系统越来越庞大的情况下，通过人工的方式很难完全整理清楚单个应用上下游的依赖情况，经常会出现在某个服务或接口出现变更的时候才会四面八方去寻找自己所依赖的上下游系统，更不用说梳理和掌握全局的服务依赖情况了。此时APM系统中全局拓扑分析的作用就体现出来了。
通过APM提供的全局拓扑分析，用户可以清晰的了解应用服务间调用关系，直观快速了解包括应用、DB、中间件等组件在内系统架构，并确定应用间流量分布情况。 根据链路拓扑可以确认服务间的依赖关系，识别潜在的故障点和性能瓶颈。
在获取到全局的依赖关系后，还可以通过依赖关系的数据进一步分析系统中各个微服务之间依赖是否合理，是否存在某些高优先级应用依赖低优先级的应用或者某些服务是否被其他服务强依赖，为后续的服务治理打好基础。

2、快速定位问题
随着服务调用链路越来越长，一旦异常出现，往往伴随着众多子系统异常联动，监控如何快速的发现、分析和定位问题变得更具有挑战性。在APM系统中通常会通过Trace的方式将众多的调用关联起来，一个Trace代表了一个事务或者流程在（分布式）系统中的执行过程。在OpenTracing标准中，Trace是多个span组成的一个有向无环图（DAG）

用户可以根据traceID查询到某次异常调用中具体的情况，包括有多少接口或中间件被调用了，调用的耗时是多少，调用在哪一步发生了错误，快速定位到出现问题的节点，简化排查流程。

3、全链路上下文传递
由于微服务中强调各个技术团队可以根据自己的偏好选择不同技术栈，于是系统中可能存在Java、Go、NodeJS、Python等不同语言构成的应用，各个应用功能完成自我闭环即可。但是在很多场景下需要将各个异构语言串联起来完成诸如全链路压测、AB测试、故障测试等功能，就需要有一种机制在异构的微服务之间传递一致的上下文。
在新一代的APM系统中一般都包括这样的上下文传递机制，如Opentrcing标准中定义的Baggage item会随着Trace在整个链路中传递上下文，在链路中每个微服务都会获取Baggage item并传递到下游。
通过全链路上下文传递，可实现各种维度的流量身份识别。除了常用的全链路压测、AB测试的场景，还可以通过上下文实现不同环境间动态路由，实现流量染色、测试环境治理的功能。
综上所述APM领域在可见的将来会有相当显著的变化，应用的领域也会越来越宽广。