首页手记聊聊我在阿里所经历的新零售业务商品中心微服务化的过程

聊聊我在阿里所经历的新零售业务商品中心微服务化的过程

标签：

Java

hello，慕课网的各位同学们大家好，我是姚半仙，慕课网《Java架构师成长直通车》课程架构师讲师团成员之一。今天不算命，想给大家分享一下我在阿里所经历的新零售业务商品中心微服务化的过程。

所谓往事不堪回首啊~~，我们先来看一下它的业务背景。作为整个集团的战略级项目，这个业务它的背景相当的艰难。

首先，它时间紧。 新业务需要进行急速迭代，探知市场的微妙变化，培养用户的心智，以达到快速验证商业模式可行性的目的。

其次，这个业务它的任务非常的繁重。 我们所经历的不是给一座摩天大楼添砖加瓦，而是从0到1搭建这座大楼。因此，在那段黑暗的岁月里，所有员工过的都是相当的辛苦。9117就像呼吸一样的自然。（咦，同学们知道9117是什么意思吗？可能大家只知道996吧，9117意思是早上九点到晚上十一点，一周七天班）

时间紧、任务重，这都还好说，咱小伙伴们皮实着呢，但是关键问题在于我们承担的责任大呀。 首先这是集团No.1的战略方向。集团对这项业务的投入可以这样说，叫不计成本。

综合以上三点,我们的小伙伴们只好把互联网精神中的糙快猛这种开发模式运用到了极致。所以当时我们推进项目的方针只有一个字，那就是快。

这里只是一个开头,我们接下来往下看。除了业务背景以外，我们再来了解一下业务方都有哪些。咱们做电商业务的，就是要把商品卖给用户，所以我们的第一个业务方自然就是终端的用户，他们可以通过我们开发的A p p来访问我们系统，除此以外，我们的系统还集成到了手机淘宝当中。手淘这个超级巨无霸App会源源不断的将用户流量导入到我们的业务系统。除了这两项以外，我们还有线下的POS，也就是说，用户可以在阿里入股的大型超市中通过线下买单的形式，在我们的后台应用中创建订单。

我们的业务方当然还包括咱自己的运营小二同学们。我们的产品同学，运营同学，采购同学，他们通常会通过Web页面登录后台的管理系统来制定业务的规则。除了这些坐在办公室的同学，我们还有奋战在一线的工作人员，这些工作人员可以通过履约终端App或者是拣货端的扫码枪来访问我们的业务系统，所以我们的业务方非常多元化，用户导流的入口也是分散在不同的地方。考虑到我们有手淘的导流，这个用户体量可是相当相当大的,对我们的业务系统的性能是一项非常大的挑战。

那接下来我们就去了解一下新零售业务都有哪些业务上的需求。 我这里把系统当中比较核心的业务模块先跟同学们讲一下。首先, 首当其冲的就是商品模块,有的时候我们也叫它商品中心。它是所有电商业务当中最重要的组成部分，因为我们所围绕的业务核心就是商品。除了商品以外，我们还有订单中心以及履约中心。订单中心控制的订单生成和后面的支付系统相对接。履约中心则是后面的配送流程，所以商品，履约，订单这三个模块是我们整个业务系统中最重要的三个部分。当然了，我们可以显示在这个页面上的，都是非常重要的需求。

后面还有库存模块，它管理着你的商品有多少库存，能卖多少。这一块控制不好，可是容易出现超买超卖的情况。后面我们还有用户中心，那用户这个概念穿插在整个电商链路上下游所有的业务当中。什么样的用户可以享受什么样的优惠？你是不是新人？会不会给你发放新人优惠券？如何查看这个用户的当前订单，历史订单等等，都要通过用户中心来获取用户的信息。那接下来还有搜索模块，搜索是一个非常重要的导流端，你想买什么商品，都是通过这一个模块来触发的。我们的业务系统不仅涉及到台前这些跟用户直接打交道的模块，同时还有幕后的模块，那就是后台的运营系统。我们的运营同学，销售同学以及采购同学，他们需要在后台系统当中定制业务的玩法，比如说接下来的营销模块，我们可以通过后台的运营系统在营销模块中创建新的优惠规则，比如买二送三或者满五十减十块或者发放新人优惠券。那再接下来是导购投放系统，这里就涉及到用户画像，通过你的过往浏览记录，或者是你的购物记录来猜测你所需要的商品，投放对应的商品信息到你的页面当中。这里还有一个重要模块是购物车，它是达成下单的一个必不可少的步骤。那半仙老师我将我自己的青春奉献给了哪些模块呢？

就是商品中心，后台运营系统和营销平台了。其中商品中心和营销平台可以说是我一手搭建起来的，后台运营系统我也挥洒了很多汗水啊。那我们在这个页面当中展现的十个模块，它们背后都被拆成了n多个微服务。但是要提醒同学的是，这里只是我们整个业务系统中相对重要的模块，我们当然还有很多的支持模块，它并没有出现在这里，所以同学们可以预想到在一线互联网公司中的电商场景，它后台所涉及的业务真的是非常非常复杂的。

那我们接下来就拿老师最熟悉的商品中心再来看一看它在最早期初代的短命版本都是怎么样的架构的。首先我们来画一个圈圈，这个圈圈是什么啊？它自己说了：“我是一个War包。”

那你想怎么着吧？它又说了：“我这里面啥都有”。那我的看看这里面都有什么呀。

这里商品发布，商品上下架，详情页服务，商品搜索，商品优惠，编辑图文，所有的功能全部都掺杂在这里。一个War包提供了整个商品中心所有的功能点，这就是一个非常典型的单体应用。那同学们可能会说，堂堂大阿里的战略级产品怎么构建成了单体应用的架构呢？大家要知道这个单体是一个人写出来的，所以相当的不容易。为了达到快速上线的目的，可能也不得不这么做。不过把项目架构成这个样子的可不是我啊，我把这个锅甩出去了，但是，转折来了，我们说这个版本是一个短命的版本，为什么它的命这么短啊？因为这个时候老师登场了呀。我加入到这个项目以后呢，就开启了仙人指路的模式，然后我们立马上马了一个新的项目，叫老城区改造项目，也就是整个商品中心的微服务改造的大幕被缓缓的拉开了。

现在就带大家去看一下当时老师做老城区改造计划的时候，是从哪些方面来做服务的拆分规划的。我首先从抗压的角度来分析，将所有的用户场景划分为不同的维度。那为什么从这个角度出发呢？是因为我想把那些非常高频的（用我们的黑话就叫QPS）这类服务单独拎出来。这部分服务所承接的压力非常大，我们在做微服务改造的时候，尽可能的要把这部分服务和基础服务隔离开来。那我拎出哪些服务呢？一个是商品发布服务，另外一个是库存发布服务，我们把这两个服务归类到了低频瞬时流量的场景。

为什么说它低频？因为商品发布通常都是我们自己集团的工作人员来操作的，那什么时候操作呢？比方说我开了一家新店的时候，或者说我这里有一批次供应商刚刚谈好了合同，有很多的新商品需要加入，那它的访问频率并不是非常高，也就是说它是一个低频场景，不过瞬时流量高，为什么呢？打个比方，我今天开了一家新的门店，我要把所有现有的十万或者是二十多万个商品一键发布到新店，那这时候可能就会在短时间内打出非常高的QPS，那库存发布也是同样的一个道理，我在每天午夜时分要发布第二天的库存，那它是一个后台执行的批量请求，它只在某天当中的几个时间段会触发。但是呢，它影响到的商品数量会非常的多，因此我们需要将这种低频瞬时流量的场景隔离出来。这样呢，一旦我们因为突发流量导致商品服务不可用，它也不会影响到其他的技术服务。

ok，我们接下来看另外一个场景。商品详情页和商品搜索服务。这两个场景不用说我们也知道，它是高频的匀速流量场景。

所谓高频，就是说每个用户在达成一个真实订单之前，它总要来来回回选择自己心仪的商品对不对。这个筛选商品的操作一定会途径商品搜索服务所检索出来的商品列表，并且它还要点进去看商品详情。这两项服务一定是高频场景，并且它是相对匀速的，因为我们的剁手族总会在这一天中的任何时刻打开App,翻来覆去的去看自己心仪的商品。那除了低频突发流量和高频匀速流量这两个场景以外，我们还有一些低频的场景，比如说商品编辑。运营团队为了吸引顾客，可能会在自己的商品文案当中做一些修改，那这个场景相对频次会比较低。除此以外，还有预售和改价单，比如设置某一个商品为预售商品用户可以先点击预购买，但是我并不会实际的发货，那这就是预售场景了。可下单往往只应用在某些大促活动之前。打个比方，双十一之前我设置了一个改价单，让它在双十一的0点生效，这个场景同样频次也并不高。那接下来往后看，我们还有营销规则的设置，比如就是前面提到的买二送一，满五十送五块。这类营销规则通常来讲也是绑定在某些特定的日期，比如说双十一、双十二或者是在新店开张的时候。与营销规则类似的，还有优惠券的场景，这里要设置一个新的优惠券模板，新人专享卷或者是老人专享券等等。那接下来是商品的类目编辑，因为我们新零售业务主要集中在吃货场景上，所以我们的商品类目要比淘系的全链路类目少很多很多，这一类的低频场景数不胜数，它涵盖在各种的运营场景当中。

那我们这一页举的例子就是想告诉同学们，我们从抗压的这个角度，把所有的服务大致归为了三类：低频突发流量，高频匀速流量和低频的场景。

那我们接下来下一部分是老城区改造计划的业务角度来出发，把不同的服务归类于不同的业务，然后把边界划分清楚。比方说我这里有一个定时任务，定时任务包括改下单，它会在某年某月某日我指定的时间生效。还有库存发布计划，那这两个场景，我们把它归类为定时任务的场景。

接下来还有主链路+用户场景。主链路是我们电商场景中最核心的链路，也就是说，我们的微服改造尽量要围绕着主链路展开。针对主链路上的服务，我们会添加投放更多的硬件资源，同时定制非常细致的降级熔断策略。那这里比较有代表性的，有一个是商品详情页，还有商品的搜索服务。这两块是主链路中非常核心的部分。除此以外，我们还有广告投放。其实广告投放并不是主链路的一部分，但是它和商品搜索和商品详情页都紧密的绑定了起来，共同构成了用户购买行为的流量入口。接下来还有营销优惠的计算，以及领取优惠券，这两部是在主链路当中生成订单环节必须要参与订单价格计算的。那说到订单，我们自然会想到购物车以及订单页面需要展现的商品信息。

我们说主链路大部分是和用户息息相关。用户在购买行为当中会直接去操作，去接触。除此以外，我们还有一些幕后的运营场景，比如说我们前面提到的商品编辑，以及预售商品的设置，还有运营、营销规则的设置，满减满送或者是满额送券等等。一提送券，我们又要提到优惠券的模板设置了，当然还有商品的发布服务，也是运营场景当中的一部分，后面还有商品类目的编辑。

那我这里只是从众多运营场景中筛选了几个例子，我们将所有服务大致笼统的归为了这三类，不过当时在做老城区改造的时候，其实还有更加细致的分类。这里只是举这样几个例子，化繁为简，帮助同学们理解如何根据业务维度来对商品服务进行分类。

那看完了这两个不同的分类维度之后，我们就要去谈一谈，老城区改造计划都有哪些指导方针。我们的总方针就是拆迁。但是这个拆迁也要谈一谈补偿安置方案，你怎么拆，拆多少。在这里这个方针更像是一个口号，比如说我们前面根据业务场景做了一些分类，那么我在做老城区改造计划的时候，要隔离业务场景。什么意思呢？主链路当中的场景，我们尽可能把它的服务剥离出来不与其他类型的场景混用，因为主链路的场景是用户完成一个下单必不可少的步骤，我们需要更多的资源去守护它，因此也并不希望它被其它的边缘业务所影响。除了业务隔离以外呢，我们还要剥离高频访问的接口，比如前面提到的商品详情页和商品搜索。因为高频高QPS的计划往往最容易被用户的流量给压垮。所以为了减轻这种情况下对其他服务的影响，我们要剥离高频的接口。

那接下来我们就顺着这两个指导方针一刀两段。

看一看经过老城区改造之后的商品中心长什么样子。

欢迎各位领导莅临参加新城区改造项目的验收会，我们先有请淘系的中台业务方登场。这里有IC订单中心，淘系商品中心，UMP营销优惠中心和后台的支付系统。作为集团大中台战略中的一部分，这里的淘系中台业务会为集团所有不同的事业部业务方提供服务支持。那对于我们商品中心来说，首先拆卸的两个服务就是商品详情页的微服务，以及商品发布的微服务。商品详情页微服务是一个高频高并发的场景，而商品发布服务是一个低频，但是有突发流量的场景，所以从性能角度考虑，这两个微服务都要对上各种各样的中间件。这里有分布式的配置中心，缓存以及各种的图片存储，视频存储的部分。除此以外，由于商品发布的调用链路非常长，经常会在某些链路上卡壳，所以我们这里引入了一个容错机制来专门做异常补偿，那它底层会将商品发布的失败请求转发到RocketMQ，然后重新消费。因为咱底层是使用的淘系商品，所以这两个微服务自然而然的需要对接到淘系中台里的第二个服务-淘系商品服务。那我这里抽象出了一层专门做对接的微服务，就是服务淘宝微服务。服务淘宝专门跟淘系的中台打交道。不过在这个架构下，其实还是有点优化空间的，因为毕竟如果服务淘宝承接了过多的业务方，那它本身也可能成为一个主链路中的性能瓶颈，所以我们也可以把商品详情页和商品发布服务直接对接到淘系的中台。

从我个人的使用感受来说，其实中台服务的对接成本是相当相当低的。

那我们接下来往后看，还有哪些微服务？

这里列出了商品营销的微服务，还有商品导购的微服务，导购就是前面提到的用户画像，一步步把你勾引过来去消费的这个服务。接下来还有资源位的微服务，它是设置手机App的展示商品的列表顺序以及它的布局。那前面我们有提到过定时任务的场景对不对啊，就是商品后台批量发布的任务，比如改下单和库存发布。那这里把这两个任务单独抽成了一系列的微服务，同时它们对接到RocketMQ做流量的消峰，用这种方式降低突发流量对系统的冲击。我们这里还有一个非常重要的微服务是商品搜索微服务，它直接对接到淘系的中台，为手机App端提供搜索支持。与此同时，我们的运营在后台的运营系统当中也会进行商品搜索，只不过这个商品搜索我们走了另外一条链路，集成了淘系自己研发的OpenSearch框架，提供搜索支持。