現(xiàn)代云數(shù)據(jù)中心服務器架構(gòu)選型

1、現(xiàn)代云數(shù)據(jù)中心服務器架構(gòu)選型Agenda33傳統(tǒng)企業(yè)的互聯(lián)網(wǎng)之路分布式架構(gòu)轉(zhuǎn)型之路服務器平臺如何選型經(jīng)驗分享互聯(lián)網(wǎng)時代傳統(tǒng)行業(yè)如何轉(zhuǎn)型以運營商為例：傳統(tǒng)電信運營商 業(yè)務套餐復雜，內(nèi)容僵化且計費 成本高，使用體驗差。未來電信 業(yè)務的轉(zhuǎn)型可多向互聯(lián)網(wǎng)業(yè)務學 習以用戶體驗為中心的業(yè)務設計 模式，簡化業(yè)務規(guī)則、簡化系統(tǒng) 設計難度并嘗試后向收費模式。從執(zhí)行層面分析，當前可以重點從以下幾個方面進行業(yè)務轉(zhuǎn)型：（1）真正以客戶為中心，提升客戶體驗（2）全渠道接觸，貼近客戶，增強客戶黏性（3）推動數(shù)字化運營，向數(shù)據(jù)要效益運營商傳統(tǒng)業(yè)務互聯(lián)網(wǎng)業(yè)務業(yè)務設計核心目標以流程為中心以用戶體驗為中心業(yè)務規(guī)則組合業(yè)務多，規(guī)則

2、復雜單品業(yè)務多，規(guī)則簡單業(yè)務套餐設計內(nèi)部人員設計，一般不能用戶定制開放給用戶靈活定制業(yè)務計費方式前向收費為主后向收費為主業(yè)務體驗業(yè)務體驗與資費基本無法掛鉤業(yè)務體驗與資費直接對應業(yè)務流程設計以安全性為第一以可用性為第一計費規(guī)則復雜簡單43互聯(lián)網(wǎng)IT架構(gòu)的發(fā)展對傳統(tǒng)行業(yè)的啟示傳統(tǒng)企業(yè)和互聯(lián)網(wǎng)公司的業(yè)務需求差異業(yè)務需求的巨大差異必然帶來IT架構(gòu)設計的迥異傳統(tǒng)企業(yè)業(yè)務需求互聯(lián)網(wǎng)企業(yè)業(yè)務需求系統(tǒng)設計目標優(yōu)先級可用性第一安全和業(yè)務一致性第 二安全和業(yè)務一致性第二可用性第二業(yè)務流程長流程、復雜流程多短流程組合為主事務復雜性復雜事物多基本沒有復雜事物性能要求業(yè)務并發(fā)變化小，一般可以提前預估性能變化業(yè)務并發(fā)變化

3、大，要求系統(tǒng)能夠快速響應性能伸縮數(shù)據(jù)類型以結(jié)構(gòu)化數(shù)據(jù)為主非結(jié)構(gòu)化數(shù)據(jù)很多業(yè)務需求和IT設計關系業(yè)務需求主導IT設計IT設計可以影響或引導業(yè)務需求讀寫比例7：3或8：210：1以上54“互聯(lián)網(wǎng)+”時代的業(yè)務系統(tǒng)對IT基礎架構(gòu)提出多樣化的要求High PerformanceMature and Growth Markets Large Scale AdoptionScalabilitySecurityEfficiencyData CapabilitiesIndustry AffiliationReliability and AvailabilityAdvanced VirtualizationAu

4、tomation分析洞察系統(tǒng)5核心交易系統(tǒng)智能資源調(diào)配應用快速部署架構(gòu)靈活擴展業(yè)務持續(xù)運行海量數(shù)據(jù)處理實時分析響應數(shù)據(jù)安全合規(guī)軟件定義架構(gòu)互動參與系統(tǒng)設備無縫接入安全可控至上敏捷開發(fā)迭代開放互聯(lián)協(xié)作混合IT架構(gòu)將成為企業(yè)IT架構(gòu)新常態(tài)混合IT 將現(xiàn)有技術與新興技術相融合，協(xié)助 企業(yè)滿足并超出客戶日益增長的需求與期望設備應用傳感器交互系統(tǒng)、洞察系統(tǒng)+HRERP記錄系統(tǒng)CRMDB企業(yè)混合IT環(huán)境公有云傳統(tǒng)IT私有云6傳統(tǒng)IT架構(gòu)向互聯(lián)網(wǎng)架構(gòu)學習轉(zhuǎn)變思路基礎架構(gòu)云化：實現(xiàn)資源的精確供給、動態(tài) 伸縮、快速應用部署、自動化運維關鍵應 用資源 池一般應用 資源池存儲 資源 池對外服務SOA化：梳理服務類型

5、和接口，實 現(xiàn)對外服務的標準化，和能力的對外開放應用邏輯模塊化：將標準化的服務，使用分布式的應用架構(gòu)實現(xiàn)，服務實體可以橫向伸縮現(xiàn)現(xiàn)自頂上頂 而層下層 的設設設 計計，計7從服實務實SOA化高到高 應可用可 ?？繅K靠 化性再性 到要資要源求池求化縱向解耦、橫向分層SOA化，構(gòu)建統(tǒng)一服務 層分布式架構(gòu)輕量級中間件模塊化組合靈活擴展，快速部署， 水平伸縮Agenda99傳統(tǒng)企業(yè)的互聯(lián)網(wǎng)之路分布式架構(gòu)轉(zhuǎn)型之路服務器平臺如何選型經(jīng)驗分享分布式計算一定強？分布式計算的Trade-off并行計算后的Time Overhead：Mater節(jié)點任務分解和匯總的開銷各節(jié)點通信的開銷子任務啟動和停止的系統(tǒng)開銷長尾子

6、任務的延時開銷并行計算后的Cost Overhead：更多的節(jié)點=更多的附屬不可壓縮成本(線纜、磁盤、端口、空間)更多的節(jié)點和OS=更多的運維成本更多的節(jié)點和OS=更多的系統(tǒng)開銷(OS系統(tǒng)常駐內(nèi)存、系統(tǒng)進程)更多的節(jié)點=更難的資源均衡和更低的平均資源利用率并行計算需要更多的軟件優(yōu)化和開發(fā)成本更多的節(jié)點=更高的子任務長尾概率以上對比假設原始任務可以分解為任意多 個可以并行的子任務123456789101112123456789101112TimeTimeMaster節(jié)點:750MHz CPUSlave節(jié)點:750MHz CPUSlave節(jié)點:750MHz CPUSlave節(jié)點:750MHz CP

7、USlave節(jié)點:750MHz CPU4Ghz CPU原始任務9美國加州.伯克利大學EricBrewer教授提出CAP理論-一 個分布式系統(tǒng)不可能 同時滿足一致性、可用性 和分區(qū)容忍性這三項需求, 最多同時只能 滿足其中兩 項。因此集中式處理方式 更適用于要求數(shù)據(jù)完整性 核心帳務交易處理分布式架構(gòu)要犧牲可用性或一致性10系統(tǒng)分布化的難點：事物交易系統(tǒng)為什么OLTP在線交易數(shù)據(jù)庫集群要采用共享式架構(gòu)？CAP理論告訴我們集群系統(tǒng)狀態(tài)下 如果數(shù)據(jù)不共享，必須要犧牲A（可 用性）或者C（一致性）的其中一個。支付業(yè)務屬于高并發(fā)、高可用性要 求和高一致性的典型應用，其數(shù)據(jù) 庫只能采用共享式集群架構(gòu)。Ora

8、cle RAC架構(gòu)Oracle RAC為典型的集中共享式集群，所有節(jié)點共享一份數(shù)據(jù)，節(jié)點間通 過網(wǎng)卡高速交換內(nèi)存數(shù)據(jù)，保證狀態(tài)一致性，并通過共享磁盤保證持久化 數(shù)據(jù)一致性Oracle RAC適合對數(shù)據(jù)一致性和可用性要求很高的支付應用其架構(gòu)橫向擴展困難，需要縱向擴展Oracle RAC對系統(tǒng)硬件（CPU、內(nèi)存、IO板卡、磁盤）均有極高的可靠性 要求，任何輕微的硬件故障均可能導致Oracle重啟11進行分布式架構(gòu)轉(zhuǎn)變需要考慮的問題131312可用性：小型機存儲的高冗余機制,PC和MySQL能否做到一致性：Oracle物理級別一致性,MySQL有沒有問題(語句模式)高性能：高端小機存儲的性能和IO能

9、力很強,PC能否頂?shù)眠^；MySQL和Oracle對SQL的處理性能是否相同 擴展性：分多少庫分多少表,什么維度分 后期二次拆分如何更方便（1）數(shù)據(jù)遷移，包括異構(gòu)數(shù)據(jù)遷移，全量怎么遷移，增量怎么遷移？怎樣才能無縫升級？（2）數(shù)據(jù)路由，如何屏蔽分表給應用帶來的復雜性 ？如何解決多維度查詢？如何解決跨分表查詢？（3）數(shù)據(jù)同步，搜索、數(shù)據(jù)倉庫、其他業(yè)務方都有數(shù)據(jù)導出需求，如何實現(xiàn)實時同步，并且只同步一次（4）分布式事務，一個事務涉及到2張不同緯度的表該怎么辦？一個事務涉及到2個分庫該怎么辦?（5）規(guī)模化運維，如跨庫數(shù)據(jù)訂正怎么解決？DDL的問題怎么處理等這類日常運維工作？如何應對從一臺到幾千臺的運維量

10、變，監(jiān)控、告警怎么搞？如何應對更多的業(yè)務需求變化,開發(fā)能否對DB的操作實現(xiàn)自助？拆分數(shù)據(jù)庫帶來的問題事務的有限支持。支持基于單庫的事務,但不支持跨庫 進行事務。一旦業(yè)務需要跨庫的事務處理, 要么使用復 雜的數(shù)據(jù)模型和應用邏輯來保障,要么使用昂貴的系統(tǒng) 方法(降低其擴展能力)。無法處理局部熱點。局部熱點不會隨著數(shù)據(jù)拆分而消 失,另外拆分的數(shù)據(jù)平衡也是極其復雜的問題。開發(fā)的低效性 。數(shù)據(jù)”分區(qū)”是非標準化的解決方案, 只支持很基本的SQL操作.使用該方法將造成程序員開發(fā)的低效性和提高應用邏輯的復雜度。架構(gòu)的獨特性。獨特的架構(gòu)引入了維護與監(jiān)控以及和 其他商業(yè)軟件的互聯(lián)互通等一系列獨有的問題.以支付寶

11、為例,為了保證其擴展性和可用性,犧牲數(shù)據(jù)一致性,每筆支付需要500條SQL和80個數(shù)據(jù)庫事務通過 近500個系統(tǒng)來完成，這與運營商的實現(xiàn)方式完全不同。數(shù)據(jù)庫拆分的方法，引入中間層，犧牲一致性13分布式計算集中式計算，各有不同用點，適合不同的業(yè)務場景需求14互聯(lián)網(wǎng)應用確實將分布式計算帶到了新的臺階,但是并沒有突破計算機科學的CAP基本原理。因此需要 犧牲數(shù)據(jù)一致性換得處理能力的線性可擴展性。而傳統(tǒng)企業(yè)業(yè)務需要注重數(shù)據(jù)的實時強一致性采用集中處理,在一個統(tǒng)一的唯一數(shù)據(jù)視圖上進行橫向和 豎向的擴展來滿足業(yè)務的吞吐量要求。所以傳統(tǒng)企業(yè)的架構(gòu)是集中和分布的綜合體。選擇完整性/可用性(C/A)保證數(shù)據(jù)的強一

12、致性事務處理 交易, 是傳統(tǒng)企業(yè)在過去的三十幾年的業(yè)務發(fā)展過程中要求遵循的基本架構(gòu)及編程原則。采用數(shù)據(jù)庫、交易管理中間件從系統(tǒng)級提供的數(shù)據(jù)強一致性,簡化業(yè)務應用的編程使其致力于業(yè)務功能 的實現(xiàn)是運營商過去的最佳實踐。因此,集中式計算體系依然至關重要。在互聯(lián)網(wǎng)業(yè)務這種保持數(shù)據(jù)弱一致性非事務處理交易,采用分布式計算則是最經(jīng)濟的選擇。同理, 傳統(tǒng)的面向客戶服務的互聯(lián)網(wǎng)業(yè)務平臺也可以采用分布式架構(gòu)未來傳統(tǒng)企業(yè)的架構(gòu)一定是一種集中式和分布式混合體系。新興的面向互聯(lián)網(wǎng)業(yè)務平臺架構(gòu)轉(zhuǎn)型思路161615傳統(tǒng)企業(yè)的面向互聯(lián)網(wǎng)業(yè)務平臺，與互聯(lián)網(wǎng)公司的業(yè)務系統(tǒng)有著相似的業(yè)務特征和系統(tǒng)建設需求，因此可以全面學習互 聯(lián)

13、網(wǎng)公司的系統(tǒng)架構(gòu)和建設思路。針對互聯(lián)網(wǎng)業(yè)務平臺的應用場景，需要根據(jù)數(shù)據(jù)類型和數(shù)據(jù)價值考慮結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲方案。此 外，需要格外關注動態(tài)可擴展性和分布式計算，基于shared-nothing技術架構(gòu)構(gòu)建分布式數(shù)據(jù)庫，支持數(shù)據(jù)節(jié)點的最大 橫向擴展要求，滿足海量數(shù)據(jù)存儲與海量用戶的并發(fā)處理能力。同時采用讀寫分離操作模式，有效地減輕數(shù)據(jù)庫與I/O 壓力。大數(shù)據(jù)領域?qū)儆谧x多寫少分析為主的場景，一般不用考慮CAP沖突，因此可以方便的使用分布式架構(gòu)進行設計。需重點 考慮分布式文件系統(tǒng)、NoSQL數(shù) 據(jù)庫、并行計算框架和流數(shù)據(jù)處理等技術，從而支持海量數(shù)據(jù)的存儲、檢索、分析及 對流數(shù)據(jù)的動態(tài)

14、實時分析處理。大數(shù)據(jù)分析提供的客戶與市場洞察、網(wǎng)絡與客戶體驗洞察優(yōu)化、運營洞察與優(yōu)化能力促 進了傳統(tǒng)企業(yè)核心競爭力的提升，同時催生出新的商業(yè)模式創(chuàng)新和新產(chǎn)品的創(chuàng)新，而這正是互聯(lián)網(wǎng)時代傳統(tǒng)企業(yè)轉(zhuǎn)型戰(zhàn) 略的內(nèi)容。此外，針對客戶行為及喜好的分析，為客戶提供個性化、精準的服務，從而達到增強用戶體驗的目的。數(shù)據(jù)庫架構(gòu)擴展兩種思路邏輯上仍然采用傳統(tǒng)集中式處理架構(gòu)，但是物理上采用閃存介質(zhì)和可分布式存儲 層等方式，構(gòu)建更加容易擴展更加高效的數(shù)據(jù)庫資源平臺。實現(xiàn)對應用完全透明。171716運營商數(shù)據(jù)庫架構(gòu)優(yōu)化應堅持以ScaleUP為主傳統(tǒng)企業(yè)需要謹慎使用業(yè)務補償機制,選擇以Scale-Up為主,Scale-Ou

15、t為輔的解決方案較為符合現(xiàn)狀。181817傳統(tǒng)企業(yè)尤其是國企負有政治責任，不能隨意采用業(yè)務補償機制 數(shù)據(jù)庫架構(gòu)可以使用大Scale-Up,小Scale-Out架構(gòu)不掌握核心開發(fā)團隊,盡量在技術架構(gòu)解決問題核心業(yè)務系統(tǒng)以穩(wěn)定為第一，在保持穩(wěn)定可靠并且對業(yè)務邏輯影響最小的的前提下，盡量通過硬件技術的進步提升系統(tǒng)性能。傳統(tǒng)企業(yè)“去Oracle”可選的產(chǎn)品路線191918，產(chǎn)品路線操作意義可行性分析1Oracle以外的 商業(yè)數(shù)據(jù)庫使用O以外的商業(yè)數(shù)據(jù)庫來實現(xiàn)去O,投 機取巧的選擇,不具備任何意義如果去O,不能是采用其他商用數(shù)據(jù)庫軟件來替換Oracle,而是應該去除所有國外商業(yè)數(shù)據(jù)庫2使用純國產(chǎn)數(shù)據(jù)庫對

16、現(xiàn)有系統(tǒng)迚行重構(gòu),直接使用純國產(chǎn) 數(shù)據(jù)庫 來實現(xiàn)去O,簡單粗暴的選擇,但 國產(chǎn)數(shù)據(jù)庫穩(wěn) 定性以及性能未得到長 時間運行驗證,風險極高國產(chǎn)數(shù)據(jù)庫在沒有經(jīng)過運營商核心系統(tǒng)運行的驗 證, 同時選擇國產(chǎn)數(shù)據(jù)庫,會迚入到產(chǎn)品的細小分 支, 后續(xù)支持力度可能會存在問題3收購數(shù)據(jù)庫其本質(zhì)還是商業(yè)數(shù)據(jù)庫,跟路線一類似, 只有 象征意義國內(nèi)廠商收購的國外數(shù)據(jù)庫, 國人完全掌控需要 一段時間,建議以觀察為主4采用純開源數(shù) 據(jù)庫方案互聯(lián)網(wǎng)業(yè)界主流的去O方案,要求較高 的技術門檻, 同時需要對現(xiàn)有系統(tǒng)迚行 大幅改造開源數(shù)據(jù)庫是于聯(lián)網(wǎng)去O的主流選擇。但 需要較 高的技術掌控門檻,同時需要較強的定制能力 ， 運營商近期不

17、具備掌控能力5基于開源數(shù)據(jù)庫進行定制對純開源數(shù)據(jù)庫,定制版在高可用能力、維 護支持力度上有較大改善定制開源數(shù)據(jù)庫需要小心與開源主流分支的兼容 同時定制數(shù)據(jù)庫本質(zhì)上與研發(fā)數(shù)據(jù)庫需要同樣水 平的開發(fā)能力。Oracle數(shù)據(jù)庫架構(gòu)優(yōu)化思路Oracle數(shù)據(jù)庫性能優(yōu)化主要有兩條路：一個是存儲層分布式化+數(shù)據(jù)庫一體機，這種方式采用InfinibandSSD產(chǎn)品成本高昂，軟硬件緊密耦合綁定，且增加 了運營維護難度。另一種思路是利用全閃存介質(zhì)替代磁盤陣列作為持久化存儲，從而大幅提高數(shù)據(jù)庫性能。此種方式對Oracle數(shù)據(jù)庫應 用架構(gòu)沒有任何更改，保持了運維手段的一致性。典型的代表有IBM 全閃存陣列方案，近年在國

18、內(nèi)各大券商得到廣泛 應用和推廣，在保持對應用透明的基礎上均提高交易能力5倍以上。Oracle數(shù)據(jù)庫的性能優(yōu)化遵循漏斗法則，磁盤IO的優(yōu)化往往比CPU和內(nèi)存的擴容效 果更加顯著。使用全閃存陣列存放所有數(shù)據(jù)是綜合性能提升效果最明顯，對系統(tǒng)架構(gòu)改變最小， 最成熟穩(wěn)定和容易維護的方案。典型的代表有IBM 全閃存陣列方案，今年在國內(nèi)各 大券商得到廣泛應用和推廣，在保持現(xiàn)有應用架構(gòu)不變的基礎上均提高交易能力5 倍以上。202019Oracle數(shù)據(jù)庫一體機方案Oracle數(shù)據(jù)庫“一體機”的核心思路是通過將存儲層分布式化，并利用Infiniband和閃存技術極大降低數(shù)據(jù)交互延遲提升 數(shù)據(jù)IOPS來提升性能。O

19、racle數(shù)據(jù)庫“一體機”的最好方案是Exadata，但是Exadata最大的問題是高昂的價格和封閉技術路線無法在傳統(tǒng)企業(yè) 大規(guī)模使用。國內(nèi)涌現(xiàn)出大量的山寨版Oracle數(shù)據(jù)庫“一體機”方案，其實現(xiàn)分布式存儲無非是以下幾種技術：1、Oracle ASM技術2、分布式存儲技術（Sheepdog，Ceph，VSAN） 山寨版Oracle數(shù)據(jù)庫“一體機”方案風險在于：需要注意Oracle原廠support問題堆疊了大量Infiniband和閃存，成本很高架構(gòu)維護難度遠高于傳統(tǒng)IOE架構(gòu)212120Agenda傳統(tǒng)企業(yè)的互聯(lián)網(wǎng)之路分布式架構(gòu)轉(zhuǎn)型之路服務器平臺如何選型經(jīng)驗分享兩種系統(tǒng)架構(gòu)對硬件平臺的需求

20、區(qū)別集中式架構(gòu)系統(tǒng)更高的單節(jié)點性能縱向擴展能力單節(jié)點的可靠性高應用架構(gòu) 特點22對服務器 的需求單機高性能RISC指令集大規(guī)模多處理器架構(gòu)32256core CPU單機可靠性99.997%服務器產(chǎn)品代表IBM PowerHP SuperDomeOracle/Sun M9000分布式架構(gòu)系統(tǒng)較低的單節(jié)點性能橫向擴展能力單節(jié)點的可靠性低單機性能要求不高RISC/MICS指令集簡單多處理器架構(gòu)232core CPU單機可靠性98%X86 PC服務器Power PC服務器ARM 服務器如何根據(jù)系統(tǒng)應用選擇服務器平臺非功能性需求（NFR）系統(tǒng)業(yè)務需求如業(yè)務峰值，并發(fā)度，業(yè)務復合增 長率，業(yè)務連續(xù)性需求，

21、業(yè)務可靠 性需求等系統(tǒng)軟件架構(gòu)軟件擴展方式，軟件HA模式，軟件 負載均衡方式，軟件FailureOver方 式等IT管控與運維IT安全規(guī)定，內(nèi)控規(guī)定，運維管理要求等其他限制條件如已有軟件架構(gòu)，與現(xiàn)有平臺的兼 容性，機房集中網(wǎng)管備份條件，機 房占地能耗要求，技術自主可控 等性能需求可靠性需求擴展性需求安全性需求可管理性需求兼容性需求節(jié)能環(huán)保需求虛擬化需求其他需求高端服務器中端服務器低端服務器23性能與可靠性：服務器平臺的分類性能Power710/7 40X86低端小Power機PC高端服務器領域以IBM Z代表的大型機以IBM Power代表的小型機面向高端企業(yè)級市場不斷追求更高單機性能更高的硬

22、件可靠性低端服務器領域以X86代表的PC兼容服務器面向消費市場和低端企業(yè)市場不斷追求更低的硬件成本放寬可靠性設計以ARM為代表的更廉價服務器以IBM Power PC為代表的新一代服務器可靠性ARM大型機IBM Z高端小型機Power78024中端小型機Power750如何基于系統(tǒng)應用負載需求特征進行平臺選型單機可靠性應用節(jié)點少，系統(tǒng)業(yè)務重要，要求很高的 單機可靠性多節(jié)點應用集群，主要靠軟件保障可靠性，不要求很高的單機可靠性單機性能對單機性能要求較高對單機性能要求較低縱向/橫向擴展性應用橫向擴展困難，以縱向擴展為主應用為分布式橫向擴展架構(gòu)，可以方便地 進行橫向擴展安全隔離要求應用安全性高，需要

23、物理級的安全隔離應用安全性不高，不要求嚴格的安全隔離應用更新頻度應用一年更新一次或更少，強調(diào)系統(tǒng)穩(wěn)定應用經(jīng)常更新，應用邏輯變化快廉價要求系統(tǒng)采購以低成本為第一要求系統(tǒng)采購以綜合造價/TCO為評價要求綠色節(jié)能要求部署核心機房，機房資源少造價高，要求 設備盡量減少空間能耗部署一般機房，機房造價較低，對設備節(jié) 能和空間消耗要求較低技術支持要求要求本地的原廠售后技術支持一般不需要原廠售后技術支持25互聯(lián)網(wǎng)系統(tǒng)架構(gòu)發(fā)展思路和平臺選擇采用SOA和服務總線，結(jié)合輕量級中間件、分布式文件系統(tǒng)、分布式緩存、分布式NoSQL數(shù)據(jù)庫，結(jié)合建立橫向擴展的，基于服務松耦合的分布式架構(gòu)。前端展現(xiàn)層服務層數(shù)據(jù)庫層NoSQL

24、緩存技術、分布式文件系統(tǒng)、流和更快的橫向擴展提供多種分庫分表的路由，支持讀寫分 離、一主多備的數(shù)據(jù)分布。為應用提供數(shù)據(jù)透明訪問接口，屏蔽數(shù) 據(jù)分布的變化支持數(shù)據(jù)訪問的流量管理和故障切換。核心庫仍以Oracle數(shù)據(jù)庫為主通過歷史數(shù)據(jù)剝離、垂直分庫及讀寫分 離等難度較低方式，逐步降低核心數(shù)據(jù) 庫的壓力服務SOA化，實現(xiàn)服務的標準化與可重用。數(shù)據(jù)中間層演進思路對平臺的需求使用輕量級Web服務器，結(jié)合分布式量分發(fā)和均衡技術，實現(xiàn)更高的并發(fā)能力 使用服務總線技術，結(jié)合流程引擎技術和 消息總線技術，實現(xiàn)高性能、分布式、易 擴展的服務層。橫向擴展架構(gòu)，多節(jié)點集群側(cè)重多并發(fā)多線程能力 對單機可靠性要求較低業(yè)務

25、需求變化快，強調(diào)架構(gòu)的靈活和快速相應混合擴展架構(gòu)，多節(jié)點集群對單機可靠性要求較高業(yè)務需求變化一般，強調(diào)架構(gòu)相對穩(wěn)定 和靈活橫向擴展架構(gòu)，多節(jié)點集群對單機可靠性要求較高業(yè)務需求變化較慢，強調(diào)架構(gòu)穩(wěn)定縱向擴展架構(gòu)，雙節(jié)點集群對單機可靠性要求很高業(yè)務需求變化很慢，強調(diào)架構(gòu)穩(wěn)定II類II類I類I類26I類應用平臺建設建議安全隔離 應用更新廉價要求橫向擴展性I類:核心關鍵負載類單機可靠性技術支持單機性能綠色節(jié)能縱向擴展性平臺選型建議：27Power小型機+Power虛擬化技術，構(gòu)建關鍵應用云化資源池，并保持平臺的性能、可靠性和QoS。結(jié)合LPM， Remote Restart、Enterprise Po

26、ol等創(chuàng)新技術，實現(xiàn)應用的靈活伸縮和擴展，及應用的快速部署和故障遷移，提 高架構(gòu)的彈性和可靠性原因分析：Power虛擬化技術是目前市場最能夠滿足Oralce數(shù)據(jù)庫等核心關鍵應用負載的企業(yè)級虛擬化技術Power云化對現(xiàn)有應用來說遷移工作量和風險最小，并可以做到不降低原有應用的QoS要求PowerVM可以采用中高端小型機的動態(tài)分區(qū)模式，使用專有CPU和IO滿足系統(tǒng)數(shù)據(jù)庫等關鍵應用對性能和可 靠性的苛刻需求Power創(chuàng)新的Enterprise Pool技術，實現(xiàn)更加簡單靈活的資源彈性使用采用PowerVM可充分利舊現(xiàn)有的設備，減少資源浪費Power小型機能耗水平低，占地空間少，有利于節(jié)約核心機房寶貴

27、的機房資源(如核心數(shù)據(jù)庫/交易中間件/內(nèi)存數(shù)據(jù)庫)應用云化思路以平臺的穩(wěn)定可靠為宗旨，并進行云化改 造，實現(xiàn)應用和硬件松耦合。對集中的數(shù) 據(jù)庫按照地域和功能進行拆分，部署松耦 合的應用架構(gòu)，提高架構(gòu)的彈性和靈活性。數(shù)據(jù)庫系統(tǒng)基礎平臺平臺需求的分析系統(tǒng)軟件架構(gòu)系統(tǒng)軟件采用Oracle RAC，典型的集中共享式高可 用架構(gòu)，適合對數(shù)據(jù)一致性和可用性要求很高的支付 應用軟件架構(gòu)橫向擴展困難，需要縱向擴展Oracle RAC對系統(tǒng)硬件（CPU、內(nèi)存、IO板卡、磁 盤）均有極高的可靠性要求，任何輕微的硬件故障均可能導致Oracle重啟系統(tǒng)業(yè)務需求典型OLTP在線交易應用要求高并發(fā)事務處理未來業(yè)務量連續(xù)增

28、長，要求具備平滑擴展能 力屬于在線支付業(yè)務，業(yè)務中斷造成的損失大，要求極高的業(yè)務連續(xù)性，保障用戶資金安 全IT管控與運維滿足公司安全法規(guī)滿足公司內(nèi)控規(guī)定滿足運維集中監(jiān)控、網(wǎng)管、故障告警、備份、容災等要求其他限制條件28硬件平臺必須兼容現(xiàn)有的數(shù)據(jù)庫軟件，必須有大量實際運行案例必須兼容現(xiàn)有網(wǎng)管、監(jiān)控、容災、備份等系統(tǒng)滿足機房供電規(guī)范，滿足機房能耗和節(jié)能要求，滿足 機架標準數(shù)據(jù)庫硬件選型的對比29數(shù)據(jù)庫平臺其他一般應用平臺性能雙節(jié)點集群，采用1+1 HA方式，要求故障時每個節(jié)點的單機性能必需能接管全部業(yè)務采用多節(jié)點集群方式，N+1 HA，對單個節(jié)點的性能沒有很高要求，整個系統(tǒng)的性能靠多節(jié)點疊加實現(xiàn)可

29、靠性Oracle RAC對硬件的可靠性有很高的要求一般靠軟件實現(xiàn)Failure Over，單個節(jié)點故障對整個集群影響 可控，對硬件可靠性要求可適當降低擴展性縱向擴展為主，要求硬件必須具備很強的單機 擴展能力橫向擴展為主，硬件單機不要求很強的擴展能力安全性核心交易業(yè)務，系統(tǒng)安全要求高要求操作系統(tǒng)安全性高，漏洞少，抗病毒和攻 擊能力強數(shù)據(jù)庫節(jié)點間要嚴格物理隔離一般業(yè)務，系統(tǒng)安全要求可適當放寬對操作系統(tǒng)漏洞和抗病毒等要求相對寬松，一般采用開放的linux平臺應用節(jié)點間不要求嚴格隔離，一般共享資源提高利用率可管理性要求隨機具備完善的原廠管理和監(jiān)控軟件一般采用第三方或開源的監(jiān)控和管理軟件維護保障要求原廠

30、的售后維護保障機制，具備本地完善的支持團隊采用第三方代維即可兼容性必須兼容現(xiàn)有系統(tǒng)架構(gòu)和軟件必須兼容現(xiàn)有系統(tǒng)架構(gòu)和軟件節(jié)能環(huán)保滿足機房節(jié)能環(huán)保要求滿足機房節(jié)能環(huán)保要求虛擬化要求虛擬化性能損失小，一般不做虛擬化可接受適當?shù)奶摂M化性能損失，一般做虛擬化II類應用平臺建設建議應用云化思路采用低成本云化平臺，建設完全云化的資源池，實現(xiàn)完 全共享、橫向擴展和動態(tài)伸縮的云化架構(gòu)，實現(xiàn)應用和 硬件的完全解耦。平臺選型建議：PowerLinux低成本服務器平臺，采用成熟可靠虛擬化技術，并結(jié)合開放的可軟件定義的云管理平臺，并積極探索PaaS云 技術，實現(xiàn)更高層次的云化。實現(xiàn)基于自動化手段的集中式監(jiān)控，實現(xiàn)大規(guī)模

31、集群的高效自動化運維。原因分析：Linux平臺，業(yè)界使用最廣泛，平臺成熟，兼容性風險小，開發(fā)和維護成本低根據(jù)應用負載對單機性能要求的不同，可靈活選擇高端PC服務器或低端PC服務器Powerlinux產(chǎn)品，標準Linux平臺的高端PC服務器，兼顧性能、可靠性和低成本，并適于橫向擴展，是替代低端PC服 務器的更好選擇Powerlinxu的虛擬化技術與Power相同，更加便于資源池的統(tǒng)一維護和管理基于OpenStack等開源云管理方案，可實現(xiàn)靈活定制的云管理流程，并能廣泛兼容各種型號和品牌的服務器產(chǎn)品。31II類:一般應用負載類單機可靠性技術支持單機性能綠色節(jié)能縱向擴展性廉價要求安全隔離 橫向擴展性

32、應用更新30(如前端Web服務器/接口機/網(wǎng)管/報表服務器)Agenda3322傳統(tǒng)企業(yè)的互聯(lián)網(wǎng)之路分布式架構(gòu)轉(zhuǎn)型之路服務器平臺如何選型經(jīng)驗分享33IBM系統(tǒng)基礎架構(gòu)全面支撐企業(yè)向“互聯(lián)網(wǎng)+”轉(zhuǎn)型基礎硬件平臺（開放，自主安全可控，深度定制，軟件定義，自由擴展）應用平臺軟件（開放，開源，優(yōu)化）能力開放，API經(jīng)濟傳統(tǒng)系統(tǒng)平臺化，水平化，靈 活擴展互聯(lián)網(wǎng)系統(tǒng)敏捷化，移動化，無 縫化大數(shù)據(jù)系統(tǒng)實時化， 海量化， 數(shù)據(jù)安全移動APPFlash Systems混合云資源管理平臺（開放，兼容，靈活定義，安全）BHYRIDHybrid Cloud創(chuàng)新業(yè)務Linux社區(qū)貢獻排名公司第2，主流Linux發(fā)行版均

33、有Power優(yōu)化版本， Power支持KVM虛擬化。IBM Power與開源的合作白金贊助商，19 個核心貢獻者，貢 獻排名第2，超過100個活躍開發(fā)者。IBM基礎架構(gòu)云全面以OpenStack為中心。投入10億美金發(fā) 展 Linux及相關 開源技術。IBM發(fā)起創(chuàng)立軟件定義 網(wǎng)絡開源聯(lián)盟Hadoop社區(qū)主要貢獻者，提供Hadoop發(fā)行版，發(fā)起成立ODP，提供Hadoop增強方案。IBM與國內(nèi)實力最強的 星環(huán)、亞信，巨杉等新 技術公司合作，開發(fā)Power優(yōu)化的Hadoop版本和NewSQL數(shù)據(jù)庫，與國內(nèi)公司一起拓展 開源商業(yè)生態(tài)系統(tǒng)。IBM與Redis合作，基于IBM CAPICPU硬件加速技術

34、，建立創(chuàng)新的Redis方案。IBM 和 Docker 宣布建立戰(zhàn)略伙伴關系，提供基于Power的Docker優(yōu)化版本。Power+PostgreSQL提供分布式事務處 理數(shù)據(jù)庫優(yōu)化方案33/ibmsoeIBM Power支持各領域主流開源軟件34Docker on Power：下一代云方案Docker是業(yè)界領先的輕量級虛擬化開源方案， 能夠提供更加快速、靈活、低成本和云兼容的云 化方案，代表了未來云計算技術發(fā)展的方向。2014年6月10日 雙方建立合作伙伴 關系DockerHub將支持托管在SoftLayer之上IBM將提供WebSphere應 用中間件鏡像Docker容器可以部署在SoftL

35、ayer上，無論是裸機還是虛擬機2014年12月4日 雙方建立戰(zhàn)略合作 伙伴關系IBM將通過集成方案和單獨產(chǎn)品兩種模式生產(chǎn)和銷售Docker Hub企業(yè)版。IBM將通過集成了Docker 編配引擎的IBM BlueMix提 供容器服務。2014年12月9日2015年Docker已經(jīng)被移植到Power8小端 架構(gòu)上，可通過Ubuntu源安裝。Docker官方Top15鏡像都已經(jīng)或正 在支持Power架構(gòu)，百余應用鏡像 也在移植到Power8架構(gòu)中。/press/us/en/pressrelease/45597.wss35Stream基于Powerlinux的創(chuàng)新方案PowerPowerPower

36、PowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerGPFS/HDFSETL清單 查詢?nèi)罩?分析流量 分析精確 營銷Symphy/Hadoop/SparkHive/HBase文檔管理SequiaDB MongoDB行為分析DB2GBase數(shù)據(jù) 倉庫數(shù)據(jù) 集市海量NAS軟件定義存儲 云存儲無狀態(tài) 計算數(shù)據(jù)挖掘PowerMatlab/Excel可視數(shù) 據(jù)挖掘Power實時計算 告警分析SPSS/SAS計費批價分布式服務 總線36利用Powerlinux適于大數(shù)據(jù)處理的特性，基于IBM自有/開源/第三方商業(yè)軟件，發(fā)展各種新

37、型的數(shù)據(jù)采集、處理、存儲、查詢和分析應用方案基于Powerlinux的創(chuàng)新方案PowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerDPDKPowerMySQL/PostgreSQL交易數(shù)據(jù)庫Redis/Memcache內(nèi)存數(shù)據(jù)庫網(wǎng)格BES/ACE交易中間件利用Powerlinux適合Java應用的特性，圍繞Java的生態(tài)系統(tǒng)，融合商用/開源的各種數(shù)據(jù)庫和中間件,支撐分布 式系統(tǒng)架構(gòu)JavaddWAS/Weblogic/BESWeb服務集群Nginx/LVSHTTP服務器SDNOpenMP

38、EG視頻處理37PostgresQLPostgresQL-XC on Power8：國內(nèi)與中移蘇研合作進行 基于Power8的分布式數(shù)據(jù)庫平臺測試。PostgresQL-XL on Power8：國內(nèi)與亞信合作進行基于 Power8的分布式數(shù)據(jù)庫平臺測試。以下是在亞信進行的測試結(jié)果：Power + PostgresQL/MariaDB：分布式OLTP數(shù)據(jù)庫MariaDBMariaDB在Power8上運行比x86上可獲得 2.2倍的每秒交易數(shù)，同時每個交易的成本 只有x86平臺的56%。Projections are based performance results reported in /

39、partnerworld/wps/servlet/ContentHandler/stg_ast_sys_wp_ibm-power- systems-solution-for-mariadb/lc=en_ALL_ZZ. Individual results will vary depending on individual workloads, configurations and conditions. IBM Power System S822L with (per socket) 10 cores / 80 threads, POWER8; 3.67GHz, 128 GB memory,

40、Ubuntu 14.04 IBM; Linux kernel: 3.13.0-35-generic with MariaDB 10.0.14 compared to Competitive stack: IBM System x3650 M4 with (per socket) 12 cores / 24 threads; Intel E5-2697 v2; 2.7 GHz; 128 GB , Ubuntu 14.04 IBM; Linux kernel: 3.13.0-35-generic with MariaDB 10.0.14.S822L results were extrapolate

41、d to an C812L-M based 10c 3.5 GHz / 1-socket / 256 GB memory / 2x4TB drive system. The HP DL380p results wereextrapolated to E5-2620: 12c 2.0 Ghz / 2 socket / 256 GB memory / 2x4TB drives. The results were obtained under laboratory conditions, and not in an actual customer environment. IBMs internal

42、 workload studies are not benchmark applications, nor are they based on any benchmark standard. As such, customer applications, differences in the stack deployed, and other systems variations or testing conditions may produce different results and may vary based on actual configuration, applications

43、, specific queries and other variables in a production environment.38Power + LVS/Keepalived: 高性能web接入服務器IDC交換機 視頻自有交換機Real Server 1Nginx 反向代 理LVSDirector2公網(wǎng) VLAN 私網(wǎng) VLAN單個公網(wǎng) IP 接入：VIP（22）LVSDirector1VIP：22DIP：（私網(wǎng)地址）DIP：（私網(wǎng)地址）RIP：（私網(wǎng)地址）Real Server 2Nginx 反向代 理RIP：（私網(wǎng)地址）私網(wǎng)網(wǎng)關公網(wǎng)網(wǎng)關上海視頻 交換機內(nèi)容服務器ApacheKeepalived 是集群管理中保證集群高可用的一個服務軟件，其 功能類似于heartbeat，用來防止LVS節(jié)點