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

目录

一、微服务介绍

二、主链路规划

        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 转化率重因子

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

        人们在淘宝买东西的时候通常会先看一下商品长什么样子再决定是否下单，商品图片都加载自“淘宝图片空间”，如果图片空间发生了故障，一定会大幅降低