StubHub架構揭秘：世界上最大的票務市場到底有多復雜？
譯文【51CTO快譯】StubHub這個令人關注的架構之所以值得剖析，是因為作為票務做市商，它從事的行業不同于我們通常所考慮的行業。
StubHub規模大得驚人，每年以20%的速度發展，每小時提供80萬個復雜頁面，每年出售的各種票多達500萬張，每小時處理200萬次API（應用編程接口）調用。
而票務行業來得異常復雜。StubHub的流量很復雜。其流量具有突發性，主要圍繞不可預測的比賽結果、文體活動、比賽時間表和賽季。這行當涉及許多的錢，涉及許多不同的演藝人員，涉及許多復雜的業務流程。而StubHub有幾個互為補充但全然不同的業務部分：它有一個廣告服務器組件（為ESPN等網站提供廣告）、豐富的交互式用戶界面以及實時票務市場組件。
我最感興趣的是，StubHub怎樣把曾經高度人性化的物理領域（各種票、銷售點系統、聯邦快遞送貨、買賣雙方和錢財）搬入到數字領域。它實現這一切的手段是，與美國職業棒球大聯盟等組織進行全面深入的電子集成，并借助生命周期總線（Lifecycle Bus）讓復雜的業務流程與應用領域隔離開來。
由于StubHub既要向前發展，又要應對早期發布擴大業務的功能特性是優先項目時構建的遺留系統，這個令人關注的問題顯得更加困難了。下面看看StubHub是如何成功做到的。
本文來源
■StubHub架構主管Charlie Fineman在QCon大會上的演講：《StubHub：為擴展性和創新而設計，打造世界上最大的票務市場》
經營模式
■StubHub好比是票務市場的電子港灣（eBay）。為買票賣票雙方提供了一個市場。它與世界上最大的票務公司特瑪捷公司（Ticketmaster）不一樣。
■第三方保管模式用來為買賣雙方提供信任和安全機制。信用卡在StubHub存檔起來，只有訂單確認為票已收到后，買方才從信用卡上轉賬。
■門票不是普通商品。比如說，買方想要特定的門票，而不是露天看臺座椅。門票數量有限，門票也不可以延期交貨。面對不斷變化的市場形勢，賣方不斷更新價格和數量。這是個非常活躍的市場。
統計數字
■每年500萬筆訂單。
■200萬張待售門票。
■門票涉及大約4500場文體活動。美國職業棒球大聯盟季后賽和美國橄欖球超級杯大賽是銷售最旺的時期。
■銷售幅度每年增長20%。
■每小時提供60萬至80萬個復雜頁面。季后賽期間，猛增到每小時100萬個頁面。
■在美國觀看比賽的黃金時段（每晚10點至12點）的短暫時間期間，流量的突發性非常強。比如說，季后賽結束后，會出現人們瘋狂購買下一個賽季門票的情況。
■來自附屬組織的API調用每小時多達200萬次。
■24至36名工程師。
■這是高度人性化的行業。過去，支持電話與交易比是1：1，但現在情況好多了。工作人員最主要的工作是客戶服務和后臺業務運營支持。
平臺
■Java
■Cold Fusion（遺留平臺）
■ActiveMQ
■SEDA（分階段事件驅動架構）
■Lucene/Solr
■Jboss
■Memcache
■Infiniband—連接至存儲區域網絡（SAN）的高速網絡
■XSL
■甲骨文的高級隊列（Advanced Queuing）
■TeamWorks—IBM工作流程構建器
■Splunk
■Apache HttpClient
■Log4j（使用消息格式）
■Tapestry
架構
■購買門票有三個來源：互聯網、銷售點系統和批量上傳。批量上傳允許多張門票上傳到系統。
■Manager層在Ticket數據庫上提供了一種業務對象抽象機制。它負責調控與訂票系統的所有聯系。
■訂票系統因買賣雙方的活動和文體活動天生具有突發性的流量而擁堵。
■活躍市場會使得使用移動設備的客戶無法及時了解系統現狀，所以買方應對的是舊數據。
■兩個數據泵（data pump）將數據從Tickets數據庫抽取到內外系統：My Account、Find和Public Feed。My Account是用戶賬戶的接口。Find是一項搜索功能。Public Feeds則支持ESPN和電子港灣等網站。
■Internal Feed：含有用于儀表板的敏感信息，比如賬戶信息，包括賣方是誰、銷售情況如何、銷售速度和熱圖（heat map）等。它還提供主頁中基于敏感市場數據的部分，比如什么熱銷，這些是StubHub不想拿來與公眾共享的。
■External Feed（LCS）—通過該Feed為ESPN等廣告商提供數據來源。廣告由IP地址實現地理映射。
■LCS（列表目錄服務）
■這里先說聲抱怨，幻燈片有點錯誤，很難把演講者與演講文稿對應起來。所有錯誤都怪我。
■觸發器用來確保修改表格及時更新；數據庫一出現變更，這些變更內容就會出現在表格中。
■變更數據捕獲（Change Data Capture）作業不斷查詢變更，并把消息注入到ActiveMQ中介。這是路由傳送的第一道，含有較小的有效載荷：對象編號、對象類型和變更日期。
■變更數據傳送到Master，這是數據中心之間進行復制的基本機制。輔助數據中心訂閱這些主題，這就是數據中心之間復制數據的方式。
■一旦在Master中，數據被注入到SEDA隊列，進行處理（稍后會有詳細介紹）。
■并不使用Manager，因為存在不使用Manager、直接進入到數據庫的許多遺留系統，所以數據庫是分發變更內容的常見點。
■大部分廣告是Flash廣告，但有些使用HTML渲染。
■購票體驗得到LCS的支持，比如從體育館的交互圖形中選擇門票。Solr使得添加諸如此類的新功能特性變得很容易。
■SEDA（分階段事件驅動架構）在Master中的使用
■SEDA是減輕負擔的一種方法。從資源管理的角度來看，它對StubHub來說行之有效。其想法是，把工作負載分解成足夠小的部分，那樣這些細分后的工作負載不會竊取其他用戶的線程。工作負載分階段建模，每個階段都有自己的線程池，這相當于有效控制了工作負載。
■Master收到小的更新內容后，弄清楚如何構建進入到memcache的內容，以便最終傳送到Solr。
■消息使用一種協議緩沖器格式緩存在memcached中。
■消息發送到第二個中介，該中介將消息向外分發到邊緣，即Lucene/Solr。
■消息使用者收到中介發來的消息
■從數據庫裝入實體。
■確定更新內容有沒有帶來任何級聯效應。由于Solr及其他NoSQL數據庫并不進行連接（join）操作，那樣比如樂隊名稱出現了變更，該變更內容必須告知所有事件。
■實體序列化。把實體存儲在memcache中。
■將消息發送到第二個ActiveMQ中介，由它將消息傳送到邊緣，即Solr。
■中介由負責路由傳送的另一個進程進行偵聽。這番操作一度在Jboss中進行，但是Jboss會不堪重負，而StubHub遇到了饑餓矛盾問題，于是它把偵聽工作移到了Jboss外面。該偵聽器成了系統中一個實用的閥門，起到操作管理。如果StubHub需要換掉新的Solr索引，引入一種新的數據庫架構（schema），就可以關掉這個閥門，讓消息在消息中介備份起來，再次打開閥門，消息就會再次開始流入。遇到Solr故障后恢復、復制索引和更新數據庫架構時，閥門對StubHub的操作穩定性起到了巨大影響。
■所有這些都是阻塞操作，所以使用線程池可以防止同時出現大量數據庫連接。
■Solr
■Solr提供了一項很好的文檔存儲和自然語言文本查詢功能。
■所有搜索都建立在Solr上，包括分面搜索（faceting）。
■運行速度快。查詢在10毫秒或更短時間內返回結果。StubHub使用與SAN相連的Infiniband網絡，發現自己不需要把數據緩存到內存中，而是可以借助這個高速網絡，以足夠快的速度從SAN提供數據。
■功能強。靈活的查詢語言、全文本搜索和地理空間搜索。
■支持許多輸出格式：XML、Atom、RSS、CSV和Json等。因而更容易與各種客戶端進行集成。
■高頻率寫入方面不是很好。在高頻率寫入環境下，復制似乎沒有很好地集成。你看到成千上萬的變更時，進行同步操作行不通。你得到的其實是過期數據。所以，StubHub只好擴建了自己的復制機制。
■平面數據結構。仍然幾乎是面向行。StubHub希望能夠支持結構更復雜的文檔。
■DCL—雙擊瀏覽
■URL映射到編號上：性別編號、地理編號和顯示類型編號。
■類別編號和地理編號由DCL（就是XSL）使用，為LCS創建查詢。然后，以一般方式顯示返回的數據。所以，所有足球隊都可能有為它們創建的類似頁面，有著一模一樣的結構，使用URL映射、XSL和LCS。
■大大提升生產力，而且添加新的功能特性變得容易多了。頁面中的每個塊都是通過內容管理系統（CMS）來管理的一種資產。它們是大段的XSL，對照從LCS檢索的上下文文檔來進行顯示。
■有了RenderChunkByName調用，很容易在Facebook等其他服務網站上顯示文體活動。
■這一切都在后端進行，旨在實現搜索引擎優化（SEO）。由于搜索引擎可以檢索Ajax，StubHub不需要進行這番操作。
■對gif文件和樣式表等進行邊緣緩存（edge caching），但是數據緩存在服務器上。
■減少每筆交易的客戶交互次數：
■客戶交互對StubHub的經營收入來說是最大的開銷。萬一出現什么問題，買賣雙方就要花大量的精力來解決問題。
■增加客戶自助服務。客戶（買賣雙方）想知道何時拿到錢和票。MyAccount屏幕讓客戶不用借助客戶服務，就可以查看訂單進度。
■把API展示在賣方面前，那樣他們就能把這些功能特性集成到自己的系統中。
■IVR—集成語音識別（IVR）系統支持客戶為查詢賬戶狀態而打來的電話。
■現金流量對商家來說很重要，所以StubHub致力于更快地完成支付。
■與美國職業棒球大聯盟進行電子集成，那樣StubHub就能在賣方實際拿到門票之前，將門票直接從賣方交給買方。優點包括：立即送票、客戶滿意度大幅提高、消除了故障點。
■生命周期總線
■用來防止在應用程序中硬連線復雜的工作流程。結賬應用程序不想非得為下游的所有不同業務流程而操心。你想操心的只是經驗驗證的信用卡和訂單，不是像訂單履行和電子郵件這些東西。
■在處理遺留問題和管理網站出現的變更時很有用。
■存在所有主要生命周期事件的主題。軟件代理偵聽甲骨文的隊列，了解主題。訂單下達后，它進入到未經核實的狀態。偵聽器偵聽到“未經核實的”主題后，發電子郵件給賣方，訪問網站、核實訂單。當賣方核實訂單后，代理就會從買方的第三方托管賬戶收到款項，然后發郵件給買方，表示賣方已核實、何處拿票。門票確認無誤后，款項付給賣方。
■所有這些邏輯與網站面向最終用戶的部分脫離開來。這些都是后臺引擎。
■TeamWorks為這些流程建模，查找薄弱環節，監控流程，核實服務級別協議 （SLA），以及觸發操作。并幫助更好地優化后端業務流程。盡管StubHub每年的增長率達到20%，但是它不想操作團隊的規模每年同比壯大20%。
■聯邦快遞是原始的訂單履行模式。后來添加了電子訂單履行。業務流程如下：未經核實->自動核實；經過核實->條形碼重新發和分發PDF文檔；訂單履行。你只要編寫遵循同一訂單生命周期的軟件代理，即可實施新的履行模式。這個邏輯并不在應用程序中，而是在代理中，它是可以單獨部署和測試的單元。
■避免欺詐。使用與訂單履行一樣的生命周期模式，不過增加了兩個新的狀態：已購買和已批準。StubHub不必進行任何變得，即可添加避免欺詐的功能。StubHub只要更改狀態機就行。軟件代理決定把它移到已批準狀態或未批準狀態。
■銷售點系統集成
■使用兩個階段的提交：在外部系統上預訂門票，在StubHub中把它標為已認購，在外部系統上提交購買。
■考慮擴大這項功能的應用范圍，那樣作為交易的一部分，其他系統也能購買門票。門票與旅行或酒店客房預訂捆綁起來。
■Splunk和Dye
■這是StubHub成效最顯著的項目之一。在問題調試和排除方面節省了大量時間。
■Dye—工件注入到每個請求的HTTP頭中。
■這些使用Log4j記入日志。
■使用Splunk；如果訂單有問題，你可以使用Dye標記（Dye marker）查看日志里面的一行行內容，往回查看屬于請求一部分的所有調用，包括對LCS等其他服務的二次調用。很容易追溯活動的根源。
■StubHub很喜歡Splunk。它就像長行的文檔存儲區。把Dye標記和訂單編號放入到日志行，比如一系列鍵值對（key-value pair），Splunk就會讓你很容易查看日志。StubHub的儀表板用Splunk編寫而成，可顯示每分鐘交易和每分鐘交易失敗次數等統計數字。你可以隨意對數據進行交叉分析。
■使用消息格式的Log4j，那樣它不會進行動態字符串創建。
汲取的經驗教訓
■可擴展性就是專門化。每一個問題空間（problem space）都有其獨特的特點；任何系統都必須是為了解決這個特定問題而構建的。StubHub受制于對安全購票體驗的需要、票務市場具有的獨特性、突發流量和事件的變幻無常。其系統必須體現這些要求。
■一開始就使用抽象層。否則，你就只好支持遺留客戶端，早超出了你的容許范圍也得支持。
■在生產環境中進行比較。實施多個解決方案，在生產環境中進行一番比較，確定哪個版本效果更好。StubHub在生產環境中曾測試了兩種不同的數據泵版本，看看哪一個更合適。你不希望到頭來支持多套基礎設施。
■把工作移到Jboss外面。數量眾多的請求可能會引起Jboss處于饑餓狀態，于是StubHub把工作移到了Jboss外面。
■為dye賦予因果鏈。提交請求，那樣可以跟蹤請求在整個堆棧中的情況。能夠跨整個堆棧調試問題是一大優點。
■優化業務流程。系統之間實現電子集成。通過在買方、賣方和職業棒球大聯盟之間充當協調者，StubHub得以提高客戶滿意度，消除交易中大量可能存在的故障點。StubHub買下了一個流行的轉售點計劃，那樣它就能與之集成起來。
■建立在自己的API上。StubHub在花大量的時間，努力在自己的API上構建自己的應用程序，那樣它就能為用戶和合作伙伴更有效地管理購票體驗。
■一般化地定義資產。定義資產以便資產可以在任何上下文中顯示，這樣便于制作不同格式的頁面，在其他網站上顯示文體活動。
■從投資回報的角度，最大限度地提高開發效率。尋求提高開發人員投資回報的項目。使用Solr對StubHub來說是一大成功秘訣。它易于使用、運行速度快，又非常實用，能夠直接滿足許多類型查詢的需要。
■SEDA適用于阻塞讀取。StubHub的許多系統基于阻塞讀?。╞locking reads），所以SEDA很適合這種使用場合。線程池防止過量占用它所要使用的資源。
■客戶端顯示。對于很酷的交互式地圖，如體育館地圖，客戶端上處理所有的用戶界面交互，可以為服務器減輕許多負擔。即使對比較大的文體活動（待售門票達1萬至2萬張）來說，下載整個列表也是比較好的解決辦法。
■選擇簡潔的框架而不是笨重的框架。笨重的框架容易使用，但也容易濫用。隱藏復雜性讓你很快對自己的網站失去控制，比如基于Hibernate的框架和Component的框架。驗證和業務邏輯可能會滲入到表示層。要做出謹慎的決定。要明白你在解決什么樣的遺留問題。
■糟糕的經歷其實是最好的培訓機會。說到教你如何做好事情，沒有比失敗更理想的東西了。開辦StubHub的一幫人當初通過盡快推出功能特性來發展業務，但是這留下了遺留系統。管理遺留系統的關鍵是，管理依賴關系。使用基于代理的生命周期總線式解決方案幫助StubHub了解了遺留系統上的依賴關系。
■使用工作流程把狀態機與應用程序脫離開來。不要把復雜的流程嵌入到應用程序邏輯中。把邏輯放在應用程序的外面，那樣業務流程能夠以更靈活的方式結合起來。這使得系統在將來極具靈活性和適應性。
■避免抽取、轉換和加載（ETL）。ETL帶來了你寧愿不想處理的許多依賴關系。它是個風險因素。當你試圖搞清楚某次變更會不會破壞你在經濟上依賴的系統時，遺留數據模型其實會不斷消耗資源。
■不要疏忽了配置管理（CM）及部署?，F在對開發人員來說，這是目前最浪費時間的方面。這讓人痛苦不堪。現在就要投入到你的CM和部署系統。
■致力于持續改進。持續改進不會自然到來，需要你付出心血。對項目進行事后分析。確保問題不會再次出現。貴公司在發展時，這個系統可能無法擴展?，F在應該做出正確的決策，否則將來要花三五倍的精力來解決問題。
■把操作閥門做入到系統中。比如說，如果你需要換掉一種新的數據庫架構，就要有一個閥門，那樣你就能關閉事件、再次重啟事件。
原文鏈接：
http://highscalability.com/blog/
