本文根據〖高效運維社群講壇〗線上活動的分享整理而成。

歡迎關注“高效運維(微信ID：greatops)”公眾號，以搶先賞閱乾貨滿滿的各種原創文章。

嘉賓介紹

主題簡介

本次分享將帶大家瞭解電商系統的發展過程，並分析在高速發展期的電商面臨的問題，同時跟大家分享樂視電商雲的架構和實踐方案。

1. 電商系統發展過程

電商網站在不同時期的架構複雜度有所不同：

• 初創期：商品型別少，業務複雜度低，系統架構簡單。採用高可用資料庫、分散式快取、檔案儲存等基本元件就可滿足需求。

• 發展期：資料量、業務複雜度、系統複雜度、計算資源需求都劇增。則需要業務拆分並獨立部署，採用CDN、高可用資料庫、分散式快取、分散式訊息佇列、分散式檔案儲存等。

電商技術基礎架構圖，如下所示：

2. 高速發展期的電商面臨的問題

2.1 業務的快速擴張、資源需求快速擴張，但利用率低下

企業的主要目標是在市場上搶得先機，降低經營成本。傳統租用伺服器或資料中心的方式對硬體資源、人力資源都要有很大的開支，而且從採購、招人到系統部署上線週期很長，效率低下。

2.2 系統複雜度的直線上升，耦合嚴重，牽一髮動全身

隨著業務規模的擴大，大部分時間在進行新功能的開發和bug修復，可能沒有精力對系統進行及時梳理與重構，導致系統日益龐大與臃腫， 耦合度比較高，牽一髮動全身。

甚至有些公用的程式碼在不同專案中存在多份拷貝，修改一份公有程式碼後其他的卻忘了同步，出問題不好排查，複用率低下。

2.3 安全性問題愈加嚴重

業務做大了以後容易招致DDoS、惡意刷單、惡意滲透、使用者隱私洩露等安全風險。在新網路安全法草案的規約中，對電商企業提供服務的安全性也提出了明確的標準。

一般的企業核心在商業市場上，而不是在技術保障上。小微電商或傳統電商都難有相應的技術實力去做這些安全保障。

以上問題通過使用電商雲可以很好的解決。系統複雜度的問題通過微服務架構來進行處理，資源需求、安全問題通過電商雲解決。

3. 架構向微服務化演進

伴隨著網站規模的增大、功能的複雜、服務和資料處理種類的增多，微服務化的架構設計思路逐漸成為了業界的廣泛共識。

推薦以循序漸進的方式拆分，不輕易進行推翻式的重構。

拆分也要有個度，不是越細越好，主要還是要關注在業務領域，同時注意提取公共元件，進行分層抽象。

3.1 微服務化的優勢

1. 將服務分割成高內聚低耦合的模組，有利於軟體的開發維護。每個獨立團隊關注在自己獨立的領域裡，更加專注於業務。

2. 不同的微服務可以進行分散式部署，可針對瓶頸模組進行獨立彈性伸縮， 提高系統併發能力。控制粒度更細。

3.2 微服務化的劣勢

1. 服務數量增加，加大部署、管理、監控等運維操作的難度與工作量，同時對運維人員的質量與數量也提出了新的要求。

2. 服務內部通訊增多，增加依賴關係管理的複雜度。

3. 故障排查的難度增加，一個請求需要經過的處理節點增多。

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中約定的閾值，當達到閾值時，觸發自動報警。

彈性伸縮

監控器會向排程器報告服務的執行情況與資源消耗情況，再由排程器控制容器資源的伸縮。

使用服務

服務消費者請求服務後，將會被服務路由攔截，在服務路由先進請求授權系統進行服務鑑權，鑑權通過後路由轉發服務。服務轉發過程中會進行一次負載均衡，將服務按優先順序或根據資源的閒置情況來決定最終由哪些容器中的服務來提供。

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：主要有以下三個原因：

1. BeeHive 是基於我們自己的技術棧建立的。

2. BeeHive 深度適配樂視雲各類業務系統架構，更適合我們。提供了抽象代理層，可相容不同的實現，這個實現也可以我們自己做。

3. 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新版本對於小檔案儲存的能力。儲存服務是由我們雲平臺內部另一個團隊負責的。