# 04 | 核心链路：如何梳理符合真实业务场景的核心链路？

    你好，我是高楼。

上一讲，我给你展示了我认为一个完整的全链路压测方案应该具有的样子。在项目的选择上，我们使用的是开源微服务电商项目。这个项目采用的技术栈，是当前技术市场中流行的主流微服务技术栈，所以很可能对你也有借鉴意义。

这节课，我们还是用这个项目来讲讲，怎么梳理出符合真实业务场景的核心链路。

我们知道，在完整的企业级系统中，业务逻辑是非常复杂的。为了清晰地把业务实现到技术层面，就需要一层层地分析。

可是对一线做技术的人来说，这种做法常常会让人陷到细节里无法自拔，从而丧失全局观。所以，在做技术细节的同时，我们也很有必要再转换一下思维，从更全面的视角来观察系统。

再具体到全链路压测来看，因为我们面对的是一个完整而又复杂的线上系统，所以我们就要从架构的视角出发来分析业务链路。

不过提到架构，很多人对它并没有明确的概念，另一些人又觉得架构是个宏观的东西，无法把控。

## 从架构聊起

既然如此，我们就先来聊一聊，架构是个什么东西？

简单来说，架构就是一个系统的抽象描述，它包括系统中的组成元素以及元素与元素之间的关系。

既然是抽象，那不同的视角抽象出来的东西就不一样。像RUP 4+1视图，它就包括逻辑视图、开发视图、进程视图和物理视图，而场景则是用来描述他们之间的关系的。

在逻辑层面，我们经常聊到的业务架构、技术架构、部署架构等，这些都是架构的不同视角。

在实现层面，我们经常聊到的单体架构、SOA架构、微服务分布式架构、分层架构、微核架构、云架构等，这些都是从不同的技术层面来分类的。

上面说的都还只是架构的一些具体的分类。更系统地来看，技术发展到现在，已经把一个系统、完整的架构分为了四个大类，它们分别是：应用架构、技术架构、数据架构、安全架构。这是从不同的实现视角来承接业务架构的。但是这样的视角还必须落到系统中，还需要再细化到逻辑架构和物理层面，才可以最终落地。

讲了这么多架构的分类，你可能要问了，它和我们梳理业务核心链路有什么关系呢？其实讲这些是因为，链路要在架构上来画才能描述得更清楚。

那从哪种架构开始梳理业务链路更清楚呢。先来看一下，我们这个系统应用架构的逻辑图。

![](https://static001.geekbang.org/resource/image/46/32/46ae02d0f31af5831382216700a75632.jpg?wh=1920x1453)

像这种框框画出来的图，是不是让人看一眼大概就能知道里面有什么东西了？但这张图还没有表示出具体的部署情况。如果你觉得这个图不好看，我再放一个这样的图。

![图片](https://static001.geekbang.org/resource/image/2f/4b/2f032901efyy2d9f9e3df8f123e8534b.png?wh=1673x926)

这个图是不是看起来逻辑架构清晰一点了？这张图虽然看起来和上一张图差不多，都是一些小方框，但已经开始偏向部署视角了。不过，我还没有画出服务之间的关系。

我们再换一个视角。

![](https://static001.geekbang.org/resource/image/ab/9e/abd7df412998461cd240fe314104a99e.jpg?wh=1920x1590)

这样看起来是不是又清楚了一点？没错，这张图已经把部署视角很清晰地描绘出来了。

我这么详细地给你描述架构的不同视角，是希望你能够理解我下面的动作。我希望你能够分清楚各种不同架构的目的，因为只有理解架构才能理解链路。

## 梳理核心业务链路

但是，我们要梳理的是核心业务链路，上面的图却没有办法体现调用关系。那业务链路要怎么从这样的视角体现出来呢。

这时候我们就要祭出APM工具了。打个比方，对当前比较主流的微服务分布式架构来说，它的链路图是这样的。

![图片](https://static001.geekbang.org/resource/image/cf/74/cf08a14529f7a888a3ddb1348c9f1c74.png?wh=1920x1143)

在SOA架构的时代，链路图都是记在脑子里的。因为服务没有那么多，倒也记得住。但是在微服务架构中，你很难记得住那么多服务。为了更有条理地梳理核心链路，我们就要借助链路监控工具了。

只有链路图还不行，要想梳理核心业务链路，还得知道什么是核心业务。核心业务的特点其实主要就两个：一、用得多；二、利润高。

我们先看符合“用得多”这个特点的业务。

先做一个业务接口访问的统计。

![图片](https://static001.geekbang.org/resource/image/fa/b9/fa9716d8514b597995ba008cc3ebbeb9.png?wh=252x340)

截图中展示的是统计出来的业务接口，梳理下来就是这样的业务内容。

![](https://static001.geekbang.org/resource/image/ff/82/ffeb1ca2f370f317d671bfacb946b182.jpg?wh=1920x917)

知道了是哪些业务，关键的一步就来了：你要在架构图上画出对应的链路。

我们先拿生成订单信息（在这个系统中，这个接口是最复杂的）的这个接口来说。从接口路径/order/generateOrder上来看，显然是直接访问的order接口。我们来看一下这个接口的泳道图。

![图片](https://static001.geekbang.org/resource/image/8d/8e/8da29a39eda07e833760d8a95b41698e.png?wh=1920x2554)

这张图是不是乍一看相当复杂？但如果仔细分析一下，你会发现它清晰明了。

从泳道图上，你可以直观地看到和order直接相关的服务。因为这个图比较大，看不清楚，我们细看其中一段。

![图片](https://static001.geekbang.org/resource/image/ec/6e/ecf1d18ea4295f7411868ce89dfbe06e.png?wh=1023x730)

从细节图中可以看出，这个接口调用了Cart服务和Member服务。这样一来，这个链路就可以画成下面这样了。

![](https://static001.geekbang.org/resource/image/e2/b0/e2aabb4b9185d6f304ea73df5fb429b0.jpg?wh=1920x794)

如果接着往下分析，你就能知道这个接口调用的所有链路了。但是从代码中一点点去翻链路关系显然是不理智的，借助APM工具SkyWalking，我们就可以得到下面这样的图。

![图片](https://static001.geekbang.org/resource/image/c2/50/c2bf12532f7bd2caf09314bc0ee73a50.png?wh=1007x680)

具体用哪种APM工具你可以根据自己的习惯和需要来选，只要看到相应的结构即可。比如用Zipkin梳理出的链路图是这样的。

![图片](https://static001.geekbang.org/resource/image/28/d0/2861380c4fbda55d3bbfe14842c5a1d0.png?wh=1920x1043)

在这些链路图中，你可以看到所有相关的服务，包括数据库、缓存等。不过，直晃晃地给一个图出来，还是没有办法说明链路。你还要画出箭头表示调用方向。

![图片](https://static001.geekbang.org/resource/image/af/83/af9e53bb6c993852e5bbb377011f2683.jpg?wh=1920x1297)

为了配合上面泳道图中的内容，我只画了相关的服务。这样我们就有了一个接口的链路图了。

用这样的方法把所有的接口都梳理一遍，你会得到一组完整的调用链路关系。

![](https://static001.geekbang.org/resource/image/43/d3/438832ce2a5a276151917068d89480d3.jpg?wh=1920x1080)

这样，我们就把核心业务链路都罗列出来了。

对于有第三方调用的链路，你可以直接Mock。因为全链路压测中要屏蔽到第三方系统性能对自身系统的影响，在这一点上不用纠结。我看有些企业为了让全链路真的全起来，将第三方系统也纳入到了压测范围。从技术上说不是不可以，但是从协调上来说，就要考虑一下项目进度的风险和协调的难度了。

## 总结

好了，到这里，这节课的主要内容就讲完了。对于梳理核心业务链路来说，重点就是去看一个业务涉及到了哪些服务，这些服务又有哪些对应的技术组件。你可以遵照下面的思路：

*   先看架构图，看架构图是为了了解一个系统里有哪些具体的服务和组件。
*   再看调用链路，看调用链路是为了明确一个业务接口涉及到的具体服务和组件。
*   最后将所有流量大的业务接口统计出来，对应每一个业务接口梳理出调用链路。这样，我们就可以确定混合容量场景会涉及到的所有服务和组件了。

这些都是我们在后续的全链路压测过程中要重点关注的部分。

## 课后题

在结束今天的学习之前，我还给你留了两个小问题：

1.  你知道哪些确定业务接口的链路的方法？
2.  对不同的容量场景是否需要独立做业务统计？

欢迎你在留言区与我交流讨论，我们下节课再见！