深信服楊旭榮：傳統企業雲化IT架構建設之路

本文根據楊旭榮2018年10月17日在【第十屆中國系統架構師大會】上的演講內容整理而成。

講師介紹：

楊旭榮

深信服雲端計算BU架構師，擁有近10年雲端計算領域，核心底層技術研發工作。熱愛開源社群，OpenStack，SDN，PAAS專家，挖掘發表多項核心專利。作為雲端計算架構師，主導超融合，私有云，混合雲等架構產品化落地，參與電信，金融等行業雲化資料中心解決方案，SDN/NFV及應用架構轉型專項工作。

分享大綱：

• 傳統企業IT架構演進及核心訴求

• 深信服雲體系架構介紹

• 超融合aCloud+aCMP架構設計

• 資料中心可靠效能力建設

• 資料中心安全能力建設

結合過去數字化轉型實踐，介紹企業IT架構演進思路和核心訴求，透過深信服超融合架構和雲管一體化架構滿足廣泛應用，打造安全可靠資料中心!

一、傳統企業IT架構演進及核心訴求

目前而言，越來越多的傳統業務客戶選擇把核心的應用或資料上雲。超融合憑藉其把計算網路儲存安全融為一體的架構，很靈活滿足了整個傳統企業的IT應用。

隨著核心的應用上雲之後，可能會涉及到另外一個問題，即整個資料可靠性的保障和容災中心的建立，包括本地容災，異地容災兩地三中心的架構體系的建設，整個體系完全是為了滿足傳統企業虛擬化雲化之後的過程。

但另一方面某些創新型的應用，比如AI大資料，包括在整個公有云服務體系上，一些模型場景的具象化服務能力輸出之後，部分客戶對公有云的能力開始有一些訴求，整個業務就必須要從私有的資料中心，或者單一的雲環境要向多元業務，或者說像混合雲這方面去傾斜。

有些客戶可能對公有云有特殊的要求，比如專屬雲，或者託管服務。整個基礎設施這一層的構成，從深信服過去實施的大量專案中，得到一個很大的實踐訴求，就是一定是要求穩定安全可靠和高效能的基礎設施。

基於整個底層的架構之上，還會進一步引申出來一個對底層多叢集多業務多租戶的一個管理訴求。雲管理平臺(CMP)的主要職責就是體現多租戶業務，包括計量計費、自服務體系、以及服務目錄等一些建設。

深信服把所有的訴求做了一箇中心化的具象，抽象開來說，第一個基礎的服務模組叫資源池，是統一管理底層的虛擬化資源和多叢集等，然後體現多租戶能力，設定配額，發放資源等。

第二個是監控中心，即可以對業務進行端到端的檢測和告警，收集相關日誌，包括資料探測、效能探測等。另外一個是可靠性中心，即整個資料中心的可靠性的建設。做兩方面去拆解，一個是在整個視覺化上做了全面視覺化的管理。第二個就是依賴底層虛擬化的技術，能夠實現備份，容災等能力。

另外一個就是多雲，整個管理功能就是要給公有云和私有云提供一致性的操作體驗。在整個資源池入口，發放一個虛機，它的資源池是可以選擇私有云，也可以選擇公有云進行發放。實際上對於傳統的製造業來講，會存在特別多的分支機構，而且很多是部署在多個地方，我們的超融合叢集可以部署不同的地方，然後透過CMP平臺統一管理起來。

還有一個能力中心是安全中心，以往整個傳統IT建設是有安全邊界的，並且藉助一些具體的安全廠商的能力去做安全的區域防守或區域的這種保護。隨著業務雲化之後，上了虛機之後，實際上邊界保護變得越來越模糊了，而且虛擬化的安全的防護會讓客戶會變得更加困難。

整個安全中心，藉助安全產品和優勢，整合虛擬化的能力，從虛擬化底層到整個安全資源池，包括整個安全服務體系的建設，為客戶的整個安全等保業務打造了一個非常安全的體系。

基於安全中心之上，還有兩大中心，一個是應用中心，隨著現在越來越多的客戶對雲原生應用的場景訴求，包括容器、服務目錄等，使用者透過應用中心的視角，把企業固有的一些IT應用進行模板化和編排。在整個應用中心裡，可以提供各種各樣的服務目錄，包括大資料服務，資料庫RDS服務的一些應用，這是應用中心的構成。

最後一個是運營中心，就是把整個雲體系的解決方案給到更多的企業和客戶，實際上這個階段會碰到一個問題，就是如何把雲資料中心的能力往垂直行業，或者說往自己的渠道商輸送。這需要一個運營體系去支撐，包括整個服務商的管理計量計費，VDC虛擬資料中心和運維體系的構成。

整個CMP的訴求實際上就是需要完成對廣泛業務形成一個支撐，並且能夠適應整體企業傳統轉型過程中業務架構的變化，從而能更好的支援上層傳統資料庫和新型應用。

二、深信服雲體系架構介紹

實際上產品體系可以分為幾大模組，最下面是資源池的訴求，透過自己的超融合架構acloud去交付整個虛擬化資源池的能力，然後基於acloud之上，形成AC MP的雲管平臺。

基於這個平臺之上，為更大的客戶和集團輸出MSP運營商管理平臺，它可以把雲的能力變成行業的解決方案或垂直的解決方案，並且把這種能力很好的為其他客戶或同行去進行輸出。

整個運維平臺和服務體系的打造，結合了公有云運維。在幫助企業客戶運維的過程中，逐步形成了這樣的一個運維平臺，可以交付給客戶。透過運維平臺更好地實現對資料中心的管理，也可以透過運維平臺幫助客戶代運維和管理。

整個雲的業務體系介紹完成之後，接下來我會分解一下支撐整個雲業務體系的超融合架構和acmp的管理平臺。過去在大型專案的實施過程中，都會有這樣一個感受，就是必須要有一個統一標準的公共框架來支撐整個產品的引進過程。

隨著併發專案的增多，整個開發團隊能力的邊界其實是參差不齊的，大家對規範的遵守，以及一些公共元件的使用，實際上也是不標準的。這樣會導致整個產品體系和平臺體系慢慢的進行腐化，腐化到一定過程就會導致必然要採取措施對這個架構要進行重構。

在重構的過程中，會整合客戶的需求。實際上自己的開發速度也很慢，會拖累整個產品的迭代速度。舉個列子，阿里雲把電商的一些模型也進行了服務化的框架輸出，包括在阿里雲上類似EDAS的服務，把電商的基礎服務框架進行產品化輸出之後，可以很好地支撐同行企業的快速創新和產品開發。

想進行電商業務嘗試的企業，可以很快把底層的基礎架構構建起來。深信服也有這樣的一個基礎框架叫phoenix框架。實際它是由這幾部分組成，底層框架，中介軟體和業務應用app，最底層都是要依賴一個體系的服務框架。

在開發隊伍裡面，採用多程式或協程的模式，或者是微服務這樣一種形態，都是屬於底層服務框架。服務框架實際上是作為底層的一個插座。基於服務框架之上，可能還會依賴很多中介軟體，包括擴充套件模組，比如說整個日誌的處理。

配置的管理操作，還有整個國際化翻譯，包括整體測試框架的遵守，實際上是整個中介軟體的組成。這些中介軟體經過一定的封裝適配之後提供標準的公共介面，開發人員只需要遵守公共介面，後臺整個中介軟體的能力建設，由整個後臺的底層框架去保障的。

基於上面來做業務需求的轉化，當開發人員或產品經理接到新的需求時，實際上有開發人員只是把業務需求轉化成具體的一個業務應用，它並不關心底層實際應用是多程式還是多執行緒。

在整個體系架構向前引進的過程中，底層是用微服務架構，還是用容器去部署，作為APP來講實際上是解耦的。也就相當於把開發人員的角色跟整個底層框架的角色進行區分，這樣的話整個業務在開發和部署速度上都會加快起來。

三、超融合aCloud+aCMP架構設計

整個Phoenix基礎框架的底層，實際上把通用服務能力，比如說外部響應的這種服務能力，一些週期任務，這種RPC還有日誌公共的進行一層封裝，基於這個框架上進行上層APP的開發，拿到phoenix基礎框架的開發人員。

第一個命令可以很快建立一個專案，第二個是建立專案之後對整個服務進行開發。如果把這個框架拿去要做一個使用者管理系統，可能有一個APP是使用者賬號，一個是認證APP，這些APP之間的內部可以透過RPC呼叫，也可以透過http呼叫。

對於超融合架構來講，基於通用X86伺服器上進行去中心化設計，整個主控節點是透過叢集的通訊去自動選舉出來的，當發生網路或者伺服器當機的故障後，對整個主控節點會進行重新選取，這就是去中心化設計的架構原則。

而後臺實現這種技術實際上用到了一個叢集檔案系統，它分佈於每一個X86的節點上，對所有虛擬化資源的配置資訊進行存放。無論哪個節點掛了，另外的節點會對這些配置資料的一些恢復，這是叢集檔案系統的一個技術採用，整個超融合架構，可以把計算網路儲存安全融合於一體，然後支援提供給客戶這樣一個特別簡單容易部署的架構。同時也可以進行計算和儲存分離和混合部署。

整個超融合架構的基礎，實際上就是最下面的計算儲存網路的虛擬化，持續的會在整個底層的虛擬化平臺上打造，為了滿足客戶穩定可靠安全高效能的訴求，會持續的打磨整個底層平臺。

從儲存網路計算上，可能會去對比一些友商，或者一些效能去進行測試，在更多的使用者場景上，更好地保證整個應用的執行。aCMP架構對於雲管平臺來講其實並不陌生，都是開源的。

我們對雲管平臺進行了重新的設計，其原因有以下幾點：

第一點， 實際上，整個openstack隨著社群化的運作和發展，其實整個體系已經非常龐大了，它的業務模組以及整個互動，整個業務流程變得相當的複雜。

第二點， 社群化的版本向前引進的過程跟產品化的整個配套過程是很難融合在一起的。作為產品來講，我們必須要響應客戶的定製化的需求，從而滿足客戶脫離整個社群以外的其他功能。

雖然整個架構的底層元件，比如說計算儲存網路元件，實際上底層的程式碼風格，包括組織都千差萬別。這樣就會給整個開發團隊帶來許多問題，如何建立這樣的過程以及維護。

所以基於此，我們對整個aCMP架構設計做了一些變動。對比較成熟的一些公共元件，比如說使用者認證管理體系，資料採集等，會基於框架做相關擴充套件開發。

這是整個CMP體系，上層是一個適配層，適配層主要是去區分使用者介面和後端模組化設計的適配。

後端的業務模組化劃分之後，需要在上層進行資料的聚合，包括很好的使用者體驗，必然就會把多個模組的資料需要組裝在一起。比如在虛擬機器列表裡面，它可能同時需要計算模組的虛擬機器資訊，同時又需要告警模組或監控模組。

那這些資料需要單個模組去除錯介面，從產生這樣的一些資料，最終提供給客戶，需要很久的響應時間。由此可見，這種體驗是非常差勁的。在此我們用了一個適配層，但是整個aCMP設計架構的亮點，就是採用了portal-api和資料查詢庫libselect打造的。

為了更好地滿足使用者體驗，包括整個介面的響應請求。我們用了一個快取層，實際上是快速地把後臺各個模組的資料進行一個聚合，融合之後能夠呈現在這個介面上，使其使用者訪問資料的時候，不需要按照傳統已有的模組分別查詢資料。

但是引入快取層之後，會面臨一個問題。對於整個實時資料的請求，比如說我在上層創了一個虛機之後，如何能夠快速地把下面建立的虛機資訊刷到訪談層裡面，其實這裡面涉及了一個reflesh機制，是對它的整個使用者請求的讀與寫進行了分離。

在寫請求完成之後，會自動帶入已同步的資料重新整理到快取，這是一個資料同步和一致性設計。

整個CMP對於多雲的或者第三方雲的託管，實際上都有一個最大的困難，就是公有云的各個廠商，它的整個介面形式，包括資料模型千差萬別。在混合雲管理平臺裡，我們用了多雲模板，並將其能力進行抽象。最後統一把整個雲能力拉管起來，提供這種一致性的操作。

四 、資料中心可靠效能力建設

可靠性中心，實際上分為兩個版塊。第一塊就是可視，能夠從整個硬體資源，包括平臺的服務，CPU，或者網口和資料的容災備份，進行統一的全域性視覺化服務。

這樣針對傳統企業來說，或者IT運維能力相對比較差的客戶。在整個視覺化的過程當中，可以快速地發現整個平臺存在的問題。這個能力就是視覺化的一個能力輸出。

第二塊就是對於整個資料的容災，傳統的資料庫首先建立容災和備份的機制，然後是生產的節點和恢復節點，它們之間可以透過底層虛擬化的資料進行實時的備份同步。當虛機資料受損時，可以從本地的備份進行恢復，也可以在恢復站點裡面，透過恢復中心同步回來。

對於不同保護組的應用，進行這種保護策略，來設定它的RPO和RTO。然後對本地的備份和實時的雲端進行容災，然後看到整個業務保護組策略，一個全域性關聯關係。

五、資料中心安全能力建設

整個可靠性的能力打造之後，實際上在面向更多的客戶輸出，包括目前來講對於整個雲平臺的安全治理的產出規範之後，藉助於安全廠商的這些優勢，在整個雲平臺上做了很多關於安全體系架構設計的內容。

作為在CMP上的獨立安全中心，能夠實現整個雲平臺的安全策略體系。在平臺層提供了一個虛擬化安全，在網路整塊虛擬化安全上一系列安全防護，使得在整個虛擬化平臺層能夠幫助客戶減少很多的安全配置。

安全的運維會把整個安全體系和安全能力，作為一個安全資源池來統一編排。或者透過安全元件化，在整個超融合架構裡面，幫助客戶能夠在安全能力建設上達到安全擔保和行業行規的標準。

安全服務體系可以透過安全服務化的能力，幫助客戶在雲平臺建設過程中達到安全的指標，包括整個安全事故或安全保障，基於所有底層的虛擬化安全和安全配置，包括整個安全資源池。

在上面有一個全域性的SIP(態勢感知平臺)，它可以實現對於整個平臺的統一監測，包括資料分析，藉助大資料和AI的後臺，進行一些訓練和學習，可以實時地把整個病毒庫和所有的安全體系，能夠在整個態勢感知平臺裡進行一個展示。最終達到一個可視可控的平臺，從而靈動地響應整個安全事件。