3月18日雲棲社群線上實時分享順利結束，本次由有貨CTO李建分享了有貨為了應對流量的爆發式增長，對其整個系統做了大面積的系統重構，在資料中心、應用系統等方面全變改進，全方面地提升系統的可用性。本次視訊直播的整理文章、視訊、幻燈片整理完畢，如下內容。
為什麼選擇混合雲架構？圖一 為何選擇混合雲架構？
為什麼選擇混合雲架構這個問題可以拆成兩個問題，一是為什麼使用公共雲？另一個問題就是為什麼不完全使用公共雲，為什麼還保留原來的IDC？採用這種混合雲的架構是基於以下幾個痛點考慮的：
業務痛點：對於網際網路的業務而言，企業必須做到快速響應業務需求，同時網際網路業務需求是靈活多變的，傳統IDC模式很難保證在短時間內上線一款新的應用。對於公共雲來說，其具有的彈性伸縮能力，能應對頻繁業務活動；同時像雙十一之類的對於流量突發增長活動，公共雲可以採取峰值應對，彌補傳統IDC的不足；運維痛點：對於傳統的IDC，要完成一次具體的擴容，必須要從伺服器的採購申請，再到伺服器的上架，再去安裝作業系統，再去部署應用等等一系列操作，十分複雜。同時在擴容過程中，不僅流程過去繁瑣，還有可能遇到一系列的問題，比如因為伺服器環境差異導致系統故障等問題。這些問題不僅增加了運維過程中的難度，還使得整個系統的可用性大大降低；成本控制：一方面使用公共雲可以降低整體的硬體、運維成本；另一方面從傳統的IDC遷移到公共雲上的遷移成本，包括遷移過程中對系統進行改造和遷移時間的成本。所以基於兩者考慮，最後選擇了混合雲的模式；安全控制：從安全形度出發，採用混合雲模式：將前臺應用相關計算、快取節點全部遷移到阿里雲上。核心組資料依然保留在IDC中，保障核心資料的安全。基於混合雲的系統架構圖二 基於混合雲的系統架構
上圖是有貨抽象化的混合雲系統架構的整個層次結構。中間是整個服務註冊中心，主要分為六層。客戶端採用多種高可用策略，在客戶端完成降級、快取、Http DNS等操作；客戶端下側的入口層主要涉及智慧DNS、高防DDOS、SLB、Nginx等；從入口層再往下是閘道器層，在閘道器層內完成安全、流控、降級等操作；核心業務服務層完成所有的核心業務邏輯，包括服務註冊、服務發現、服務呼叫等等；從服務層再往下就是快取層，在快取層內一是對熱點資料進行加速，同時也需要考慮快取資料的更新時效等問題；最下面一層是資料層，主要的資料儲存在MySQL中，同時進行資料雙活操作，保證資料的一致性。
六層結構的左側是垂直運維平臺，平臺在每一層都有相關的運維監控工作，右邊是基於大資料平臺的資料分析系統。
圖三 客戶端
下面來具體對每一層架構進行分析。在客戶端：
通過使用HttpDNS，解決LocalDNS的潛在問題。在移動端採取Http直連的模式，防止DNS劫持問題，通過HttpDNS Server獲取後端服務的IP列表，避免LocalDNS快取問題，避免域名解析慢或者解析失敗，能快速應對故障處理。同時在高可用方面，混合雲的模式下，如果其中一個數據中心出現問題時，可以通過HttpDNS快速進行流量切換；在前端使用阿里雲的CDN加速圖片、Js等靜態資源，極大的提升了使用者體驗；App客戶端通過Cache-Control HTTP頭來定義自己的快取策略，通過預載入和客戶端快取，實現離線化，大幅度提升效能；服務降級，客戶端根據降級策略可在特定條件下對非關鍵業務進行降級，以保證核心關鍵業務的高可用；對網路品質監測，根據使用者在2G/3G/4G/Wi-Fi等不同網路環境下設定不同的超時引數，以及網路服務的併發數量。同時根據不同的網路品質設計不同的產品體驗；業務異常監測，在客戶端監測使用者使用過程中的異常情況、快照資訊，實時上報異常資料，實時定位分析問題；如果App出現大面積故障，可快速切換至Web App模式，保障了系統的高可用。圖四 入口層
入口層使用智慧DNS分發流量至混合雲的雙資料中心，將應用做成無狀態模式，在兩個應用中心做對等的部署，突破運營商地域限制，按照地域切分流量，比如將南方的資料流量切入到阿里雲上，將北方的流量切換到自建的IDC中。
安全方面，使用阿里雲高防DDOS產品防護DDoS攻擊。使用阿里雲SLB作為應用層負載均衡，實現叢集內水平伸縮，同時結合阿里雲的ECS，很好地應對流量高峰時、高峰過後的複雜情況。此外，介面層還使用自建Nginx+Lua做反向代理、分流限流、AB測試、灰度釋出、故障切換、服務降級等處理措施。
圖五 閘道器層
入口層之下的閘道器層內也做了很多措施來保障系統高可用性。安全控制方面，在閘道器層統一完成客戶端請求的身份認證，統一完成資料的加密解密；分流與限流方面，將流量按業務切分，路由至後端不同業務線的服務中心，以實現後端服務的實時動態水平擴充套件。當流量超過預定閥值，系統出現瓶頸的時候自動限制流量進入後端服務，以防止雪崩效應。服務降級方面，在系統出現瓶頸是，自動降級非關鍵業務，以保證核心業務的正常運轉。
熔斷機制方面，根據後端服務的健康狀況，自動熔斷對服務的呼叫，以防止雪崩效應。非同步化方面，閘道器非同步化呼叫後端服務，避免長期佔用請求執行緒，快速響應處理結果，快速釋放執行緒資源。
在閘道器層，一級快取用於加速熱點資料；二級快取使用者容災。請求進入網路層後首先呼叫一級快取，如果一級快取命中，直接將結果返回給客戶端；如果沒有命中，閘道器層會呼叫後端服務，從服務中返回資料，在這個過程中如果服務出現故障無法訪問時，閘道器會訪問二級快取，因為二級快取是用於容災處理，所以二級快取的時間非常長，資料儲存24小時。
圖六 服務層
服務層主要用於服務化的改造，將在之後的服務化章節詳解講解。
圖七 快取層-使用者資料持久化場景
在不同的場景下，採用不同的快取策略。在使用者資料（收藏夾、瀏覽記錄）持久化場景中，採用混合雲雙資料中心完全對等的部署方式、做雙寫雙活。每個資料中心微服務將資料寫入快取時，均是將資料傳送到當前資料中心的MQ中，讀取資料是直接從當前資料中心的Redis叢集讀取。Redis叢集同時訂閱兩個資料中心的MQ的資料，確保兩個資料中心部署的Redis叢集完全對等，同時Redis叢集中的資料也是全量資料，當一個數據中心出現問題時，可以將流量切換到另一個數據中心。
圖八 快取層-共享資料加速，保持資料一致性場景
在共享資料加速，保持資料（如訂單資料）一致性的場景下，採用單主多從的快取模式，在兩個資料中心更新快取時，是先寫到一個Redis Master叢集中，然後從一個Redis Master叢集同步到兩個資料中心的Redis Slave叢集中，整個請求的邏輯就是：請求進入其中一個機房的微服務中，微服務首先會讀取微服務本地的一級快取，如果沒有命中，再去本資料中心的Redis Slave叢集進行查詢，如果還是沒有命中，再回源到本資料中心的資料庫中進行查詢，將讀取後的資料寫入到Redis Master叢集，同時更新本地的一級快取和Redis Slave叢集，當然Redis Master叢集也會將資料同步更新到另一個數據中心的Redis Slave叢集中。這種單寫多讀的快取模式實現資料加速以及保證資料一致性的要求。目前這種跨機房的主從同步延時並不明顯，延遲在一兩毫秒左右。
圖九 快取層-共享資料加速但不考慮資料致性場景
在共享資料加速但不考慮資料（商品）一致性的場景下，也是採用多活的理念，即在兩個資料中心部署完全對等的快取叢集。在上圖的機房一中，當有資料請求時，首先從本地一級快取進行查詢，如果沒有命中，再去查本地的Redis叢集，依舊沒有命中時，回源到本地的資料庫進行查詢，同時將查詢到的資料更新到本資料中心的Redis叢集。雖然兩個資料中心的快取叢集部署一致，但是在Redis叢集中存的資料可能不一致。
圖十 資料層
資料層作為六層架構中的最底層，主要的應用還是基於MySQL的主從模式。下面提到的特點是在非核心業務上的一些嘗試，並沒有大面積應用：
同城雙活，即由業務層來控制資料的實時性和最終一致性，而不是通過資料同步來保證實時性和一致性。業務層雙寫，資料非同步分發至兩個資料中心，任意機房寫入的資料通過非同步訊息的方式分發到另一個機房，以此來保證兩個機房資料的最終一致性。業務層通過二級查詢保證資料的實時一致性，由於業務層雙寫只能保證資料的最終一致性，無法保證實時一致性，因此，針對具有實時一致性要求的業務場景，我們通過業務層的二級查詢來保證。重複寫入應對單機房故障，當任意機房出現故障時，如果寫入的資料還沒有分發至另一個機房，則由業務層在可用機房重複寫入資料，通過演算法來生成相同的ID。通過failover庫為高可用提供雙重保險，針對流水型業務資料，在資料庫故障時，需要進行主從切換，此時通過業務層將所有資料的讀寫切換至failover庫，主庫恢復以後再將流量切回主庫。垂直拆分與水平拆分結合使用。服務化之所以需要服務化，是因為在做服務化之前系統高度耦合，牽一髮而動全身，直接影響到系統可用性；同時業務相互影響，系統很難維護；系統邏輯過於耦合，很難進行水平擴充套件；也無法通過流控、降級等手段保障系統的可用性；此外由於系統的高度耦合，極易產生雪崩效應。因此基於上述原因，服務化改造勢在必行。
圖十一 服務系統框架
上圖是服務化系統的架構，最上面一層是客戶端，客戶端下面就是服務閘道器層，再往下就是具體的業務服務中心，目前對電商而言三大核心就是商品、會員、訂單中心。圍繞服務中中心的是一些服務治理策略，如流控/降級、負載均衡等。系統的最低層是服務註冊中心。
圖十二 服務註冊、發現、呼叫
對於服務化而言，最核心的就是服務的發現、註冊、呼叫。目前有貨採用的是Spring+Register+Zookeeper搭建的最簡單的服務框架，通過Zookeeper完成的服務註冊和發現，通過Register完成服務的呼叫。
圖十三 服務化負載均衡
服務化還有一個很重要的要求就是服務化負載均衡，一般是有兩種方案：
集中式的LoadBalance，在服務消費者和提供者之間通過阿里雲的SLB或者F5搭建獨立的LoadBalance，通過集中式的負載均衡裝置完成對服務呼叫的負載均衡；在程序內做負載均衡，即軟負載的方式，將負載均衡策略滲入到服務框架裡面，服務消費者作為負載均衡的客戶端，請求只需要從服務註冊中心獲取最新的服務列表，利用服務框架自身攜帶的負載均衡策略，完成負載均衡的呼叫。圖十四 服務降級和流量控制
在服務降級方面，通過使用開源的Hystrix配置服務超時時間，當服務呼叫超時時，直接返回或執行Fallback邏輯。另外基於Hystrix提供的熔斷器元件，可以自動執行或手動呼叫對當前服務進行暫停後再重新呼叫服務。流量控制方面，通過計數器服務限定單位時間內當前服務的最大呼叫次數（比如600次/分鐘），如果超過則拒絕，以保證系統的可用性；同時為每個服務提供一個小的執行緒池，如果執行緒池已滿，呼叫將被立即拒絕，預設不採用排隊，加速失敗判定時間。
圖十五 服務化的監控、優化、呼叫鏈分析
服務化中，對於服務的監控、效能優化以及呼叫鏈的分析也尤為重要。通過Hystrix提供的服務化監控工具實時觀察線上服務的執行狀態，有了監控之後可以進行相應的效能優化。對於呼叫鏈分析，當請求從閘道器層進入時，追加一個Trace ID，Trace ID會在整個呼叫過程中保留，最後通過分析Trace ID將整個請求的呼叫鏈串聯起來。
自動化運維平臺圖十六 自動化運維
目前採用的混合雲雙資料中心模式，如果依舊採用傳統的手工部署應用，做檔案拷貝、同步等工作，很容易出現版本不一致、檔案更新異常等問題。因此在混合雲模式下構建自動化運維平臺需要考慮以下核心問題：
首先在運維平臺上要能完成對雙雲的一鍵式的自動化部署釋出，以及部署失敗後的一鍵快速回滾；在運維平臺中需要完成對流量的管理控制，可以完成對整個應用系統的容量規劃；最核心的部分是運維平臺實現監控和報警，包括對業務層級監控、應用系統的監控、以及系統層級的IO、磁碟、網路的監控。在運維平臺中，需要做到應對故障快速恢復的預案，分析系統可能出現的故障點，在出現故障時，通過自動化的指令碼對故障進行恢復。QA環節:1、有貨歷史架構的演變歷程，達到什麼樣的規模時才選用混合雲模式？
答：企業到了一定階段，需要去考慮效率和成本時，以及系統的穩定性，自然會選擇混合雲的方式，目前是將需要彈性伸縮、流量突發的業務遷移到公共雲上，後臺運營等相對穩定的業務保留在傳統的IDC。當流量訪問併發達到500-1000時，通過IDC中增加物理機支撐帶來維護和成本上的問題時，去考慮選擇混合雲模式。
2、如何完成多中心的自動化部署？
答：有貨在這一方面做的比較簡單，通過簡單的指令碼方式，使用Shell指令碼打通版本管理、編譯打包、目標伺服器，將它們串聯起來，在此基礎之上，再簡單的封裝一個圖形化的介面，方便操作和許可權控制，底層就是呼叫這一套指令碼來完成的。
3、為什麼要進行異地的雙寫，這樣做成本是不是比較高？
答：異地的雙寫是針對不同的應用場景，對一些實時性和一致性要求很是很高的場景，整個應用允許一定的延遲，可以選擇異地雙寫。異地雙寫的成本是非常高的，目前有貨是同城雙寫，IDC和公共雲之間通過專線連線，有效降低了時間延遲。
4、前臺後臺進了系統解耦，如何做到兩者互不影響？
答：剛開始整個應用系統都在一個數據中心部署，前臺和後臺都採用同一套資料庫，後臺的批量操作有可能影響到前臺的執行。首先需要做資料庫的解耦，即前臺和後臺不共用資料庫，目前通過MQ的方式做前後臺的資料互動。
5、如何進行合理的服務拆分？
答：目前服務拆分是針對不同的業務線進行的，對於電商來講，會分為商品、訂單、會員等幾個大的業務線，業務線對應著各種業務中心，服務中心下面還分佈著不同的服務叢集，目前採用的是面向領域的模式進行拆分。例如商品服務，將商品的價格、庫存等銷售屬性和非銷售屬性分別拆成不同的模型，針對不同的模型，進行提供服務。
6、保證系統高可用的核心理念？
答：核心理念不是讓系統很穩健，不出故障。而是恰恰相反，任何系統的節點，軟體或者硬體出現故障時，整個系統依舊可用，即某一點的故障不使得整個系統癱瘓。
關於分享者：
李健 有貨CTO
有貨旨打造中國潮流生態圈，其核心業務包括有貨App、YOHO、Mars應用。有貨也積極舉辦線下活動，例如舉辦潮流嘉年華等活動。YOHO!將在2016年5月在艾尚開3000平方米的旗艦店，將集理髮、拍照、咖啡、讀書等為一體。該店將採用完全的電子貨架，也是全球唯一一個完全的電子貨架模式。