根据高楼老师《全链路压测实战30讲》中的核心链路一节，从架构的视角来梳理核心业务链路。
在完整的企业级系统中，业务逻辑非常复杂，为避免陷入技术细节，要从架构的视角来观察系统。架构和梳理核心链路有什么关系呢？因为链路在架构上画才能够清楚。
要梳理核心链路，得先知道什么是核心业务？核心业务满足两个特点：1) 用的多，2) 利润高。
“用的多”特点的业务
1) 对业务接口进行访问统计。根据访问的接口，来梳理对应的业务。
ps：个人理解，1) 项目上可以整理一个操作和接口对应的清单(操作和接口可能一对多)，根据接口的访问量，使用工具得出对应的操作列表。2) 此处的业务接口的访问统计，也是从外部访问的流量，而不是系统自动执行业务的流量。
2) 将梳理出来的业务链路，画到架构图中。
以生成订单的信息generateOrder为例，
/order/generateOrder接口调用了CartlemService和MemberService两个服务，业务链路可以画成如下
3) 借用工具在环境上生成真实的业务链路关系图
借用APM的SkyWalking得出更详细的链路图，这些链路图中可以看到相关的服务，包括数据库和缓存等等。当然也可以选择Zipkin来梳理链路图。
最后我们得出一个业务链路调用关系清单。
梳理核心链路，是有系统边界的，外部的系统调用可以通过测试桩模拟掉，能保证发送的请求和上传数据的正确性甚至满足压测能力。
总结
梳理核心业务链路，重点是一个业务涉及哪些服务，这些服务对应哪些技术组件，可以遵循以下思路：
1) 先画清楚架构图，架构图中包括哪些服务和组件。
2) 定义什么是核心业务，找到业务接口对应的操作清单。
3) 根据操作清单梳理调用链路，一个调用链路为了明确一个业务接口涉及的具体服务和组件。
4) 将核心业务对应的所有调用链路统计出来。
有待讨论的点
1) 怎么定义核心业务？本文是从业务接口访问量和利润比较高来定义核心业务。
还可能由产品的定位，用户使用量，某个领域的外场故障个数来决定是否是核心业务。
本文决定是否是核心业务的方法，可适用推广的产品类型待定，通过接口访问量并不一定准确。
2) 梳理调用链路，不一定所有产品都支持SkyingWalk和zipping。可以通过产品定义出核心业务，通过SE或开发输出的流程图来梳理核心链路。
网友评论