京東商品詳情頁技術方案在之前這篇文章已經為大家揭秘了，接下來為大家揭秘下雙十一抗下幾十億流量的商品詳情頁統一服務架構。
這次雙十一整個商品詳情頁在流量增長數倍的情況下，沒有出現不可用的情況，服務非常穩定。
統一服務提供了：促銷和廣告詞合并服務、庫存狀態/配送至服務、延保服務、試用服務、推薦服務、圖書相關服務、詳情頁優惠券服務、今日抄底服務等服務支持。
其實就是一個大的網關，提供各種服務。但區別于一般網關，它還提供業務邏輯的處理。這些服務中有我們自己做的服務實現，而有些是簡單做下代理或者接口做了合并輸出到頁面，我們聚合這些服務到一個系統的目的是打造服務閉環，優化現有服務。并為未來需求做準備，跟著自己的方向走，而不被別人亂了我們的方向。這樣一起盡在自己的掌控之中，想怎么玩就看心情了。
大家在頁面中看到的c.3.cn/c0.3.cn/c1.3.cn/cd.jd.com請求都是統一服務的入口。我們分別為有狀態服務和無狀態服務提供了不同的域名，而且域名還做了分區。
為什么需要統一服務？
商品詳情頁雖然只有一個頁面，但是依賴的服務眾多，我們需要把控好入口，一統化管理。
這樣的好處：
統一管理和監控，出問題可以統一降級
可以把一些相關接口合并輸出，減少頁面的異步加載請求
一些前端邏輯后移到服務端，前端只做展示，不進行邏輯處理。
有了它，所有入口都在我們服務中，我們可以更好的監控和思考我們頁面的服務，讓我們能運籌于帷幄之中，決勝于千里之外。
在設計一個高度靈活的系統時，要想著當出現問題時怎么辦：是否可降級、不可降級怎么處理、是否會發送滾雪球問題、如何快速響應異常。完成了系統核心邏輯只是保證服務能工作，服務如何更好更有效或者在異常情況下能正常工作也是我們要深入思考和解決的問題。
整體架構
整體流程
請求首先進入nginx，nginx調用lua進行一些前置邏輯處理，如果前置邏輯不合法直接返回；然后查詢本地緩存，如果命中直接返回數據。
如果本地緩存不命中數據，則查詢分布式redis集群，如果命中數據，則直接返回。
如果分布式redis集群不命中，則會調用tomcat進行回源處理；然后把結果異步寫入redis集群，并返回。
如上是整個邏輯流程，可以看到我們在nginx這一層做了很多前置邏輯處理，以此來減少后端壓力，另外我們redis集群分機房部署，如下圖所示：
即數據會寫一個主集群，然后通過主從方式把數據復制到其他機房，而各個機房讀自己的集群；此處沒有在各個機房做一套獨立的集群來保證機房之間沒有交叉訪問，這樣做的目的是保證數據一致性。
在這套新架構中，我們可以看到nginx lua已經是我們應用的一部分，我們在實際使用中，也是把它做為項目開發，做為應用進行部署。
我們主要遵循如下幾個原則設計系統架構：
兩種讀服務架構模式
本地緩存
多級緩存
統一入口/服務閉環
引入接入層
前端業務邏輯后置
前端接口服務端聚合
服務隔離
兩種讀服務架構模式
讀取分布式redis數據架構
可以看到nginx應用和redis單獨部署，這種方式是一般應用的部署模式，也是我們統一服務的部署模式，此處會存在跨機器、跨交換機或跨機柜讀取redis緩存的情況，但是不存在跨機房情況，因為使用容器化，不太好做不跨機柜的應用了。通過主從把數據復制到各個機房。如果對性能要求不是非常苛刻，可以考慮這種架構，比較容易維護。
讀取本地redis數據架構
可以看到nginx應用和redis集群部署在同一臺機器，這樣好處可以消除跨機器、跨交換機或跨機柜，甚至跨機房調用。如果本地redis集群不命中， 還是回源到tomcat集群進行取數據。此種方式可能受限于tcp連接數，可以考慮使用unix domain socket套接字減少本機tcp連接數。如果單機內存成為瓶頸（比如單機內存最大256gb），就需要路由機制來進行sharding，比如按照商品尾號sharding，redis集群一般采用樹狀結構掛主從部署。
本地緩存
我們把nginx作為應用部署，因此大量使用nginx共享字典作為本地緩存，nginx lua架構中，使用httpluamodule模塊的shared dict做本地緩存（ reload不丟失）或內存級proxy cache，提升緩存帶來的性能并減少帶寬消耗。
之前的詳情頁架構也是采用這種緩存。另外使用一致性哈希（如商品編號/分類）做負載均衡內部對url重寫提升命中率。
在緩存數據時采用了維度化存儲緩存數據，增量獲取失效緩存數據（比如10個數據，3個沒命中本地緩存，只需要取這3個即可）。維度如商家信息、店鋪信息、商家評分、店鋪頭、品牌信息、分類信息等；比如本地緩存30分鐘，調用量減少差不多3倍。
另外使用一致性哈希 本地緩存，如庫存數據緩存5秒，平常命中率：本地緩存25%%uff1b分布式redis28%%uff1b回源47%%u3002一次普通秒殺活動命中率：本地緩存 58%%uff1b分布式redis 15%%uff1b回源27%%u3002而某個服務使用一致哈希后命中率提升10%%u3002對url按照規則重寫作為緩存key，去隨機，即頁面url不管怎么變都不要讓它成為緩存不命中的因素。
多級緩存
對于讀服務，在設計時會使用多級緩存來盡量減少后端服務壓力，在統一服務系統中，設計了四級緩存，如下圖所示：
首先在接入層，會使用nginx本地緩存，這種前端緩存主要目的是抗熱點；根據場景來設置緩存時間。
如果nginx本地緩存不命中，接著會讀取各個機房的分布式從redis緩存集群，該緩存主要是保存大量離散數據，抗大規模離散請求，比如使用一致性哈希來構建redis集群，即使其中的某臺機器出問題，也不會出現雪崩的情況。
如果從redis集群不命中，nginx會回源到tomcat；tomcat首先讀取本地堆緩存，這個主要用來支持在一個請求中多次讀取一個數據或者該數據相關的數據。而其他情況命中率是非常低的，或者緩存一些規模比較小但用的非常頻繁的數據，如分類，品牌數據；堆緩存時間設置為redis緩存時間的一半。
如果java堆緩存不命中，會讀取主redis集群，正常情況該緩存命中率非常低，不到5%%u3002讀取該緩存的目的是防止前端緩存失效之后的大量請求的涌入，導致后端服務壓力太大而雪崩。默認開啟了該緩存，雖然增加了幾毫秒的響應時間，但是加厚了防護盾，使服務更穩當可靠。此處可以做下改善，比如設置一個閥值，超過這個閥值才讀取主redis集群，比如guava就有ratelimiter api來實現。
統一入口/服務閉環
在《億級商品詳情頁架構演進技術解密》中已經講過了數據異構閉環的收益，在統一服務中也遵循這個設計原則，此處主要做了兩件事情
數據異構，如判斷庫存狀態依賴的套裝、配件關系進行了異構，未來可以對商家運費等數據進行異構，減少接口依賴。
服務閉環，所有單品頁上用到的核心接口都接入統一服務。
有些是查庫/緩存然后做一些業務邏輯，有些是http接口調用然后進行簡單的數據邏輯處理；還有一些就是做了下簡單的代理，并監控接口服務質量。
引入nginx接入層
在設計系統時需要把一些邏輯盡可能前置以此來減輕后端核心邏輯的壓力。另外如服務升級/服務降級能非常方便的進行切換，在接入層做了如下事情：
數據校驗/過濾邏輯前置、緩存前置、業務邏輯前置
降級開關前置
ab測試
灰度發布/流量切換
監控服務質量
限流
服務有兩種類型的接口：一種是用戶無關的接口，另一種則是用戶相關的接口。因此使用了兩種類型的域名c.3.cn/c0.3.cn/c1.3.cn和cd.jd.com。
當請求cd.jd.com會帶著用戶cookie信息到服務端。在服務器上會進行請求頭的處理，用戶無關的所有數據通過參數傳遞，在接入層會丟棄所有的請求頭(保留gzip相關的頭)。
而用戶相關的會從cookie中解出用戶信息然后通過參數傳遞到后端；也就是后端應用從來就不關心請求頭及cookie信息，所有信息通過參數傳遞。
請求進入接入層后，會對參數進行校驗，如果參數校驗不合法直接拒絕這次請求。對每個請求的參數進行了最嚴格的數據校驗處理，保證數據的有效性。
如圖所示，我們對關鍵參數進行了過濾，如果這些參數不合法就直接拒絕請求。另外還會對請求的參數進行過濾然后重新按照固定的模式重新拼裝url調度到后端應用。此時url上的參數是固定的而且是有序的，可以按照url進行緩存
緩存前置
很多緩存都前置到了接入層，來進行熱點數據的削峰，而且配合一致性哈希可能提升緩存的命中率。在緩存時按照業務來設置緩存池，減少相互之間的影響和提升并發，使用lua讀取共享字典來實現本地緩存。
業務邏輯前置
在接入層直接實現了一些業務邏輯，原因是當在高峰時出問題，可以在這一層做一些邏輯升級。
后端是java應用，當修復邏輯時需要上線，而一次上線可能花費數十秒時間啟動應用。重啟應用后

營銷網站建設工作中，需要了解的十大SEO技巧
【黃山seo】了解查找引擎優化的營銷方式
低延時、穩定、極具性價比的香港服務器
如何把網站遷移到云服務器
電腦版uc瀏覽器打開網頁不顯示圖片如何解決
阿里云服務器什么時候最便宜
帶寬和延遲是怎樣影響您的香港服務器的呢?
哪里有便宜的云服務器