微服務架構在大型電商中的運用
電商是促銷拉動式的場景，也是價格戰驅動的場景。618和雙11都是典型的促銷活動。其實都是在搶用戶、擴市場佔有率。在這樣的場景之下，對秒殺、搶購是很熱衷的玩法。
促銷式的拉動對系統的挑戰是什麼呢？
可以從上圖裏看到：對高可用性的要求是非常高的，需要99.99%的高可用性。快速迭代對對系統容性的要求很高，從幾萬單變成幾十萬單、百萬單，架構上不能影響快速迭代，所以有空中加油或者是高速公路換輪胎的說法。
另外，爲了應對瞬間的海量訪問（尤其是秒殺場景），系統需要高可伸縮（快速擴容和縮容），這些都是對系統的要求。
大型電商系統的架構
從下往上，數據層，埋點數據把用戶行爲數據，實時數據存儲在NoSQL、關係型數據庫、大數據平臺 。
基礎架構層
這層實際上是中間件和服務，包括MQ的消息、job的調試中心、sso聯合登陸，還有發消息的，分佈式的文件存儲，用戶上傳的一些圖片等等，除此之外還有應用監控的整個體系、自動發佈的框架，支持到AB測試。
基礎服務層
再上面一層就是基礎服務層，這實際上是用基礎架構層提供的組件和服務，加上一些業務邏輯，構建了一些公用的服務，包括OMS、PMS採購，運費模板、配送區域等，這些都是電商最常用的基礎服務。
業務服務層
業務服務層我們可以看到的是，比如用戶在前臺能看到的界面，比如購物車、訂單、首頁，不管是不是微服務，至少是服務化的。這層就是所有網站應用的核心。除此之外就是第三方平臺的api對接。
虛擬類目相當於“標籤”，比如我們正常的類目叫做“生鮮”、“服裝”，還有一些虛擬的類目叫做“618特賣”，裏面會聚合很多的商品，可以理解爲一個標籤，作爲展示用。
暴露在最頂層的我們可以看到，這些就是各個端，比如H5、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等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！