## 詳情頁架構設計原則
[TOC=3,3]
### 數據閉環
?數據閉環即數據的自我管理，或者說是數據都在自己系統里維護，不依賴于任何其他系統，去依賴化；這樣得到的好處就是別人抖動跟我沒關系。
數據異構，是數據閉環的第一步，將各個依賴系統的數據拿過來，按照自己的要求存儲起來；
數據原子化，數據異構的數據是原子化數據，這樣未來我們可以對這些數據再加工再處理而響應變化的需求；
數據聚合，將多個原子數據聚合為一個大JSON數據，這樣前端展示只需要一次get，當然要考慮系統架構，比如我們使用的Redis改造，Redis又是單線程系統，我們需要部署更多的Redis來支持更高的并發，另外存儲的值要盡可能的小；
數據存儲，我們使用JIMDB，Redis加持久化存儲引擎，可以存儲超過內存N倍的數據量，我們目前一些系統是Redis+LMDB引擎的存儲，目前是配合SSD進行存儲；另外我們使用Hash Tag機制把相關的數據哈希到同一個分片，這樣mget時不需要跨分片合并。
我們目前的異構數據時鍵值結構的，用于按照商品維度查詢，還有一套異構時關系結構的用于關系查詢使用。
詳情頁架構設計原則?/?數據維度化
對于數據應該按照維度和作用進行維度化，這樣可以分離存儲，進行更有效的存儲和使用。我們數據的維度比較簡單：
1、商品基本信息，標題、擴展屬性、特殊屬性、圖片、顏色尺碼、規格參數等；
2、商品介紹信息，商品維度商家模板、商品介紹等；
3、非商品維度其他信息，分類信息、商家信息、店鋪信息、店鋪頭、品牌信息等；
4、商品維度其他信息（異步加載），價格、促銷、配送至、廣告詞、推薦配件、最佳組合等。?
### 拆分系統
?將系統拆分為多個子系統雖然增加了復雜性，但是可以得到更多的好處，比如數據異構系統存儲的數據是原子化數據，這樣可以按照一些維度對外提供服務；而數據同步系統存儲的是聚合數據，可以為前端展示提供高性能的讀取。而前端展示系統分離為商品詳情頁和商品介紹，可以減少相互影響；目前商品介紹系統還提供其他的一些服務，比如全站異步頁腳服務。
### Worker無狀態化+任務化?
1、數據異構和數據同步Worker無狀態化設計，這樣可以水平擴展；
2、應用雖然是無狀態化的，但是配置文件還是有狀態的，每個機房一套配置，這樣每個機房只讀取當前機房數據；
3、任務多隊列化，等待隊列、排重隊列、本地執行隊列、失敗隊列；
4、隊列優先級化，分為：普通隊列、刷數據隊列、高優先級隊列；例如一些秒殺商品會走高優先級隊列保證快速執行；
5、副本隊列，當上線后業務出現問題時，修正邏輯可以回放，從而修復數據；可以按照比如固定大小隊列或者小時隊列設計；
6、在設計消息時，按照維度更新，比如商品信息變更和商品上下架分離，減少每次變更接口的調用量，通過聚合Worker去做聚合。
### 異步化+并發化
?我們系統大量使用異步化，通過異步化機制提升并發能力。首先我們使用了消息異步化?進行系統解耦合，通過消息通知我變更，然后我再調用相應接口獲取相關數據；之前老系統使用同步推送機制，這種方式系統是緊耦合的，出問題需要聯系各個負責人重新推送還要考慮失敗重試機制。數據更新異步化 ，更新緩存時，同步調用服務，然后異步更新緩存。可并行任務并發化， 商品數據系統來源有多處，但是可以并發調用聚合，這樣本來串行需要1s的經過這種方式我們提升到300ms之內。異步請求合并，異步請求做合并，然后一次請求調用就能拿到所有數據。前端服務異步化/聚合，實時價格、實時庫存異步化， 使用如線程或協程機制將多個可并發的服務聚合。異步化還一個好處就是可以對異步請求做合并，原來N次調用可以合并為一次，還可以做請求的排重。
### 多級緩存化
瀏覽器緩存，當頁面之間來回跳轉時走local cache，或者打開頁面時拿著Last-Modified去CDN驗證是否過期，減少來回傳輸的數據量；
CDN緩存，用戶去離自己最近的CDN節點拿數據，而不是都回源到北京機房獲取數據，提升訪問性能；
服務端應用本地緩存，我們使用Nginx+Lua架構，使用HttpLuaModule模塊的shared dict做本地緩存（?reload不丟失）或內存級Proxy Cache，從而減少帶寬；
另外我們還使用使用一致性哈希（如商品編號/分類）做負載均衡內部對URL重寫提升命中率；
我們對mget做了優化，如去商品其他維度數據，分類、面包屑、商家等差不多8個維度數據，如果每次mget獲取性能差而且數據量很大，30KB以上；而這些數據緩存半小時也是沒有問題的，因此我們設計為先讀local cache，然后把不命中的再回源到remote cache獲取，這個優化減少了一半以上的remote cache流量；
服務端分布式緩存，我們使用內存+SSD+JIMDB持久化存儲。
### 動態化
數據獲取動態化，商品詳情頁：按維度獲取數據，商品基本數據、其他數據（分類、商家信息等）；而且可以根據數據屬性，按需做邏輯，比如虛擬商品需要自己定制的詳情頁，那么我們就可以跳轉走，比如全球購的需要走jd.hk域名，那么也是沒有問題的；
模板渲染實時化，支持隨時變更模板需求；
重啟應用秒級化，使用Nginx+Lua架構，重啟速度快，重啟不丟共享字典緩存數據；
需求上線速度化，因為我們使用了Nginx+Lua架構，可以快速上線和重啟應用，不會產生抖動；另外Lua本身是一種腳本語言，我們也在嘗試把代碼如何版本化存儲，直接內部驅動Lua代碼更新上線而不需要重啟Nginx。
### 彈性化
我們所有應用業務都接入了Docker容器，存儲還是物理機；我們會制作一些基礎鏡像，把需要的軟件打成鏡像，這樣不用每次去運維那安裝部署軟件了；未來可以支持自動擴容，比如按照CPU或帶寬自動擴容機器，目前京東一些業務支持一分鐘自動擴容。
### 降級開關
推送服務器推送降級開關，開關集中化維護，然后通過推送機制推送到各個服務器；
可降級的多級讀服務，前端數據集群--->數據異構集群--->動態服務(調用依賴系統)；這樣可以保證服務質量，假設前端數據集群壞了一個?磁盤，還可以回源到數據異構集群獲取數據；
開關前置化，如Nginx--àTomcat，在Nginx上做開關，請求就到不了后端，減少后端壓力；
可降級的業務線程池隔離，從Servlet3開始支持異步模型，Tomcat7/Jetty8開始支持，相同的概念是Jetty6的Continuations。我們可以把處理過程分解為一個個的事件。通過這種將請求劃分為事件方式我們可以進行更多的控制。如，我們可以為不同的業務再建立不同的線程池進行控制：即我們只依賴tomcat線程池進行請求的解析，對于請求的處理我們交給我們自己的線程池去完成；這樣tomcat線程池就不是我們的瓶頸，造成現在無法優化的狀況。通過使用這種異步化事件模型，我們可以提高整體的吞吐量，不讓慢速的A業務處理影響到其他業務處理。慢的還是慢，但是不影響其他的業務。我們通過這種機制還可以把tomcat線程池的監控拿出來，出問題時可以直接清空業務線程池，另外還可以自定義任務隊列來支持一些特殊的業務。
### 多機房多活
應用無狀態，通過在配置文件中配置各自機房的數據集群來完成數據讀取。
數據集群采用一主三從結構，防止當一個機房掛了，另一個機房壓力大產生抖動。
### 多種壓測方案
線下壓測，Apache ab，Apache Jmeter，這種方式是固定url壓測，一般通過訪問日志收集一些url進行壓測，可以簡單壓測單機峰值吞吐量，但是不能作為最終的壓測結果，因為這種壓測會存在熱點問題；
線上壓測，可以使用Tcpcopy直接把線上流量導入到壓測服務器，這種方式可以壓測出機器的性能，而且可以把流量放大，也可以使用Nginx+Lua協程機制把流量分發到多臺壓測服務器，或者直接在頁面埋點，讓用戶壓測，此種壓測方式可以不給用戶返回內容。
