四、單品頁技術架構發(fā)展

單品頁技術架構發(fā)展

架構1.0

IIS+C#+Sql Server，最原始的架構，直接調用商品庫獲取相應的數(shù)據(jù)，扛不住時加了一層memcached來緩存數(shù)據(jù)。這種方式經(jīng)常受到依賴的服務不穩(wěn)定而導致的性能抖動。

架構2.0

該方案使用了靜態(tài)化技術，按照商品維度生成靜態(tài)化HTML。主要思路：

1、通過MQ得到變更通知；

2、通過Java Worker調用多個依賴系統(tǒng)生成詳情頁HTML；

3、通過rsync同步到其他機器；

4、通過Nginx直接輸出靜態(tài)頁；

5、接入層負責負載均衡。

該方案的主要缺點：

1、假設只有分類、面包屑變更了，那么所有相關的商品都要重刷；

2、隨著商品數(shù)量的增加，rsync會成為瓶頸；

3、無法迅速響應一些頁面需求變更，大部分都是通過JavaScript動態(tài)改頁面元素。

隨著商品數(shù)量的增加這種架構的存儲容量到達了瓶頸，而且按照商品維度生成整個頁面會存在如分類維度變更就要全部刷一遍這個分類下所有信息的問題，因此我們又改造了一版按照尾號路由到多臺機器。

主要思路：

1、容量問題通過按照商品尾號做路由分散到多臺機器，按照自營商品單獨一臺，第三方商品按照尾號分散到11臺；

2、按維度生成HTML片段（框架、商品介紹、規(guī)格參數(shù)、面包屑、相關分類、店鋪信息），而不是一個大HTML；

3、通過Nginx SSI合并片段輸出；

4、接入層負責負載均衡；

5、多機房部署也無法通過rsync同步，而是使用部署多套相同的架構來實現(xiàn)。

該方案主要缺點：

1、碎片文件太多，導致如無法rsync；

2、機械盤做SSI合并時，高并發(fā)時性能差，此時我們還沒有嘗試使用SSD；

3、模板如果要變更，數(shù)億商品需要數(shù)天才能刷完；

4、到達容量瓶頸時，我們會刪除一部分靜態(tài)化商品，然后通過動態(tài)渲染輸出，動態(tài)渲染系統(tǒng)在高峰時會導致依賴系統(tǒng)壓力大，抗不??；

5、還是無法迅速響應一些業(yè)務需求。

我們的痛點

1、之前架構的問題存在容量問題，很快就會出現(xiàn)無法全量靜態(tài)化，還是需要動態(tài)渲染；不過對于全量靜態(tài)化可以通過分布式文件系統(tǒng)解決該問題，這種方案沒有嘗試；

2、最主要的問題是隨著業(yè)務的發(fā)展，無法滿足迅速變化、還有一些變態(tài)的需求。

架構3.0

我們要解決的問題：

1、能迅速響瞬變的需求，和各種變態(tài)需求；

2、支持各種垂直化頁面改版；

3、頁面模塊化；

4、AB測試；

5、高性能、水平擴容；

6、多機房多活、異地多活。

主要思路：

1、數(shù)據(jù)變更還是通過MQ通知；

2、數(shù)據(jù)異構Worker得到通知，然后按照一些維度進行數(shù)據(jù)存儲，存儲到數(shù)據(jù)異構JIMDB集群（JIMDB：Redis+持久化引擎），存儲的數(shù)據(jù)都是未加工的原子化數(shù)據(jù)，如商品基本信息、商品擴展屬性、商品其他一些相關信息、商品規(guī)格參數(shù)、分類、商家信息等；

3、數(shù)據(jù)異構Worker存儲成功后，會發(fā)送一個MQ給數(shù)據(jù)同步Worker，數(shù)據(jù)同步Worker也可以叫做數(shù)據(jù)聚合Worker，按照相應的維度聚合數(shù)據(jù)存儲到相應的JIMDB集群；三個維度：基本信息（基本信息+擴展屬性等的一個聚合）、商品介紹（PC版、移動版）、其他信息（分類、商家等維度，數(shù)據(jù)量小，直接Redis存儲）；

4、前端展示分為兩個：商品詳情頁和商品介紹，使用Nginx+Lua技術獲取數(shù)據(jù)并渲染模板輸出。

另外我們目前架構的目標不僅僅是為商品詳情頁提供數(shù)據(jù)，只要是Key-Value獲取的而非關系的我們都可以提供服務，我們叫做動態(tài)服務系統(tǒng)。  

該動態(tài)服務分為前端和后端，即公網(wǎng)還是內(nèi)網(wǎng)，如目前該動態(tài)服務為列表頁、商品對比、微信單品頁、總代等提供相應的數(shù)據(jù)來滿足和支持其業(yè)務。