Java生鮮電商平臺-微服務大型複雜系統的架構實踐(小程序/APP)
說明：Java生鮮電商平臺-微服務大型複雜系統的架構實踐，本文只是引用微服務架構來實戰下目前實際的電商項目，本文只是一個拋磚引玉的作用，希望對大家有用.
微服務架構已經是大型複雜系統的首選架構方式，我們以大型電商系統應用場景爲例， 介紹微服務在大型複雜系統的架構實踐。
電商是促銷拉動式的場景，也是價格戰驅動的場景。 618 和雙 11，都是典型的促銷活動。其實都是在搶用戶、提高市場佔有率。在這樣的場景之下，對秒殺、搶購是很熱衷的玩法。
電商業務面臨的挑戰
促銷式的拉動對系統的挑戰是什麼呢？
可以從上圖裏看到：對高可用性的要求是非常高的，需要 99.99% 的高可用性。快速迭
代，對系統容性的要求很高，從幾萬單變成幾十萬單、百萬單，架構上不能影響快速迭代， 所以有空中加油、或者是高速公路換輪胎的說法。
另外，爲了應對瞬間的海量訪問（尤其是秒殺場景），系統需要高可伸縮（快速擴容和縮容），這些都是對系統的要求。
大型電商系統的架構
從下往上，數據層，埋點數據把用戶行爲數據，實時數據存儲在 NoSQL 、關係型數據庫、大數據平臺 （visio 2013畫的圖）
大型電商系統技術架構
基礎架構層
這層實際上是中間件和服務，包括 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 系統整體架構
埋點和網關
移動電商裏對 Ａpp 來說，還有一個很重要的是埋點，指的是全鏈路埋點。從 Ａpp 裏用戶的每一個操作，這個操作經過網絡、服務層、中間件，整個鏈路要可以監控。對於快速 的定位問題是非常有幫助的，尤其是移動電商性能的優化，第一步就是埋點。
在網絡這一層，還有網關的接入。比如限流，動態負載。在網關裏沒有加太多邏輯，也有不同的做法。對於服務來說，最複雜的，是服務的依賴和治理。服務之間調用的優化，要基於業務場景，比如說購物車的服務，調用到價格、庫存、促銷等。當依賴的服務，不可用的時候，比如價格不可用，設計依賴的時候，要在購物車服務中做一個緩存，來對緩存調用， 最後再對最終一致性進行驗證。
全鏈路監控的做法，需要做到預警，這就是一個基礎。通過對數據的監控請求來後，根據場景來做預警方案。
以上就是，微服務在大型電商系統中的應用，許多知識點和架構用法沒有展開講，感興趣的讀者，可以去深入研究這些用法背後的思考邏輯。
結語
覆盤與總結.
總結：
做Java生鮮電商平臺的互聯網應用，無論是生鮮小程序還是APP，微服務系統架構設計是非常重要的，本文只是起一個拋磚引玉的作用，
希望用生鮮小程序的搭建微服務系統架構設計實戰經驗告訴大家一些實際的項目經驗，希望對大家有用.
QQ:137071249
共同學習QQ羣：793305035