原文地址 http://dbanotes.net/arch/IOE.html
這篇文章算是今年年末的一個技術總結。談談技術圈一度的熱門話題「去 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」有一種公司政治的傾向，或者成爲一個一窩蜂的運動，這很令人討厭，或者說這事情出發點未必如何好，但令人意外的是，最後在阿里諸多優秀技術人才的努力下，卻取得了一個令人驚訝的很好的結果，那麼，就別管出發點如何了。
爲何「去 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
評論：