你好，我是姚秋辰，今天想跟你聊聊主链路规划在微服务中的应用。
说起微服务改造，我们第一个想到的就是要对各个服务进行拆分，微服务拆分的合理性很大程度上决定了整个业务链路的可用性。在微服务拆分的过程中，我们的首要任务是识别出核心服务，那么核心服务为何如此重要呢？
如果把所有线上服务比喻为一个大军团，那么“核心服务”就是这个军团当中战斗力最强的精锐部队，是完成战略目标的攻坚力量。比如在双11这类大战役中，所有的后勤资源（虚拟机、磁盘、网络资源等）都要优先供给给精锐部队，保证整个军团的集体作战能力（业务高可用性）。
如果能精准识别核心服务场景，将这些核心服务拆分成独立的微服务模块，我们就可以在核心微服务链路上应用弹性机房水位调拨、流量整形和熔断降级等技术手段，构建核心服务与边缘服务之间的隔离带，在极端洪峰流量场景下保证核心业务的高可用性。
那如何才能识别核心服务场景呢？这就要讲到今天的主题：主链路规划。主链路规划是一种非常直观的方法论，帮助我们快速识别核心链路。今天我就来和你探讨两个“主链路规划”相关的话题：
所谓主链路，用一句话概括就是“保证业务可用性的核心链路”，那什么样的业务场景才能够入围核心链路呢？
如果我们拿出一个复杂的业务系统，把其中所有的业务场景铺开来，让你评选出哪些场景是“核心链路”，再按重要程度排个序，咱还真不知道如何下手。这场面就如同妈妈们聚在一起聊自家的娃，自说自话，都觉得自己的娃比别家的娃厉害。
如果能有一套简单易用的理论模型，帮助我们在纷繁复杂的业务场景中精准识别其中的主链路，岂不美哉？这个可以有，我们在长期的实践中总结了主链路的几个特征，可以帮助我们梳理、甄别核心链路。这四个特征分别是：
如果一个业务场景具备其中一个特征，那它就是主链路。具体怎么判断呢？接下来我们分别对这四个特征做个简单了解，再通过一个电商场景来做一个沙盘演练，学习如何运用这四个特征识别业务场景中的主链路。
入围主链路的一个最重要的评选条件就是要具备“业务完整性”，我们用网购下订单为例来理解一下“业务完整性”的意思。
我们拿一个商品下单的业务流程来说，首先你需要去搜索商品，然后在商品列表页点击心仪商品进入到详情页，在详情页里有商品介绍、图片、买家评论等等，最后你要通过一键下单完成这笔订单。这个场景的业务目标是“完成订单”，为了达到这个目标，用户必须经过商品搜索、查看详情和一键下单这三个步骤，任意一个步骤出现故障都无法保证下单链路的“业务完整性”。
如果某个关键链路是保证业务完整性的必要环节，那么它当之无愧被选为核心主链路中的一员。在下单场景中，查看商品评论是一个辅助功能，即便出现了故障，也并不会对业务完整性造成明显的影响，也就被排除在了主链路之外。
这就像我们通关RPG游戏一样，游戏里有主线任务也有支线任务，而“业务完整性链路”就是游戏的“主线任务”。支线任务失败会影响一部分游戏体验，但不会影响主线剧情；但主线任务过不去，那可真就卡在原地了。
有一些业务场景，它们并非是保证业务完整性的必要条件，看似无关紧要，但是对业务转化率有重大影响，这类场景其实也是主链路规划中的常客。我用一个购物的例子解释一下“转化率重因子”的重要性。
人们在淘宝买东西的时候通常会先看一下商品长什么样子再决定是否下单，商品图片都加载自“淘宝图片空间”，如果图片空间发生了故障，一定会大幅降低订单转化率。试想如果连图片都看不到，那网购的体验就像古代娶媳妇儿一样，等同于开盲盒，没有人敢贸然下单吧？
因此，我们在做主链路规划的时候，也要把这类对业务转化率有重要影响的关键链路包含进去。
正所谓条条大路通罗马，如果完成最终业务目标的途径有很多种，那么这所有的途径都是核心主链路吗？答案当然是No，能否入围主链路，还要看有多少用户流量通过这条路径完成了业务目标。
这就好比古代运送贡品进京一样，临安府县令此刻正站在杭州眺望北京，思考着该从哪条路线运送贡品。一条是顺着各地驿站蜿蜒进京，陆运费用昂贵而且耗时又长，还容易被山匪打劫，鲜有人走；另一条是顺着京杭大运河一路向北，水运费用低时间短，似乎是大部分纳贡队伍的首选方案。两条路都能完成任务，那么哪条是主链路？自然是用户流量占比居多的水路。
在主链路规划中我们要参考各个链路和导流端的用户流量分布，将流量占比高的链路划分为主链路的一环。
“你的梦想是什么？”在创业圈子里，投资人也经常发起类似的灵魂拷问：“你的商业模式是什么（你怎么赚钱）？”甭管多漂亮的业务模式，最终都要回到商业的本源：赚取利润。利润是公司业务的正向现金流，我们把这些提供正向现金流的业务叫做“现金水库”。
现金水库是公司业务运转的源动力，尤其在电商行业更是如此，正向现金业务的故障通常会被定级为重大资损事件。因此，我们在做主链路规划的过程中，需要将现金水库类业务划归到主链路，保护现金流不受影响。
在了解了主链路的四个特征之后，我带你做一个基于真实业务场景的沙盘演练，看如何将这些特点应用到主链路规划当中。
我们接下来的沙盘演练基于一个真实的新零售业务的电商全链路场景，希望你可以举一反三，通过这个案例将主链路的知识点应用在自家公司的业务场景中。在开始之前，我先来给你做一个知识铺垫，学习一个用来分析业务场景的万金油模型 - 漏斗模型。我们通过漏斗模型将整个电商场景沙盘推演开来。
这是一个漏斗模型图，它用来描述用户从业务流入口到业务流终点的整个过程。我们把这个模型套用在电商的下单场景中，漏斗的上方部分是主搜、导购、商品详情页之类的场景，这是用户开始业务流的入口，承载着最多的用户访问流量；漏斗中间部分是订单转化的关键环节，购物车模块；漏斗最下方的部分是下单前的临门一脚，订单和支付模块。电商行业运营侧的漏斗模型相对会复杂很多，通常划分为用户获取、激活、留存、收益和传播等阶段，不过我这里把这个过程做了简化，我们只关注几个关键的环节就好了。
漏斗模型有三个特点：
接下来我就带你从漏斗顶部走到底部，探讨一下如何识别各个部位的主链路。
漏斗顶部承载着用户导流和转化的双重任务，导流端主要负责将四面八方的用户流量导入到商品详情页做进一步转化，常见的业务场景有站内主搜、站外短链、口令服务、类目渠道、直播转化等，这些场景都做了同一件事，那就是导流和获取用户。如果完成业务目标的途径有很多种，那么自然是流量占比越高的场景链路优先级越高。横向比对来看，在这个环节的主链路是站内主搜，它是流量占比最高的业务场景。
你可能会奇怪，站外短链和购物口令也很重要，现在直播购物和分享购物带来的用户流量这么庞大，依靠的就是短链和口令分享，为什么这俩不是主链路呢？其实，在主链路规划的过程中，我们有很多“奇技淫巧”可以让看似重要的东西变得不那么重要，这里就要讲到业务降级策略。
以短链口令场景为例，当我们通过短链口令来分享商品时，可以做一个“小机关”，将商品的ID加入到口令的文案中，即便后台的口令或者短链解析模块出现故障，无法还原出原始的单品网址，APP层面仍然可以做一层兜底方案，根据口令文案中的商品ID直接跳转到商品详情页。运用这种策略，我们就可以将短链口令的业务场景“嫁接”到另一个主链路“商品详情页”之上，只要详情页顶得住，那么就可以保证短链口令场景的可用性。
在实际的项目中，我们需要巧妙运用降级策略，尽可能减少主链路的数量和比例。这样做的道理很简单，虚机、带宽、硬件资源是有限的，有限的资源要投入到最重要的链路中。如果所有的场景都是主链路，那这个项目的架构师一定是个学渣，学渣的特点是把一整本书的全部内容都画成了重点，无法用有限的精力学习重点知识。作为学霸，我们要尽可能抓住真正的重点，把重中之重的链路划归为主链路。
除了主搜以外，其实还有一个重要的主链路业务：搜索竞价营销服务，它是带来正向现金流的现金水库业务。类比淘系业务里的“直通车业务”，搜索竞价营销服务掌管着搜索竞价、精准推荐等各类付费点击类业务，妥妥地把阿里妈妈事业部变成了集团的大金主部门。
如果你细心观察，就会发现业内的互联网公司都有自己的“现金水库”类业务，作为一个优秀的架构师，只有了解自己公司的业务模式，明白它赚钱的道理，才能结合业务场景做出最合适的主链路规划图。
转化端的主要责任落在了商品详情页这里，回想以往的购物经验，详情页的主要功能有商品元数据的展示、SKU模块、库存信息、用户评论、商品营销优惠信息、主图和视频空间、富文本TFS详情，以及一些锦上添花的小功能如用户画像推荐、热搜排行等。
作为转化端的重头戏，商品详情页的信息可谓是纷繁复杂。不过在双11大促之类的场景中，很多挂在详情页的边缘功能都会被主动降级，腾出服务器资源供到主链路服务中。接下来，让我们雾里看花，从这些功能点中识别出核心主链路。
从业务完整性角度来看，以下功能都是完成下单不可或缺的步骤，因此被划归为主链路的一部分：
商品元数据服务：商品名称、规格、产地等等的元数据，构成了详情页的基础信息。
SKU服务：Stock Keeping Unit，也就是我们下单之前选择的“款式”，比如IPhone 16G 红色、和IPhone 16G金色就是两个不同的SKU，电商业务中的库存数量也是控制到SKU这个层级上。
库存模块：贯穿下单场景的重要服务（电商场景中经常采用分段库存来解决秒杀场景）。
前面我们说到详情页承担了转化的主要责任，提到转化就会想到“转化率重因子”，我们将以下重因子场景识别为主链路的一部分：
图片空间：商品主图和附图（相比之下，视频素材在转化率角度上的戏份不如主图，没必要作为主链路的一部分）；
富文本服务：富文本指的就是商品详情上图文并茂的商品文案。
很多人在设计电商系统的时候，会把富文本作为商品详情接口的一部分结果返回给应用端，其实这种设计并不合理。从主链路规划的角度思考，既然富文本是主链路的一环，我们就将这个服务与其他服务“拆分”开，尽可能减少主链路服务对其他上下游服务的依赖。在淘系场景中，商品详情页接口只会返回一段TFS链接给到手机app，通过访问TFS链接来独立加载富文本。
漏斗中部是购物车模块，承担着订单转化的重要环节，主链路模块所占的比例也随之提高。
从详情页到下单，在购物车场景中有这几类核心场景：添加/删除购物车商品、购物车商品列表、订单营销优惠信息、地址模块、导购模组（热卖、最近浏览、拼单立减等等）。
从业务完整性角度来看，我们抓出了以下几个主链路功能：
从转化率重因子的角度来看，有一个具备争议的功能点也被化为了主链路的一环，就是购物车内的营销优惠计算，它是营销优惠业务最后的导流环节，必须0故障显示出当前车内商品可以应用的优惠条件和扣减情况，否则极易让用户放弃下单。
看到这里，你可能会有疑问，为什么购物车内的营销优惠计算模块是主链路，而在转化端的商品详情页却不是呢？这就涉及到一个“前端柔性”的话题了。
商品详情页历来是QPS数一数二的业务场景，我们以淘系的UMP营销计算服务为例，每个商品详情页请求都需要调用UMP服务计算单品优惠信息，即便在双11这种堆缓存抗压的方式下，营销计算服务仍然面临很大的压力。当服务发生故障，优惠信息无法透传到详情页的时候，我们可以在页面显示一段类似“请到购物车查看最终优惠金额”的文字，引导用户添加购物车，继续向下走购物流程，这样一来，详情页上优惠计算服务的故障对业务转化率的影响就被降到了最低。这种方式就是“前端柔性方案”（也叫用户端柔性）。
前端柔性方案的思想是降低用户对“故障”和“性能瓶颈”等异常情况的感知，在不经意之间，将某个原本会被用户感知到的“异常情况”转嫁到一条正常的链路中，完成最终的业务场景，这和“最终一致性”的思想有异曲同工之妙。在一个复杂的业务系统中，作为一个架构师，你要清楚地了解每个业务场景的上下游调用链和其他同质类业务，这样才能恰到好处地利用前端柔性将异常情况“嫁接”到正常链路中。
漏斗底部是庄严肃穆的下单环节，根据漏斗模型的理论，越靠近底部，主链路的占比也就越高，所以下单链路中的几乎所有场景都是主链路的一环。
我列举几个下单链路中的场景，如创建/查询订单、订单页商品列表、订单快照功能、营销优惠信息透传、支付模块对接。相信你已经看出，除了商品快照服务以外，其他场景都是完成订单必不可少的一环，因此也是核心主链路的一部分。
而且，你可能注意到了某个出镜率很高的微服务模块：营销优惠服务，它在漏斗模型的上中下部都有露脸。对于这类贯穿电商玩法全链路的模块来说，即便它在各个场景下所实现的功能非常相似（计算优惠），我们也不会采用“高度可复用”的单一接口来实现。相反，我会根据其处于漏斗模型的位置不同做服务划分，比如商品搜索页、商品详情页、购物车页面、订单结算流程这四个步骤中的营销优惠服务，尽管功能类似，但背后其实是四个不同的微服务接口。
所以说，在微服务设计中，面对高并发业务场景的考验，讲究“可复用性”未必是一个很好的思路，根据主链路对核心服务做细粒度的拆分，将服务与服务之间的故障隔离开来，是保证整体链路可用性的一个很好的方式，这种看似“浪费”实则“精打细算”的方式才是更合适的方案。同理，我们在复杂业务中经常需要对同一份数据做多维度的数据异构存储，两者有异曲同工之妙。
现在，我们来回顾一下这节课的重点内容。今天我们了解了如何在复杂的业务场中识别主链路，以及主链路的四个重要的特征：业务完整性、转化率重因子、流量端占比和现金水库。通过一个电商场景的沙盘演练，我们深入了解了主链路规划在实际业务中是如何开展的。
我在这节课讲的“漏斗模型”是个万金油，它不光可以套用在电商领域，也可以应用在大多面向客户的应用场景中。我们应用漏斗模型的一个目的，就是换一个视角，从用户的应用场景视角对系统做切分，让你的微服务拆分更有层次感。
按照程序员的思维，我们总习惯从“功能性”的角度对微服务做切分，比如营销计算就是一个功能，不管用在什么场景，我把所有计算优惠的场景都放到一个微服务里，这个视角其实是比较片面的。当你应用漏斗模型对应用场景做进一步拆分的时候，你就会发现同一个“功能”在不同场景下的重要性是不一样的，这样你就可以更精准的识别主链路服务。
在微服务架构的领域里没有“银弹”，主链路规划再好也不能滥用，我们要活学活用主链路规划的理论，不能生搬硬套，更不要为了主链路而主链路。
如果你的应用本身并不复杂，也没有多少用户，那么硬生生套用主链路规划把后台服务拆的零零散散，这其实是浪费精力。只有当你的业务达到一定复杂度和集群规模之后，主链路规划才能发挥它真正的作用。而学习这些服务治理的理论，了解微服务技术的全貌，也是你对自己知识体系的一次升级，这是从小作坊走向大厂的一道必经之路。
识别出主链路并做好服务拆分之后，我们有哪些技术手段保证主链路的高可用性呢？你可以联想一下前面课程里我们讲过的几种大厂里的常见方案，除了这些以外你还能想到其他技术方案吗？欢迎你在留言区分享你的想法和收获，我在留言区等你。
好啦，这节课就结束啦。欢迎你把这节课分享给更多对Spring Cloud感兴趣的朋友。我是姚秋辰，我们下节课再见！
评论