雲端運算Cloud computing學習心得筆記(三) Yahoo的架構

  提到Hadoop其實就會想到Yahoo, Yahoo 目前是最大的Hadoop使用者,於2009年10月公佈的數字,已有4000個node clusters在運作

為何Yahoo要改用Hadoop呢

Yahoo 提出的理由如下[1] :

 

的確, 如果Yahoo在以前是使用傳統N-tiers 的方式,在維護及擴充方面會比較困難,而且成本較高,我想這也是為何Yahoo在服務上的擴展一直不如Google迅速有效率的原因,看來這幾年Yahoo花了不少功夫在改變核心架構以提升競爭力,還於2006年聘顧了Hadoop 之父Doug Cutting來主持Hadoop計劃.

 

  我們再來看看 Yahoo從2006年以後 Hadoop 硬體上的成長曲線[2],已經到了25000 nodes ,82Peta的Disk,成長速度相當驚人,這也讓我們了解到,要長期維持在全球流量第一,就必須持續的擴充及成長,而不是停在原地。

Yahoo 的Hadoop架構用在哪些方面呢?

以Yahoo首頁為例[3]

 

傳統的網頁是靜態的，也就是說內容都是由編輯人員事先設定完成，但新型態的網頁內容都傾向由用戶行為去分析哪些資料是重要的，也就是說，在Yahoo首頁會根據用戶的點選及搜尋行為,去做內容的優化，也可以根據mail上用戶的行為來判斷垃圾信，傳統網站的做法會把這些網站內容的用戶使用記錄存放在資料庫裡分析，這樣的成本相當額貴而且沒效率。

 

Yahoo 導入Hadoop後增加多少效率呢?

以Search assist 為例 :

 

我們每次利用關鍵字搜尋資料，在Search box下方會有些推薦的關鍵字，這些資料的產生若用以前傳統的架構，要26天才分析完成3年的資料再更新到網站，光開發這個功能就要3周的時間，但利用Hadoop架構只要2-3天就開發完成，而且可以每20分鐘就分析完資料並更新，一些熱門的關鍵字都可以很快的被顯示在Search assist上,帶給用戶更好的使用體驗。

 

開發流程管理

Yahoo 目前是用Gridmix3及Rumen 來管理布署及監控Hadoop架構[4]

 

未來發展

我們可以參考Hadoop summit 2010 會議 ,Hbase、 Pig、 Hive、 Cascalog 、ZooKeeper 等相關技術持續在討論,流程管理工具Oozie還在發展中,有興趣的人可以報名參加。

Agenda 在 http://developer.yahoo.com/events/hadoopsummit2010/agenda.html#71

 

 

資料來源:

[1]Yahoo!Webmap ,Christian Kunz, March 25, 2008

[2][3]Hadoop at Yahoo, Eric Baldeschwieler ,VP Hadoop Software Development, Yahoo!

[4] http://developer.yahoo.net/blogs/hadoop/2010/04/gridmix3_emulating_production.html

http://www-07.ibm.com/tw/imc/igs/article/2_1/3.html

http://developer.yahoo.net/blogs/hadoop/

Hadoop at yahoo https://opencirrus.org/system/files/OpenCirrusHadoop2009.ppt

http://research.yahoo.com/node/2104

雲端運算Cloud Computing學習心得筆記(二) Facebook的雲端架構

傳統的網頁通常是用戶主動在Browser上refresh頁面才會更新資料,一般節省資源的方式為把動態網頁(asp,php,jsp..)轉靜態頁面(html),並利用Trigger的方式更新資料庫資料及網頁資料,但隨著AJAX技術普及化,許多網站加入了即時更新內容的機制,如 Facebook 的 news feed 或status update ,由於每個人本身都是訊息發佈者及訂閱者，因此當用戶的關係越密切，讀寫的資料就越龐大，就Facebook 2009年公布的數據為:

 

資料產生:

超過3億位有效用戶

每天有3000萬個用戶至少會更新一次自己的狀態

每個月有超過10億張的照片上傳

每個月有超過1000萬的影片上傳

每周新增超過10億種的內容(網站連結,新聞,部落格文章,記事本,照片..等)

 

資料用量為:

每天產生4TB的已壓縮資料

每天有135T的已壓縮資料被掃描檢視

每天8萬小時的運算時間

 

由於資料量相當大，如果要購置可以支援的高階超級伺服器將會相當額貴，因此Facebook採用Hadoop架構，用大量的PC去取代高階伺服器，既省錢又因平行運算的架構及高容錯性，對於Peta級資料量其查詢效能相當好，其所規畫出來的儲存的空間為

4800台cores (虛擬server), 5.5 PB (Peta=10¹⁵)

每個node配置 12TB空間

 

硬體架構如下:

Facebook Datacenter 影片 :

 

由於Facebook 上需要分析用戶資料來做相關的推薦，因此他們還使用了HIVE來當資料庫倉儲系統，其架構如下:

Scribe 是蒐集Log 的 server , 將蒐集到的log 往 Hadoop Hive warehouse丟, 即可用近似SQL的語法來做分析,一些推薦的內容如 朋友、社團、專頁、廣告..等應該都是透過這樣的機制產生。

 

由Facebook公開的資料可以得知，經營一個全球化的SNS網站絕不能用一般的思維來設計，看似簡單的網站，若架設在單一Server上給少數使用者用，一樣可以運作，但到了要服務3億人時，網站看似沒變但整個架構就都不一樣了，要如何彈性有效率，可以參考一下Facebook 的架構。

 

資料來源:

Facebook Tech Talk: Rethinking Servers & Datacenters http://www.facebook.com/techtalks?v=wall#!/video/video.php?v=208561675468&ref=mf

Hadoop & its usage in facebook http://www.snia.org/events/storage-developer2009/presentations/keynotes/DhrubaBorthakur-Hadoop_File_System_Architecture_Facebook.pdf

Hadoop and Hive Development at facebook http://www.borthakur.com/ftp/hadoopworld.pdf

雲端運算Cloud computing學習心得筆記（一）

  最近常被一些媒體拿雲端出來亂炒,把所有網路服務都試為雲端服務,所有傳統網站突然就變成雲端網站,大家都號稱自己擁有雲端技術,然後大幅報導全球將引爆雲端商機,我看了是一頭霧水,在這裡分享一下個人所知道的雲端運算.

 

緣由

在雲端運算發展以前,其實已有Grid computing , Utility computing 等架構,因此平行運算、on demand service的概念早就存在，但以前的系統大都為企業和組織內部使用，直到雲端運算才開始有對外完全開放且統一的架構.

而雲端運算的技術是始於Google、Yahoo、Amazon這類超大型網站服務公司在想解決大型網路架構效能所演進而成的技術，追朔其歷史，應該始於2007年10月，Google與IBM開始在美國大學校園，包括卡內基美隆大學、麻省理工學院、史丹佛大學、加州大學柏克萊分校及馬里蘭大學等，推廣雲端運算的計畫，這項計劃希望能降低分散式運算技術在學術研究方面的成本，並為這些大學提供相關的軟硬體設備及技術支援（包括數百台個人電腦及BladeCenter與System x伺服器，這些運算平台將提供1600個處理器，支援包括Linux、Xen、Hadoop等開放原始碼平台）。而學生則可以透過網路開發各項以大規模運算為基礎的研究計畫。[1]

 

大型網站面臨的問題

在2000年左右，絕大部分的網站用的都是three tiers architecture，大型網站則是N tiers，其概念還是把各網站功能拆解成一台台的伺服器，一般基本的規劃如下：

 

Web server  2台 , 2 CPU ,4 G RAM

AP server   2台  , 2 CPU , 4G RAM

Mail server  2台 , 2 CPU,4 G RAM

Database  2台, 4 CPU , 8G RAM

File server  2台

Storage : NAS / SAN 5T

 

一次購買2台主要是要做load balance 及 Cluster，來提高網站的stability、 avalibility與scalability.

若再加上Firewall 、DNS server、 Switch、 router 等網路設備，一開始就得投入不少資金購買設備。

隨著網站會員增加，主要的server loading不勝負荷，通常就會開始購買額外的Server，而Database就要看需求增加CPU或採分散式資料庫架構，並增加許多Cache的function 來降低Loading

因此一般中型網站經拆解後,其伺服器數量可能變成如下:

 

Web server  10台

AP server  8台

Mail server  2台

Master Database  2台(8 CPU) + sub-Database X 4台 (2 CPU)

File server  4台

Storage : SAN 20T

 

這時問題就發生了

1. 各Server 資源使用不均

透過監控軟體可以發現,80%的server CPU loading 低於 30% 但 20%的 Server CPU 大都維持在60%

2. Database Cost過高

把所有網站的資料都存在資料庫在初期ok，但一旦資料一多，每個存取都相當耗系統資源，當然可以做資料庫效能調校、資料表切割、資料快取、分散式架構，但由於Database的license 通常不便宜，這樣的擴增相當燒錢。

3. Storage 的效能不足

在大量的資料存取下，Storage Disk I/O 居然也吃緊，必須準備更多的Storage 來分散存放資料

 

問題解決方式

我想這類問題在超大型網站Google Yahoo 上早就發生，看看他們是怎麼解決的

 

1. 將硬體虛擬化，導入平行運算

虛擬化的好處是可以讓一些閒置Server也可以運用，而且維護方便，不用停機。目前常看到的解決方案為 : XEN、VMware、Hyper-V

平行運算可以讓一些複雜吃資源的運算在短時間完成，不會讓某特定做運算的Server lock住導致整體效能變差，目前常用的解決方案 ： Hadoop MapReduce、 Sector、google Mapreduce

由於伺服器虛擬化且可以平行運算，Google 早期都採用PC等級的電腦充當伺服器，大家可參考下列影片，很難想像這就是雲端的前身

2.  分散式資料及noSQL 架構

主流資料庫大都為RDBMS關聯性資料庫架構，其好處式資料易於維護、有Transaction Rollback功能、可以有多重索引、資料完整性及準確性高，但缺點是擴增不易、成本高、對於大量存取資料效能不佳，因此RDBMS比較適合在金融、EC、Dataware house、ERP…等商業應用上，而網頁的資料，並不需要那麼精準，但非常需要效率，所以衍生出下列分散式資料架構及noSQL資料庫

 

分散式檔案架構

Google File system :

        Goolge 於2003年發表的一篇論文,使用分散容錯的架構在許多便宜的HDD上取代當時昂貴的Storage,並大幅提升存取效率 [2]

Hadoop HDFS :

       Apache Hadoop架構下的分散式檔案架構,可以搭配Hive及 Pig 來存取資料[3][4]

 

noSQL Database:

Google Bigtable :

       為了能高速讀取及搜尋Peta Bytes級資料而研發出的資料庫架構[5]

Hadoop Hbase :

      Hadoop架構下的資料庫架構,可搭配Hive或Pig[6]

Apache Cassandra :

      由facebook 開發並釋出的open source NoSQL 資料庫架構, Twitter 與Digg 也都採用此架構 [7]

Hypertable :

     也是一個open source 的noSQL database[8]

當然分散式檔案架構也有其致命缺點，其耗用原始資料3倍的空間儲存資料，可謂用空間換取時間，但卻有效的改善了網站的效率及擴充性，更重要的是這樣的架構只要在PC及一般的硬碟上跑就可以，相當經濟

而雲端運算平台的選用，個人看來以Hadoop為首選，但並竟是開放源碼的架構，在安裝及設定上都頗麻煩，目前有商業化套件 Cloudera http://www.cloudera.com/ 可供選用，目前還是免費下載的喔

 

如果對RDBMS及HDFS的效能比較有興趣，可以參考這篇文章，10 Ways To Complement the Enterprise RDBMS Using Hadoop

演化- 雲端服務

 

既然雲端運算的架構如此強大又容易擴充，若將其商業化建立雲端中心共企業或ISV使用，勢必有一定的商機，因此演化出3種營運模式

1. IaaS : 可以視為虛擬主機租用，但由於彈性高，可以根據CPU使用率來計價，可以細到以使用小時來計價，如Amazon EC2.

2. PaaS : 在雲端架構下建立的Platform, 提供ISV來上傳在平台規範下開發的軟體

3. SaaS : 即以前的ASP,但建構在雲端架構下

 

原本以經濟與效率為取向的雲端運算，轉為商用後，變成了雲端資料中心，提共更穩定更省電更高效能的環境，目前還有雲端貨櫃中心(Container Computer)[9][圖一]的產品，以低耗能高密度高校能為訴求，一個貨櫃可以擺放576台Server，販售對象為想建立私有雲應付大量運算的大型企業、醫院、國家組織、研究單位…等，但如果是一般網站經營者，可以思考改租用雲端服務或架設分散式架構來節省營運成本，個人建議先從VMware及Hadoop著手研究吧!!

 

圖一: 可以擺放576台server的貨櫃 圖片來源 : iThome

 

[1]Wiki : http://zh.wikipedia.org/zh-tw/雲端運算

[2]GFS 論文 http://labs.google.com/papers/gfs.html

[3] HDFS http://hadoop.apache.org/hdfs/

[4] Run PC 初探Hadoop開放原始碼平台環境 http://www.runpc.com.tw/content/cloud_content.aspx?id=105318

[5]Bigtable http://labs.google.com/papers/bigtable.html

[6]Hbase http://hbase.apache.org/

[7]Cassandra http://zh.wikipedia.org/zh-tw/Cassandra

[8]HyperTable http://trac.nchc.org.tw/cloud/wiki/HyperTable

[9]雲端貨櫃 http://www.ithome.com.tw/itadm/article.php?c=58652

延伸閱讀

Baseline “How Google work”http://www.baselinemag.com/c/a/Infrastructure/How-Google-Works-1/e

ebiz “10 Ways To Complement the Enterprise RDBMS Using Hadoop”http://www.ebizq.net/blogs/enterprise/2009/09/10_ways_to_complement_the_ente.php

Google TV之觀察

Google 於 5/21日Google I/O大會發表了Google TV平台,正式宣告要進入客廳的影音市場,其相關新聞及文章如下:

搶700億美元商機 Google TV即將問市

與GoogleTV設計師對談

Google宣布推出Google TV　年底全面向蘋果宣戰

英特爾與多家廠商宣布聯手開發Google TV

Google TV 的Project leader 是Vincent Dureau, 之前待過Direct TV 與 Open TV這2家公司,因此對數位電視產業應該算熟悉,上面的文章有他的專訪,看來他的設計有幾項重點

1. 平台介面網頁化

這邊有給Google TV 網頁用的設計規範 : http://www.google.com/tv/developer/

這邊有介面的初步展示,但我用他的方法無法Sign up,不過看來整個channel的介面就是一個網頁的型式,因此網路內容商應該只需要小修改就能符合Google TV的需求

 

2. 支援Flash 10.1

3. 採用Android 2.1 版本, STB會支援OTA(over-the-air)升級

4. 初期沒有Android Market for TV ,能安裝的application 都是Per-installed 的,  不過日後會開放

5. 對STB製造商而言, Goolgle 就是提供了一個open platform 給他們選擇

6. 支援搖控器、滑鼠和鍵盤控制, 規格是IR Blaster,以後可以用Android手機直接控制電視

7. 內建Chrome 5.0瀏覽器

 

目前看到到的Partner 是

 

1 TV製造商 Sony : Sony 也參與了 Yahoo! TV widgets, 真是雙邊押寶

2 STB 製造商 Logitech : 羅技應該是第一次開發STB吧?

3.CPU Intel ATOM :Intel 與 Microsft 的MCE 和自身推的ViiV 都失敗了,這次轉向與Google合作

 

以這樣的陣營看來其實不太樂觀,我的理由如下:

 

1. 缺乏有線或無線MSO的支持

這也是Microsft 與 Intel 和 Apple 失敗的原因，對於MSO而言，這類的純IP STB 等於在重寫產業的遊戲規則，大部分MSO不願意加入此類平台，因此進入者大都為幾家內容商或網路平台，用戶幾乎看不到一些比較熱門的頻道.

 

2. 缺乏大型STB(SET-TOP box )廠商的支持

STB 的規格大都由MSO業者指定後下單，目前最大的平台為DVB- MHP 與 OCAP,CPU大都用ARM,對這部分google完全不考量,STB業者恐怕不太敢貿然跟進

如果想直接販售給用戶,以目前市場少的 DVB數位電視盒 或 PVR(TiVO)，在市場比例上都算少數,市場難以擴增

3. 介面設計不夠娛樂化及無腦化

這點真的要跟http://www.boxee.tv/ 好好學學

http://vimeo.com/moogaloop.swf?clip_id=8599559&server=vimeo.com&show_title=1&show_byline=1&show_portrait=1&color=8dc541&fullscreen=1

Boxee Beta from boxee on Vimeo.

 

4. 沒有給內容商(電視台)的雲端solution

既然要跳過掌握last miles的MSO業者,何不提供Live TV streaming或 HD VOD的solutions,以目前ISP提供的網路品質，要流暢的看網路電視實在是一大問題呀!

 

這裡有一篇比較的文章, 個人覺得不錯

http://hd.engadget.com/2010/05/21/google-tv-who-is-the-competition-and-what-are-they-saying-about/

TV 這塊市場，看來競爭相當激烈，各陣營互相角力著，這次的平台發表個人認為並無驚艷之處，Google要加點油了

漫談Flash 與 HTML5

戰火的緣由 

最近由於Apple iPhone/iPad/iPod 等熱賣產品始終不願意支援Flash, Jobs 甚至放話Flash是舊時代的產物, HTML5才是未來, 雖然Adobe CEO 努力的解釋正在持續改善Flash的效能,但Jobs 的回應是,請Adobe不要再糾纏.

Jobs 的觀點是:

First, there’s “Open”.   Flash player 是專有的player,不開放. 我想很多人不知道Device 商還需要付license fee給Adobe的

Second, there’s the “full web”. Jobs反擊Adobe說不支援Flash player就不能有完全的web體驗,他舉出大部分的影音網站,包括Youtube都有提供H.264的格式,而不能玩Flash game也不是問題, App store裡有5萬個game.

Third, there’s reliability, security and performance. 這是Flash player很難改善的問題,畢竟他是瀏覽器裡的plug-in

Fourth, there’s battery life. Flash 相當吃系統資源, 當然耗電

Fifth, there’s Touch. Flash player 沒有針對電容式Touch screen 作微調, touch的體驗不佳

Sixth, the most important reason.  Adobe 希望Apple app store的 developers 用Flash來開發Apple行動裝置程式,由Flash硬轉為iPhone app 雖然可用, 但卻會造成系統不穩,因此Apple會禁止使用Flash開發的App上架.

 

當然Adobe方面的回應是新的Flash player 10.1版將會在安全性及效能上有重大更新,播放影片以可使用硬體加速解碼,但Apple方不願意等待,雙方合作可謂破局, Adobe只好轉向全力與Android與Microsoft平台合作.

 

Flash 的演進

剛接觸Flash 是在Flash2.0 大約1998年的時候,當時想在web上做game,有考慮使用較普遍的Java applet,但java applet 相當不穩定且沒有Macromedia Flash這樣好用的開發工具, 於是開始鑽研Flash,這幾12年間Flash不斷演進, 因此也多了Flash動畫師與Flash程式設計師這2種職務,雖然Flash 的 開發工具及功能持續演進但安全性及效能的罩門卻始終沒有大幅的改善,對於Flash 我當時的原則是

1. 能用DHTML 就不用Flash

2. Flash 裡的圖片一定要向量化,圖片盡量重複使用,一些移動及變形都要用程式優化

3. 需要被搜尋的內容絕不作成Flash

4. Flash 可以被反組譯,重要的帳號密碼都不能包在裡面

主要就是安全性及效能和SEO的考量,因此Flash 被定位在製作

1. 動畫

2. 動態Banner廣告

3. 簡易的Game

4. 影音光碟

5. 需特效的GUI

 

一直以來只要播放影片就只用embed media player的方式播放wma/wmv/mp3 等格式, 想不到Marcomedia 在推出Flv格式後,竟改變了網路影音由Microsoft wmv 、Apple quicktime 及 Real rm 格式獨占的局面

記得當時公司內的工程師建議Vlog使用FLV格式時,大家也是質疑他的效能及品質, 畢竟Vlog不是PPV的VOD服務,但若定位在互動性及娛樂性上, 其實FLV有絕對優勢, 相較於使用media player 他的優勢為

1. 可以自訂Player的 GUI

2. 可以在影片上加layer,因此隨時插上廣告及文字都沒問題

3. 可以存取webcam 直接錄製

4. 互動性佳, 可以在影片上做相關影片推薦、評分..等功能

而且Abobe在Flash player 9.0 r115後推出了新的f4v格式, 使用H.264編碼,也可支援標準h.264格式、HD畫質,並終於推出adobe media encoder cs4影片編碼工具, 比起flv的on2 vp6 及h.263編碼品質又好了許多.

這幾年也不乏有挑戰者來挑戰Flash的地位,如Microsoft的Silverlight,但都還看不到威脅性,個人觀察其原因為

1. 好用又完整的開發工具

Photoshop + Dreamweaver + Flash professional + illustrator  這樣的開發工具群目前沒有對手

2. 跨平台跨瀏覽器

adobe 在跨平台上的努力值得誇讚, Silverlight這部份有點薄弱

3. 廣大的3rd party 與 Developer forum

隨便找也一堆sample code, 不會寫程式的設計師也可以輕易copy到一些特效程式

http://www.flashcomponents.net/

http://www.flashkit.com/

http://www.freedownloadscenter.com/ 

Adobe 更把Flash 由網站推到桌面程式, 推出 Flash AIR /Flash Flex 架構及 Flash builder / Flash platform 開發工具,想讓Flash 變成擁有酷炫外表的Application,當這個方向,延伸到iPhone/iPad/iPod 上時,卻踢到了鐵板.

 

 

HTML5 VS Flash

 

Apple 以 Flash 耗電、耗用硬體（CPU）資源、不穩定、不安全..等理由, 在App store裡禁用Flash開發,這點美國政府已在調查其公正性, 而我們也來看看受Jobs推崇的Open standard HTML5 有何過人之處.

• 這是HTML5 的spec

http://www.w3.org/TR/html5/

 

• HTML tags 一覽表,新增了不少常用但HTML4.0沒有定義的tags、Event 及 Attribute

http://www.w3schools.com/html5/html5_reference.asp

 

• 這個網站還展示了9 個讓人驚奇的HTML5的範例
• 最讓人驚奇的是Guacamole,在不裝任何plug-in下,在瀏覽器上做出VNC的client

 

• Google 工程師示範html5幾項features: http://www.whatwg.org/demos/2008-sept/

個人覺得比較實用的是postmessage 到 iFrmae ,並用eventListener 收訊息

Localstorage 與 SessionStorage 可以減輕server的負擔，也可應用在離線瀏覽

Drag & Drop 蠻好用的,新的input type 如 range 、 date、url、email 很不錯,繪圖能力也增強不少,還有針對3D優化

 

除此之外, 還有針對Ajax的解決方案 websockets API

可以背景執行javascript的 web worker 

 

以下還有一些相關的示範網站

http://html5tutorial.net/

http://www.youtube.com/html5

http://html5demos.com/

http://mugtug.com/sketchpad/

本來只有Google、 Apple與Firefox支持的HTML5,日前Microsoft 也宣佈要開始支援,看來把Flash一些補足Browser所不能的功能包進新一代的瀏覽器已經是趨勢,Adobe的確要思考怎樣去支援Html5,及釐清自己的定位,一直以來HTML與Flash 是魚幫水 水幫魚的關係，彼此都有進步空間，比較確定的是Adobe應該還是可以開發出全世界最好用的Html5開發工具,但Flash player會不會慢慢消失就要看各瀏覽器大廠的決心了

Adobe 對HTML5 取代Flash的看法 :  Adobe：HTML5不會終結Flash ; Adobe：『打不贏，就加入他吧！』

 

這邊有篇日本野州先生的比較文章, 說明了Flash 目前的優勢

http://clockmaker.jp/blog/2010/02/flash-vs-html5/

我的歸納如下:

1. video : HTML5 的video codec 各家瀏覽器支援並沒有統一,Flash 影片沒有此問題,而且flv/f4v 還有字幕同步及文字註解功能

2.直排文字 ： 直有亞洲地區才有的直排文格式,可以在Flash 上呈現， HTML5沒有規範。

3.動畫製作 :  Flash 的動畫製作有納入時間軸概念及漸變功能 , HTML5 沒有

4. 3D : 多種3D模型可以匯入Flash內做動畫 ,如 Papervision3D 、Swift3D、 3dMax、Maya…等。

5. 錄音錄影拍照 :  除了透過webcam 錄影 錄音,還可以將Flash mix過的音樂錄起來,也可以caputure Flash screen 成一張照片

6. AR 擴增實境：運用webcam讀取的技術，有許多AR都運用Flash 當其Player,也有些toolkit 可以用，如FLARtoolkit

 

 

個人對Adobe flash 還是頗有信心，HTML5的互動性及普及性要趕上Flash 還有一段距離 , 而且如果你寫過腳本做Flash動畫,就會知道Flash有多好用了，況且有Microsoft 、Google 及 Apple 這3個死對頭一起推動的規格,最後應該會各走各路吧,我們就靜看其發展。

但Adobe 不再痛定思痛,好好改進自己的致命傷,其被取代的危機只會越來越大。

 

最近越來越多人出來打落水狗

Smartbook 在哪裡？ARM：「一切都是 Flash 和 tablet 的錯！」

Opera 也在 Flash 大戰中參一腳

 

是啦!在PC上已經跑不太動的Flash，怎麼在行動裝置上跑呀，Adobe趕緊加油吧，要不然大家只好定新規格把你換掉了

 

結論

很明顯Flash 不像Jobs所說是要被淘汰的舊技術，只能說以他目前的效能實在不適合在資源相當有限的行動裝置上執行，Apple 為了讓用戶使用上更流暢，甚至還放棄了多工，怎會容許吃資源的怪物在他的OS上跑，這是Apple堅持的地方，但HTML5和Flash看來還會並存合作好一陣子，說誰取代誰，有點言之過早。