千萬級調用量微服務架構實踐

微服務架構在大型電商中的運用

 

 

 

電商是促銷拉動式的場景，也是價格戰驅動的場景。618和雙11都是典型的促銷活動。其實都是在搶用戶、擴市場佔有率。在這樣的場景之下，對秒殺、搶購是很熱衷的玩法。

 

 

 

促銷式的拉動對系統的挑戰是什麼呢？

能夠從上圖裏看到：對高可用性的要求是很是高的，須要99.99%的高可用性。快速迭代對對系統容性的要求很高，從幾萬單變成幾十萬單、百萬單，架構上不能影響快速迭代，因此有空中加油或者是高速公路換輪胎的說法。

另外，爲了應對瞬間的海量訪問（尤爲是秒殺場景），系統須要高可伸縮（快速擴容和縮容），這些都是對系統的要求。

 

 

 

大型電商系統的架構

從下往上，數據層，埋點數據把用戶行爲數據，實時數據存儲在NoSQL、關係型數據庫、大數據平臺 。

 

 

 

基礎架構層

這層其實是中間件和服務，包括MQ的消息、job的調試中心、sso聯合登錄，還有發消息的，分佈式的文件存儲，用戶上傳的一些圖片等等，除此以外還有應用監控的整個體系、自動發佈的框架，支持到AB測試。

基礎服務層

再上面一層就是基礎服務層，這其實是用基礎架構層提供的組件和服務，加上一些業務邏輯，構建了一些公用的服務，包括OMS、PMS採購，運費模板、配送區域等，這些都是電商最經常使用的基礎服務。

業務服務層

業務服務層咱們能夠看到的是，好比用戶在前臺能看到的界面，好比購物車、訂單、首頁，不論是不是微服務，至少是服務化的。這層就是全部網站應用的核心。除此以外就是第三方平臺的api對接。

虛擬類目至關於「標籤」，好比咱們正常的類目叫作「生鮮」、「服裝」，還有一些虛擬的類目叫作「618特賣」，裏面會聚合不少的商品，能夠理解爲一個標籤，做爲展現用。

暴露在最頂層的咱們能夠看到，這些就是各個端，好比H五、PC、官網，這就是最終可見的端。

 

 

 

微服務架構的設計

應用的無狀態化

不少網站一開始可能不是微服務化的，在早期的一些項目裏，咱們爲了快速上線交付，會作一些單體的應用。隨着訂單量的發展，咱們就開始作所謂的「微服務化」，第一步是把所謂的單體應用，變成應用的無狀態化，以登陸SSO來看，就是一種解決去狀態化的方法。咱們會拿到一個token，每次訪問都會帶着token，這就是所謂的去狀態化。以後每個應用都有橫向可擴的能力。當訪問量大的時候，就能夠經過加服務器來加強水平擴展的能力。

這種應用無狀態，其實配置文件仍是有狀態的。好比訪問的數據庫和節點，這些是經過配置文件來完成。我說到的案例基本都是基於spring boot來作微服務化，相關技術框架包括：dubbo、zk、hystrix、rocketmq、elasticsearch、redis等等。

單體應用的拆分

在作了應用的無狀態以後，就是對單體應用的拆分。拆分有幾個維度，一個是從系統的維度，最簡單的拆法就是先後臺拆開。好比購物車、商品、搜索、首頁等屬於前端，然後端給網站運營人員用。

還能夠按功能的維度來拆分，對於用戶服務，從service層到表結構，實際上是能夠獨立部署的，這就是微服務的概念。技術架構反應的就是組織架構，在這種架構下開發團隊分爲用戶服務開發組，價格開發組，商品開發組等。

還能夠根據讀寫維度進行拆分。好比搜索和商城的索引確定是獨立的兩個服務。用戶註冊下單支付是一個完整的業務流程。這些是由若干個微服務構成。

 

 

 

服務架構搭建

 

 

 

數據的異構

在大型電商系統裏面的服務架構搭建的經驗和技巧。首先是數據的異構，以訂單表爲例，通常訂單都很是龐大，通常按照id來分表分庫。這種分法對於查詢用戶全部訂單時就要去各表撈數據，所以能夠按用戶維度來異構一張表。對於數據的存儲，會分爲熱數據、冷數據和溫數據，分別存在不一樣的地方。同時也會對數據進行聚合。在一些訂單詳情頁，因爲有不少ajax請求，因爲請求數太多，也須要作一些請求合併。後臺的服務也要作一個合併。

以商品詳情頁爲例，使幾個接口的數據緩存合併在redis中，從redis中取得聚合好的數據，稱爲數據閉環。這是優化網絡請求的一般作法。

緩存

緩存在大型電商系統中是經常使用的優化技巧。瀏覽器級別的緩存經過響應頭進行設置。還會用到app客戶端的緩存，把H5/CSS/JS/圖片打包，提早拉到客戶端，在客戶端作一個代理服務器，可是不會讀取數據。能夠提高用戶體驗。緩存的使用在網絡上還有經常使用的cdn。進到接入層後，若是使用軟負載，也可使用內存級別的緩存。

消息隊列的應用

消息隊列的應用，是作服務解耦的好方法。也要考慮消息失敗和重試的場景，須要來作一些額外補償來防止數據丟失。還有一個機制是數據的校驗和補償。不少的場景能作到的是最終一致性，大型的電商系統和金融系統場景很是不同，在設計分佈式系統時，這是經常使用的方式。在電商中大多數狀況只要實現最終一致性就能夠了。

高可用的架構設計

高可用的架構設計，對於電商來講，其實高可用是最基本的要求。若是在促銷時，引來千萬級別的用戶，宕機會損失很大。

服務的降級、分組和故障的隔離

基於微服務架構的電商系統，高可用的方案有如下幾個部分，首先要支持服務的降級。要作降級的開關，寫在配置中內心面。好比在大促時，先把訂單放在緩存時，再進行落庫等操做。同時還要有服務分組和故障的隔離。好比秒殺時，對秒殺的應用單獨部署服務，當秒殺的應用掛了以後，不會影響其餘服務，由於有服務的隔離。同時要有限流機制，不少的框架都有支持。

流量治理

在極限的場景下， 對流量的治理要從多層面進行。好比在促銷當天，會開啓對於爬蟲和機器人的流量進行限流。通常會在大促前進行封板，若是出現問題，就進行回滾，好比數據版本的回滾，在設置數據結構的時候，要作支持帶數據版本號的回滾。

業務設計

業務設計方面的思考。從圖中能夠看到訂單支付的流程。在設計的時候要考慮防重設計，能夠採用防重key或者防重表的方案，可是耗費和代價很高，會在某些場景使用，好比積分，扣費等和金錢相關的場景下用。

 

 

 

業務設計要考慮狀態機。尤爲是訂單的流轉狀態裏，要作狀態機的應用，包括正向和逆向流程，及其產生的結果。

大型移動電商的架構

 

 

 

動態路由

最後來回顧一下大型移動電商的架構。下圖是一個移動電商的完整架構。從app端，主要作的是靜態文件的緩存和智能的動態路由。中國的網絡環境很複雜，須要在app端作智能動態路由。能夠上一些cdn，對動態的內容也作鏈路優化。會有一些對網絡環境檢測的機制，能夠是cdn，或者是走域名，也能夠暴露ip。

 

 

 

埋點和網關

移動電商裏對app來講還有一個很重要的是埋點，指的是全鏈路埋點。從app裏用戶的每個操做，這個操做通過網絡、服務層、中間件，整個鏈路要能夠監控。對於快速的定位問題是很是有幫助的，尤爲是移動電商性能的優化，第一步就是埋點。

在網絡這一層，還有網關的接入。好比限流，動態負載。在網關裏沒有加太多邏輯，也有不一樣的作法。對於服務來講，最複雜的是服務的依賴和治理。服務之間調用的優化要基於業務場景，好比說購物車的服務，調用到價格、庫存、促銷等。當依賴的服務不可用的時候，好比價格不可用，設計依賴的時候，要在購物車服務中作一個緩存，來對緩存調用，最後再對最終一致性進行驗證。

全鏈路監控的作法，須要作到預警，這就是一個基礎。經過對數據的監控請求來後，根據場景來作預警方案。

歡迎工做一到五年的Java工程師朋友們加入Java架構開發：697-579-751

羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！