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

摘要:本文重点介绍了海尔电商平台的架构方案,也用很多篇幅阐述面临的场景和挑战,以及在架构方案决策过程当中的关注点。其实做为一个优秀的电商平台,提供极致的用户体验、让技术最大化地创造价值,才是架构的终极目标。数据库

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

从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应用,尽量达到通用灵活的目的。
  • 扩展性:经过逻辑模型屏蔽了底层的数据模型,将数据模型的优化、扩展工做量以及影响范围下降到最小限度,提高了电商平台中产品服务的可维护性和扩展性。

 

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

相关文章
相关标签/搜索