技術文章 / 社交設計

【心得】淘寶網如何利用 Java 雲端平台技術支撐單日億級訂單量

閲讀次數：29713 發表時間：2013/08/29

今年的 Java Developer Day 最吸引我的題目莫過於「淘寶網如何利用 Java 雲端平台技術支撐單日億級訂單量」。一來是工作上有使用許多雲端服務來解決大量運算需求的問題，另一方面是淘寶確實有面對單億級訂單的戰績。聽完演講的整體感覺：這不是一場深入技術的場次，但帶給我們一些思考方向。王文彬博士分享將內容定位是在架構的層次，過程中有提到許多淘寶專有的架構，而這份講題主要的核心平台為聚石塔。

當初在聆聽演說時不太完全明白，到底是用了什麼 Java 技術達成單日億級訂單，浮在腦中的 keyword 剩下這些

機器都是無狀態的（或一些不重要的中間狀態），機器 crash 了就只要重開就好。
現在仍剩下小部分的東西沒放上雲平台，也儘量避免依賴這些小東西，不然會產生雪崩效應。
我們去掉了 IOE，IBM、Oracle、EMC （雖然今天是 Oracle 的場子），走向 LAMP。
CAP 的最終一致性不同功能的容許成度不同，不需要每一項都要求在極短的時間內一致。

對於沒有去聽這個場子，以及現在在文章的人也許會覺得這些片段是什麼鬼？套句電演台詞：「阿鬼，你還是說中文吧」這場講演若不是為了 Java Developer Day 的需求，那可以去掉 Java 這個關鍵字。正名為：「淘寶：可擴展架構的最佳實踐與經驗分享」。

基礎建設

在 Q&A 的時間提到，淘寶最終捨棄了 Oracle DB（由於現場人員沒有遞麥克風，完全聽不到問了什麼問題。）這其實是一件有趣的事，隨著越來越多人採用雲端方案，動態擴展機器達成短時間內獲得更大的運算力，變成一種可行的架構選項。而商業軟體目前的 business model，似乎還無法那麼動態地配合動態增減的想法。即使在淘寶的使用上，它可能不會短時間需要增加許多資料庫，但有看過 Oracle 參考價目表的人，應該都知道那不是一筆小數目。隨著商業規模的成長，就會發現一件事，企業本身的 business model，被特定商用軟體的 business model 掐住了脖子。

除了錢得少賺一點，在架構上有什麼影響呢？就如同先前在 PyCon TW 2013 心得聽 Building a Render Cloud 時注意到的問題，由於主要的核心是使用 Adobe After Effects，無論工作有多少，在合法的情況下，只能夠使用與 License 相等數量的 VM，整體的擴展性受限於基礎建設的選擇。

淘寶在早期使用 Oracle DB、IBM 伺服器、EMC 儲存體，最終會應付不了用量的成長，於是在幾年前就開始轉向 LAMP 架構。這些決定由現在往回看，確實相當合理，並且持續在政策上要求用戶與第三方軟體供應商配合（在聚石塔的文件有提到，符合入塔要求的要點中就是必需使用雲平台上的 RDS，它即為 MySQL 資料庫）。

支持可擴展性的戰略

在適當的基礎建設之上，可擴展性的自然限制（成本與法律問題）便能減少許多。這場演講的焦點在於用雲平台技術解決問題，這裡的平台我想主要的焦點在聚石塔，它不同於阿里云是一般用途的雲端供應商，而是在為了淘寶系戰略架構建出來的「沙箱」，你也可以想成它是「特區」或「境外轉運中心」之類的。

加入聚石塔才能夠使用一些商家專用的特定 API，使用淘寶系的資源。它有一些規範，並且需要通過人工審核才能符合「入塔」標準，到這一步為止是由政策面所推動的可擴展性支援（聽這樣描述，是不是跟上架 Apple App 有點像？）。對於那些可能有爆量訂單的賣家，都必需「入塔」進入雲平台，其中的一個標準是必需使用 RDS 資料庫（MySQL），不可是以建在 local VM 上的 MySQL，它牌的資料庫也必需轉成 MySQL，例如 FAQ 上列的不支援的 Oracle 也是如此。

由聚石塔的相關文件看起來，它不僅是一個雲平台。由設計的意圖與申請的審核規範，淘寶打的主意應該是「安全」與「分散資料庫流量」（當然賺平台的錢是必要的，同樣能看到一些討論這樣的平台對於資本小的商家不利的新聞）。用受管理的 VM 與限制的區域提供加值 API 的存取控制，對於安全管理的實現相對起來簡單而聰明，即使真的出問題了，也能知道是來自那一個商家租用的機器有異常行為。

另外，其中一項服務是數據推送服務「天猫联合淘宝、万网、阿里云一起推出了数据同步服务，通过使用聚石塔中的云数据库，实现将淘宝的订单、商品、退款等主要数据直接实时、准确地推送给用户，让用户再也不用为这些数据而烦恼！」讓平台使用者透過管理選單，選擇需要同步哪些資料。這是個巧妙的策略，商家確實需要訂單資料，但若讓千百萬的商家都直接連到主資料庫那麼再大的資料庫叢集也無法負荷，相對的在服務類型上替商家主動推送他所需要的資料那就能將個別資料存取的需求分散。

創業伙伴

在演講中常提到平台上的軟體都是第三方開發的，意謂著淘寶只負責提供 API 與雲平台相關設施的租用。商家可以自製他們需要的功能，或是有第三方軟體供應商購買或訂製特殊需求來支援他們的商業活動。這是個值得參考的模式，由於賣家的品項差異可能很大，需要的功能應該是難以想出一個能滿足所有人的需求的管理介面。供應 API 給賣家使用，讓賣家做自己想做的管理軟體。這與只提供統一的後台管理界面，再一直被賣家投訴界面很難用是完全不同的道路。

這樣賣家所得到的，不再只是單方面接受統一的使用方法，能做出符合自己公司需求的系統，例如整合公司內的資訊系統。獲得 API 使用權，在某種意義上淘寶與開店的賣家才能稱為創業伙伴，而非房東與房客的關係。

這是場什麼演講

若要用一些簡單的句子來總結它，我會這麼說：架構演進是一個捨棄弱點的過程，必需先明白目前架構的弱點，並著手改進它。由決策面、政策面、技術面都需協調一致，在擁有持續進步的執行力之下，沒有跨越不了的困境。

嚴格來說，它並不是場充滿技術的場子，即使提到的技術也不會是相當難懂的方法。因為技術細節並不是這演講主要的重點，何況理性的開發者們，也從不會期待有一套單一的方法論能解決所有問題。透過王文彬博士的講演，再次提醒了自己，思考架構的問題，即為取捨的問題。若要自問是否羨慕嗎？答案是否定的，他們只是在做著平實的架構工作與適當的實踐。對於架構性質的演講，這不會是最後一場，但是否能對自身工作有所幫助，那還得看自己公司對於面對問題的態度與可能投入的資源而定，不過，我相信這已經激起了許多開發者的「架構魂」。