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