'在電商問題不斷暴露時代，來看看樂視電商雲的整體架構與技術實現'
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
6.2 BeeHive資源調度系統
6.2.1 BeeHive核心設計思想
- 開放
- 抽象
- 包容
6.2.2 BeeHive內部結構示意圖
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
6.2 BeeHive資源調度系統
6.2.1 BeeHive核心設計思想
- 開放
- 抽象
- 包容
6.2.2 BeeHive內部結構示意圖
Beehive分為調度抽象層、計算抽象層、網絡抽象層、存儲抽象層四部分，調度層位於其他三層之上。
可以把這四個抽象都理解為接口，共同完成了對各方面資源及調度能力的抽象，對外為樂視雲提供統一的抽象接口提供資源能力輸出代理，屏蔽不同容器管理系統的 複雜性和多樣性。支持可插拔和多接口適配設計。
Beehive先期為這幾層之下都提供了默認實現，後期可以考慮接入業內成型的開源系統，開放包容。在資源 隔離方面，提供內存、CPU、 磁盤IO、網絡IO的隔離機制。
6.2.3 網絡結構示意圖
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
6.2 BeeHive資源調度系統
6.2.1 BeeHive核心設計思想
- 開放
- 抽象
- 包容
6.2.2 BeeHive內部結構示意圖
Beehive分為調度抽象層、計算抽象層、網絡抽象層、存儲抽象層四部分，調度層位於其他三層之上。
可以把這四個抽象都理解為接口，共同完成了對各方面資源及調度能力的抽象，對外為樂視雲提供統一的抽象接口提供資源能力輸出代理，屏蔽不同容器管理系統的 複雜性和多樣性。支持可插拔和多接口適配設計。
Beehive先期為這幾層之下都提供了默認實現，後期可以考慮接入業內成型的開源系統，開放包容。在資源 隔離方面，提供內存、CPU、 磁盤IO、網絡IO的隔離機制。
6.2.3 網絡結構示意圖
vRouter 是我們支持的網絡模式之一，基於SDN思想，通過vRouter將物理機構成網絡整體。
- 控制層：去中心化和高可用，部署至實體機，構成網絡集群。
- 轉發層：通過kernel routor方式轉發，沒有NAT性能損耗的缺點。
除此之外還支持MacVLAN方式和NAT等網絡方式。
7. 全球化
2016年是樂視集團全球化戰略元年，電商雲作為樂視雲上的一朵雲，也具有這種基因。隨著從去年開始跨境電商的興起，電商雲如何為客戶提供更好的基礎設施與服務，是我們必須認真思考的問題。
7.1 使用場景
客戶需要電商網站能觸及東南亞，北美，印度等新興或者傳統市場，達到商品的全球化銷售或者代購，系統肯定推到離用戶越近的區域，用戶的體驗越好。
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
6.2 BeeHive資源調度系統
6.2.1 BeeHive核心設計思想
- 開放
- 抽象
- 包容
6.2.2 BeeHive內部結構示意圖
Beehive分為調度抽象層、計算抽象層、網絡抽象層、存儲抽象層四部分，調度層位於其他三層之上。
可以把這四個抽象都理解為接口，共同完成了對各方面資源及調度能力的抽象，對外為樂視雲提供統一的抽象接口提供資源能力輸出代理，屏蔽不同容器管理系統的 複雜性和多樣性。支持可插拔和多接口適配設計。
Beehive先期為這幾層之下都提供了默認實現，後期可以考慮接入業內成型的開源系統，開放包容。在資源 隔離方面，提供內存、CPU、 磁盤IO、網絡IO的隔離機制。
6.2.3 網絡結構示意圖
vRouter 是我們支持的網絡模式之一，基於SDN思想，通過vRouter將物理機構成網絡整體。
- 控制層：去中心化和高可用，部署至實體機，構成網絡集群。
- 轉發層：通過kernel routor方式轉發，沒有NAT性能損耗的缺點。
除此之外還支持MacVLAN方式和NAT等網絡方式。
7. 全球化
2016年是樂視集團全球化戰略元年，電商雲作為樂視雲上的一朵雲，也具有這種基因。隨著從去年開始跨境電商的興起，電商雲如何為客戶提供更好的基礎設施與服務，是我們必須認真思考的問題。
7.1 使用場景
客戶需要電商網站能觸及東南亞，北美，印度等新興或者傳統市場，達到商品的全球化銷售或者代購，系統肯定推到離用戶越近的區域，用戶的體驗越好。
7.2 保證此場景的舉措
- 樂視基礎設施遍佈全球幾十個國家，電商雲可以依託強大的資源池，幫助用戶輕鬆達到跨境售賣與建站的訴求。
- 樂視雲的全球化消息隊列在各大基礎設施間進行消息同步與分發。Beehive依託消息，進行全局化的調度，無中心節點設計原則。
- 各大洲分別部署多套電商雲的架構，獨立進行服務。同時在各大洲分別部署全局的控制中心，保證雲服務的穩定性與性能。
- 業務鏡像可以支持不同地域的鏡像構建，支持全球化的鏡像市場，支持全球化存儲和區域存儲。
8. 展望
8.1 DCOS（Data Center Operation System）
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
6.2 BeeHive資源調度系統
6.2.1 BeeHive核心設計思想
- 開放
- 抽象
- 包容
6.2.2 BeeHive內部結構示意圖
Beehive分為調度抽象層、計算抽象層、網絡抽象層、存儲抽象層四部分，調度層位於其他三層之上。
可以把這四個抽象都理解為接口，共同完成了對各方面資源及調度能力的抽象，對外為樂視雲提供統一的抽象接口提供資源能力輸出代理，屏蔽不同容器管理系統的 複雜性和多樣性。支持可插拔和多接口適配設計。
Beehive先期為這幾層之下都提供了默認實現，後期可以考慮接入業內成型的開源系統，開放包容。在資源 隔離方面，提供內存、CPU、 磁盤IO、網絡IO的隔離機制。
6.2.3 網絡結構示意圖
vRouter 是我們支持的網絡模式之一，基於SDN思想，通過vRouter將物理機構成網絡整體。
- 控制層：去中心化和高可用，部署至實體機，構成網絡集群。
- 轉發層：通過kernel routor方式轉發，沒有NAT性能損耗的缺點。
除此之外還支持MacVLAN方式和NAT等網絡方式。
7. 全球化
2016年是樂視集團全球化戰略元年，電商雲作為樂視雲上的一朵雲，也具有這種基因。隨著從去年開始跨境電商的興起，電商雲如何為客戶提供更好的基礎設施與服務，是我們必須認真思考的問題。
7.1 使用場景
客戶需要電商網站能觸及東南亞，北美，印度等新興或者傳統市場，達到商品的全球化銷售或者代購，系統肯定推到離用戶越近的區域，用戶的體驗越好。
7.2 保證此場景的舉措
- 樂視基礎設施遍佈全球幾十個國家，電商雲可以依託強大的資源池，幫助用戶輕鬆達到跨境售賣與建站的訴求。
- 樂視雲的全球化消息隊列在各大基礎設施間進行消息同步與分發。Beehive依託消息，進行全局化的調度，無中心節點設計原則。
- 各大洲分別部署多套電商雲的架構，獨立進行服務。同時在各大洲分別部署全局的控制中心，保證雲服務的穩定性與性能。
- 業務鏡像可以支持不同地域的鏡像構建，支持全球化的鏡像市場，支持全球化存儲和區域存儲。
8. 展望
8.1 DCOS（Data Center Operation System）
在企業數據中心裡兩大核心應用
- 並行計算
- 微服務
如何更高效能的管理服務與複用資源提供利用率等課題，擺在我們的面前。數據中心裡多數服務獨佔資源，且屬於長運行，但未必佔用很多資源。這部分剩餘資源的調度與使用是關鍵。將數據中心的零散資源，當做一臺計算機的資源管理看待，是業內普遍的抽象思路與探尋的目標。
電商雲也在探索並實踐，期望提高樂視雲的資源使用率，在提供穩定資源服務的同時，減少企業成本，環保經營。
在DCOS的概念下，BeeHive逐步演進為 Le Distribution Kernel（LDK）, 作用在IaaS基礎設施之上，PaaS層之下的資源調度與管控層。LDK的主要思想是通過集成Service Framework來構建一個完整的DCOS體系。對於DCOS需管控服務類型，LDK留有通用API，其他服務框架可以通過可插拔的方式輕鬆接入，不與具體框架做強綁定關聯。
做好對計算、存儲、網絡資源的高度抽象，支持現有的可插拔接口設計，兼收幷蓄，吸收業界優秀的開源資源管理系統的優點或者複用，完成對資源合理調度與虛擬資源的全生命週期管理。
8.2 電商雲服務治理框架
結合通用服務框架，電商雲內置服務治理框架。在一些企業如果還不能達到進行服務拆分與服務治理的能力時，可以使用此框架達到立杆見影的效果。無語言相關性，頁面可配置接口，可形成調用關係圖譜，可視化管理微服務集群。
主題簡介
本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構複雜度有所不同：
- 初創期：商品類型少，業務複雜度低，系統架構簡單。採用高可用數據庫、分佈式緩存、文件存儲等基本組件就可滿足需求。
- 發展期：數據量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用數據庫、分佈式緩存、分佈式消息隊列、分佈式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。
2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼後其他的卻忘了同步，出問題不好排查，複用率低下。
2.3 安全性問題愈加嚴重
業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、用戶隱私洩露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的複雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
- 將服務分割成高內聚低耦合的模塊，有利於軟件的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。
- 不同的微服務可以進行分佈式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。
3.2 微服務化的劣勢
- 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
- 服務內部通信增多，增加依賴關係管理的複雜度。
- 故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
- 業務層
- 產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
- 公共服務層
- 在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
- 基礎組件層
- 業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分佈式緩存、分佈式消息隊列、NoSQL等。基礎組件層更偏向PaaS服務，可由電商獨立構建，也可以採用已有的雲組件提供服務。
要發揮微服務架構的優勢和克服它的缺點，可以通過電商雲和容器技術來解決。
4. 樂視電商雲
微服務化的提出比較早，但在雲成熟落地後，微服務架構才有了比較好的載體。近年逐漸形成了垂直領域雲的風潮，不斷推出適合垂直領域的產品，使客戶的使用門檻降低，且能提供更多偏向垂直領域中的通用服務，更貼近現實與解決迫切的問題。樂視電商雲是針對電商行業提供了一整套幫助企業利用雲計算優勢的解決辦法。
4.1 電商行業對垂直雲的要求
- 高性能
- 高可用
- 良好伸縮性
- 方便地拓展性
- 安全保證
4.2 電商雲的產品形態
4.2.1 電商公有云
比如電商的初級客戶，希望快速構建電商系統。在電商公有云只需註冊一個賬號，即可開通面對電商的完整服務體系。從服務到基礎設施無縫銜接，複雜的技術體系與適配硬件設備等工作對客戶透明，且可提供帶運維的增值服務。
用戶訪問服務（域名）經 DNS解析，通過DNS輪詢做第一次負載均衡，靜態資源請求流量會導至離用戶地理位置較近的CDN節點。雲防護系統先進行流量過濾，清洗無效流量、惡意流 量，攔截攻擊行為等安全防護。
電商業務系統推薦以微服務的方式進行架構設計並實施，上述微服務第三層的組件技術層可以採用 PaaS組件服務，如RDS、分佈式消息隊列、OSS、分佈式緩存等。
微服務化的業務通過容器部署在IaaS資源上，Service Router或API Gateway將負責引導請求進入各服務集群進行邏輯運算。
4.2.2 電商私有云
隨著電商企業的成長，公有云服務可能不能滿足用戶的特殊化需求，電商私有云可以提供客戶需求的定製化服務，提供整套的解決方案。
從數據中心建設中的方案推薦，到服 務部署實施都可打包對外銷售。幫助中型的電商客戶快速成長，由於數據全部在客戶的數據中心裡，免去客戶對公有云數據安全性的擔憂。
4.2.3 電商混合雲
混合雲模式可以同時擁有公有云和私有云的優勢。電商公有云可以快速幫助客戶屏蔽掉營銷帶給基礎服務的衝擊，可以將面對終端用戶的請求量與業務邏輯全部由電商公有云來承載，免去客戶對基礎設施的持續投資。
與此同時，財務、用戶信息等核心數據又可以存留在電商私有云裡，不用擔心洩露的風險。
通過混合雲的方式不僅保障核心業務與數據由企業自己掌控，還保證了特定業務下對資源需求的彈性控制，按量付費，不僅節約成本，還可輕鬆應對秒殺、搶購等高併發應用場景。
通過全局負載均衡來導流，將請求轉發至公有云或私有云，按業務類型單獨或者合作，為終端用戶提供服務。
4.3 電商雲平臺架構
電商雲平臺架構如下圖所示：
4.3.1 日誌收集
用戶通過自助化方式購買日誌服務。日誌分析結果將以接口的方式提供給用戶，用戶可以按需請求數據或通過樂視雲提供的數據可視化服務來監控成交量、用戶行為、熱銷商品等數據。客戶通過數據來改進自己的業務流程、調整產品研發方向、改進業務系統服務質量等，達到以數據驅動業務的目的，減少決策失誤。
4.3.2 監控
監控服務可以基於日誌、接口、服務參數等因子進行採集，並且通過預先設定的閥值，進行不同級別的報警。目前已支持電話、短信、微信等方式通知客戶上線處理。對因子和報警方式都做了抽象，支持不同的組合，靈活可配置。讓管理人員對整個系統運行狀態瞭如指掌。
4.3.3 伸縮
應用舉例：電商購物節
1） 在預定好電商搶購節之前，及時進行系統的擴容，加強系統的服務能力。
2） 雲平臺配合進行壓力及伸縮實驗，做好峰值的壓力測試，幫助企業達到快速便捷的能力擴展。
3） 在關鍵流量節點做好資源冗餘，核心業務數據確保萬無一失。
4） 在購物節過後，快速進行資源的銷燬，幫助企業節省資金。
4.3.4 流量調度
上雲後，結合電商企業自定義的流量調度機制可以實現更大範圍的調度，也可以把流量調度策略放在電商雲中，做更無縫的代理功能。流量調度不僅是容災的考慮，更為了在搶購或者秒殺期間，能抗住前一個小時或者半個小時的海量併發請求。其中包括跨地域、跨機房、集群內的三個層級的流量調度策略。第一層DNS，第二層 負載均衡，第三層Service Router，配合流量卡尺算法和資源池服務能力，靈活變更流量調度策略。使全網能安全度過最初半小時的請求量，完成訂單轉化。
4.3.5 計費
1）按量計費。PaaS層組件按照請求量進行計費，階梯制進行計費。
2）服務套餐選擇，多服務靈活組合，按套餐計費方式提供。
4.4 混合雲體系及訪問數據流示意圖
4.5 電商雲支持搶購的案例解析
搶購活動最基本的技術特徵是瞬時高併發，具體舉措在用戶端到服務端，應用層到基礎設施層都有所體現。
4.5.1 搶購的指導思想
- 減少到達服務端的流量
- 減少數據庫的直接操作
- 保證資源冗餘
- 從應用程序到操作系統等各個層次實施好最小權限原則（安全性保證）
4.5.2 場景列舉及應對方法
場景一： 用戶不斷刷新頁面獲取商品信息造成大量訪問請求，會佔用大量的帶寬資源。
解決辦法：頁面儘量靜態化，壓縮頁面內容，優化HTTP頭，可以使用樂視CDN做靜態加速。一些不必保持全局一致性的元數據，可以使用緩存進行保存。
場景二： CDN解決了靜態資源的問題，但仍有大量有效或惡意的請求被轉發至服務端，服務器壓力很大。
解決辦法：樂視雲盾可進行流量過濾，把非正常流量、無效流量在到達服務端之前清洗掉，可以屏蔽絕大部分DDoS，並接入WAF程序對HTTP請求進行分析，可以有效攔截SQL注入、XSS跨站、獲取敏感信息、漏洞利用等常見攻擊行為。請求預處理，通過業務邏輯限制儘早攔截無需繼續處理的請求；透傳的流量將作用在提前擴容的資源上。
場景三：大量要處理的請求導致數據庫壓力巨大，頻繁的操作導致數據庫性能低下甚至宕機。
解決辦法：針對業務設計高效的緩存策略，熱數據利用OCS進行緩存，需全局一致性數據存儲在樂視RDS。
場景四： 高併發下數據不一致性會導致超賣等情況。
解決辦法：通過上面請求預處理後已經大大減少了訂單的創建和超賣的可能，但超賣還是可能存在的。首先，利用消息隊列來緩衝請求，超過設定閾值的請求不處理，直接返回搶購結束。其次，利用分佈式消息隊列來同步商品庫存量，操作庫存時臨時加鎖，將庫存減扣和訂單更新等必要操作封裝成事務。
5. 容器技術
容器技術的出現大大促進了微服務架構和雲的發展
5.1 容器技術優勢
- 更高的資源使用率
- 啟動銷燬的速度快
- 結合容器技術可以比較完美的支持水平伸縮業務
5.2 容器技術劣勢
- 隔離性
- 容器中對於網絡的支持
下面介紹樂視雲平臺基於容器的支撐體系。在此體系中，主要包括： Matrix 和 BeeHive兩個系統。
6 BeeHive & Matrix
Matrix系統，負責用戶體系與資源及組件關係維護、跨域資源的全球調度。支持自助化組件申請，服務監控報警，計費，服務編排等服務。
Beehive 系統，負責在IaaS層之上進行組件服務的調度管理。支持容器資源的構建、集群管理、容器管理等服務。
6.1 Matrix & Beehive協同部署示意圖
6.2 BeeHive資源調度系統
6.2.1 BeeHive核心設計思想
- 開放
- 抽象
- 包容
6.2.2 BeeHive內部結構示意圖
Beehive分為調度抽象層、計算抽象層、網絡抽象層、存儲抽象層四部分，調度層位於其他三層之上。
可以把這四個抽象都理解為接口，共同完成了對各方面資源及調度能力的抽象，對外為樂視雲提供統一的抽象接口提供資源能力輸出代理，屏蔽不同容器管理系統的 複雜性和多樣性。支持可插拔和多接口適配設計。
Beehive先期為這幾層之下都提供了默認實現，後期可以考慮接入業內成型的開源系統，開放包容。在資源 隔離方面，提供內存、CPU、 磁盤IO、網絡IO的隔離機制。
6.2.3 網絡結構示意圖
vRouter 是我們支持的網絡模式之一，基於SDN思想，通過vRouter將物理機構成網絡整體。
- 控制層：去中心化和高可用，部署至實體機，構成網絡集群。
- 轉發層：通過kernel routor方式轉發，沒有NAT性能損耗的缺點。
除此之外還支持MacVLAN方式和NAT等網絡方式。
7. 全球化
2016年是樂視集團全球化戰略元年，電商雲作為樂視雲上的一朵雲，也具有這種基因。隨著從去年開始跨境電商的興起，電商雲如何為客戶提供更好的基礎設施與服務，是我們必須認真思考的問題。
7.1 使用場景
客戶需要電商網站能觸及東南亞，北美，印度等新興或者傳統市場，達到商品的全球化銷售或者代購，系統肯定推到離用戶越近的區域，用戶的體驗越好。
7.2 保證此場景的舉措
- 樂視基礎設施遍佈全球幾十個國家，電商雲可以依託強大的資源池，幫助用戶輕鬆達到跨境售賣與建站的訴求。
- 樂視雲的全球化消息隊列在各大基礎設施間進行消息同步與分發。Beehive依託消息，進行全局化的調度，無中心節點設計原則。
- 各大洲分別部署多套電商雲的架構，獨立進行服務。同時在各大洲分別部署全局的控制中心，保證雲服務的穩定性與性能。
- 業務鏡像可以支持不同地域的鏡像構建，支持全球化的鏡像市場，支持全球化存儲和區域存儲。
8. 展望
8.1 DCOS（Data Center Operation System）
在企業數據中心裡兩大核心應用
- 並行計算
- 微服務
如何更高效能的管理服務與複用資源提供利用率等課題，擺在我們的面前。數據中心裡多數服務獨佔資源，且屬於長運行，但未必佔用很多資源。這部分剩餘資源的調度與使用是關鍵。將數據中心的零散資源，當做一臺計算機的資源管理看待，是業內普遍的抽象思路與探尋的目標。
電商雲也在探索並實踐，期望提高樂視雲的資源使用率，在提供穩定資源服務的同時，減少企業成本，環保經營。
在DCOS的概念下，BeeHive逐步演進為 Le Distribution Kernel（LDK）, 作用在IaaS基礎設施之上，PaaS層之下的資源調度與管控層。LDK的主要思想是通過集成Service Framework來構建一個完整的DCOS體系。對於DCOS需管控服務類型，LDK留有通用API，其他服務框架可以通過可插拔的方式輕鬆接入，不與具體框架做強綁定關聯。
做好對計算、存儲、網絡資源的高度抽象，支持現有的可插拔接口設計，兼收幷蓄，吸收業界優秀的開源資源管理系統的優點或者複用，完成對資源合理調度與虛擬資源的全生命週期管理。
8.2 電商雲服務治理框架
結合通用服務框架，電商雲內置服務治理框架。在一些企業如果還不能達到進行服務拆分與服務治理的能力時，可以使用此框架達到立杆見影的效果。無語言相關性，頁面可配置接口，可形成調用關係圖譜，可視化管理微服務集群。
服務上線
當有新服務需要上線的時候，先在服務註冊器裡註冊該服務，不僅方便管理，而且可以監控微服務之間的依賴關係，避免循環依賴的發生，提前預警。註冊服務的同時，調度器會通知自動部署程序進行自動部署，部署程序自動進行從代碼倉庫拉取代碼，製作鏡像，部署上線等一系列操作。
服務發現
服務在註冊器登記以後，通過消息隊列發佈服務通知服務消費者，服務消費者訂閱服務。
服務優先級
服務註冊後會添加服務路由，服務路由負責記錄服務的優先級信息、路由信息以及控制服務的開關。在應對特定需求時通過服務路由來控制服務的升級與降級以保證優先級高的服務高可用。
服務授權
專門的服務權限管理系統來管理服務的權限，當服務請求到達服務路由層時，路由向權限系統請求檢查該消費者是否有權訪問服務提供者，如果鑑權通過則進行路由服務，鑑權失敗則停止路由服務返回錯誤狀態。
服務監控與SLA
服務消費者在請求服務的過程中會監控服務提供者是否可用，並將狀態反饋給監控程序；自動部署程序也會將部署成功、失敗、啟動、停止等信息反饋給監控程序，資源消耗等情況也會送達監控程序，監控程序判斷各項指標是否達到SLA中約定的閾值，當達到閾值時，觸發自動報警。
彈性伸縮
監控器會向調度器報告服務的運行情況與資源消耗情況，再由調度器控制容器資源的伸縮。
使用服務
服務消費者請求服務後，將會被服務路由攔截，在服務路由先進請求授權系統進行服務鑑權，鑑權通過後路由轉發服務。服務轉發過程中會進行一次負載均衡，將服務按優先級或根據資源的閒置情況來決定最終由哪些容器中的服務來提供。
歡迎大家關注轉發支持一波~
關注我：轉發+私信回覆“架構資料”獲取往期Java高級架構資料、源碼、筆記、視頻
Dubbo、Redis、設計模式、Netty、zookeeper、Spring cloud、分佈式、
高併發等架構技術
相關推薦
