## 單品頁技術架構發展
[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獲取的而非關系的我們都可以提供服務，我們叫做動態服務系統。??
該動態服務分為前端和后端，即公網還是內網，如目前該動態服務為列表頁、商品對比、微信單品頁、總代等提供相應的數據來滿足和支持其業務。
