逆天:蘑菇街下单平台演进,从PHP到Java-阿里云开发者社区

开发者社区> 中生代技术> 正文

逆天:蘑菇街下单平台演进,从PHP到Java

简介: 本文是来自中生代技术交流群的分享,分享者逆天(朱伟)主要负责蘑菇街电商基础平台。本文就为大家分享蘑菇街下单平台演进之路。
本次分享的主题为:蘑菇街下单平台演进。主要介绍的内容是蘑菇街如何一步一步从PHP往Java服务化平台转化的过程。


63e31ae7208b46f3aa2710f6cb926a380b1672cd

这次介绍的主要内容包括5个点:
1、首先,我们需要看一下就是去年9月我刚到蘑菇街时,我所看到的下单系统。当时这个系统所面临的一个问题是什么?面对这些问题我们应该做如何的应对方案。
2、其次,我们为什么要做系统拆分,整个服务化过程是怎么做的。我们抽取的数据模型、服务梳理、系统架构是如何做的。
3、下单系统独立过程中,对蘑菇街快速的业务发展,如何进行对应的支撑。如何实现下单真正的平台化,快速支持业务和需求。
4、独立化前后,我们在日常的问题排查、性能优化中所做的变化。
5、总结,新阶段下单平台的能力。

a16307f03ae748d83e5a64240470c10809dc17be

在做下单服务化之前,蘑菇街整体还是以PHP为主的。随着蘑菇街每年业务成倍数的发展,系统面临的问题越来越严重,挑战越来越大。主要体现在三个方面:
系统上:这个时候的蘑菇街应用称为主站。主站是一个单体的应用。蘑菇街所有的业务场景代码基本都在这个PHP应用中,大小2G+的应用。这个时候,几百号人同时修改着这个应用,每周周一到周四下午是发布时间点。我记得,每次发布的时候,各个应用模块的人,都把代码提交到主干,然后上百人修改的发布就这么浩浩荡荡的往上面发布了。

这个时候,最常出现的问题就是:A:某个同学发布把另外⼀一个同学的代码带上线了,因为他们在同时修改同一个文件。B:发布过程中,在测试机时(线上beta环境)发现了问题,这个时候,所有人的代码都回滚回来,重新发布。在这个时候,各个应用模块之间的耦合严重,稳定性也相当差。很容易出现线上故障。由于这样复杂的相互依赖关系,导致整体性能很低,无法满足大促需求。同时,出现线上问题时,排查起来相当低效。


业务上:没有一个抽象的业务模型,各个业务都是对应的业务PD提需求过来,然后开发评估工作量和可行性,然后对应这个业务流程就开始开发。没有把所有业务流程好好的梳理出来(其实也努力过,梳理过程中,也没有对应的下单能力支撑,最终以失败告终)。另外,业务的边界很不清楚,比如,资金的同学需要对某种业务做红包或者支付减免,这个时候,就需要我们对这个业务做对应的判断,然后新增加一个字段传递给资金,告诉他们这个业务类型。扩展上,也是一样的问题。


总结种种因数,我们得到一个结论:拆。把下单系统从主站中拆出来,做为一个独立的java服务化应用。08bf6f29361f72acd59306635bab20fe3571e0ca

刚刚分析了,拆分是势在必行。那么我们要做应用独立,要服务化,遇到的第一个问题就是:现有服务依赖问题。这么多的依赖,这么多的入口:PC、H5、App、快抢、秒杀等,不同入口不同的业务,他们对各个服务的依赖也不一样,处理逻辑也不一样。另外,第二个问题就是,下单过程中涉及到的一个分布式事务问题。

ef2bb3c6879f2c6ce6855d814ed9bec4579ffece

这里是我在入职之初,删老代码过程中,整理出来的一个原有下单系统内部流程图。其中每个框(无论大小,大框代表核心节点,小框代表各种⼩小业务节点)代表一个功能或者业务节点。基本一个节点就是对应的一个服务依赖。

整个下单过程中的依赖有几十个,分属于各种业务,也包含了强弱依赖。
那么,对于这样一个流程,问题来了:我们怎么知道哪个业务走了哪个节点。对于每个节点对外的服务依赖是强依赖还是弱依赖,大促时我们应该如何降级。另外还有个很严重的问题,就是由于经历了多代码农的辛勤耕耘,相互之间代码理解不一致,加上没有通用的数据模型规范,有一些业务节点,分散在四处。

举个例子:校验这个节点,在入口的地方,在商品读取,拆单,价格计算,运费计算都有。并且,在新来业务时,如做预售,又要新增一个全局的util方法,供给各个接口使用。这样,校验节点不断累积重复。

b572a444f46986ecc4a171eeefe18d87cbcc3911

总结原因,在服务化之初,做的第一项重要的任务就是把所有的服务进行梳理,下单过程中所有的功能节点进行抽取。合并相同的功能节点,拆分负责的综合节点。然后将下单过程中所有可能涉及的功能节点进行固化(对应提炼了功能节点新增标准和扩展标准)。对于同一类型的服务依赖,定义为一个功能节点。比如,计价节点:包括了促销优惠计价,普通优惠计价,多阶段计价等不同的实现。

如上图所示,下单的功能节点和对应的依赖抽象出来之后。就可以很轻松的总结出,下单过程中其实主要包括了三个要素:下单的静态数据(下单流程中所需要的所有数据),下单功能节点(抽象出来的对应节点)以及对应的订单数据模型(落入对应的DB数据,持久化)。

另外,抽象出来了这些功能节之后,我们对于强弱服务的依赖治理也变得相对简单很多。每个节点对应一个对应的功能,每个节点的具体实现,有对应实现该功能的服务。

比如,对于校验模块,我们可能有黑名单校验,有限购检验两个实现;我们在大促时,可以直接对黑名单校验进行对应开关推送,降级该服务以保障整个下单流程的稳定。

对于其他的服务同理,如果对应依赖的服务出现故障或者系统不稳,我们可以切换对应的节点开关,⾛走其他的备用链路。

14709024953c16ce4aeb50cfb7635773659405c2

刚刚在总结功能节点时,我们提炼出来了三大要素。针对这三大要素之后,我们在实现过程中发现,其实这样的功能节点实现时,就是一个模板+一个策略模式的选择器。

就 实现了整个下单流程。整体流程如上图1所示:用户请求进入时,首先根据下单的入参,进行对应的外部信息查询,拼装好对应的下单数据模型(下单流程上下文, 见图2中:orderSDTO);拼装好数据之后,开始执⾏行整个模板对应的功能节点,获取到最终的订单模型;最后将订单模型写入DB生成订单。

我 们可以看到,每个功能节点实现方式,以及执行过程完全一致,如图3中的举例计价功能节点的选择实现过程。这些功能节点都是:通过一定的 condition,然后选择对应的一个或者多个provider,然后顺序执行(invoke)。同时,在退款,在购物车等其他应用中,都有类似的一种 场景需求;所以,对应这样的功能节点实现以及选择过程,抽象出来了一个基础框架:SPI框架。这个框架做了以下几件事情:

1:抽象出了对应的SpiBase类银SpiProvider类,所以具体的功能节点实现继承者两个基础的类。框架将所有的实现类实现集中管理到ProviderFactory中。
2:各个节点针对不同的业务场景实现,通过xml配置对应的condition。不同的业务场景,执行不同的功能节点实现。
3:对功能节点提供互斥(只能选择一个实现类执行)、组合(选用对个实现类执行)的选择器功能(SpiSelector)。

1b69cec32acfaa55397ae20a4a9a1d690d947c65

通过下单的功能节点管理过程抽象获取到的SPI框架,同时也建立了对应的SPI标准,也是对应的功能节点管理的一个标准:
SPI粒度:对应功能节点的抽取,与依赖管理的功能节点一一映射的关系。

SPI互斥和组合:每个功能点执行的时候,不是说简单的只能执行一个,也不是说顺序执行等。而是可以建立对应的互斥组合关系。比如:校验,可以多个实现都执行;计算价格,只能选择⼀一种计算价格方式(优惠计价/多阶段价格/其他系统自定义价格/等)
SPI与共建:由于有了SPI,对于某些业务方需求,可以开权限让业务方自己实现对应的某个SPI节点的特殊业务实现。举例:快抢业务,下单过程对于超时功能节点的需求,不是通用节点的30分钟或者24小时;于是让快抢业务方对于这个SPI新写了一个provider(15分钟),执行的condition为:当快抢业务时,该SPI选择新写的provider。这样业务方自己写代码,我们负责review,然后发布上线,实现平台共建。

SPI隔离:不同的SPI实现隔离标准,目前是通过condition条件隔离。

1d64c2b9954a9a12b9cfb1c1fa987aa8815d8ecf

在服务化过程中,遇到的第二个问题是之前的分布式事务实现方式。

PHP时代,采用的是手动catch,然后人工回滚的方式。比如:减库存时,失败了。这个时候手动catch住,然后调用回库存和解锁券的接口。这种手动处理的方式会带来比较多的问题:首先,如果回库存接口或者回券接口异常,会导致券和库存不准问题。其次,如果回券接口卡了,会影响这个下单rt。

在服务化过程中,不再使用这样的分布式事务处理方式。通过消息来结构整个回滚过程,流程如上图所示。 如果在锁券或者减库存时,出现了异常,这个时候异步发出废单消息,库存和促销应用接对应的废单消息,即可以回滚对应的优惠券和库存。(库存和优惠券内部做幂等)


d12b59e8c15d9d6aa29ae07d4bdbe26918c7952b

在服务化过程中,除了系统方面的问题外,还有很多业务支撑相关的问题。

首先,没有业务模型:所有的对各个垂直业务进行详细的梳理,每个垂直业务的特点、流程、下单过程的要求、依赖等。对于部分业务,如快抢、秒杀等都是单开接口,单独处理对应的业务流程。导致同时维护多个下单流程接口。

扩展性不好:下单内部,没有抽取一个可扩展的业务模型和数据模型,遇到新的业务流程时,⽐比如:新来一个预售,可能需要从下单入口开始,对应的PC、H5、App、秒杀、快抢等多个接口同时维护对应的校验和相关的处理。订单表也没有合适的字段来标记这个类型的订单,导致后续的订单列表,退款,物流等各个系统处理复杂。

业务边界:如试用有抽奖、魔豆商城也有抽奖,还有很多地方都有抽奖流程面对临时需求:只能通过if else,然后在整体的大的php数组中添加一个额外的字段,来标记这个临时需求,下单内部的上下文也不断增大。开发人员之间,也相互不是很
理解这么多的字段具体的含义。

f32cfa26ab7c0285b4c94e62a3ef86f0509e3609

为了支撑各类业务的发展,在服务化过程中,对所有的业务流程进行了抽象和整理。总结出来了20+种下单业务流程类型,如上图所示。每种业务流程,在下单内部映射为对应的流程标记,SPI以这些标记作为condition条件,执行不同的功能节点以及走对应的后续下单流程。

c7c2a852ffa71a91763227378aeb1618e094d8b3

如上所述,我们需要根据不同的业务,把不同的外部流程转换为内部的标记,然后通过标记执行不同的功能节点实现。对于整个流程,对于外部入参,整理出来了六个维度的识别入口。
1:channel:渠道信息,不同的渠道,如快抢(channel_fastbuy)、秒杀(channel_seckkill),传不同的channel,通过标记转化规则转化为内部的entranceTag。
2:flowType:不同的业务流程类型,传不同的流程,如0元订单(flowType=ZERO)。通过标记转化规则转化为内部的itemProcessTag。
3:店铺:根据店铺信息获取对应的卖家信息,映射为对应的sellerTag。
4:用户、会员:通过用户接口,获取对应的买家信息,通过标记转化规则转化为内部的buyerTag。
5:商品:通过商品接口,获取对应的商品类型信息,通过标记转化规则转化为内部的itemTypeTag。
内部,根据6个Tag,决定对应的流程类型(processType),这也决定了下单内部的功能节点执行condition。

b921f690f5857fd06af760962c4b7e9bbcb89810

整合上面对业务流程的总结,我们整理出来了真个交易业务流程的一个规则(如上图所示):
根据业务的描述—-》对应的交易流程——》交易的内部环节——》下单内部选择哪些功能节点——》写⼊入不同的订单数据27c1c72ef478abb4324fb57c3a8ef0ebbc758534

结合上面对交易流程的总结,我们确定了新的下单流程的一个内部分层结构。
外部请求过来时,下单根据对应的外部数据源,经过标记隐射层,转换获取到对应的下单内部的六个标记和流程。然后进入到下单内部服务层,根据Tag执行SPI,写入对应的订单信息。

85be296eb81d14e2704aaefaab2b9a3776aa3af1

在这样的一个业务流程抽象标准之下,我们对实际的业务也进行了对应的PHP到新java应用的迁移。具体情况如上图所示。
图2中,绿色的部分为对原有通用节点有改动,蓝色部分为标示该业务对此节点新增的provider实现。


举例:在快抢这个业务接入的时候,我们对订单校验(添加只能一次购买一个商品校验),extra数据(添加快抢的活动Id,计入订单表的extra字段)两个节点的通用实现进行了扩充,对订单超时(超时时间修改为半小时)和减库存节点(新增减活动库存实现)进行了新增实现。

3d1ad830d27c7117924e464aed122e0ed062f392

我们对于整个下单系统的服务治理、业务支撑、系统耦合等等问题都进行了对应分析和处理。改造完成之后对于我们具体有什么效果,或者说好处。那么可以从线上问题分析这一点直接看出来

1:线上问题排查:
php时代,耦合比较严重、职责不清:问题排查效率低(一般通过打日志跟踪)

服务化之后:入口收拢、逻辑内聚,只有一个入口接口,规范错误码,所有的服务节点和实现都有对应的错误码,大部分错误通过错误码一眼就能看到问题。例如:上右图
中所示,测试妹子在测试环境测试时,看到确认下单接口返回的错误码FAIL_BIZ_CALC_PROMOTION_INVOKE_PROMOTION_INIT_EXCEPTION 直接就去找促销的同学了,一眼就定位出来是促销异常。

b8e723065fd113ffa8f65c141a5cbae0b5148e40

另外,在服务化之火,还对下单系统增加了业务系统监控、服务器系统监控、所有日志采用统一的规范便于查找。

68ff85f267c58006da4ce472a48e5fdec8f8cc91

同样,在对系统优化时,相对于服务化之前,也有了很多改观。
1:首先,服务化过程去除了很多冗余的依赖,这样使得下单的整体链路短了很多。

2:通过流程标记+SPI的方式,让不同业务能跳过不必要的功能节点,减少了对其他服务的压力。如:非海淘业务,跳过对关税税率节点的依赖。

3:新的系统下,做服务优化时,也变得简单易行:每个服务都是一个功能节点内部。整个下单系能优化的过程,其实主要是对下单各节点依赖的服务的优化过程。通过压测,压出各个节点的拐点,然后配合相应的服务提供方,优化接口。如缓存问题,多线程问题等。

4:对于下单系统内部的优化,也有很多成熟可行的方案。如:上图中,是最近,通过Tprofiler对下单应用的踩点分析结果。该结果中显示,在下单内部的一个util方法JSON转化过程中,平均耗时18ms,对于这样的实现,就可以进行对应的优化。721124fc783a0a007ca6a6da4466ca8c23258980

经过对服务依赖的治理,对业务流程的抽象,对整个下单流程的进行的独立和服务化之后,形成了现有的下单平台。
整个下单系统也从最初的综合主站应用(左图)—-》现有的下单分层架构(右图)


Q&A

提问一:蘑菇街这套下单系统发展了几年,为什么有这么严重的技术债务。或者说虽然历经过淘宝洗礼的黄裳等也必须经历再一次的洗礼?(黄裳->皇上,即蘑菇街创始人之一岳旭强。)

 

回答:其实不仅蘑菇街,很多初创公司,为了满足业务的发展,都会选择快速支持业务的PHP技术架构。这样在早期的业务快速扩展中,能够实现快速的迭代。这个也是为什么会出现到15年,蘑菇街业务高速发展时,技术上面会面临的一些挑战。

 

问题二:对于新搭建电商的创业团队,业务也是拓荒。老师在设计原则上能不能总结一些建议?

 

回答二:

首先,其实蘑菇街的业务发展,经历了6年的时间。在做服务化时,如我上面的介绍也说到,其实已经有一个大致的问题参考点在了。我们觉得主站比较冗杂,所以做拆分。我们觉得业务没有梳理好,所以,我们梳理了业务模型和流程等。

其次,对于设计过程中,除了技术架构的简单、分层的明确以外,业务参照上面,其实还是会考虑到未来至少2年的业务发展情况;同时还会参照其他电商公司的一些业务情况,进行分析。

 

问题三:新下单平台架构,DSL这一层 是用什么实现的,和普通的web服务有什么区别

 

问题三:其实就是我们内部的业务规则。就是我们目前对于业务接入时,有个业务规则映射过程,这个是抽象出来的一个规则引擎。目前,是通过配置Groovy脚本来实现的。与普通Web服务的区别在于,普通的Web服务只是针对具体的业务请求和提供对于的数据服务接口,而DSL这一层只是一个业务规则的层,不直接对外暴露服务的。



分享者简介

朱伟,来自蘑菇街电商基础平台,花名:逆天。本、硕均就读于于华中科技⼤大 学(俗称:关山⼝口男子职业技术学院)。毕业后进入阿里(花名:猪尾),主要做运费、物流相关的工作,15年9月进入蘑菇街后,主要负责下单、去支付相关 ⼯工作。


本文来自中生代技术交流群 微信公众号:freshmanTechnology

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
官网链接