Hybris E-commerce网站性能条用 主讲嘉宾hui 来源

2016-03-20 20:56:00
hainuo
转贴:
中国架构师讲坛
1391
![](https://blog.hainuo.info/data/upload/201603/f_943595c6cac8a535903c0cf71c589f92.jpg) SAP 在2014年收购了HYBRIS,所以SAP已经在电商行业内处于领军人物的较色。 JDA是另外一家重要的电商解决方案平台,从IBM剥离出,也是出于领军较色。 SAP从今年开始会逐步推广Hybris。 ![](https://blog.hainuo.info/data/upload/201603/f_bac490c5bfd423fc7af443e9b52239da.png) Ommi channle是全渠道,为用户提供网上,APP, 微信,支付宝等渠道,用户可以通过其中任何一种渠道,享受一样的购物体验。 ![](https://blog.hainuo.info/data/upload/201603/f_7be261272954a8836ffb9ac3cbddff71.jpg) Hybris 提供相关接口进行二次开发 这是Hybris的平台全图 其中PCM是产品管理,WCMS 是网站内容管理(主要是页面,图片,动画等),一般电商平台都有类似的功能 平台层里,最重要的是Caching, 特别对于性能尤其重要,因为Hybris的性能主要依赖于缓存。 当然大家可以看到ECLIPS,所以Hybris是基于JAVA 的。Hybris可以基于多种数据库,从项目实践来看,ORACLE上性能表现较好,SAP 也在努力提升HYBRIS 与HANA 数据库的整合。 下面给大家介绍下PCM的基本信息 其实大家再网站上看到的信息,一般都成为ONLINE DATA ![](https://blog.hainuo.info/data/upload/201603/f_fbb21eeb23d2969d666d6cdf4b3d9a11.jpg) 而在PCM里,需要维护STAGE DATA, 只有当SATGE DATA 被批准后,才会同步到online 上,这个过程叫stage to online, 这是为了避免业务操作直接修改 online 数据,因为任何online 数据的修改,会直接反映在网站上。 除了Stage to online,还有一个重要的PCM功能就是目录管理 ![](https://blog.hainuo.info/data/upload/201603/f_ad7fee91eb73cc5da1962f253a665035.jpg) 一般客户的业务部门可以维护多个版本的目录,目录下可以有多种产品种类等等。当然这些数据也是有Stage to online的概念的。 也就是业务部门可以在后台Stage 里维护多产品信息,但只同步需要发布产品to online, 如果产品下架也可以通过同步online操作 所以Hybris 可以非常灵活的管理相关产品信息,一般都是由公司的业务或市场部门的团队进行操作 WCMS: 网页内容管理 ![](https://blog.hainuo.info/data/upload/201603/f_96dffc70279a4ea498ebd206a6a9d38d.jpg) ![](https://blog.hainuo.info/data/upload/201603/f_32a4d8ebed7e2bfd9748b1faf4a51e34.jpg) 这块就是帮助大家搭建电商网站页面 hybris是提供了相关的模板,组建,可供选择,大家也可以上传相关的图片。 大家也可以上传相关的图片,![](https://blog.hainuo.info/data/upload/201603/f_27c4f5a074c4526cd2a1cc73c464e783.jpg) 下面我给大家介绍下性能调优的一些实践,一般我们会对java 代码做相关的traces。 JAVA代码,我们可以用一些动态工具,比如wily, dynatrace 等用户可以在前台进行相关的步骤操作(比如选择产品,加购物车,下单),后台的程序执行和时间都会被记录下来。 ![](https://blog.hainuo.info/data/upload/201603/f_29f61cf0e4b3197a2a257aa3297e78a9.png) 然后我们会将比较花时间的方法找出,在源代码里进行分析,一般的原则是,减少数据库执行。因为hybris的数据库查询SQL是动态生成的(我们成为flexible search,由对象populator产生),所以SQL语句的具体产生是BLACK BOX。现在由于很多项目都是AGILE模式,很多程序员为了完成自己的STORY,所以在方法调用上并没有精简,很多方法被重复调用,这会产生大量的flexible search,性能也会降低了。一般我们认为flexible search 对于大型网站,一个步骤尽量控制在500次调用以下,如果是小型网站,100次一下,当然这种性能提高也是很微观的,一般在0.2秒到0.5秒 每步,不过一般客户或者大型电商对于性能也是苛刻的,0.5秒的性能提高也是很不容易的, ![](https://blog.hainuo.info/data/upload/201603/f_2295087e249b78fbc6a3f349b029c7ad.png) 一个例子关于call traces, 标红的就是flexible search 除了用第三方工具做代码分析外,我们还可以通过hybris自带的jdbc trace分析。![](https://blog.hainuo.info/data/upload/201603/f_52ee4c10e381a03bdb179b49be6df71b.png) JDBC信息比较全,但信息量大,所以一般是结合一起看,在我遇到的一个项目里,flexible search 产生的SQL语句都有5到6个页面这么长,一般只能通过JDBC trace能看全。![](https://blog.hainuo.info/data/upload/201603/f_9bd2b7092d33a604510d758444443730.png) 一个简单的JDBC例子 ![](https://blog.hainuo.info/data/upload/201603/f_f10788d797a7394ce14a639522514408.png) ![](https://blog.hainuo.info/data/upload/201603/f_79af9593376fc42c54fc2d66404ba956.png) 相关信息解释 下面一个就是cahce ,cache 非常重要,因为cache 的优化,可以对性能有很大的提高,原则是希望数据查询都通过cache, ![](https://blog.hainuo.info/data/upload/201603/f_bd9dcc3330526ba2ea8b985ebe77ed7a.png) Hybris 是自带标准cache的,但我们需要根据项目的实际需求,增加或减少cache 种类,一般都应该增加,并且挑战size 首先,cache 的策略,建议使用LRU,因为这样可以将最常使用的信息在cache 里保存时间最久 cache 的 eviction item很重要,evitions item 意味着 cache size 不够了,有很多信息被剔出。这个时候就要考虑增加size。但这个会有一个数据不一致性的问题,因为很多时候,业务部门是会更改后台的数据库的信息,尤其是价格信息,如果所有查询都一直从cache 里拿,那么新的价格信息是不生效的。建议用脚本清理cache ,在新的数据生成之前。而且目前的hybris版本是不会将cache 里的信息 invalidate的,也就是是说数据库更新数据, hybris 不会被通知到并主动invalide cache 信息,我们一般会将expensive SQL 返回结果,给他们创建独立的cache 空间,这是一个项目里,我们通过代码分析取得的一些expensive sql 返回的结果。 ![](https://blog.hainuo.info/data/upload/201603/f_86c912086023000c0a693d33fdf540d4.png) 那么可以给他们开创独立的空间 ![](https://blog.hainuo.info/data/upload/201603/f_25dc848124c3046bdfbaf37e4e41e264.png) 大家觉得好可以扫码打赏 ![](https://blog.hainuo.info/data/upload/201603/f_0d8fd0f0e1ca691208b3f467afb2832c.png)