從上一篇文章的反饋來看，大家還是喜歡八卦多過技術細節，那這一篇繼續一些題外話，說說我對“去IOE”的看法。

對同一件事情，參與的沒參與的人，討論起來，都會有各自的立場。所以這裏先申明一下，以下內容只是我個人的觀點，與任何公司及組織及其他個人皆無關；限於個人記憶力，部分細節可能有出入，如有差錯，純屬年老失憶。

淘寶當年從單個Java應用到服務化後的垂直分庫，再到水平分庫，一步一步走過來，每一步皆有其必然性。但從傳播性和話題性上來講，“淘寶技術架構升級”，顯然不如“去IOE”這種標簽化的短語有力量，短短幾個字，既有動詞“去”，又牽扯到當世三大企業服務廠商，想不吸引眼球當“網紅”都難。

說起淘寶技術架構升級，2007年是一個繞不過去的時間點，呃，這麽說的原因，當然很大一部分也因為我是這一年加入淘寶的。那一年的淘寶，意氣風發，空降了幾位很有影響力的高管，包括阿裏巴巴集團現任CEO逍遙子、菜鳥現任CTO菲青、現任VP優曇（記不太清楚是07年底還是08年初了），還有已經離職的前技術VP空聞、前HR VP趙敏等。

2007年的淘寶技術架構，在Java層有一個大名鼎鼎的應用denali。真的是一個應用哦，淘寶前臺業務大部分代碼都堆砌在這一個應用中，牽一發而動全身。所以空聞和菲青來了以後，招了幾個技術好手開始做服務化改造。於是有幾個基礎性的東西產生了： 畢玄主導HSF（High Speed Framwork）做為服務化的基礎RPC框架，解決了服務化後各個應用之間的高性能通信需求；華黎主導的消息中間件Notify（後來Kafka出來後，又用Java重寫了個MetaQ），解決了服務化後各應用之間異步依賴的消息通信需求。從產品命名上就可以看出來，包括後面的數據庫中間件TDDL，當年淘寶的技術人員是有多土鱉了。有了這兩大法寶，服務化和垂直拆分就水到渠成。

從2007年到2009年，馬不停蹄的從denali中拆分出了用戶中心UIC、商品中心IC、交易中心TC、店鋪中心SC、評價中心、收藏夾等等垂直的服務中心，以及每個服務中心對應的上層應用，那些暫時拆不出來的一大坨，就都塞在一個叫Misc的數據庫裏面。數據庫也從原來集中的商品和交易庫垂直拆分成了十幾套數據庫，壓力大的用IBM p950和EMC DMX高端存儲，壓力小一點的用IBM p550和EMC CX中端存儲，2007年到2009年在每年業務至少翻番，系統壓力翻幾番的情況下，土鱉的淘寶技術人員，用土辦法見招拆招，算是順利度過了這段艱難時期，也奠定了後續的技術方向。這段時期當然也有很多插曲，包括各種宕機，甚至是機房兩次斷電等，那又是另外一個故事了。

時間到了2009年，數據庫這麽垂直的拆下去，到最後單個數據庫只放一張用戶表或者一張交易表，用最高端的小型機和最高端的存儲，也快頂不住壓力了，尤其是連接數。前端無狀態的Java應用服務器現在已經能夠隨著業務壓力加機器擴容了，但應用加機器都得要加連接數啊。Oracle是進程模式的，基本上一個連接數需要消耗8～10MB的內存，這樣5000個連接數就需要50GB左右的內存，加上SGA，連接數的天花板近在眼前。

數據庫當時采用的高端小型機＋高端存儲＋Oracle，價格確實是不便宜。垂直拆分已經搞出了十幾套這樣的硬件，再來個水平拆分，DBA團隊做預算的壓力真是山大。所以開始把目光投向了MySQL。當時比較成熟的版本應該還是5.0，2008年底剛剛GA沒多長時間的5.1算是新銳版本。我們開始在一些邊緣系統嘗試，也面向全國開始招MySQL DBA，但其實一個也沒招到，只好從應屆生開始培養。好在服務化垂直拆分做完以後，大量的關聯查詢都在應用服務層通過接口調用來解決，數據庫基本上就只有基於主鍵的增刪改查操作了，基本上也就相當於一個KeyValue存儲在使用。所以說，服務化是數據庫水平拆分很重要的一個前提。

但是，服務化只是一個前提。要做核心數據庫如用戶庫和交易庫的拆分，還必須要解決IOPS的問題。為什麽要用高端存儲？因為IOPS啊。傳統機械硬盤在可接受的10ms響應時間內的IOPS峰值大約只有80～100。當時我們一個交易庫使用的高端存儲配置了480塊硬盤，可以支撐大約4萬～5萬的IOPS，按照一臺PC Server可以插16塊硬盤來計算，需要30臺機器。看起來也不多是吧？但這麽大的動作做完，肯定需要至少能支撐2～3倍的余量才行啊，所以需要一下子拆分到至少64個節點128臺機器，而且很可能兩三年後就要朝著上千臺的規模去了，而這個規模純粹是因為IOPS，CPU卻是大大浪費的。對於當時還只有十幾套Oracle數據庫的DBA團隊來說，維護成本也猶如達摩克利斯之劍啊。

正所謂車到山前必有路。我們在Percona的mysqlperformanceblog.com上了解到了一款名叫FusionIO的PCI-E Flash閃存卡，小小一片印刷電路，竟然擁有超過十萬甚至百萬IOPS的能力，響應時間還能到1ms級別，這種法寶正好也開始進入中國了。於是我們相當激進的開始引入測試，並且一舉上線，反正壓力在身不得不前行，加上有主備復制，還有Notify做Oracle/MySQL異步復制新舊兩套數據庫系統並行的雙保險，就這麽搞成了。

所以說，所謂的“去IOE”，在當時其實有兩個重要的前提條件：

1. 服務化的完成，數據庫變成了簡單的KeyValue存儲模式；

2. PCI-E Flash卡的成熟，解決了IOPS的問題

PCI-E卡是好東西，可是也很貴，當時一片的價格要10萬左右。Flash存儲成熟後，英特爾也跑出來要分一杯羹，推出了傳統IDE接口的SSD硬盤，雖然單個盤的IOPS比PCI-E卡下降了至少一個數量級，但價格也便宜了很多，而且一臺機器上可以插多個盤。所以除了壓力非常大的核心數據庫，其他的數據庫也就可以一股腦兒的從Oracle遷移到了基於SSD的MySQL上。反正遷移和拆分這事兒，一回生二回熟了。

水平拆分的架構升級幫助淘寶沈澱了另外一個神器：TDDL（Taobao Distributed Data Layer）。TDDL除了水平分庫的路由功能，還有一個非常核心的模塊叫動態數據源。因為原來需要在Java應用中顯式的配置每個數據庫的連接參數，每次修改都需要重新打包發布應用。水平拆分以後，數據庫節點變多了，應用的機器也越來越多，這個事情就越來越不好玩。我就和華黎/沈詢商量，能不能把數據庫連接參數搞成動態可配置，這樣DBA幹拆庫/主備切換這樣的小動作時，應用的同學就不用陪著熬夜了。就這樣，這幫靠譜的家夥就搞定了三層的動態數據源。

淘寶這一路的技術架構升級，沈澱出來，其實就三個東西，今天已經在阿裏雲上做為互聯網中間件對外提供服務，這是一個好事情：

1. 企業級分布式應用服務EDAS，就是HSF和阿裏巴巴B2B團隊搞的Dubbo（已經開源）的內部合體版本

2. 消息隊列MQ，就是Kafka的Java版本MetaQ

3. 分布式關系型數據庫服務DRDS，就是內部的TDDL

所以我一直認為，“去IOE”更準確的說法應該是淘寶技術架構的大升級；而雲計算，則是傳統IT架構的一次大升級。這兩者相互之間也可以說是有傳承的，都是在向著擁抱X86開放式體系，向著彈性升縮的方向升級。但“去IOE”這種簡單粗暴的標簽化提法，雖然在宣傳上比較有效，但其實掩蓋了很多的來龍去脈。

在阿裏雲上遇見更好的Oracle（二）