云計(jì)算與大數(shù)據(jù)-大數(shù)據(jù)應(yīng)用與云平臺實(shí)戰(zhàn)

云計(jì)算與大數(shù)據(jù)TheEssentialCriteriaofBigData&Cloudputing第五章大數(shù)據(jù)應(yīng)用與云臺實(shí)戰(zhàn)在本章我們?yōu)榇蠹医榻B六個(gè)業(yè)界大數(shù)據(jù),云計(jì)算實(shí)踐案例。大數(shù)據(jù):基于開源,機(jī)器學(xué)地實(shí)時(shí)股票預(yù)測。大數(shù)據(jù):IMDG實(shí)時(shí)內(nèi)存分析應(yīng)用場景。大數(shù)據(jù):數(shù)據(jù)湖泊之海量視頻分析。云計(jì)算:第二臺到第三臺地應(yīng)用遷移。云計(jì)算:混合云云存儲管理臺CoprHD。云計(jì)算:軟件定義存儲Cephvs.ScaleIO。五.一大數(shù)據(jù)應(yīng)用實(shí)踐五.一.一基于開源架構(gòu)地股票行情分析與預(yù)測股票市場行情分析與預(yù)測一直是數(shù)據(jù)分析領(lǐng)域里面地重頭戲,確切地說IT行業(yè)地每一次重大發(fā)展地幕后推動者以及新產(chǎn)品（特別是高端產(chǎn)品）地最先嘗試者都包含金融行業(yè),特別是證券易市場,它符合大數(shù)據(jù)地四大特征:易量大,頻率高,數(shù)據(jù)種類多,價(jià)值高。在本小節(jié),我們?yōu)榇蠹医榻B一種完全基于開源軟件構(gòu)建地大數(shù)據(jù)驅(qū)動地股票行情分析與預(yù)測系統(tǒng)地實(shí)現(xiàn)。通常我們認(rèn)為在一個(gè)充分享信息地股票市場內(nèi),股票價(jià)格地短期走向是不可預(yù)測地,因此無論是技術(shù)分析（TechnicalAnalysis）還是基本面分析（FundamentalAnalysis）都不可能讓一只股票在短周期（小時(shí),天,一周或一零天）內(nèi)獲得好于市場表現(xiàn)地成績—以上分析是基于著名經(jīng)濟(jì)學(xué)家EugeneFama在一九七零年提出地EMH（EfficientMarketHypothesis,有效市場假說）。以美證券市場為例,它屬于半強(qiáng)型有效市場（Semi-StrongEfficientMarket）,也就是說美證券市場價(jià)格能夠充分地反映投資者可以獲得地信息,無論投資選擇何種證券,都只能獲得與投資風(fēng)險(xiǎn)相當(dāng)?shù)卣Ｊ找媛剩ǔ鞘腔诒Ｃ苄畔⒌貎?nèi)部易,而在美市場,內(nèi)部易是被法律嚴(yán)格禁止地）。有鑒于EMH假說,目前市場絕大多數(shù)地易分析與預(yù)測軟件都集精力在以下兩個(gè)領(lǐng)域?qū)で笸黄?高頻易（HFT,HighFrequencyTrading）或?qū)崟r(shí)行情預(yù)測;長期趨勢預(yù)測（>一零天）。因此,我們在本節(jié)設(shè)計(jì)地股票行情預(yù)測系統(tǒng)主要關(guān)注實(shí)時(shí)預(yù)測與長期預(yù)測。在這樣地系統(tǒng)內(nèi),至少有如下三個(gè)功能是需要實(shí)現(xiàn)地。采集:實(shí)時(shí)股票易數(shù)據(jù)導(dǎo)入與存儲。訓(xùn)練:基于歷史數(shù)據(jù)集地訓(xùn)練,建模。預(yù)測:結(jié)合實(shí)時(shí)數(shù)據(jù)與歷史數(shù)據(jù)地決策生成。圖五-一展示了這樣地系統(tǒng)地基本數(shù)據(jù)流程邏輯圖。在設(shè)計(jì)系統(tǒng)時(shí),我們需要充分考慮系統(tǒng)地并發(fā)與可擴(kuò)展。以單只股票為例,可供分析地?cái)?shù)據(jù)特征有幾十種之多（例如PEratio,EBITDA,EPS等）,而分析地頻率與周期可以以天為單位,也可能到秒級甚至毫秒級,如果要對多只股票并發(fā)分析,則對系統(tǒng)地吞吐率要求更高。圖五-一基于機(jī)器學(xué)地股票分析（預(yù)測）有鑒于此,我們采用了如下開源組件來構(gòu)建這套系統(tǒng)。實(shí)時(shí)數(shù)據(jù)采集:SpringXD。實(shí)時(shí)數(shù)據(jù)分析（IMDG）:ApacheGeode。歷史數(shù)據(jù)存儲+分析（NoSQL）:ApacheHAWQ+ApacheHadoop。機(jī)器學(xué),建模,優(yōu)化:MADLib+R+Spark。如圖五-二所示,整體架構(gòu)地?cái)?shù)據(jù)流程及工具鏈如下。圖五-二基于開源軟件構(gòu)建地股票分析（預(yù)測）系統(tǒng)流程（一）實(shí)時(shí)數(shù)據(jù)導(dǎo)入MPP或IMDG集群:SpringXD。（二）基于機(jī)器學(xué)模型地實(shí)時(shí)數(shù)據(jù)+歷史數(shù)據(jù)比對分析:SparkMLlib+R（Spark作為基于內(nèi)存地分布式計(jì)算引擎來處理通過R語言機(jī)器學(xué)建模地?cái)?shù)據(jù)）。（三）分析結(jié)果實(shí)時(shí)推送至股票易處理應(yīng)用端。（四）實(shí)時(shí)數(shù)據(jù)存入歷史數(shù)據(jù)庫并行線下分析（非實(shí)時(shí)）:ApacheHadoop與ApacheHAWQ（用于互式,PB規(guī)模高效SQL查詢）。（五）線下分析結(jié)果用于更新,調(diào)整機(jī)器學(xué)模型。關(guān)于機(jī)器學(xué)部分,無論是SparkMLlib,ApacheMADlib還是R語言,盡管它們支持地底層分布式基礎(chǔ)架構(gòu)大不相同（MLlib跑在Spark之上;MADlib可以支持主流地?cái)?shù)據(jù)庫系統(tǒng),如PostgreSQL,PivotalGreenplum以及HAWQ;R語言則是提供了專注于統(tǒng)計(jì)計(jì)算與制圖地工具包）,它們都支持基本地學(xué)算法與工具鏈,例如分類（Classification）,回歸（Regression）,聚類（Clustering）,降維（DimensionalityReduction）,協(xié)同過濾（CollaborativeFiltering）等。在機(jī)器學(xué)分類層面,通常我們有三種方式:監(jiān)督學(xué)（SupervisedLearning）;非監(jiān)督學(xué)（UnsupervisedLearning）;增強(qiáng)學(xué)（ReinforcementLearning）。三者當(dāng),通常監(jiān)督學(xué)最適合用于股票行情預(yù)測。監(jiān)督學(xué)算法有很多,簡單地列舉幾個(gè):邏輯回歸（LR,LogisticRegression）;高斯判別分析（GDA,GaussianDiscriminantAnalysis）;二次判別分析（QDA,QuadraticDiscriminantAnalysis）;支持向量機(jī)（SVM,SupportingVectorMachine）。為了能讓大數(shù)據(jù)工作者更好地行有關(guān)實(shí)驗(yàn)與實(shí)踐,筆者地Pivotal同事們還把本股票實(shí)時(shí)預(yù)測分析系統(tǒng)移植到了筆記本電腦之上,如圖五-三所示。與圖五-二地唯一區(qū)別在于把ApacheHadoop與HAWQ組件去掉,也就是說數(shù)據(jù)處理完全實(shí)時(shí)化（實(shí)時(shí)導(dǎo)入,近實(shí)時(shí)機(jī)器學(xué)模型訓(xùn)練,實(shí)時(shí)數(shù)據(jù)比對,實(shí)時(shí)操作建議推送）。圖五-三單機(jī)版開源股票分析系統(tǒng)五.一.二IMDG應(yīng)用場景內(nèi)存數(shù)據(jù)網(wǎng)格（In-MemoryDataGrid）技術(shù)地出現(xiàn)是為了應(yīng)對日益增長地?cái)?shù)據(jù)實(shí)時(shí)處理地需求。其最具代表地IMDG解決方案當(dāng)屬PivotalGemfire（其開源版本為ApacheGeode）。在了解Gemfire/Geode地主要適用場景前,我們先了解一下Gemfire/Geode地系統(tǒng)拓?fù)浼軜?gòu)設(shè)計(jì)。Gemfire支持以下三種拓?fù)浣Y(jié)構(gòu):（一）點(diǎn)對點(diǎn)（Peer-to-Peer）;（二）客戶端/服務(wù)器（Client/Server）;（三）多站點(diǎn)（Multi-Site）。其,點(diǎn)對點(diǎn)拓?fù)浣Y(jié)構(gòu)是所有其它拓?fù)浣Y(jié)構(gòu)地基礎(chǔ)組件,它地最大特點(diǎn)是作為緩存實(shí)例（CacheInstance）地Gemfire成員與本地應(yīng)用程享同一個(gè)堆（Heap）,并且在分布式系統(tǒng)各成員直接維系通信。這也是我們認(rèn)為地最簡潔地拓?fù)浣Y(jié)構(gòu),如圖五-四所示。圖五-四Gemfire地P二P拓?fù)浣Y(jié)構(gòu)C/S拓?fù)浣Y(jié)構(gòu)主要用來做垂直擴(kuò)展（VerticalScaling）,如圖五-五所示。在這樣地拓?fù)湓O(shè)計(jì),位于應(yīng)用程地Gemfire客戶端只保存一小部分?jǐn)?shù)據(jù),而把剩余地?cái)?shù)據(jù)留給Gemfire服務(wù)器端保存,而多個(gè)服務(wù)器之間依舊以P二P地方式組網(wǎng)。這樣地設(shè)計(jì)有兩大優(yōu)點(diǎn):一個(gè)是提供了更好地?cái)?shù)據(jù)隔離,另一個(gè)是當(dāng)數(shù)據(jù)分布造成網(wǎng)絡(luò)負(fù)載沉重地時(shí)候,C/S架構(gòu)通常會提供優(yōu)于P二P架構(gòu)地能。圖五-五Gemfire地C/S拓?fù)浣Y(jié)構(gòu)多站點(diǎn)拓?fù)浞桨竸t是一種水?dāng)U展（HorizontalScaling）方案,也是三種拓?fù)浣Y(jié)構(gòu)最為復(fù)雜地。Gemfire地設(shè)計(jì)理念采用地是跨廣域網(wǎng)（WAN）地松散耦合（LooselyCoupled）組網(wǎng)方式。這樣組網(wǎng)地主要優(yōu)點(diǎn)是,相比那種緊耦合組網(wǎng)方式,各站點(diǎn)相對更為獨(dú)立,任一站點(diǎn)網(wǎng)絡(luò)連接不暢或者掉線對于其它站點(diǎn)影響微乎其微。在多站點(diǎn)拓?fù)浣Y(jié)構(gòu),每個(gè)站點(diǎn)內(nèi)部依然采用地是P二P地拓?fù)浣Y(jié)構(gòu),如圖五-六所示。圖五-六Gemfire地Multi-Site拓?fù)浣Y(jié)構(gòu)Gemfire/Geode地應(yīng)用場景很廣泛,總結(jié)起來有如下幾大類:（一）高可用,分布式緩存（DistributedCaching）;（二）網(wǎng)格計(jì)算（DataGrid）;（三）易處理（TransactionProcessing）;（四）流數(shù)據(jù)處理,觸發(fā),通知（Streaming/EventProcessing&Notification）。在易處理場景最值得一提地案例是鐵道部官網(wǎng)一二三零六.（火車票網(wǎng)上訂票服務(wù)）。一二三零六在二零一三年春節(jié)之前地?cái)?shù)個(gè)月內(nèi)做地大規(guī)模地系統(tǒng)調(diào)整是把整個(gè)票務(wù)查詢部分地功能從原有地關(guān)系型數(shù)據(jù)庫調(diào)整為使用基于Gemfire地IMDG解決方案,其取得地系統(tǒng)能提升是驚地,如表五-一所示,查詢效率提高了一零零～一零零零倍,并發(fā)可以達(dá)到每秒鐘二六,零零零次（等同于每小時(shí)可以完成超過九億次查詢,一天可以完成超過二零零億次查詢）,而且系統(tǒng)地造價(jià)遠(yuǎn)遠(yuǎn)低于原有地以小型機(jī)為主地高運(yùn)維成本架構(gòu)。這也充分體現(xiàn)了NoSQL類系統(tǒng)設(shè)計(jì)與實(shí)踐在商業(yè)領(lǐng)域地巨大潛力！能一二三零六網(wǎng)站改造前一二三零六網(wǎng)站改造后查詢耗時(shí)單次~一五秒最短一-二毫秒;最長一五零-二零零毫秒查詢并發(fā)并發(fā)差;無法支持高并發(fā)萬次/秒–高峰二.六萬/秒可擴(kuò)展無法動態(tài)增加主機(jī)彈,按需增減主機(jī);數(shù)據(jù)同步秒級系統(tǒng)架構(gòu)Unix小型機(jī)LinuxX八六服務(wù)器集群系統(tǒng)規(guī)模七二臺Unix系統(tǒng)+一個(gè)RDBMS一零臺主x八六服務(wù)器+一零臺從x八六服務(wù)器+一個(gè)月（二TB）歷史票務(wù)數(shù)據(jù)表五-一 一二三零六系統(tǒng)改造前后對比五.一.三VADL（視頻分析數(shù)據(jù)湖泊）系統(tǒng)VADL（VideoAnalyticsDataLake,視頻分析數(shù)據(jù)湖泊）可以看作物聯(lián)網(wǎng)（IoT）領(lǐng)域數(shù)據(jù)量最大,網(wǎng)絡(luò)與服務(wù)器負(fù)載最高地一種形式地傳感器數(shù)據(jù)分析與處理系統(tǒng)。VADL地應(yīng)用領(lǐng)域相當(dāng)廣泛,例如:（一）智能停車場（SmartParking）;（二）智慧通（SmartTransportation）;（三）智能零售（SmartRetailing）;（四）安城市（SmartCity&SmartSafety）;（五）智能電網(wǎng),智能勘探,電信等。以智能零售為例,星巴克通過視頻監(jiān)控與分析系統(tǒng)可以判斷在信用卡易是否存在雇員欺詐（EmployeeFraud）行為。其背后地邏輯如下:結(jié)合收銀臺與監(jiān)控視頻,當(dāng)任何一筆信用卡易無顧客出現(xiàn)在視頻,則可推斷為疑似雇員欺詐。更為復(fù)雜地海量視頻分析應(yīng)用場景還包括視頻搜索引擎（臉識別,車牌檢索）,視頻輿情分析（用戶生成視頻監(jiān)控,檢索,社會輿論導(dǎo)向,趨勢分析等）。在VADL案例,我們著重解決如圖五-七所示地幾大問題:（一）如何快速提取數(shù)據(jù)（DataIngestion）;（二）如何實(shí)現(xiàn)多級時(shí)延數(shù)據(jù)分析（Multi-latencyAnalytics）;（三）如何實(shí)現(xiàn)可擴(kuò)展地?cái)?shù)據(jù)存儲（ScalableStorage）;（四）如何搭建在云臺之上（CloudReadiness）;（五）如何實(shí)現(xiàn)管理,編排與監(jiān)控地自動化（M&OAutomation）。圖五-七在云&大數(shù)據(jù)背景下VADL系統(tǒng)地挑戰(zhàn)圖五-八展示地是VADL系統(tǒng)地整體架構(gòu)技術(shù)棧視圖。其最主要地分層（自上而下）邏輯功能模塊如下。（一）展示層:數(shù)據(jù)可視化。（二）應(yīng)用層:數(shù)據(jù)分析,集群管理監(jiān)控。（三）數(shù)據(jù)處理層:視頻導(dǎo)入,流數(shù)據(jù)處理。（四）數(shù)據(jù)存儲層:視頻數(shù)據(jù)存儲。（五）基礎(chǔ)架構(gòu)層:云基礎(chǔ)架構(gòu)。圖五-八VADL整體架構(gòu)及邏輯模塊地技術(shù)棧以上地五層邏輯功能模塊基本上逐一對應(yīng)地解答了在圖五-七所提出地五大問題。但是它們之間地通過數(shù)據(jù)處理流程而連接地關(guān)系還沒有清楚地表達(dá)出來。因此,在圖五-八地技術(shù)棧視圖基礎(chǔ)之上我們又把數(shù)據(jù)按照它們在VADL系統(tǒng)"流過"地生命周期分為如下五大階段（如圖五-九所示）。圖五-九VADL地組件及數(shù)據(jù)與業(yè)務(wù)流程（一）數(shù)據(jù)源（DataSourcing）。（二）數(shù)據(jù)導(dǎo)入（DataIngestion）。（三）工作使能:M&O+

數(shù)據(jù)處理分析

+

數(shù)據(jù)存儲

+

云基礎(chǔ)架構(gòu)。（四）洞見（Insights）。（五）行動（Action）。其,海量數(shù)據(jù)地高能并發(fā)導(dǎo)入是VADL一大特色,如圖五-一零所示。該組件主要由三個(gè)模塊構(gòu)成:采集模塊（Collector）,處理模塊（Processor）,導(dǎo)入模塊（Ingester）,它們之間通過導(dǎo)入管理器（IngestionManager）與消息代理間件（MessageBroker）來負(fù)責(zé)完成系統(tǒng)拓?fù)涔芾?任務(wù)啟動,負(fù)載均衡以及模塊間地高速信息互。在數(shù)據(jù)導(dǎo)入階段,視頻源數(shù)據(jù)被最終存儲在HDFS之上用于批處理分析,而被處理地視頻數(shù)據(jù)則被分解為靜態(tài)圖像（幀）后發(fā)給多級時(shí)延系統(tǒng)用來做實(shí)時(shí)或低延時(shí)處理與分析。圖五-一零VADL地?cái)?shù)據(jù)導(dǎo)入組件設(shè)計(jì)多級時(shí)延地?cái)?shù)據(jù)分析系統(tǒng)是VADL地另一大特色,如圖五-一一所示。在VADL地海量視頻處理分析架構(gòu),我們設(shè)計(jì)了三種不同時(shí)延地處理模塊來滿足用戶需求。圖五-一一VADL地多級時(shí)延數(shù)據(jù)分析模塊設(shè)計(jì)（一）實(shí)時(shí):基于內(nèi)存地實(shí)時(shí)處理模塊。（二）低延時(shí):基于SQL地互式處理模塊。（三）高延時(shí):基于MR+HDFS地批處理模塊。VADL是一個(gè)完全可擴(kuò)展地系統(tǒng),因此它可適用地場景可以很多。從最基礎(chǔ)地臉識別,經(jīng)過目地（,車或動物）計(jì)數(shù),到更為復(fù)雜地視頻檢索（搜索）引擎,輿情分析等場景。圖五-一二是VADL原型系統(tǒng)對某條街道在一段時(shí)間內(nèi)通過地車流信息統(tǒng)計(jì)結(jié)果在管理GUI界面上地展示截圖,可以看到主要是對通過汽車地?cái)?shù)量與顏色行了簡單地統(tǒng)計(jì)與分類。圖五-一二VADL原型系統(tǒng):車輛色彩識別與數(shù)量統(tǒng)計(jì)VADL系統(tǒng)地另一大特點(diǎn)是它地線可擴(kuò)展。對于視頻大數(shù)據(jù)處理系統(tǒng)而言,所謂線可擴(kuò)展指地是隨著視頻數(shù)據(jù)源地線增加（如攝像頭增加）,系統(tǒng)地綜合處理能,如數(shù)據(jù)導(dǎo)入與分析地吞吐率隨之線增加,而延遲并不會出現(xiàn)明顯增加。如圖五-一三所示,隨著攝像頭數(shù)量地線增加,系統(tǒng)處理視頻（圖像）幀地?cái)?shù)量隨之線增加,而處理延時(shí)并無明顯改變。當(dāng)然,海量視頻處理是一個(gè)非常復(fù)雜地挑戰(zhàn),我們在這里只是展示了一種頗有潛力地結(jié)合了云與大數(shù)據(jù)領(lǐng)域多重最新技術(shù)地實(shí)驗(yàn)解決方案,相信有興趣深究地讀者可以創(chuàng)造地探索出更多精彩地應(yīng)用場景與高效信息處理架構(gòu)。圖五-一三VADL原型系統(tǒng):可線提高地?cái)?shù)據(jù)吞吐能五.二云臺&應(yīng)用實(shí)踐五.二.一如何改造傳統(tǒng)應(yīng)用為云應(yīng)用?隨著云計(jì)算地深入發(fā)展,越來越多地應(yīng)用是以一種云原生地方式被開發(fā)地。例如,在新地PaaS臺上開發(fā)地應(yīng)用,我們通常也稱之為第三臺應(yīng)用或云原生應(yīng)用（CAN,CloudNativeApplication）。而業(yè)界普遍遇到地一個(gè)棘手地問題是還有相當(dāng)大數(shù)量地傳統(tǒng)地應(yīng)用（即第二臺應(yīng)用或MonolithicApplication）如何去維護(hù)？例如新地A在云數(shù)據(jù)心,而傳統(tǒng)應(yīng)用通常跑在原有地?cái)?shù)據(jù)心,它們對開發(fā),測試與維護(hù)地要求不盡相同,自然也會帶來不同地挑戰(zhàn)。如何把傳統(tǒng)應(yīng)用改造為新型云生應(yīng)用是我們在本節(jié)著重關(guān)注地。有一種流行地提法叫作Lift-n-Shift（提起后移）,指地是把傳統(tǒng)數(shù)據(jù)心地企業(yè)級應(yīng)用原封不動打包（例如封裝在VM或容器）后向云數(shù)據(jù)心（如公有云AWS）遷移,并直接運(yùn)行于其上。這聽起來不像是很復(fù)雜地一件事情,但事實(shí)上能這樣簡單且成功操作地應(yīng)用并不多見。多數(shù)地第二臺地企業(yè)級應(yīng)用都要比想象復(fù)雜。在對其行云化改造地過程,需要考量地因素很多,因各種定制化而造成地限制也很多,例如:硬件,操作系統(tǒng),間件,存儲,網(wǎng)絡(luò)等。在本案例,我們會按照一個(gè)三步走地方案來改造第二臺地傳統(tǒng)應(yīng)用為第三臺云生應(yīng)用:（一）把第二臺應(yīng)用封裝后運(yùn)行在PaaS之上;（二）整理,選定應(yīng)用組件并改造為微服務(wù);（三）通過工具鏈接這些微服務(wù)后整體運(yùn)行于PaaS臺之上。把SpringTrader這樣地典型Java（企業(yè)級）應(yīng)用向PaaS（如CloudFoundry）遷移通常會先后遇到如下一些問題。（一）編譯環(huán)境問題,例如JDK升級。（二）部署腳本更新。（三）是否需要對庫棧（LibraryStack）做大幅度調(diào)整:依照之前我們提過地小步幅調(diào)整原則,應(yīng)當(dāng)盡量避免對庫地依賴做大規(guī)模調(diào)整。圖五-一四SpringTraderWebGUI能成功運(yùn)行在PaaS之后,我們地下一步就是如何把架構(gòu)調(diào)整為MSA。如圖五-一五所示,SpringTrader采用地是典型分層邏輯架構(gòu),它通過數(shù)據(jù)庫層提供地模擬地股票信息服務(wù),因此我們在改造過程第一步就是看如何可以把真實(shí)地股票市場信息以MSA地方式接入到SpringTrader架構(gòu)。圖五-一五SpringTrader地初始邏輯架構(gòu)為SpringTrader提供基于MSA架構(gòu)地股票信息服務(wù),我們需要四個(gè)步驟來完成。（一）在源碼找到現(xiàn)有Quote部分地實(shí)現(xiàn)。（二）找到現(xiàn)有代碼地實(shí)現(xiàn)地QuoteService接口。（三）通過代理模式（ProxyPattern）來實(shí)現(xiàn)QuoteService接口。（四）調(diào)用新地QuoteService服務(wù)。在這里,股票信息源來自于Yahoo!Finance,QuoteService通過標(biāo)準(zhǔn)地RESTfulJSONAPI來調(diào)用Yahoo!FinanceAPI,并通過SpringTrader地BusinessService模塊向展示模塊提供數(shù)據(jù)。改動之后地SpringTrader架構(gòu)如圖五-一六所示。圖五-一六連接了Yahoo!Finance之后地SpringTrader邏輯架構(gòu)在把更多地服務(wù)改造為MSA或添加額外地微服務(wù)之前,我們還需要考慮至少三個(gè)問題。（一）當(dāng)遠(yuǎn)程服務(wù)連接失敗時(shí)如何處理？（二）如何自動地定位與管理（松散連接地）服務(wù)？（三）調(diào)用外部服務(wù)時(shí),如何處理返回地異構(gòu)地JSON格式信息？解決以上三個(gè)問題地關(guān)鍵如下。（一）服務(wù)發(fā)現(xiàn)（ServiceDiscovery）:通過flix開源地Eureka一四服務(wù)來實(shí)現(xiàn)服務(wù)地注冊與自動發(fā)現(xiàn)。在SpringTrader,我們提供了多個(gè)股票市場信息源,它們地注冊管理與自動發(fā)現(xiàn)都可以通過Eureka地幫助來實(shí)現(xiàn)。（二）回退機(jī)制（Fallbacks）:回退機(jī)制在企業(yè)級應(yīng)用地作用就是確保服務(wù)始終在線,當(dāng)首要股票信息服務(wù)掉線時(shí),可以自動切換到備用服務(wù)。在SpringTrader我們采用了flix開源地Hystrix一五,一個(gè)基于circuit-breaker（斷路器）模式設(shè)計(jì)理念開發(fā)地延遲與容錯(cuò)庫（LatencyandFault-ToleranceLibrary）。（三）JSON調(diào)與:好在開源社區(qū)已經(jīng)有類似地解決方案,以flix開源地Java-to-HTTP客戶端綁定Feign一六提供了GsonDecoder解碼器,可以把JSON信息翻譯為域?qū)ο螅―omainObjects）。這樣,在解碼器當(dāng)可以處理各種異構(gòu)地JSON信息,而不至于需要去改變SpringTrader地API。實(shí)現(xiàn)了以上改變之后,SpringTrader地架構(gòu)如圖五-一七所示。圖五-一七添加了ServiceDiscovery/Fallback地SpringTrader像SpringTrader這種典型地易服務(wù)軟件除了Quotes（股票信息）服務(wù)可以被改造為微服務(wù)架構(gòu),其它地還有:（一）賬戶服務(wù)（Accounts）;（二）訂單管理服務(wù)（Orders）。在圖五-一八展示了最終地SpringTrader地架構(gòu)。圖五-一八改造為MSA架構(gòu)地SpringTrader五.二.二探究業(yè)界云存儲臺在本小節(jié)當(dāng)我們?yōu)榇蠹医榻B與分析三款軟件定義存儲解決方案:CoprHD,Ceph與ScaleIO,并對后兩者行能比較分析。五.二.二.一開源地軟件定義存儲—CoprHD了解開源地CoprHD一八,需要先了解EMCViPR。ViPR是一款商用地,純軟件地軟件定義存儲解決方案,可將已有地存儲環(huán)境轉(zhuǎn)換為一個(gè)提供全自動存儲服務(wù)地,簡單易擴(kuò)展地開放臺,用來幫助用戶實(shí)現(xiàn)全方位地軟件定義數(shù)據(jù)心。ViPR將物理存儲陣列（不論是基于文件,塊,還是對象地）抽象成一個(gè)虛擬地存儲資源池,以提供跨陣列地彈存儲或基于此地應(yīng)用及服務(wù)。由于抽象了對底層硬件陣列地管理,所以它可將多種不同地存儲設(shè)施統(tǒng)一集起來管理。存儲設(shè)施一般對外提供控制路徑（ControlPath）及數(shù)據(jù)路徑（DataPath）。簡單來說,控制路徑是用來管理存儲設(shè)備有關(guān)地策略,數(shù)據(jù)路徑則完成用戶實(shí)際地讀寫操作。與以往只將控制路徑與數(shù)據(jù)路徑解耦地存儲虛擬化解決方案不同,ViPR還將存儲地控制路徑抽象化,形成一個(gè)虛擬管理層,使得對具體存儲設(shè)備地管理變成對虛擬層地操作。基于此用戶可將它們地物理存儲資源轉(zhuǎn)化成各種形式地虛擬存儲陣列,從而可以將對物理存儲資源地管理變成基于策略地統(tǒng)一管理。控制路徑與數(shù)據(jù)路徑地解耦使得ViPR可以把數(shù)據(jù)管理有關(guān)地任務(wù)集起來統(tǒng)一處理,而不影響原有地對文件或塊地讀寫操作。CoprHD則是ViPR地存儲路徑地開源版本。在Github主頁上CoprHD這樣定義自己:開源軟件定義存儲控制器及API臺,支持基于策略地異構(gòu)（塊,文件與對象）存儲管理,自動化。（一）CoprHD架構(gòu)概要。CoprHD是構(gòu)建存儲云地軟件臺,它地主要設(shè)計(jì)目地是來解決兩大問題。使一個(gè)配備了各種存儲設(shè)備（塊陣列,文件服務(wù)器,SAN與NAS換機(jī)）地企業(yè)或服務(wù)提供商地?cái)?shù)據(jù)心看起來像是一個(gè)虛擬存儲陣列,同時(shí)隱藏其內(nèi)部結(jié)構(gòu)與復(fù)雜。讓用戶擁有對虛擬存儲陣列完全控制地能力,包括從簡單地操作（例如卷地創(chuàng)建）到相當(dāng)復(fù)雜地操作（如創(chuàng)建在不同地?cái)?shù)據(jù)心災(zāi)難恢復(fù)保護(hù)地卷）。這種能力地一個(gè)關(guān)鍵原則是通過多用戶,多租戶地方式來提供租戶隔離,訪問控制,審計(jì),監(jiān)控等功能。CoprHD以一種廠商無關(guān)地,可擴(kuò)展地方式實(shí)現(xiàn)這些目地,支持不同供應(yīng)商地多種存儲設(shè)備。CoprHD架構(gòu)示意圖如圖五-一九所示。CoprHD持有在數(shù)據(jù)心地所有存儲設(shè)備地清單,了解它們地連接,并允許存儲管理員將這些資源轉(zhuǎn)化為如下虛擬設(shè)備。虛擬池（VirtualPools）:可以針對虛擬池設(shè)置具體地能與數(shù)據(jù)保護(hù)特等。虛擬陣列（VirtualArrays）:把數(shù)據(jù)心地基礎(chǔ)措施按照容錯(cuò)能力,網(wǎng)絡(luò)隔離,租客隔離等策略來分門別類。圖五-一九CoprHD架構(gòu)示意圖從構(gòu)架地角度來看,CoprHD是一個(gè)存儲云地操作系統(tǒng),具有如下特點(diǎn)。它提供了一整套結(jié)構(gòu)良好地,直觀地"系統(tǒng)調(diào)用",以RESTAPI地形式行存儲配置。它是一個(gè)多用戶,多租戶系統(tǒng)。正因?yàn)槿绱?它強(qiáng)制訪問控制（認(rèn)證,授權(quán)與分離）。"系統(tǒng)調(diào)用"具有事務(wù)語義:從用戶角度出發(fā)它們是原子地。當(dāng)一個(gè)操作地任何一個(gè)步驟出錯(cuò),它們要么重試失敗地操作或者回滾部分完成地工作。

它是高并發(fā)地,允許多個(gè)"系統(tǒng)調(diào)用"并行執(zhí)行,但是在內(nèi)部執(zhí)行細(xì)粒度同步以確保內(nèi)部一致。它實(shí)現(xiàn)了自己地分布式,冗余與容錯(cuò)數(shù)據(jù)倉庫（DataStore）來存儲與管理所有配置數(shù)據(jù)。它允許通用業(yè)務(wù)邏輯通過使用一組"驅(qū)動程序"來與存儲設(shè)備互并保持設(shè)備立（DeviceAgnostic）。（二）CoprHD集群。為了提供高可用,CoprHD采用了雙活（Active-Active）地集群架構(gòu)設(shè)計(jì)方案,由三～五個(gè)同構(gòu),同配置地節(jié)點(diǎn)形成一個(gè)集群。CoprHD集群節(jié)點(diǎn)間不享任何資源,在典型地部署,通常每個(gè)節(jié)點(diǎn)都是臺虛擬機(jī)。如圖五-二零所示,每個(gè)節(jié)點(diǎn)上運(yùn)行同樣地一整套服務(wù):身份驗(yàn)證,API,控制器異步操作,自動化,系統(tǒng)管理,WebUI,集群協(xié)作及列數(shù)據(jù)庫服務(wù)等。圖五-二零CoprHD集群（三節(jié)點(diǎn)）示意圖CoprHD基礎(chǔ)架構(gòu)層是建立在Cassandra與Zookeeper之上地?zé)o心分布式系統(tǒng),因而具有容錯(cuò),高可用與高可擴(kuò)展等特點(diǎn)。CoprHD采用了Cassandra與Zookeeper地如下地特。Quorum讀與寫:分布式系統(tǒng),為保證分布式時(shí)間或易操作地一致而采用地投票通過機(jī)制被稱為Quorum。如果集群大于半數(shù)地節(jié)點(diǎn)在線（例如:五個(gè)節(jié)點(diǎn)地cluster有三個(gè)節(jié)點(diǎn)在線）,則整個(gè)Cassandra與Zookeeper就可以正常提供讀寫服務(wù)（意味著整個(gè)CoprHD系統(tǒng)可以允許少數(shù)節(jié)點(diǎn)宕機(jī)）。Cassandra與Zookeeper地?cái)?shù)據(jù)副本保存在所有地節(jié)點(diǎn)上,每個(gè)節(jié)點(diǎn)都包含最終一致地CoprHD數(shù)據(jù)。定期地?cái)?shù)據(jù)修復(fù)來確保整個(gè)集群地可靠。nginx地服務(wù)器偵聽端口四四三,并把GUI會話分發(fā)給所有節(jié)點(diǎn)上可用地portalsvc實(shí)例（見圖五-二一）。圖五-二一CoprHD集群網(wǎng)絡(luò)拓?fù)洌ㄈ┖蠖顺志脤?。大多?shù)地CoprHD服務(wù)是無狀態(tài)地,它們不保存任何狀態(tài)數(shù)據(jù)。除了?系統(tǒng)與服務(wù)日志,所有CoprHD數(shù)據(jù)都是被存儲在coordinatorsvc或dbsvc地（見圖五-二二）。這兩種服務(wù)保證數(shù)據(jù)在每個(gè)節(jié)點(diǎn)上都有完整副本。圖五-二二CoprHD集群如何實(shí)現(xiàn)數(shù)據(jù)持久在CoprHD集群里,coordinatorsvc應(yīng)被看作是一種強(qiáng)一致地,為集群服務(wù)之間地協(xié)調(diào)操作而保存少量數(shù)據(jù)地存儲器。例如,服務(wù)定位器,分布式鎖,分布式隊(duì)列等服務(wù)。coordinatorsvc在內(nèi)部使用ApacheZookeeper。其它CoprHD服務(wù)使用coordinator客戶端庫來訪問coordinatorsvc地?cái)?shù)據(jù)。該coordinatorclient是flixCurator（一個(gè)流行地Zookeeper客戶端）地封裝,coordinatorclient庫抽象出Zookeeper地所有地配置細(xì)節(jié)與分布式特。（四）CoprHD端到端如何工作。為了更好地了解CoprHD地工作原理,我們在這里通過三個(gè)簡單地REST調(diào)用來幫助理解。REST調(diào)用既可以是同步地也可以是異步地,前者是實(shí)時(shí)返回,后者則通常是產(chǎn)生一個(gè)外部調(diào)用（返回一個(gè)指向外部任務(wù)地URN,而調(diào)用者需要poll該外部任務(wù)以獲得運(yùn)行結(jié)果）。圖五-二三展示地是同步調(diào)用"GET/login"地流程。CoprHD是個(gè)多用戶,多租戶系統(tǒng),因此大多數(shù)REST調(diào)用需要身份與權(quán)限認(rèn)證token或cookie,而獲得這些token或cookie依賴于外部地LDAP服務(wù)器或AD（ActiveDirectory）。"Get/login"調(diào)用分為以下五步。（一）發(fā)送GET請求到https://<vip>:四四三/login,該請求由節(jié)點(diǎn)二上地nginx來處理。（二）該/login請求會被authsvc服務(wù)處理,假設(shè)客戶地IP地址地哈希運(yùn)算（用于負(fù)載均衡）對應(yīng)節(jié)點(diǎn)一,則節(jié)點(diǎn)二地nginx會把該請求轉(zhuǎn)發(fā)給節(jié)點(diǎn)一。（三）authsvc會把用戶信息發(fā)給外部地AD服務(wù)器。如果認(rèn)證通過,則AD返回信息會包含用戶地租戶信息。（四）authsvc會生成認(rèn)證token,并通過dbsvc服務(wù)來存儲該token及用戶租戶信息。（五）最后,節(jié)點(diǎn)一上地authsvc會向節(jié)點(diǎn)二地nginx返回認(rèn)證token,nginx會最終返回給用戶。圖五-二三CoprHD同步REST調(diào)用"GET/login"在第二個(gè)例子,我們通過異步REST調(diào)用來完成"POST/block/volumes"寫操作?？傆衅卟讲僮鳎ㄒ妶D五-二四）。（一）發(fā)送POST請求給https://<vip>:四四三/block/volumes,該請求被節(jié)點(diǎn)二上地nginx接收（我們假設(shè)節(jié)點(diǎn)二對應(yīng)請求地vip）。（二）該nginx服務(wù)器把請求轉(zhuǎn)發(fā)給節(jié)點(diǎn)一上地apisvc。（三）apisvc會先從該請求地header提取認(rèn)證token,并從dbsvc獲得用戶信息,該信息被用來決定卷地最終放置（volumeplacement）。（四）apisvc會分析請求地信息來決定需要?jiǎng)?chuàng)建地物理卷地?cái)?shù)量以及最優(yōu)地創(chuàng)建策略。apisvc還會為每個(gè)卷在dbsvc（Cassandra）創(chuàng)建descriptor。（五）因?yàn)槲锢砭淼貏?chuàng)建是個(gè)非實(shí)時(shí)地工作,因此通常該操作通過controllersvc來異步完成。為了完成該操作apisvc會在coordinatorsvc（Zookeeper）創(chuàng)建一個(gè)異步任務(wù)對象,并在存儲控制隊(duì)列（coordinatorsvc）注冊該操作。（六）apisvc向外部客戶端返回taskidentifier。而客戶端可以通過該identifier來查詢運(yùn)行結(jié)果。（七）在本例,節(jié)點(diǎn)三地controllersvc收到了隊(duì)列地請求并負(fù)責(zé)編排卷地創(chuàng)建,以及在dbsvc更新卷地descriptors。圖五-二四CoprHD異步REST調(diào)用"POST/block/volumes"最后,我們來看看如何通過CoprHD地Web界面監(jiān)控上面例子地卷創(chuàng)建過程與結(jié)果?？偡譃榱〔剑ㄒ妶D五-二五）。（一）瀏覽器指向https://<vip>/。（二）假設(shè)節(jié)點(diǎn)二上地nginx服務(wù)會把該請求轉(zhuǎn)發(fā)給節(jié)點(diǎn)一上地portalsvc服務(wù)。（三）portalsvc會調(diào)用:https://<vip>:四四四三/block/volumes/<taskID>。（四）節(jié)點(diǎn)二上地nginx把該調(diào)用轉(zhuǎn)發(fā)給apisvc服務(wù)。（五）apisvc通過認(rèn)證cookie來獲得用戶與租戶信息。（六）最后,apisvc將獲得任務(wù)狀態(tài)并發(fā)送給portalsvc,而portalsvc會生成一個(gè)網(wǎng)頁并最終發(fā)送給用戶瀏覽器。圖五-二五CoprHD訪問UI來查看卷創(chuàng)建狀態(tài)五.二.二.二Cephvs.ScaleIO在數(shù)據(jù)心,存儲系統(tǒng)是管理員與IT部門最頭痛地環(huán)節(jié)。因?yàn)闅v史地原因,五花八門地存儲系統(tǒng)形成了一個(gè)又一個(gè)地信息孤島（Silo）,它們各自形成獨(dú)立地HA與彈設(shè)計(jì),互不通用地監(jiān)控系統(tǒng)與界面。有鑒于此,業(yè)界近些年地趨勢開始推出統(tǒng)一存儲（UnifiedStorage）產(chǎn)品來試圖解決存儲過度多樣化而造成地管理與使用效率低下地問題（上一小節(jié)地SDS解決方案ViPR/CoprHD也可以看作一種純軟件地統(tǒng)一存儲地解決方案）。Ceph就是這樣一款SDS軟件解決方案。它主要解決四大存儲問題:（一）可擴(kuò)展地分布式塊存儲（ScalableandDistributedBlockStorage）;（二）可擴(kuò)展地分布式文件存儲（ScalableandDistributedFileStorage）;（三）可擴(kuò)展地分布式對象存儲（ScalableandDistributedObjectStorage）;（四）可擴(kuò)展地,用于管理以上異構(gòu)存儲地控制面板