海尔电商峰值系统架构设计最佳实践

 多数电商平台都会经历相似的过程,流量和业绩每年以几倍至十几倍的速度增长,每年都要接受几次大规模、全方位的系统检阅,例如双11、周年庆等购物狂欢节,期间流量和订单可能是日常的十几倍甚至几十倍,产生的峰值对平台形成极其强烈的冲击,对电商平台的架构带来巨大的考验。因此,对电商平台的规划和架构工作不仅要高瞻远瞩,而且要细致入微,否则将导致平台无法满足高速增长的业务发展,细微处的失误也可能造成严重后果,不仅影响业务指标的实现,还可能导致对系统进行重新架构,劳时费力又伤钱。

  从2012年开始,海尔进入了网络化发展阶段,企业平台化、用户个性化和员工创客化的“三化”做法为电商的蓬勃发展提供了很好的土壤,也是海尔在面对互联网转型时的一个重点。海尔电商平台在发展过程中也同样经历了上述的问题。下面就抛砖引玉,为大家分享海尔电商平台应对电商峰值的架构设计经验。

  站在巨人肩膀上的SOA架构

  随着电商业务开展和业绩增长,系统结构和逻辑变得越来越复杂。为应对业务规模和复杂性的增长,需要将系统按照细分专业领域拆分;为应对流量和交易的增长,需要将网站进行大量子站拆分。这种状况下,SOA在保持清晰的系统结构和良好的逻辑组织方面提供了有力保障,为业务优化调整及新业务的开展带来巨大收益。

  通过服务封装和严格分离,为电商平台实现高伸缩性打下坚实基础。实现高伸缩性的主要工作集中在服务内部,对客户端影响的评估和改造工作也变得非常清晰。这将大大降低了实现高伸缩性的难度、工作量和实施周期。

  Dubbo是阿里提供的一个优秀的开源服务框架,在高并发情况下具有优秀的性能表现,海尔电商的SOA架构全面基于Dubbo服务框架。关于Dubbo框架的详细介绍可以参考GitHub上的Dubbo项目文档。下面对Dubbo框架工作机制进行简单介绍。

  如图1所示,每个服务提供者启动时都会注册到注册中心,并且通过长连接与注册中心保持心跳检测。这样注册中心就拥有一份完整、可用的服务提供者清单,某个服务提供者下线或由于故障中断,注册中心都能感知到并从清单中删除这个提供者。消费者启动时从注册中心获得服务提供者清单,并与提供者建立长连接,后续直接调用服务提供者,不再经过注册中心,避免注册中心成为瓶颈。每个消费者同样与注册中心保持长连接,这样有新的提供者注册或者某个提供者下线,都由注册中心通知到每个消费者。消费者在调用服务提供者时支持各种负载均衡和故障容错策略。监控中心则负责运行状态统计,例如每分钟的调用次数和平均耗时等。

图1  Dubbo服务部署架构示意图

  Dubbo框架不仅实现了高性能、高可用性,而且使用方便,扩展性非常好。海尔电商所有服务都基于Dubbo框架开发,图2是系统整体SOA架构情况。

图2  海尔电商SOA架构示意图

  鱼与熊掌兼得的产品服务架构

  面临的挑战

  产品的检索和展示在电商平台中具有举足轻重的地位,贯穿用户浏览、购物整个过程,以及订单交付全流程。产品服务需要为整个平台提供数据请求和检索服务,而各品类的产品差异性非常大,这给产品服务设计带来了巨大的挑战。

  • 负载权重高。电商平台中几乎每一个前台页面都与产品展示和检索相关,产品服务的负载在整个平台中占比非常高,对产品服务的请求量可能达到整站流量的几倍、几十倍。在电商活动高峰期间,核心系统中首当其冲的便是产品服务。因此,产品服务的设计必须满足高可用性,并且实现良好的性能和高伸缩性。
  • 产品差异性大。不同品类的产品具有不同维度的属性和规格参数,产品结构的设计必须具备足够的通用性和灵活性,才能良好地满足电商平台多品类运营的要求,以及在平台、品类扩展时可以提供快速的响应支持。
  • 全方位检索、排序。让用户方便快捷地在大量产品中找到自己满意的产品,是电商平台用户体验和信息架构中非常关键的一点。除了关键词搜索、按类目检索浏览之外,还需要提供按常用属性进行检索。在深入优化用户体验时,可能会提出更复杂的检索处理逻辑,例如组合属性检索,自动根据检索结果反过滤掉无结果的类目和属性,展示符合各个属性条件的商品个数,以及实时地结合大数据分析结果添加更多自动化、智能化的策略等。

  将页面或者部分页面的静态化是一种非常有效的优化方式,可以极大地降低对后台服务和数据的请求。但静态化带来的最大弊端就是服务端丧失了控制力,使得一些深入的自动化、智能化策略难以应用。因此,我们希望通过提升服务端的性能和伸缩性,来避免静态化的方案。

  性能和伸缩性是电商平台的关键指标。为了保障系统性能和伸缩性,不少时候我们需要牺牲或者完全拒绝某些功能,或者降低系统的灵活性和扩展性等。在产品服务架构设计阶段,我们努力思考和研究着一种可以鱼和熊掌兼得的解决方案。

  解决方案

  如图3所示,在数据库层允许复杂的产品存储结构设计,以细粒度、深度优化的关系模型充分实现产品数据模型的通用性、可扩展性。在数据模型设计时完全不用关心客户端检索查找的复杂性和性能问题。

图3  产品服务逻辑架构示意图

  产品查询引擎将复杂的数据存储模型封装成一个简单的逻辑模型。这个逻辑模型实现的效果,完全等同于产品的所有属性都存储在同一张数据库表中,逻辑模型的每个属性对应数据库表中的一个字段。在这个逻辑模型的基础上实现了一个简洁的DSL,供客户端进行检索查询。客户端工作在逻辑模型和DSL之上,检索查询简单、灵活,同样完全不用关心产品数据存储模型的复杂性和性能问题。

  产品查询语言DSL

  产品查询语言DSL的语法类似SQL中的where条件语法,任何一个开发人员都很容易掌握。客户端将DSL表达式传给服务端,即可得到满足条件的产品列表及相关属性数据(图4)。

图4  查询语言DSL工作原理

  DSL还支持中文语法,更方便使用,尤其对于业务人员进行复杂的后台检索查询,或者为前台页面及栏位设置产品展示的过滤条件等情况。

产品查询引擎

  图5描述了查询引擎的核心组件及关键的执行流、数据流。编译器基于Antlr开发,职责是将DSL表达式编译为语法树,并完成一系列编译优化操作。执行引擎使用语法树逐个对产品进行匹配,得到符合条件的产品列表。智能排序引擎基于产品综合竞争力评估模型,为结果集进行排序,实现最大化提升转换率的目的。结果构造器则根据客户端在调用服务时指定的要求,将客户端所需属性加载到结果集中。

图5  查询引擎工作机制

  在服务启动时将产品数据缓存到内存中,通过订阅MQ消息队列,在数据发生变化时刷新有变化的数据。

  产品服务架构

  产品服务分不同集群进行部署,面向Web应用和其他服务的集群在运行期间几乎不会产生数据库请求,因此不管网站访问量和交易量多高,数据库都不会产生压力瓶颈。在系统峰值期间,只需为Web和服务添加服务器即可,实现了高伸缩目标。

  效果

  • 性能:最高峰值2.6亿次/天,平均耗时60毫秒/次,后续对编译器和执行引擎进行优化,性能还有更大的提升空间。
  • 伸缩性:在一定条件下接近线性伸缩,所有使用产品服务的地方无须出于性能和系统压力原因额外设计其他方案,直接调用产品服务即可。
  • 通用性:不会因为电商平台性能和伸缩性要求而受到任何限制,可以像开发内部管理系统PDM一样设计产品数据模型,并且直接用于其他在线服务和前台Web应用,尽可能达到通用灵活的目的。
  • 扩展性:通过逻辑模型屏蔽了底层的数据模型,将数据模型的优化、扩展工作量以及影响范围降低到最小限度,提升了电商平台中产品服务的可维护性和扩展性。

  以查询引擎为核心的产品服务是一个鱼与熊掌兼得的架构设计案例,通用性、扩展性、伸缩性等在电商平台中相互制约、矛盾的一组核心架构目标全部得到满足。

  作者刘志斌,海尔电商首席架构师,资深技术控,10多年专注于供应链和电商领域,曾先后在麦考林和麦包包任职架构师。

时间: 03-08

海尔电商峰值系统架构设计最佳实践的相关文章

小型电商网站的架构

小型电商网站的架构 又是一年年底了,这一年,从传统软件行业进入到电商企业,算是一次转行了吧.刚开始,觉得电商网站没有什么技术含量,也没有什么门槛,都是一些现有的东西堆积木似的堆出来而已.然而,真正进入到这个行业之后,才发现并不是这样.记得有人说过,好的架构,是演化出来的.电商网站的架构也是如此,现在牛逼的电商网站,看似很复杂,很牛逼,其实也是从很小的架构,也是从没什么技术含量开始的.架构的演化过程,就是在技术团队,不断追求极致的过程. 今天就来总结总结小型电商网站的架构,一套电商系统最初期的架构

Unity3D手游开发日记(2) - 技能系统架构设计

我想把技能做的比较牛逼,所以项目一开始我就在思考,是否需要一个灵活自由的技能系统架构设计,传统的技能设计,做法都是填excel表,技能需要什么,都填表里,很死板,比如有的技能只需要1个特效,有的要10个,那么表格也得预留10个特效的字段.在代码里面也是写死一些东西,要增加和修改,就得改核心代码,如果我要把核心部分做成库封装起来,就很麻烦了. 能不能做成数据驱动的方式呢? 改技能文件就行了,即使要增加功能,也只需要扩展外部代码,而不用改核心代码, 我是这么来抽象一个技能的,技能由一堆触发器组成,比

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

电商网站产品数据库设计

1.最近在自学java,想用java+mysql做一个小小的电商项目实例,首先设计出产品相关的数据表,如下图 2.平常设计的话都会把产品的属性放到产品表,比如颜色.规格.尺码等.不过我把属性单独拿出两张表,一张表存属性名,一张表存属性值. 3.本来考虑要品牌表的,但是后来想想品牌可以放到属性表里,把产品当成一个属性存进P_Property表,然后把品牌对应的值存到属性值表中. 4.不知道这么设计有没有欠缺的地方,再此抛砖引玉,希望能有电商方面的大神前来指导.

秒杀系统架构设计

秒杀活动的用户量可能是网站平时正常访问量的数百甚至上千倍,网站如果为了秒杀时的最高并发量而设计部署,就需要比正常运营多的多的服务器,而这些服务器在绝大部分时候都是用不着的,浪费惊人.所以秒杀业务不能使用正常网站的业务流程,也不能与正常网站业务共用服务器,必须设计部署专门的秒杀系统. 秒杀系统所面对的技术挑战: 1.对现有业务造成冲击 2.高并发下的应用.数据库负载 3.突然增加的网络及服务器带宽 4.直接下单 秒杀规则是到点了才能下单,而下单页面也只是一个普通的url,如果得到这个url则不用等

petshop4.0 具体解释之中的一个(系统架构设计)

前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力.业界有很多.Net与J2EE之争,很多数据是从微软的PetShop和Sun的PetStore而来.这样的争论不可避免带有浓厚的商业色彩,对于我们开发者而言,没有必要过多关注.然而PetShop随着版本号的不断更新,至如今基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又非常多能够借鉴之处.PetShop是一个小型的项目,系统架构与代码都比較简单,却也凸现了很多颇有价值的设计与开发理念.本系列试

高可用、高扩展、低延迟交易处理系统架构设计

为实现一个高TPS.高可靠性.高扩展性.低响应延迟的交易处理系统,在系统架构设计上,需要有诸多考虑.  1. 交易处理系统的功能 交易系统是用于连接多个不同的交易请求系统(上游系统)与交易受理系统(下游系统),在这些交易上下游系统之间传递不同格式的交易报文.同时一个交易请求可能需要发送多个不同的子交易请求到不同的交易受理系统,交易处理系统还负责子交易的拆分.交易完整性与一致性保证. 一个典型的交易处理系统,往往需要支持多种不同的通信协议(TCP长连接.TCP短链接.CTG.CICS.MQ等),支

最近整理的关于电商峰值系统设计的一些要点

最近整理的关于电商峰值系统设计的一些要点,老是想写些东西,先酝酿一下^_^

NET ERP系统架构设计

解析大型.NET ERP系统架构设计 Framework+ Application 设计模式 我对大型系统的理解,从数量上面来讲,源代码超过百万行以上,系统有超过300个以上的功能,从质量上来讲系统应该具备良好的可扩展性和可维护性,系统中的功能紧密关联.除去业务上的复杂性,如何设计这样的一个协作良好的系统,搭建开发人员基础平台,一直是我研究的方向. SouceCounter(版本3.3.91.79)对源代码的统计信息如下: 下面来详细解析一下这个系统的设计架构,纯.NET技术架构方案,C/S W