冰支付新闻

当前位置: 冰支付 > 冰支付新闻 > 正文

微盟SAAS新零售电商业务系统的架构演进实践

2018-11-06 00:19 319

本文根据谢茂森在10月21日微盟Open Day 的演讲整理而成。

谢茂森 

微盟新零售技术部技术总监,曾就职于一号店,负责核心订单库存业务,对大型互联网系统架构,以及电商业务有深入的了解,目前整体负责微盟SaaS新零售电商系统的系统建设。

今天分四个方面和大家分享,第一个是微盟SAAS整体业务系统架构;第二是微盟新零售SAAS架构,微盟现在除了零售的业务之外,我们还有很多其他的项目,像我们的到店,像我们的无人零售,很多不同的解决方案。所以说零售仅仅是我们软件体系里面的一个点,待会儿会看到一些。后面还会从微盟电商相关的架构领域做分享,最后给大家分享我们微盟整个技术的架构。

微盟SAAS整体业务系统架构

从整个微盟的软件体系来说,有很多不同的软件体系解决方案,比如电商零售、餐饮酒店、营销管理等等。大家可以尝试登录试用一下我们的免费软件。微盟软件SAAS体系,可以以个人的名义去注册一个帐号,去试用完所有的软件。试用之后,你觉得软件符合你的需求,可以付费延长使用时间。这是现在比较流行的SAAS的体系,我们所有的服务都在云端,服务都是不断升级和迭代,不断的用互联网的思维满足不同商家的需求,不断的演进。

微盟为什么能做到如此多的软件,不断去满足商家的需求?整个体系架构是比较重要的,如果是做过SAAS软件会有比较深刻的理解。先说一下整体的架构,最左边的是软件销售CRM系统,微盟在软件这一块,我们也相当于卖东西的商家,我们卖的东西是卖软件,卖解决方案,卖整个电商平台,卖整个酒店的管理平台。所以我们会有销售的CRM系统。

第二个是SAAS集成登录系统,注册完帐号以后,你在里面创建很多自己需要用的软件,会有一个集成的登录平台。第三个是SAAS产品运营后台,做完整合新零售的软件出来以后,会有不同的套餐满足不同层次商家的需求。产品定义平台,帮助我们把功能性做完以后抽出不同的功能定义成不同的套餐,定义成不同的产品给不同的商家使用。最后整个软件的产品体系,有零售、餐厅、集成软件产品系统等。我们跟许多合作商合作,有很多接口提供出去,有自己的OPEN API,这样才能形成软件的生态。如果想深入了解的话,可以去微盟官网看一下,这些东西能够拓展大家对SAAS的认识。

讲完SAAS的系统架构以后,大家在脑子里都会形成几个点。一是我这个SAAS有销售,毕竟是要卖钱,有一个销售的平台。二是有统一的平台,让用户登录进去以后可以试用不同的软件。三是产品小伙伴针对功能开发出来以后定义出很多不同层次的产品,满足不同层次商家的需求,最后要形成一个生态,可能要有一个服务市场的平台,有一个开放平台。不单单是跟微盟玩,所有有关联的软件商家也一起玩。

新零售SAAS架构演进

第二个看一下新零售SAAS架构演进,新零售现在是一个非常火的概念。新零售到底是一个什么东西?怎么理解?我从我的角度跟大家讲一下我们这边对新零售的理解和怎么去做这个事情。

大家先看一下SAAS电商,讲新零售为什么又讲电商,要知道我们所有的体系都依赖于电商体系,最底层就是我们的电商体系,只不过展示不同的形态。不管是天猫也好,天猫底下的饿了么或者盒马鲜生也好,各种各样的形态,还有现在摆的无人零售体系的无人货柜也是我们零售体系展示的形式。

我们整个电商的体系架构分为好几个层次。最底层是一个中台的能力,比如说用户、商户、支付、卡券、会员、数据、物流,这些都是相通的,有很多的共性。往上是电商体系,里面包含商品、价格、库存、订单,到新零售的时候还有多门店、多仓库等。再往上是营销体系,有满减折、会员、卡券码这些东西。营销体系再往上是商家的体系,商家体系是B端的,还有C端用户的体系。用户登录到你的体系来可以做什么东西,有哪些点是跟你相关的。再就是交易流程的体系。再往前是给用户展示的,页面不管是首页也好,广告页也好,很多分类页也好,属于导航的体系。顶层是渠道层,公众号也好,小程序也好,H5也好,百度小程序,都是一样的,对于我们来说只要你底层架构一样了,顶上的渠道可以是任何的一个点。以上是我们整个电商的架构。

微盟经过两年多的建设,从最初最简单的电商体系,演进成新零售的体系。

如图,大家对线上商城有一个比较直观的了解,比如淘宝、京东。它是线上的渠道,很多东西都是基于线上做的,比如线上营销体。库存有时候设一个库存点就可以了。所以对于线上电商来说就是单商家体系。

我们再看演进后的整个新零售体系,一个小圆圈就代表一个线上商城,新零售就是由多个小圆圈组成的。除了商家本身外,下面还有很多子门店,对比我们说的线上商城体系,我们的新零售有很多不一样的特征就展示出来了。

我们可能出现一店一商城的情况,每个门店拥有独立、完整的商城功能,支持直营、加盟等多种门店方式。之前我们说电商线上商城是线上的场景,到现在我们支持了很多线下场景,导购、开单、收银、自提、线下支付。现在到了新零售的阶段,线上和线下打通,规模统一,价格一致,支持门店共享仓、独立仓、云仓等库存体系。线下是进销存体系,涉及到供应链的需求。现在有多种订单处理方式,之前是线上订单来了,我线下发货。新零售有前置仓,可以把订单派到不同的线下的门店,用户可以自提。同时也支持不同的策略,把订单分配给不同的门店。最后是商家+多门店的体系。零售体系和线上商城体系相比,功能体系已经发生了很大的变化,在这个过程中,业务架构设计是一个难点。特别是在商城里要做好零售的设计。在这里跟大家简单说一下,我们在做微商城的时候,已经把门店体系考虑进去。这是非常核心的点,这样你的系统设计已经成功了一半了。

新零售核心架构演进

第三点,从我们核心的业务架构,商品、库存、价格、订单、支付几个点给大家做一些分享。

这里有一些空的,我没有放出来,原因是刚开始的时候我们线上电商商品体系里面,线上商城涉及到商品是线上的,可能有B2C的订单,积分订单,商品和SKU。如果做过电商的都了解这些模型。标签也是通用型的标签,这边是活动的库存,后面价格是统一的。这样零售会变成什么样的?这样会多很多东西,这时候商品已经增加了线下的商品和多门店的商品。还有单品和组合品,如果做到仓库体系,我一瓶可乐+雪碧组合起来形成商品。单品我也可以卖一瓶可乐和一瓶雪碧,这里有组合品的概念。还有门店商品关系,进销存相关和多仓库相关的我们之前说了。设计整个商品模型的时候,就要求做线上商城的时候要考虑线下零售,要把模型设计好。越是做大系统就要考虑整个的模型体系怎么设计。刚才把底下的点铺开了,我们没有把上面的点铺开。所有的商品相关的点,我们利用商品中台对接完整个体系,营销体系、导航体系、交易体系和订单体系,还有直播、客服等等。这样要求你的中台能力非常强。

再说我们的库存,线上的简单库存体系只有普通库存和活动库存。到了新零售整个体系就完全不一样了。我们进销存体系,还有整个仓库体系不光有线上还有线下的,共享云仓、独立仓、仓库、门店仓库关系等等。举个劲霸男装的例子,他们希望把上海100个门店都生成虚拟的仓库,所有的门店都整合到虚拟的仓库里下单,所有的客户都在虚拟仓库里面,这就是我们说的云仓的概念。这就要求我们在做线上商城的时候就要把整个仓库的点考虑进去了。一开始设计的时候就要考虑这些维度。

再说价格,商品有成本价和市场销售价,还有活动的营销价。举个例子,有300件营销的价格,前面100个是100块钱,接着下来是150块钱,后面100个是200块钱。我要引爆营销活动,支持阶梯式的价格,价格是有生效时间和失效时间。体系很简单,但是一开始就要考虑好整个业务是什么样的。

再看支付,按以往了解,可能看到我在线上微信支付就完了。从商家来看则有很多不同的点。整个支付体系还分很多场景,比如分次支付、线上线下混合支付、多次合并支付及重复支付自动退款等等。支付的方式大家比较常见的有微信支付、支付宝、网银等等。如果整个架构体系来说,还涉及到收支明细、营收概况、营收趋势等等。还有一些其他业务能力,我们有很多合作的第三方支付公司,需要利用它们可支付的整合能力。比如说一个商家进来,我收了一笔钱,可能要分给A多少钱分给B多少钱,分销的时候每一级我要分多少钱,每个钱怎么分,怎么打到具体的帐号里,也是很复杂的点。我们整个支付体系已经支持了这些东西,整个架构体系考虑了非常多的东西。

现在说订单,对于零售来说有各种各样的订单,不单单是大家常见的线上下单然后我发货,这种情况属于实物订单,实际上还有很多虚拟订单,积分订单等等。怎么做这么庞大的订单系统?我们会把每一种订单按它的交付类型、交付方式统一。虚拟订单交互的方式是不一样的。对我们来说订单有很多层次,业务订单、营销订单、基础订单等等。比如说拼团订单,五个人成团,怎么去控制拼团的订单做流转?我是不是可以拼周期购的订单?这样整个体系就非常大了。我拼的是周期的充值订单体系又不一样了,所以订单的体系也是很复杂的体系。如果对于C端用户来说,不同的订单还要帮我整合起来。大家看美团点评的订单类型,我今天吃饭的单,充值的单,各种类型的单,都整合在你的订单里面。我们整个订单中台有很多不同的东西,营销订单有砍价的、秒杀的、SDP订单,会有整合搜索引擎承载这些东西。还有数据库中间件等等支撑庞大支付的体系。

再来说订单中台,所有的订单都会被收过来,最终下到基础订单,由基础订单统一对外呈现东西,把订单串联整合起来。这里需要真正做到电商体系的时候才会有深刻的理解。另外大家可以从这个点上了解一下我们做新零售,我们之前讲了整个微盟的SAAS体系,讲了新零售从线上商城到线上线下打通的多门店体系,接着我们又讲了电商核心领域怎么做演进。整个电商里面最核心的是要从商品开始,商品设计好了,整个的交易流程把商品需要的东西,或者我订单交付需要用到的东西全部承载到订单里面去,订单落地完了以后,剩下的是我们走后续交付的路线,根据不同的订单有后续不同的交付路线。

微盟技术架构

我知道很多小伙伴比较关心的是微盟的技术架构,我们整个SAAS的软件,有十几个解决方案,上百个套餐。整个平台已经有超过100万商家在用。如此庞大的体系,必定有很大的技术架构在支持。下面给大家分享一下微盟比较核心的技术架构。

最底层的是运维架构,这是我们整个监控体系,在互联网公司待过的小伙伴都比较清楚,有基础的体系,有管理体系做支撑。底层有很多网络管理相关的东西,我们上万台模型在里面做,你怎么去管理,这个也是很大的运维管理。这里有不同的数据存储层,我们引入到虚拟化与容器层,上层还有流量控制、服务注册等等支持整个运维管理层体系。顶层有安全相关的软件,如 DDOS、WAF等等,还有相关的堡垒机模型。

接着讲一下基础架构相关的东西,看起来相对比较简单。我把最核心的东西给大家抽出来,我们基础架构底层是基础设施层、消息中间件、ES、缓存、流式计算。基础设施层之上是服务治理层,这是最重要的,有配置中心、dubbo、注册中心、服务管理等等。上面还有基础工具,如媒体中心、短域名、大数据服务、IP服务等。再顶层是具体的业务层,有新零售、到店、微站等。左边是CAT监控系统,这个是通过蛮长时间的迭代发展起来的,已经可以满足大型的业务监控支持。还有全局调用链系统,这是大型互联网公司必备的,很多请求出现问题以后,一个接口在外面体现出来,底下经过几百个接口的调用,靠全局调用链系统一下就可以发现问题。有兴趣的大家也可以深入了解一下,这是值得大家关注的问题。

下面也给大家简单介绍一下简单的原理和我们实践的方式。先说整个架构的体系,前端一个请求进来了,到nginx的路由,再到web服务接收,底下很多不同的服务点。经过我们整个体系,汇总到ES体系,最终给出一个报表,整个都会记录下来。全局调用链有感兴趣的,可以到网上查一下。正常来说一个请求过来了,关键是有param、span、app、context、LOG,每次来的时候会把这个点记录下来。第一个请求进来进行处理,处理完以后调外部服务,我就知道把当前的parentRpcld传下去,每一个点都会有一个日志计算的点,整个的计算方式我们在原来parentRpcld的基础上后面加一个1,每一次会把整个日志记下来,这样会把每一个点记下来,统一汇总到一个平台串联起来。不同的点之间传递,传递下来用日志记下来,算法各种各样。整个调用链下来,你会发现很多体系感觉经过A轮、B轮服务,但是处理流程经过很多步的处理,整个体系是比较复杂的。

讲完了基础架构,这是我们整个新零售体系里面的应用架构,刚才我们说了是比较底层的东西,从应用架构层面来说,很多东西看起来比较简单,但是你要抽象出很多不同的场景做很多不同的应用。我们简单可以看一下,比如说通用日志,后台商家有很多通用日志,我们接口统一出来进行注解+AOP。规划定义不出来,出来的东西就五花八门。当人员变化比较多,有不同的处理,怎么保证这些东西大家一看到都是很清晰的。通用权限和风控拦截、分库分表等等,很多是apidoc和http register,也会有相应的动态注册。对于零售体系来说,你要提高效率,最重要的是应用架构很多规约的制定和不同场景使用什么样业务处理方式,我希望大家以后做比较大的系统的时候,也能考虑到这些点,那你就会发现整个架构设计的理念和考虑的角度很不一样。

大概给大家分享这么多,小伙伴有什么想了解的,有什么问题可以简单问一下。会下也可以跟大家一起交流,特别感谢大家下午参加我们的会议,也希望我们有缘相约微盟。谢谢大家。

相关推荐

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论: