四、单品页技术架构发展
最后更新于：2022-04-01 03:02:53
## 单品页技术架构发展
[TOC=3,3]
### 架构1.0
IIS+C#+Sql Server，最原始的架构，直接调用商品库获取相应的数据，扛不住时加了一层memcached来缓存数据。这种方式经常受到依赖的服务不稳定而导致的性能抖动。
### 架构2.0
该方案使用了静态化技术，按照商品维度生成静态化HTML。主要思路：
1、通过MQ得到变更通知；
2、通过Java Worker调用多个依赖系统生成详情页HTML；
3、通过rsync同步到其他机器；
4、通过Nginx直接输出静态页；
5、接入层负责负载均衡。
该方案的主要缺点：
1、假设只有分类、面包屑变更了，那么所有相关的商品都要重刷；
2、随着商品数量的增加，rsync会成为瓶颈；
3、无法迅速响应一些页面需求变更，大部分都是通过JavaScript动态改页面元素。
随着商品数量的增加这种架构的存储容量到达了瓶颈，而且按照商品维度生成整个页面会存在如分类维度变更就要全部刷一遍这个分类下所有信息的问题，因此我们又改造了一版按照尾号路由到多台机器。
主要思路：
1、容量问题通过按照商品尾号做路由分散到多台机器，按照自营商品单独一台，第三方商品按照尾号分散到11台；
2、按维度生成HTML片段（框架、商品介绍、规格参数、面包屑、相关分类、店铺信息），而不是一个大HTML；
3、通过Nginx SSI合并片段输出；
4、接入层负责负载均衡；
5、多机房部署也无法通过rsync同步，而是使用部署多套相同的架构来实现。
该方案主要缺点：
1、碎片文件太多，导致如无法rsync；
2、机械盘做SSI合并时，高并发时性能差，此时我们还没有尝试使用SSD；
3、模板如果要变更，数亿商品需要数天才能刷完；
4、到达容量瓶颈时，我们会删除一部分静态化商品，然后通过动态渲染输出，动态渲染系统在高峰时会导致依赖系统压力大，抗不住；
5、还是无法迅速响应一些业务需求。
#### 我们的痛点
1、之前架构的问题存在容量问题，很快就会出现无法全量静态化，还是需要动态渲染；不过对于全量静态化可以通过分布式文件系统解决该问题，这种方案没有尝试；
2、最主要的问题是随着业务的发展，无法满足迅速变化、还有一些变态的需求。
### 架构3.0
我们要解决的问题：
1、能迅速响瞬变的需求，和各种变态需求；
2、支持各种垂直化页面改版；
3、页面模块化；
4、AB测试；
5、高性能、水平扩容；
6、多机房多活、异地多活。
主要思路：
1、数据变更还是通过MQ通知；
2、数据异构Worker得到通知，然后按照一些维度进行数据存储，存储到数据异构JIMDB集群（JIMDB：Redis+持久化引擎），存储的数据都是未加工的原子化数据，如商品基本信息、商品扩展属性、商品其他一些相关信息、商品规格参数、分类、商家信息等；
3、数据异构Worker存储成功后，会发送一个MQ给数据同步Worker，数据同步Worker也可以叫做数据聚合Worker，按照相应的维度聚合数据存储到相应的JIMDB集群；三个维度：基本信息（基本信息+扩展属性等的一个聚合）、商品介绍（PC版、移动版）、其他信息（分类、商家等维度，数据量小，直接Redis存储）；
4、前端展示分为两个：商品详情页和商品介绍，使用Nginx+Lua技术获取数据并渲染模板输出。
另外我们目前架构的目标不仅仅是为商品详情页提供数据，只要是Key-Value获取的而非关系的我们都可以提供服务，我们叫做动态服务系统。
该动态服务分为前端和后端，即公网还是内网，如目前该动态服务为列表页、商品对比、微信单品页、总代等提供相应的数据来满足和支持其业务。