国产精品一区二区av交换,中文字幕人成无码免费视频,永久免费av无码网站性色av,欧美一道本一区二区三区,樱桃熟了a级毛片

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

核心技術突破點

從云計算的技術層面來講，整體的IaaS，SaaS和PaaS的架構已經足夠清晰，但是還有幾個點仍然存在一定的技術難度，就像Tesla所用到核心技術，非5-10年的功夫是無法攻克的，所以他認為，這需要集結業(yè)界的力量一起來努力。

云計算的安全性

談到云計算，安全性永遠是最熱的話題之一。由于這個點牽涉甚廣，所以文章只關注了兩點：

首先是數(shù)據(jù)中心網絡的安全性，最典型的例子，莫過于云計算最有知名度的Amazon Web Service服務，最近幾年其幾次大型故障都和網絡有關，特別是其基于局域網技術的云硬盤服務EBS。多位業(yè)界網絡專家認為其路由器的Oversubscribe(超賣)和網絡配置無法應對(比如網絡控制信息方面的流量會有波動)是整個問題的關鍵。如何解決好這個問題看來還需要進一步的實踐和創(chuàng)新。

其次是虛擬機本身的安全性，其實在虛擬機的發(fā)展之初，其實各個技術主要關注首先絕對是性能，比如當時Xen雖然上手其為復雜，但是由于其本身的半虛擬化的架構，使得其在性能方面，長期稍強于VMware，并拿這點作為其長期的談資，但是隨著各方面程序的優(yōu)化，特別是硬件虛擬化技術的引入，其實在性能方面，各方面都已經接近均勢，并且大的優(yōu)化空間也不多，所以虛擬機的安全性很有可能將會作為今后的主要考量之一。據(jù)一些行業(yè)IaaS云供應商的反饋，Xen本身有嚴重的漏洞，通過這個漏洞，虛擬機里面的程序可以直接攻擊到物理機本身，并且KVM也有類似的問題，比如KVM直接有兩個IO端口可以和QEMU通信，所以虛擬機的安全性還有待完善。云安全絕對是一個需要重視，并且需要花大力氣的領域。

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

吳朱華曾經走訪了幾家做私有IaaS云的廠家，根據(jù)溝通，這些廠商面對最大的技術挑戰(zhàn)，基本上都是“網絡難配”，主要有三個方面的原因：其一是現(xiàn)在云服務多個節(jié)點之間需要連接大量內部的通信，最明顯的例子就是Hadoop，當集群大小超過千臺時，網絡會成為比IO更大的一個瓶頸;其二是虛擬機各節(jié)點只能在同一個二級網段內才能進行非常重要的動態(tài)遷移;其三是每個虛擬主機都會運行十個以上的虛擬機，這會導致過一個網段內實際所需要承受的機器數(shù)量和具體流量都倍增。這些因素都導致數(shù)據(jù)中心網絡從之前對外為主的南北向，慢慢轉為以內部為主的東西向，同時數(shù)據(jù)中心不得不出現(xiàn)大二層的現(xiàn)象。為了解決這些問題，網絡界推出了各種解決方案，包括將路由能力帶到二層網絡的TRILL和FabricPath，用于識別虛擬機流量的VN-Tag和VEPA，用于二層互聯(lián)的VPLS和OTV。最后就是號稱改變整個網絡世界的SDN(軟件定義網絡)。對于這些技術，吳朱華認為的確能讓現(xiàn)有的云服務，特別是IaaS層在技術層面有一個質的的飛躍，但是整體成熟度和成本要下降到一個讓大家都滿意程度，顯然并非易事。

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

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

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

雖然業(yè)界各種五花八門的Hadoop用例讓人有點疑惑，但是Hadoop社區(qū)的確在最近幾年混的“風生水起”，通過Cloudera和Hortonworks這兩大巨頭推動，并且再加上類似淘寶云梯這樣案例不斷成熟，使的Hadoop快成為業(yè)界標準的大數(shù)據(jù)服務平臺。同時由于MapReduce這樣新的編程框架，使得傳統(tǒng)的基于關系型數(shù)據(jù)庫的周邊工具都無法繼續(xù)使用，所以一些新的周邊工具不斷推出，包括用于數(shù)據(jù)流支持的Pig，用于SQL解析的Hive，用于日志收集的Flume，用于ETL的Scribe，用于實時分析的Impala等。不過對于Hadoop這個生態(tài)圈，吳朱華也表示有些疑慮，雖然和OpenStack生態(tài)圈相比，表面上有兩大巨頭的支持，但這兩大巨頭各懷鬼胎，而且其整體所需要投入的工程量和OpenStack相比也是不相上下，希望兩大巨頭能拋棄成見，齊心協(xié)力。

NewSQL的興起

前幾年談及NoSQL，雖然其伸縮性不錯，但因為其不支持完整SQL語句，使得其學習成本變得很高，所以吳朱華認為既能伸縮、又能支持SQL的NewSQL興起再所必然。大家想起的NewSQL，一定是MemSQL或者SAP HANA等這類初出茅廬的新型基于內存的數(shù)據(jù)庫，但是其實在NewSQL方面，最強大的始作俑者絕對是研發(fā)出MapReduce的Google，雖然其最初整套用于半結構化數(shù)據(jù)解析的索引構建模塊是基于MapReduce的，并且研發(fā)了著名NoSQL技術BigTable，但是隨著它業(yè)務的需求和對性能等方面要求的不斷提升，在技術方面，它做了優(yōu)化和轉型，基于現(xiàn)有公開的資料，主要兩部分，其一在索引構建和OLTP方面，Google以BigTable為基礎發(fā)展出可以對大數(shù)據(jù)集進行增量更新的Percolator系統(tǒng)以用于索引的構建和服務，同時也在BigTable基礎上，推出用于分布式海量OLTP的Megastore和F1 Spanner，并且他們分別被用于Google App Engine的Data Store數(shù)據(jù)庫服務和Google的現(xiàn)金牛廣告服務，同時在OLAP方面，它推出有點類似MPP列式數(shù)據(jù)庫的Dremel，通過Dremel這個系統(tǒng)能夠構建有千臺規(guī)模的分析集群，并能快速地對PB級別的數(shù)據(jù)進行處理。無論是F1 Spanner還是Dremel，它們在伸縮性方面都非常不錯，并且在語法上面支持一定的SQL語句，吳朱華認為它們絕對是NewSQL的典范之作。不過現(xiàn)在NewSQL界，真正有實力的公司和產品并沒有出現(xiàn)。

爭議點

雖然上面提到了很多關注點，但是在吳朱華看來，還是存在很多爭議點，就像梅西和C羅各有各自的優(yōu)點，還需要進一步討論才能分出優(yōu)劣或者各自適合的場景，只有通過這樣的討論，才能幫助大家抓住關鍵點，從而引發(fā)質的飛躍。

OpenStack 還是 CloudStack?

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

結構化數(shù)據(jù)，Hadoop適合嗎?

首先，雖然現(xiàn)在Hadoop使用面很廣，包括類似OLAP的結構化數(shù)據(jù)分析，但是其實Hadoop這樣MapReduce的框架，最初的需求主要是用于類似網頁這樣的半結構化數(shù)據(jù)的處理和分析，而且MapReduce這樣暴力的方式也特別適合類似地理數(shù)據(jù)和視頻這樣非結構化數(shù)據(jù)。同時雖然現(xiàn)在有類似Hive這樣的解決方案，但是基于吳朱華最近幾年底層的收獲和一些朋友反饋，Hadoop在處理結構化數(shù)據(jù)時，無論是處理速度，還是處理成本，都和基于列式存儲的NewSQL數(shù)據(jù)庫無法接近的。另外，雖然Cloudera推出用于準實時分析的Impala，但是由于其重寫了極為耗時耗力的SQL解析引擎，所以吳朱華認為等它全面支持SQL語句那天，還為時尚遠。綜上所述，誠然Hadoop能做對結構化數(shù)據(jù)的分析，但是否合適，這就是一個仁者見仁，智者見智的問題。

GAE，還是Cloud Foundry?

雖然PaaS這個名詞在2012年比較沉寂，但是Cloud Foundry和GAE(Google App Engine)都有一定的進步，Cloud Foundry有了更多用戶，GAE又發(fā)布了新的版本。爭論的核心是Cloud Foundry和GAE在方向性上面的差別比OpenStack和CloudStack更大，在他看來，Cloud Foundry核心是快速地部署，快速地開發(fā)，支持各種編程模式和靈活地使用，而GAE的優(yōu)勢是通過它分布式的架構能快速伸縮，并且能夠最大限度地進行超買，從而在一定用戶規(guī)模的基礎上實現(xiàn)較大的盈利，但是初期構建成本比Cloud Foundry高的多，所以吳朱華認為Cloud Foundry這個方案比較適合私有云，而GAE更適合公有云，具體今后的PaaS屆誰會成為潮流，這個還很難說。

SDN有需求嗎?

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

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

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

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