談談去 IOE 運動

原文地址  http://dbanotes.net/arch/IOE.htmlhtml

這篇文章算是今年年底的一個技術總結。談談技術圈一度的熱門話題「去 IOE」這件事。數據庫

何謂 IOE ?服務器

所謂 IOE 是個簡稱。是指以 IBM 、Oracle、EMC 爲表明的小型機、集中式數據庫和高端存儲的技術架構。其中 I 指 IBM p 系列小型機,操做系統是 AIX,IBM 專有的 Unix 系統;O 指 Oracle 數據庫(RDBMS);E 指 EMC 中高端 SAN 存儲,曾經一度是 IT 企業很喜歡採用的技術架構。IOE 這個說法怎麼來的? 據我所知應是來自阿里技術團隊內部的稱謂,而後纔在整個業界流傳開來。若是你去問國外技術專傢什麼是 IOE,對方確定一頭霧水。固然,隨着國內案例逐漸被介紹到國外,或許某一天這個術語能輸出價值觀也說不定。網絡

在小型機領域,只有 IBM 這一家,獨步武林;HP 當初把寶押在安騰上,算是早早退出這個市場;Sun 日薄西山,SPARC 機器…那就更沒必要說了。另外,須要說明的是,IBM 也生產存儲產品,但 IBM 的存儲產品早期其實挺山寨,競爭不過 EMC ,並且有些用戶會忌諱把全部的東西困在一家公司身上,尾大不掉。 起碼在國內,EMC 的佔有率應該更高。中高端存儲這個領域,還有一家 HDS,不過曾經一度在阿里也栽過跟頭。數據庫軟件方面,在當初幾乎沒的選擇,只有 Oracle 這一家,IBM 的 DB2 實在是不行,雖然號稱市場佔有率不錯。國內用 Oracle 數據庫支撐互聯網應用的話,通常是採用 Data Guard 這個架構方案。架構

爲什麼要「去 IOE」?併發

提及「去 IOE」,跟阿里的王堅博士有直接關係。我無從得知他當時爲何要作出這個決定。但根據個人推斷,當時淘寶、支付寶等公司每家技術體系各有特點,技術團隊也各是一套,只有去「去 IOE」,纔有可能將淘寶、支付寶等公司的網站核心體系架構遷移到雲上,體現阿里雲的價值,某些管理者纔有可能從集團公司層面對整個技術團隊有更好的控制力。不然,阿里雲師出無名。注意,這個說法只是我我的臆測,確定不是事實,只是邏輯上是說得通的。實際上,阿里雲當時本身的活兒作的很垃圾,也幸好這個「去 IOE」運動進行並不那麼快。固然這是後話了。運維

或許有人認爲「去 IOE」會節約企業成本,實際上,當時的 Oracle 和 EMC 等軟件成本已經足夠低,硬件上,硬件上的每一年的成本也是可控的,若是考慮遷移後整體成本,新硬件成本、開發人員成本、運維成本、時間成本等等,統統算下來,未必能節約多少。這個不是我拍腦殼給出來的,而是跟很多技術人過後覆盤,結論基本一致。分佈式

客觀的說,當時「去 IOE」有一種公司政治的傾向,或者成爲一個一窩蜂的運動,這很使人討厭,或者說這事情出發點未必如何好,但使人意外的是,最後在阿里諸多優秀技術人才的努力下,卻取得了一個使人驚訝的很好的結果,那麼,就別管出發點如何了。ide

爲什麼「去 IOE」是必要的?高併發

從另一個角度考慮,尤爲從運維DBA的角度去審視,「去 IOE」 其實是必需要進行的,或者說去「O」是必須的,由於當時存在的問題是,Oracle 數據庫對用戶 (DBA) 來講已經不夠靈活,經常使用的 Data Guard 模式沒法適應互聯網公司快速增加,最基本的一點,讀寫分離就作不到,只能向上擴展(Scale Up),拼硬件能力,幾乎沒法作到橫向擴展。或許有人說,不是有 RAC 麼? 但 Oracle RAC 是沒法對付高併發下的 OLTP 應用的 – 一直到如今不少人都認識不到這一點,RAC 跑跑數據倉庫什麼的卻是不錯。

注:有人會說 Orale RDBMS 11g 的 Data Guard 能夠讀寫分離呀,這個所謂的讀寫分離可靠性實際上是不夠的,並且出現的時間也太晚了,此外,不夠靈活。還會有人爭論 Oracle RAC 怎麼就不能應付 OLTP 呢? 別爭論了,你非要說能夠應付,沒問題,可是在阿里體系的公司裏,還真沒人敢這麼玩兒,爲何? 是作不到? 仍是他們掉進坑過?

若是要動「O」,那麼 「I」 和「E」就必需要動 – 相信不會有人在小型機上跑 MySQL 的,並且,只換掉「O」也沒有意義,換湯不換藥不會有成效。

隨着中國電子商務的快速發展,整個阿里系其實已經在面對全世界增加最快最複雜的業務系統之一,這是機遇,也是挑戰。舊有的技術架構已經不足以支撐更大的夢想。從這個意義上來講,去「IOE」是至關必要的。或許,這也是王堅博士以及一些人的初衷。

爲什麼「去 IOE」成功了?

阿里幾家子公司這麼複雜的技術體系,「去 IOE」這事情堪比高速公路上給飛馳的汽車換輪胎,最後成功是至關不容易的。

成功的因素有哪些呢?

1.功不可沒的固然是一羣出色的技術人才,很了不得。我想這是無需多說的,面對這麼複雜的業務環境,這個任務若是沒有一批優秀的工程師是絕對作不到的,沒有阿里 B2B 技術團隊、淘寶團隊、支付寶技術團隊的前後投入以及合做實踐也是絕對作不到的。要強調一下的是,阿里在在分佈式事務上的處理能力和解決方案,這應該是獨門絕技。在業界各類會議上也常常能看到這一羣牛人出來分享,同行應該能感覺到。

2.開源軟件的快速成熟。舉個例子,這兩年 MySQL 體系的軟件進步至關驚人,各類經驗證的解決方案如雨後春筍般涌現出來。這得益於很多知名互聯網公司(好比 Facebook、淘寶)在使用 MySQL 的同時也將其技術改進回饋給技術社區,把技術方案分享給業界,業界在吸取這些技術的同時再次回饋給技術社區,造成正向的反饋,極大地提高了開源軟件在商業領域的競爭力。

3.硬件革命。硬件的進步給技術體系的變遷作好了鋪墊。最主要的關鍵詞:「SSD」。若是沒有「SSD」的技術成熟以及在商業應用上被廣泛接受,「去 IOE」幾乎是不可能作到的。要知道物理機械硬盤存儲的性能數十年幾乎沒獲得什麼大的改進 – 固然每一年提高一點是有的。但 SSD 相比機械硬盤來講,則是質的飛躍。我記憶深入的是,每一年作 I/O 容量規劃的時候都會發愁,由於即便已經使用上了很高端的 EMC 存儲設備,但實際上只要應用層 I/O 沒有命中到存儲內存,直接打到後面的磁盤上,幾乎沒什麼抵抗能力。好比當時一個硬盤極限能撐 100 多個 I/O,100 塊硬盤也不過是萬把個 I/O 就不行了。 但這樣的 I/O 「打擊」對 SSD 來講,則不是什麼大問題。SSD 給解決「IOE」體系最大的瓶頸 – I/O 能力提供了硬件先決條件。

4.摩爾定律。這一點最初我不想說起,但不說起,就會有別人說,因此仍是補充一下。提到摩爾定律,重點要說的 X86 芯片的計算能力不斷進步,而 IBM 的 Power 芯片雖然也在不斷進步,但正式商用的節奏明顯在控制。這就給 Intel 體系帶來了機會和空間。

國內對「去 IOE」的反應

在出現阿里這個成功案例以後,技術圈非常震動,曾經一度討論熱烈,隨後則是國內產業界對此出現了一些跟風的傾向,很多公司則打着「國產」軟件的旗號出來蒙人,這是值得警戒的。去掉 Oracle 不意味着就要採用國產的垃圾數據庫,由於 MySQL 以及衍生的各類分支數據庫纔是最佳選擇。一樣,不用 IBM 的小型機也不意味着國產服務器就迎來新機會,在用戶那裏,適合的解決方案纔是最重要的。「去 IOE」不該該成爲一個噱頭。任什麼時候候,「國產」都不該該是一個互聯網企業選型所要優先考慮的因素。在全球化的今天,咱們應該忘掉「國產」,纔有可能早點作出來更牛的軟件來。

更可笑的,還搞出來一個什麼「去 SOA」的組織,我以爲這是不太正常的,實際需求爲前提,不能本末倒置,難道是爲了「去」而「去」麼?

2014 之後會有更多公司「去 IOE」

從目前的種種趨勢來看,在從此幾年,國內一些互聯網公司以及 IT 企業會逐漸的「去 IOE」化。相比幾年前,如今的「去 IOE」的主要緣由則是:舊的「三件套」已經的確不適合互聯網應用了。開源數據庫更爲可靠成熟,SSD 可靠性也獲得驗證,技術人才甚至都不須要從頭開始進行儲備 – 相似「沃趣科技」這樣的團隊已經可以提供足夠好的技術支持服務,新的技術體系毫無疑問會讓企業更有競爭力,整體成本更低。

上文提到的「沃趣科技」是由一羣前阿里的工程師組成的技術團隊,聚集了一羣從數據庫到存儲到網絡架構的專家,若是要找「去 IOE」技術顧問,彷佛他們是獨一份(這裏不是廣告)。相比之下,IBM、Oracle、EMC 等公司近些年來,實際上對國內那些快速發展的互聯網公司已經提供不了有力的技術支持了,IBM 拿蘇寧電商練手更成爲業內笑柄。或許這也是 IOE 們被拋棄的一個緣由,也多是一些創業團隊的新機會。

一個時代過去了。

EOF

關於 IOPS 的數據補充:

機械硬盤如今最高號稱能跑到 400 IOPS,但應該 200 左右(走 SAS 接口)也就是極限了; 單塊 SSD(走 PCIe 接口)的最高記錄是九百多萬,用不了多久突破千萬 IOPS 是沒問題的,至關了不得, 即便百萬量級也足夠嚇人了。(Refer)


IOPS

http://en.wikipedia.org/wiki/IOPS


評論:


仍是補充下, I(小型機)提供的是可靠的計算服務, 經過軟件Cluster或必定的一致性/可用性的犧牲, 是比較容易作到的, E提供的是持久化的狀態快速遷移的問題, 在軟件層作mirror或必定的快速切換能力也是能夠顯著下降成本的, O提供的是一整套的業務整合能力, 以及業務的ACID支持, 若是對ACID沒有需求, 或者InnoDB就能夠知足你的需求(非資金/訂單類業務), 使用O從一開始就是個錯誤.

相關文章
相關標籤/搜索