微服务拆分：打造高性能、高扩展的未来架构

一、微服务介绍

二、主链路规划

2.1 业务完整性

2.2 转化率重因子

2.3 流量端占比

2.4 现金水库

三、如何识别主链路

3.1 导流端

3.2 转化端

3.3 漏斗中部：订单转化

3.4 漏斗底部：下单

四、总结

一、微服务介绍

单体应用将所有的功能都维护在一个巨无霸的服务中，然后打包成一个 war 包扔到 Tomcat中运行，对外提供服务。单体应用存在很多问题，比如开发中互相干扰、沟通成本高、无法快速迭代、无法单独回滚等。

由于单体服务存在很多问题，计算机中的分治思想就产生了作用，将单体应用拆分成比较小的服务，分开维护。

微服务拆分后每个服务可以单独部署、单独测试、单独发布回滚，并借助Docker和CI/CD(持续集成)完成快速上线。

微服务拆分的合理性很大程度上决定了整个业务链路的可用性。在微服务拆分的过程中，首要的任务是识别出核心服务，那么核心服务为何如此重要。

如果能精准识别核心服务场景，将这些核心服务拆分成独立的微服务模块，就可以在核心服务链路上构建核心服务与边缘服务之间的隔离带，在极端洪峰流量场景下保证核心业务的高可用。

如何识别核心服务场景呢？采用：主链路规划，帮我们识别出核心服务。

二、主链路规划

所谓主链路，就是“保证业务可用性的核心链路”，那什么样的业务场景才能入围核心链路呢？如果拿出一个复杂的业务系统，把其中所有的业务场景铺开，让你选出哪些是“核心链路”，在按重要程度排个序，还真不知道如何下手。

是否有一套简单易用的理论模型，帮我们在复杂的业务场景中识别其中的主链路？这个可以有，在长期的实践中总结了主链路的几个特征。

业务完整性
转化率重因子
流量端占比
现金水库

2.1 业务完整性

入围主链路的一个最重要的评选条件就是要具备“业务完整性”，用网购下订单为例来理解一下“业务完整性”的意思。

一个商品下单的业务流程，首先需要去搜索商品，然后在商品列表页点击心仪商品进入到详情页，在详情页里有商品介绍、图片、买家评论等等，最后你要通过一键下单完成这笔订单。这个场景的业务目标是“完成订单”，为了达到这个目标，用户必须经过商品搜索、查看详情和一键下单这三个步骤，任意一个步骤出现故障都无法保证下单链路的“业务完整性”。

如果某个关键链路是保证业务完整性的必要环节，那么它当之无愧被选为核心主链路中的一员。在下单场景中，查看商品评论是一个辅助功能，即便出现了故障，也并不会对业务完整性造成明显的影响，也就被排除在了主链路之外。

2.2 转化率重因子

有一些业务场景，它们并非是保证业务完整性的必要条件，看似无关紧要，但是对业务转化率有重大影响，这类场景其实也是主链路规划中的常客。用一个购物的例子解释一下“转化率重因子”的重要性。

人们在淘宝买东西的时候通常会先看一下商品长什么样子再决定是否下单，商品图片都加载自“淘宝图片空间”，如果图片空间发生了故障，一定会大幅降低订单转化率。试想如果连图片都看不到，等同于开盲盒，没有人敢贸然下单吧？

因此，我们在做主链路规划的时候，也要把这类对业务转化率有重要影响的关键链路包含进去。

2.3 流量端占比

如果完成最终业务目标的途径有很多种，那么这所有的途径都是核心主链路吗？答案当然是否，能否入围主链路，还要看有多少用户流量通过这条路径完成了业务目标。如果两条路都能完成任务，那么哪条是主链路？自然是用户流量占比居多的链路。

在主链路规划中我们要参考各个链路和导流端的用户流量分布，将流量占比高的链路划分为主链路的一环。

2.4 现金水库

利润是公司业务的正向现金流，我们把这些提供正向现金流的业务叫做“现金水库”。现金水库是公司业务运转的源动力，尤其在电商行业更是如此，正向现金业务的故障通常会被定级为重大资损事件。因此，我们在做主链路规划的过程中，需要将现金水库类业务划归到主链路，保护现金流不受影响。

三、如何识别主链路

接下来基于一个真实的新零售业务的电商全链路场景，希望你可以举一反三，通过这个案例将主链路的知识点应用在自家公司的业务场景中。在开始之前，先学习一个用来分析业务场景的万金油模型 - 漏斗模型。我们通过漏斗模型将整个电商场景沙盘推演开来。

这是一个漏斗模型图，它用来描述用户从业务流入口到业务流终点的整个过程。我们把这个模型套用在电商的下单场景中，漏斗的上方部分是主搜、导购、商品详情页之类的场景，这是用户开始业务流的入口，承载着最多的用户访问流量；漏斗中间部分是订单转化的关键环节，购物车模块；漏斗最下方的部分是下单前的临门一脚，订单和支付模块。电商行业运营侧的漏斗模型相对会复杂很多，通常划分为用户获取、激活、留存、收益和传播等阶段，不过我这里把这个过程做了简化，我们只关注几个关键的环节就好了。

漏斗模型有三个特点：

QPS 递减：用户流量从漏斗上方到漏斗下方呈逐渐递减的趋势，对后台应用的 QPS（Query per second）也遵循同样的规律；
流量质量递增：业务转化率由上到下依次增加，漏斗底部的业务转化率最高；
主链路比例递增：越靠近漏斗底部，主链路服务的占比就越高。

3.1 导流端

漏斗顶部承载着用户导流和转化的双重任务，导流端主要负责将用户流量导入到商品详情页做进一步转化，常见的业务场景有站内主搜、站外短链、口令服务、类目渠道、直播转化等，这些场景都做了同一件事，那就是导流和获取用户。如果完成业务目标的途径有很多种，那么自然是流量占比越高的场景链路优先级越高。横向比对来看，在这个环节的主链路是站内主搜，它是流量占比最高的业务场景。

3.2 转化端

转化端的主要责任落在了商品详情页这里，回想以往的购物经验，详情页的主要功能有商品元数据的展示、SKU 模块、库存信息、用户评论、商品营销优惠信息、主图和视频空间、富文本 TFS 详情，以及一些锦上添花的小功能如用户画像推荐、热搜排行等。

作为转化端的重头戏，商品详情页的信息可谓是纷繁复杂。不过在双 11 大促之类的场景中，很多挂在详情页的边缘功能都会被主动降级，腾出服务器资源供到主链路服务中。

3.3 漏斗中部：订单转化

漏斗中部是购物车模块，承担着订单转化的重要环节，主链路模块所占的比例也随之提高。

从详情页到下单，在购物车场景中有这几类核心场景：添加 / 删除购物车商品、购物车商品列表、订单营销优惠信息、地址模块、导购模组（热卖、最近浏览、拼单立减等等）。

从转化率重因子的角度来看，有一个具备争议的功能点也被化为了主链路的一环，就是购物车内的营销优惠计算，它是营销优惠业务最后的导流环节，必须 0 故障显示出当前车内商品可以应用的优惠条件和扣减情况，否则极易让用户放弃下单。

为什么购物车内的营销优惠计算模块是主链路，而在转化端的商品详情页却不是呢？

这就涉及到一个“前端柔性”的话题了。商品详情页历来是 QPS 数一数二的业务场景，我们以淘系的 UMP 营销计算服务为例，每个商品详情页请求都需要调用 UMP 服务计算单品优惠信息，即便在双 11 这种堆缓存抗压的方式下，营销计算服务仍然面临很大的压力。当服务发生故障，优惠信息无法透传到详情页的时候，我们可以在页面显示一段类似“请到购物车查看最终优惠金额”的文字，引导用户添加购物车，继续向下走购物流程，这样一来，详情页上优惠计算服务的故障对业务转化率的影响就被降到了最低。这种方式就是“前端柔性方案”（也叫用户端柔性）。