本文根據〖高效運維社區講壇〗線上活動的分享整理而成。
歡迎關注“高效運維(微信ID：greatops)”公眾號，以搶先賞閱干貨滿滿的各種原創文章。
嘉賓介紹
主題簡介
本次分享將帶大家了解電商系統的發展過程，并分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商云的架構和實踐方案。
1. 電商系統發展過程
電商網站在不同時期的架構復雜度有所不同：
初創期：商品類型少，業務復雜度低，系統架構簡單。采用高可用數據庫、分布式緩存、文件存儲等基本組件就可滿足需求。
發展期：數據量、業務復雜度、系統復雜度、計算資源需求都劇增。則需要業務拆分并獨立部署，采用CDN、高可用數據庫、分布式緩存、分布式消息隊列、分布式文件存儲等。
電商技術基礎架構圖，如下所示：
2. 高速發展期的電商面臨的問題
2.1 業務的快速擴張、資源需求快速擴張，但利用率低下
企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用服務器或數據中心的方式對硬件資源、人力資源都要有很大的開支，而且從采購、招人到系統部署上線周期很長，效率低下。
2.2 系統復雜度的直線上升，耦合嚴重，牽一發動全身
隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一發動全身。
甚至有些公用的代碼在不同項目中存在多份拷貝，修改一份公有代碼后其他的卻忘了同步，出問題不好排查，復用率低下。
2.3 安全性問題愈加嚴重
業務做大了以后容易招致DDoS、惡意刷單、惡意滲透、用戶隱私泄露等安全風險。在新網絡安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。
一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。
以上問題通過使用電商云可以很好的解決。系統復雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商云解決。
3. 架構向微服務化演進
伴隨著網站規模的增大、功能的復雜、服務和數據處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。
推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。
拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共組件，進行分層抽象。
3.1 微服務化的優勢
將服務分割成高內聚低耦合的模塊，有利于軟件的開發維護。每個獨立團隊關注在自己獨立的領域里，更加專注于業務。
不同的微服務可以進行分布式部署，可針對瓶頸模塊進行獨立彈性伸縮， 提高系統并發能力?？刂屏６雀?。
3.2 微服務化的劣勢
服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。
服務內部通信增多，增加依賴關系管理的復雜度。
故障排查的難度增加，一個請求需要經過的處理節點增多。
3.3 電商微服務體系結構
電商微服務體系結構如下圖所示：
電商體系可能包含很多子系統， 大致可以歸類為三層：
業務層
產品信息、購物車、訂單系統、支付系統、搶購、庫存、物流系統、評論系統、客服系統、推薦系統等等。
公共服務層
在業務層之下需要有一個公共服務層，這一層專門為業務層提供公共服務。也就是所有業務層或者部分業務層共有的邏輯或者內容需要調用的部分。
基礎組件層
業務層面系統依賴一些基礎層面組件， 例如：高可用DB、 分布式緩存、分布式消息隊列、NoSQL等?；A組件層更偏向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中約定的閾值，當達到閾值時，觸發自動報警。
彈性伸縮
監控器會向調度器報告服務的運行情況與資源消耗情況，再由調度器控制容器資源的伸縮。
使用服務
服務消費者請求服務后，將會被服務路由攔截，在服務路由先進請求授權系統進行服務鑒權，鑒權通過后路由轉發服務。服務轉發過程中會進行一次負載均衡，將服務按優先級或根據資源的閑置情況來決定最終由哪些容器中的服務來提供。
9. 后記
我們隨后會分享： 樂視RDS
RDS組件在資源調度層使用Beehive提供的服務。目前RDS在樂視集團內部已達到60%的使用規模，線上已運行了近1500個容器。
10. 關于我們
Q&A
Q1：多機房,高并發,去中心化的情況下,例如購買的場景,如何保證數據一致性?
A1：首先要做數據分區，數據存儲在用戶本區域的關系型存儲中，樂視云提供全球化RDS。如果數據需全球唯一且可以支持并發，我們目前還達不到這種能力。目前只能回寫到全球唯一的一個節點上，再做全球數據同步。這種場景還需要業務進行配合，目前還做不到完全透明。
Q2：基于Beehive的Docker集群有對同一個宿主機上的Docker instance之間的通訊做優化嗎？
A2：對于同一種業務，上線時即考慮了高可用部署，業務都不在同一臺宿主機上。同時我們也不推薦業務部署在同一宿主機上。不同的業務的優化主要在于網絡通訊上，我們采用vRouter來做流量轉發，通過kernal router做轉發，流量都不會經過交換機。
Q3：為什么不直接使用Mesosphere 的DCOS 而自己構建BeeHive ?DCOS？
A3：主要有以下三個原因：
BeeHive 是基于我們自己的技術棧建立的。
BeeHive 深度適配樂視云各類業務系統架構，更適合我們。提供了抽象代理層，可兼容不同的實現，這個實現也可以我們自己做。
Mesosphere 的 DCOS 是商業化版本，并未直接開源。
Q4：為什么說微服務化的提出比較早，但在云成熟落地后，微服務架構才有了比較好的載體？
A4：微服務化的理念很早都已經有了，只是由于微服務的缺點（部署困難，運維復雜）導致微服務并沒有得到理想的應用推廣，后來容器技術快速發展，就很好地解決了微服務的痛點，而樂視電商云很好的利用容器技術或者虛機資源來使得微服務架構有了比較好的承載。
Q5：請問樂視有關大數據引擎的部署和微服務運維架構的關系是怎么樣的？
A5：資源復用，提高資源利用率是我們一直以來的初衷。分長時和短時的任務進行調度。在微服務化的資源處于空閑時段時，會減少微服務實例，用來跑一些MR或RDD任務。同理，在需要扛高并發的業務時，短時運行資源也會減緩運行速度，以空出一部分資源，部署上微服務的資源。
Q6：請問高 iops、cpu、pps的業務場景在云端是如何應對的？解藕？
A6：通過底層的資源池來調度分配。例如高iops會對應pcie ssd設備；高cpu任務，我們提供多核的高配機。通過自定義的業務屬性，來做更高層的任務分配與復用。后期通過機器學習，能更準確的識別資源利用率，做更智能的資源調度，用戶標記的任務屬性作為一個決策因子。這也正是我們要做DCOS的初衷，數據中心資源的管控，像是一臺計算機一樣在調度。
Q7：數據分區,例如A用戶,第一次訪問在洛杉磯,然后A用戶去了中國, 那A用戶是否以后都會在洛杉磯?
A7：目前用戶數據還在洛杉磯。后期計劃中，我們的處理方法是，首先A在美國存儲數據，數據會通過全球一致性同步到世界各地的數據中心，一是為數據容災，二是為考慮此種情況。但還是像上面的問題，數據全球唯一性且支持并發，目前還無法支持。
Q8：如上一個問題中所說，A用戶第一次訪問在洛杉磯，然后A用戶去了中國, A用戶以后訪問都會在洛杉磯，這種處理方式會帶來哪些問題呢？
A8：目前是A去了洛杉磯之后，數據保存在洛杉磯，之后去了中國，還是訪問洛杉磯的數據。帶來的問題：這種情況數據有一定的延遲，數據加載緩慢。
如果變成異步全球同步數據的機制，還需要解決并發訪問的問題（用戶在異地同時登陸對唯一資源進行操作），這種情況還需要通過業務協助來解決，限制不能對全球唯一的數據同時進行多地操作。
Q9：基于BeeHive的Docker集群有考慮對不同的Docker設置不同的帶寬嗎？好像Mesos還不支持這個功能。
A9：目前還沒有限制，正在考慮使用TC來限制網絡帶寬，參考OpenStack中的做法。Service Router會做流量分配，對流量做好監測，把請求代理轉發到其他地域與機房，當然這是在更高的層級進行管控。如遇像Redis，Ceph這類的組件服務，在構建服務時，優先選擇千兆網卡的機器等策略支持。
Q10：熱數據是怎么判別并加到ocs里的？樂視商城現在ocs的發展情況是怎么樣的？
A10：熱數據的寫入，目前還是通過業務的實現來完成。由于系統比較復雜，需要多級緩存來緩解壓力。如果您問的是希望RDS來自動加載到OCS中的方式，目前據我了解樂視RDS目前還不支持此種方式，這部分可以由RDS團隊來專門介紹一下。
Q11：大文件存儲和小文件存儲都是用了什么軟件或服務？
A11：大文件存儲使用Ceph。小文件存儲是在Ceph的基礎上，加入緩存機制進行。下面也準備測試一下Ceph新版本對于小文件存儲的能力。存儲服務是由我們云平臺內部另一個團隊負責的。
