微服務架構在大型電商中的運用
電商是促銷拉動式的場景，也是價格戰驅動的場景。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架構開發：697579751
群内提供免費的Java架構學習資料（裡面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！