吳朱華是《云計算核心技術(shù)剖析》一書的作者，他認(rèn)為，目前云計算的技術(shù)已經(jīng)度過了的最初的“朦朧期”，業(yè)界已經(jīng)找出一些核心的突破點，鋪以重兵攻堅。但發(fā)展中也存有一些爭議點，值得討論。

核心技術(shù)難點

從云計算的技術(shù)層面來講，整體的IaaS，SaaS和PaaS的架構(gòu)已經(jīng)足夠清晰，但是還有幾個點仍然存在一定的技術(shù)難度。

1. 云計算的安全性

安全性永遠(yuǎn)是云計算最熱的話題之一，文章關(guān)注了兩點：

首先是數(shù)據(jù)中心網(wǎng)絡(luò)的安全性(可用性)，最典型的例子，Amazon Web Service服務(wù)最近幾次大型故障都和網(wǎng)絡(luò)有關(guān)，特別是其基于局域網(wǎng)技術(shù)的云硬盤服務(wù)EBS。多位業(yè)界網(wǎng)絡(luò)專家認(rèn)為其路由器的Oversubscribe(超賣)和網(wǎng)絡(luò)配置無法應(yīng)對(比如網(wǎng)絡(luò)控制信息方面的流量會有波動)是整個問題的關(guān)鍵。

其次是虛擬機(jī)本身的安全性，其實在虛擬機(jī)的發(fā)展之初，各個技術(shù)主要關(guān)注點絕對是性能，比如Xen雖然上手復(fù)雜，但是由于其本身的半虛擬化的架構(gòu)，其在性能方面稍強(qiáng)于VMware，并拿這點作為長期的談資。但是隨著程序的優(yōu)化，特別是硬件虛擬化技術(shù)的引入，在性能方面，各方面都已經(jīng)接近均勢，并且優(yōu)化空間也不多，所以虛擬機(jī)的安全性很有可能將會作為今后的主要考量之一。

據(jù)一些行業(yè)IaaS云供應(yīng)商的反饋，Xen本身有嚴(yán)重的漏洞，通過這個漏洞，虛擬機(jī)里面的程序可以直接攻擊到物理機(jī)本身，并且KVM也有類似的問題，比如KVM直接有兩個IO端口可以和QEMU通信，所以虛擬機(jī)的安全性還有待完善。

2. 數(shù)據(jù)中心大二層和SDN

很多做私有IaaS云廠商面對最大的技術(shù)挑戰(zhàn)，基本上都是“網(wǎng)絡(luò)難配”，主要有三個方面的原因：

現(xiàn)在云服務(wù)多個節(jié)點之間需要連接大量內(nèi)部的通信，最明顯的例子就是Hadoop，當(dāng)集群大小超過千臺時，網(wǎng)絡(luò)會成為比IO更大的一個瓶頸;

虛擬機(jī)各節(jié)點只能在同一個二級網(wǎng)段內(nèi)才能進(jìn)行非常重要的動態(tài)遷移;

每個虛擬主機(jī)都會運(yùn)行十個以上的虛擬機(jī)，這會導(dǎo)致過一個網(wǎng)段內(nèi)實際所需要承受的機(jī)器數(shù)量和具體流量都倍增。

這些因素都導(dǎo)致數(shù)據(jù)中心網(wǎng)絡(luò)從之前對外為主的南北向，慢慢轉(zhuǎn)為以內(nèi)部為主的東西向，同時數(shù)據(jù)中心不得不出現(xiàn)大二層的現(xiàn)象。為了解決這些問題，網(wǎng)絡(luò)界推出了各種解決方案，包括將路由能力帶到二層網(wǎng)絡(luò)的TRILL和FabricPath，用于識別虛擬機(jī)流量的VN-Tag和VEPA，用于二層互聯(lián)的VPLS和OTV。最后就是號稱改變整個網(wǎng)絡(luò)世界的SDN(軟件定義網(wǎng)絡(luò))。這些技術(shù)的確能讓現(xiàn)有的云服務(wù)，特別是IaaS層在技術(shù)層面有一個質(zhì)的的飛躍，但是整體成熟度和成本要下降到一個讓大家都滿意程度，顯然并非易事。

3. OpenStack完整的生態(tài)環(huán)境

2012年云計算的業(yè)界，如果說只有一個“明星”的話，那絕對是OpenStack莫屬，和之前開源的CloudStack、Eucalyptus不同的是，OpenStack強(qiáng)調(diào)的核心是生態(tài)圈，并且它的生態(tài)圈還有兩個特色，其一是模塊眾多，它不僅有傳統(tǒng)用于虛擬機(jī)的模塊，而且它還提供云存儲模塊Swift，以及用于虛擬機(jī)鏡像管理的Glance，最具創(chuàng)新型的網(wǎng)絡(luò)模塊Quantum;其次，整個圈子里面初創(chuàng)公司極為活躍，不僅國外有已經(jīng)被VMware以巨資收購的Nicira，國內(nèi)的九州云還有UnitedStack都做的有聲有色。雖然表面而言，OpenStack生態(tài)圈“歌舞升平”，但是還是存在很多隱患，最重要的就是缺乏一個領(lǐng)軍的企業(yè)來引導(dǎo)，光靠一個“松耦合”的社區(qū)的確還有點難度。

蔣清野在OpenStack、OpenNebula、Eucalyptus、CloudStack社區(qū)活躍度比較中表示，OpenStack項目提交代碼的人數(shù)遠(yuǎn)遠(yuǎn)超過其他三個項目，并且一直保持迅猛增長的勢頭。CloudStack項目提交代碼的人數(shù)也有所增長，但是其增長速度較為緩慢。Eucalyptus項目和OpenNebula項目提交代碼的人數(shù)相對較少，并且在過去12個月當(dāng)中基本上沒有增長，這表明OpenStack的發(fā)展勢頭還是很猛的。

4. Hadoop的生態(tài)圈的完善

雖然業(yè)界各種五花八門的Hadoop用例讓人有點疑惑，但是Hadoop社區(qū)在Cloudera和Hortonworks這兩大巨頭的推動下，再加上類似淘寶云梯這樣案例不斷成熟，使Hadoop快要成為業(yè)界標(biāo)準(zhǔn)的大數(shù)據(jù)服務(wù)平臺。同時由于MapReduce的編程框架，使得傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫的周邊工具都無法繼續(xù)使用，所以一些新的周邊工具不斷推出，包括用于數(shù)據(jù)流支持的Pig，用于SQL解析的Hive，用于日志收集的Flume，用于ETL的Scribe，用于實時分析的Impala等。

不過對于Hadoop這個生態(tài)圈，吳朱華也表示有些疑慮，雖然和OpenStack生態(tài)圈相比，表面上有兩大巨頭的支持，但這兩大巨頭”各懷鬼胎“，而且其整體所需要投入的工程量和OpenStack相比也是不相上下，只有兩大巨頭拋棄成見，齊心協(xié)力才能將Hadoop推向一個新的高度。

5. NewSQL的興起

前幾年談及NoSQL，雖然其伸縮性不錯，但因為其不支持完整SQL語句，使得其學(xué)習(xí)成本變得很高，所以吳朱華認(rèn)為既能伸縮、又能支持SQL的NewSQL興起再所必然。

提起NewSQL，首先可能會想到MemSQL或者SAP HANA這類新型的基于內(nèi)存的數(shù)據(jù)庫，但是其實在NewSQL方面，最強(qiáng)大的始作俑者絕對是研發(fā)出MapReduce的Google，雖然其最初整套用于半結(jié)構(gòu)化數(shù)據(jù)解析的索引構(gòu)建模塊是基于MapReduce的，并且研發(fā)了著名NoSQL技術(shù)BigTable，但是隨著它業(yè)務(wù)的需求和對性能等方面要求的不斷提升，在技術(shù)方面，它做了優(yōu)化和轉(zhuǎn)型，基于現(xiàn)有公開的資料，主要兩部分，其一在索引構(gòu)建和OLTP方面，Google以BigTable為基礎(chǔ)發(fā)展出可以對大數(shù)據(jù)集進(jìn)行增量更新的Percolator系統(tǒng)以用于索引的構(gòu)建和服務(wù)，同時也在BigTable基礎(chǔ)上，推出用于分布式海量OLTP的Megastore和F1 Spanner，并且他們分別被用于Google App Engine的Data Store數(shù)據(jù)庫服務(wù)和Google的現(xiàn)金牛廣告服務(wù)，同時在OLAP方面，它推出有點類似MPP列式數(shù)據(jù)庫的Dremel，通過Dremel這個系統(tǒng)能夠構(gòu)建有千臺規(guī)模的分析集群，并能快速地對PB級別的數(shù)據(jù)進(jìn)行處理。

無論是F1 Spanner還是Dremel，它們在伸縮性方面都非常不錯，并且在語法上面支持一定的SQL語句，吳朱華認(rèn)為它們絕對是NewSQL的典范之作。不過現(xiàn)在NewSQL界，真正有實力的公司和產(chǎn)品并沒有出現(xiàn)。

懸念

雖然上面提到了很多關(guān)注點，但是在吳朱華看來，還是存在很多爭議點，還需要進(jìn)一步討論才能分出優(yōu)劣或者各自適合的場景，從而引發(fā)質(zhì)的飛躍。

1. OpenStack 還是 CloudStack?

其實，OpenStack和CloudStack雖然其提供功能大體類似，但是它們在核心理念上是大相徑庭。CloudStack本質(zhì)是產(chǎn)品的思路，也就是通過這個產(chǎn)品能夠非?？焖俚貥?gòu)建一個提供IaaS服務(wù)的私有云，并且通過其主要用戶Zynga的使用來進(jìn)行逐步地優(yōu)化;而OpenStack則本質(zhì)是一個生態(tài)圈，并且功能強(qiáng)大的模塊有很多，但可惜實際的案例不多，特別是大規(guī)模的部署。那么到底OpenStack模式還是CloudStack模式會成為未來IaaS云計算的主流，其實很難判斷，但最近一年，如果使用OpenStack來構(gòu)建一個大型IaaS云，至少在整體項目的技術(shù)支持上，還缺乏一個能全面理解OpenStack的團(tuán)隊。

2. 結(jié)構(gòu)化數(shù)據(jù)，Hadoop適合嗎?

首先，雖然現(xiàn)在Hadoop使用面很廣，包括類似OLAP的結(jié)構(gòu)化數(shù)據(jù)分析，但是其實Hadoop這樣MapReduce的框架，最初的需求主要是用于類似網(wǎng)頁這樣的半結(jié)構(gòu)化數(shù)據(jù)的處理和分析，而且MapReduce這樣暴力的方式也特別適合類似地理數(shù)據(jù)和視頻這樣非結(jié)構(gòu)化數(shù)據(jù)。同時雖然現(xiàn)在有類似Hive這樣的解決方案，但是Hadoop在處理結(jié)構(gòu)化數(shù)據(jù)時，無論是處理速度，還是處理成本，都和基于列式存儲的NewSQL數(shù)據(jù)庫無法接近的。

另外，雖然Cloudera推出用于準(zhǔn)實時分析的Impala，但是由于其重寫了極為耗時耗力的SQL解析引擎，所以如果等它全面支持SQL語句那天，還為時尚遠(yuǎn)。綜上所述，誠然Hadoop能做對結(jié)構(gòu)化數(shù)據(jù)的分析，但是否合適，這就是一個仁者見仁，智者見智的問題。

3. GAE，還是Cloud Foundry?

雖然PaaS這個名詞在2012年比較沉寂，但是Cloud Foundry和GAE(Google App Engine)都有一定的進(jìn)步，Cloud Foundry有了更多用戶，GAE又發(fā)布了新的版本。爭論的核心是Cloud Foundry和GAE在方向性上面的差別比OpenStack和CloudStack更大。

Cloud Foundry核心是快速部署，快速開發(fā)，支持各種編程模式也非常靈活。

GAE的優(yōu)勢是通過分布式的架構(gòu)能快速伸縮，并且能夠最大限度地進(jìn)行超買，從而在一定用戶規(guī)模的基礎(chǔ)上實現(xiàn)較大的盈利，但是初期構(gòu)建成本比Cloud Foundry高的多。

所以Cloud Foundry這個方案比較適合私有云，而GAE更適合公有云，具體今后的PaaS屆誰會成為潮流，這個還很難說。

4. SDN有需求嗎?

就像前面所說的那樣，SDN是一種新興的控制與轉(zhuǎn)發(fā)分離并直接可編程的網(wǎng)絡(luò)架構(gòu)，并且號稱可以改變整個網(wǎng)絡(luò)世界。對于這種大的顛覆，首先，在技術(shù)層面是有發(fā)展的前途的，這估計也是VMware斥巨資收購Nicira的原因之一。但是在實際應(yīng)用方面，是否能找到“Killer App”也是核心的關(guān)鍵，雖然有資深專家表示網(wǎng)絡(luò)虛擬化，安全等方面會存在這樣的需求，但還是需要一定的時間來進(jìn)行檢驗。

5. 云計算是否需要API規(guī)范?

在云計算API規(guī)范方面，吳朱華也是國內(nèi)最早涉及的人之一，并且他非常推崇用于虛擬鏡像分發(fā)的OVF規(guī)范。不過對于這個爭議點，吳朱華談到了兩方面：其一，業(yè)界是否需要公共的API規(guī)范?其二，如果需要這個規(guī)范，業(yè)界會更多地采用來自專業(yè)的，經(jīng)過多方流程思考的DMTF(分布式管理工作組)的規(guī)范，還是更多地借鑒一些成功產(chǎn)品現(xiàn)成的API，比如現(xiàn)在很多云主機(jī)服務(wù)所提供的API基本和Amazon EC2所提供的基本一致。吳朱華認(rèn)為，現(xiàn)在還處于云計算初中期，硬推行一種規(guī)范，成本就有點高，并且有可能會阻礙創(chuàng)新，然而具體使用DMTF還是其他的，應(yīng)該都可以。

云計算和大數(shù)據(jù)本身就是下一代的技術(shù)，能在很多方面可以解決現(xiàn)在用戶和企業(yè)所遇到的痛點。但是如果業(yè)界沒有人專注核心的技術(shù)點，并且解決某些有爭議的問題，那么整體技術(shù)將會陷入不斷的“Reinvent the wheel”階段，就會駐足不前。