电商商品详情页演进历程

今天给大家分享下电商商品详情页演进过程。在电商系统中，电商详情页是最重要的一个模块。接下来给大家讲从小型电商商品详情页到大型电商商品详情页的整体设计思路。以图文结合的形式给大家进行讲解。

第一版的电商详情页的设计比较简单，看下图

一台nginx+电商web应用+数据库
用户访问我们的页面，请求先到nginx上，nginx把请求分发到电商web应用，电商web应用到数据库获取用户请求的数据，电商web应用返回html给用户。随着业务的推广，用户量越来越大，整体服务开始扛不住了，你开始加电商web应用，但是成本有限，你不可能无限的加机器，还有数据库的压力变动非常大，那么就需要进行系统优化。

这时候，我们需要对系统进行重构。重构的思路是访问静态页面速度会快很多，数据库的压力也会减少。

如上图所示，会有几个系统来完成这个事情，1、数据监听服务；2、渲染html模板服务；

数据监听服务作用：实时的监听数据库商品数据的变化。（ps：当然也可以手动触发商品html的生成，只是每次都需要人工处理）
渲染html模板服务：这里保存着商品详情页的模板，只要将相应的数据填充到html模板里面，就生成html文件，然后把这些html文件上传到nginx服务器上面。
nginx服务器：该服务器里面保存着商品详情页的html文件，用户访问某个页面的时候，直接把html返回给用户。

这样数据库的压力就小很多了，web服务器的压力也小很多，压力都在nginx上，html是在nginx机器上，没有机器之前的io，响应速度也是很快的。但是这个方案也是有缺点的，最大的缺点就是，如果你有上亿商品的时候，商品模板变了，这时你生成商品html代码就要好久好久，还有时效性也会变差。这套方案适合小型电商商品详情页，你的商品没那么多，如果你能忍受时效性差，那你可以使用。这时候我们又要对系统进行重构了。

重构后的系统设计包括以下几个模块

简单说明下几个系统要做的事情：
nginx服务：保存着html模板和商品本地数据。
redis：保存着商品的数据。
缓存数据服务：把数据保存到redis和ehcache里面，同时监听MQ，商品数据有变动马上就知道，然后调用商品服务。
商品服务：从数据库获取商品信息，并通知MQ。
MQ：消息队列，商品有变动通知订阅者。

以下是时序图：

上图是整个流程跳转，看图比用文字描述要清晰的多

这个方案，可以抗住上亿的流程，如果你的模板改了，只要在nginx上面修改掉模板，用户就可以马上看到了。使用了多级缓存，在高并发上也没有任何问题。
这个方案的缺点是，数据具有一点的延迟性，因为nginx本地缓存有一个失效时间。但是商品详情页绝大多数的数据的实时性不是那么高。如果实时性要求很高的话，就不要在nginx上做数据缓存，直接从redis上面取，redis上的数据是实时更新的。一个商品详情页中必须要实时展示的数据是很少的。

那么到这里，电商商品详情页的系统已经介绍完了。这里在说下，系统是随着你的业务慢慢演进的，就像taobao,jd他们也是从小系统慢慢演变成大系统。你可以结合自己现在所处的阶段，对比着看以上方案，希望能给你带来帮助。如果有写的不对的地方，请指正。