作者 | 黃哲鏗
上週，前 1 號店技術總監、海爾農業電商 CTO，《技術管理之巔》作者黃哲鏗，為大家帶來了一場，關於微服務架構的分享，包含了微服務架構在千萬級別日調用量、億級別海量數據場景下的應用實踐；從領域驅動設計、服務依賴治理、服務高可用、故障熔斷降級快速恢復等方面，結合大型移動電商系統等應用案例，全面剖析微服務的應用等豐富的內容。
下面是整理的聽課筆記，有需要的小夥伴可以收藏哦~
微服務架構在大型電商中的運用
以下所有帶文字的圖，點擊查看更清晰
電商是促銷拉動式的場景，也是價格戰驅動的場景。 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。
埋點和網關
移動電商裡對 Ａpp 來說，還有一個很重要的是埋點，指的是全鏈路埋點。從 Ａpp 裡用戶的每一個操作，這個操作經過網絡、服務層、中間件，整個鏈路要可以監控。對於快速的定位問題是非常有幫助的，尤其是移動電商性能的優化，第一步就是埋點。
在網絡這一層，還有網關的接入。比如限流，動態負載。在網關裡沒有加太多邏輯，也有不同的做法。對於服務來說，最複雜的，是服務的依賴和治理。服務之間調用的優化，要基於業務場景，比如說購物車的服務，調用到價格、庫存、促銷等。當依賴的服務，不可用的時候，比如價格不可用，設計依賴的時候，要在購物車服務中做一個緩存，來對緩存調用，最後再對最終一致性進行驗證。
全鏈路監控的做法，需要做到預警，這就是一個基礎。通過對數據的監控請求來後，根據場景來做預警方案。
閱讀更多 CSDN 的文章
