《雙十一談如何從零開始搭建大型機(jī)票交易平臺(tái)》要點(diǎn)：
本文介紹了雙十一談如何從零開始搭建大型機(jī)票交易平臺(tái)，希望對您有用。如果有疑問，可以聯(lián)系我們。

導(dǎo)讀：從無到有構(gòu)建一個(gè)大型交易平臺(tái)對工程師來說是很有挑戰(zhàn)的事情.在構(gòu)建過程中會(huì)碰見各種技術(shù)或者非技術(shù)的問題,作為一個(gè)工程師又該如何處理這些問題,這是所有工程師都需要考慮的問題.知名旅游網(wǎng)站負(fù)責(zé)交易平臺(tái)技術(shù)的小雄哥總結(jié)了自己的親身經(jīng)歷,通過在高可用架構(gòu)群的分享,給出了他自己的答案.

高可用架構(gòu)讀者大家好,先做下簡單的自我介紹,我叫小雄哥,國內(nèi)某大型旅游網(wǎng)站的開發(fā)工程師,主要負(fù)責(zé)的是交易平臺(tái)的技術(shù)開發(fā)和管理.

背景介紹

進(jìn)公司的原因是被同學(xué)和其他高管同事拉過來湊局,成立孵化平臺(tái),當(dāng)時(shí)正好缺少個(gè)技術(shù)負(fù)責(zé)搭平臺(tái),所以合伙人都是有目的性的,這點(diǎn)很重要.

當(dāng)時(shí)的市場,僅有一個(gè)類似的對手,而我們的實(shí)力,沒有技術(shù)平臺(tái),沒有落地的需求,只有對機(jī)票事業(yè)部領(lǐng)導(dǎo)的承諾、模糊的想法IDEA,1個(gè)開發(fā)1個(gè)產(chǎn)品1個(gè)商務(wù).

所以,大家首要目標(biāo)就是：招開發(fā)、測試、商務(wù)、產(chǎn)品,快速落地.自然,我的任務(wù)就是：招人提升戰(zhàn)斗力、學(xué)習(xí)業(yè)務(wù)、驗(yàn)證和實(shí)現(xiàn)idea系統(tǒng)落地.

所以本次分享大部分是基于這三點(diǎn).

開發(fā)組織

開發(fā)組織的情況

公司文化很重要,很重要,很重要.

業(yè)務(wù)負(fù)責(zé)人從內(nèi)部借到異地的開發(fā)：1 個(gè)做過兩年機(jī)票的,1 個(gè)酒店的,有幸得此兩人幫我快速了解公司內(nèi)部的技術(shù)平臺(tái).

之后,跟商務(wù)跑了家合作伙伴的公司,借到了 6 個(gè) .net 的開發(fā),其中 5 個(gè)人轉(zhuǎn)做 Java,1 個(gè)人轉(zhuǎn)去做產(chǎn)品,期間的借人過往就不描述了,很坎坷,非常感謝當(dāng)時(shí)各位,大老遠(yuǎn)過來參與封閉開發(fā).基本上大家都擰在了一起,這樣開發(fā)資源不足的問題大致解決了,當(dāng)然成本管理是公司領(lǐng)導(dǎo)考慮,這里就不細(xì)說明.

但是新問題來了,產(chǎn)品只有想法沒出 PRD,開發(fā)這邊：語言不一致,水平不一(產(chǎn)品和開發(fā)不具備 B 端經(jīng)驗(yàn))、技術(shù)團(tuán)隊(duì)落戶深圳,人員穩(wěn)定性隱患較大,人員投入困難,溝通不暢,向心力不足.

優(yōu)先解決能力提升的問題,結(jié)合上圖是解決的辦法,是個(gè)循環(huán)漸進(jìn)的過程,要堅(jiān)持.

既然要做到堅(jiān)持,就需要有約束有限制,以下是大家的約定.

以上內(nèi)容是組織管理的大部分內(nèi)容.

下邊就是時(shí)間管理部分：

結(jié)合產(chǎn)品的想法,列出所有模塊的泳道圖、流程圖,核對每一個(gè)狀態(tài)機(jī)和操作的前驅(qū)后即.

進(jìn)度匯報(bào)方面,采用的是每日晨會(huì)白板,每日早晚進(jìn)度反饋群內(nèi)分享,顏色標(biāo)記進(jìn)度等等方法.

對于預(yù)估錯(cuò)誤和延期的處理方案是：小黑屋加班.回憶起來,上線前的幾個(gè)月是沒有周末的……

需求分析階段

由于前期產(chǎn)品能力不足、給出好幾十頁的 PRD 和頁面原型非常不好理解的前提下,幫助產(chǎn)品梳理需求,給出良好、干凈的建議,也成功前期需求分解的重要工作,因?yàn)橐_立開發(fā)方向,結(jié)果變成了現(xiàn)在的較為合理的樣子.

PRD 和原型轉(zhuǎn)換成流程圖：

轉(zhuǎn)換成：

等等類似各圖.模塊流程的原型完了,進(jìn)入狀態(tài)機(jī)：

狀態(tài)機(jī)是采用無向圖的數(shù)據(jù)結(jié)構(gòu),根據(jù)交易流和狀態(tài)流向的模擬,給予產(chǎn)品 case 或形態(tài)有個(gè)很好的回歸.

還有我們開發(fā)最熟悉的,時(shí)序圖輸出：

抱著這樣探索摸透的態(tài)度,我們開發(fā)梳理了這些,是為了保證模塊負(fù)責(zé)人都能事前知道流程和技術(shù)功能.根據(jù)這樣具體的PRD,大家均能很大的明白業(yè)務(wù)到底要做什么,流程是什么.

當(dāng)然弄了這么多,缺點(diǎn)也很明顯,就是時(shí)間長了,重構(gòu)多了,這些圖和表需要人維護(hù).

推薦大家選擇時(shí)序圖,首先描述對象之間發(fā)送消息的時(shí)間順序顯示多個(gè)對象之間的動(dòng)態(tài)協(xié)作.它可以表示用例的行為順序,當(dāng)執(zhí)行一個(gè)用例行為時(shí),時(shí)序圖中的每條消息對應(yīng)了一個(gè)類操作或狀態(tài)機(jī)中引起轉(zhuǎn)換的觸發(fā)事件.

下面介紹,各大核心模塊流圖：

我用字母和數(shù)字的組合,代表了當(dāng)時(shí)上線的路徑.

約票,最簡單的模塊,為什么要拿出來,因?yàn)楫?dāng)時(shí)我們的思路是跟滴滴打車學(xué)的,有采購叫單,供應(yīng)來應(yīng).

類似各模塊的流圖都要在前期需求分析階段出來,且模塊負(fù)責(zé)人和對應(yīng)開發(fā)都要熟知.

下面介紹,數(shù)據(jù)建模：

有了這樣結(jié)構(gòu)的好處：

• 結(jié)合狀態(tài)機(jī)和操作,再根據(jù)交易流和數(shù)據(jù)流向的模擬,給予產(chǎn)品形態(tài)更好的回歸,確保業(yè)務(wù)上無阻塞問題.
• 各模塊互不干涉,從事務(wù)上給予更好的保證.

從數(shù)據(jù)量上,要有足夠的分析,預(yù)估上線的一個(gè)月內(nèi),日票量 1500 左右 即：15 * 7875 = 118125 條(數(shù)據(jù)庫記錄).

產(chǎn)生一條主單訂單時(shí),會(huì)增加：1 條訂單記錄,5 條工單,20 條工單回復(fù),10 條狀態(tài)變更,5 條支付和解凍記錄,4 條航班,9 條乘機(jī)人,約 45 條左右..

與主訂單同比,子單約 40 條左右.每百主訂單會(huì)產(chǎn)生 5% 售后子單,即百條訂單 = 105 * 45 = 4725 (數(shù)據(jù)庫記錄) .假定按出票率 60% 計(jì)算的話,百張票記錄 = 4725 / 0.6 = 7875,可保證 5 – 6 年的 150% 增長.

根據(jù)這個(gè)實(shí)際的業(yè)務(wù)量級考慮,所以我只做了分庫沒有分表.

以上的內(nèi)容是是需求分析階段,大概兩周左右.

架構(gòu)設(shè)計(jì)階段

到這個(gè)階段的時(shí)候,要分析要做的這個(gè)平臺(tái)的愿景是什么?這里要結(jié)合公司對 B 端平臺(tái)的期望,最后重點(diǎn)是穩(wěn)定、可靠、安全、靈活.

由于發(fā)現(xiàn)有個(gè)老的運(yùn)行比較久的政策管理和搜索模塊可以“借”來重構(gòu),那么只需要考慮的其他幾個(gè)模塊了,售前、售后、工單、運(yùn)營平臺(tái)等.

找其他技術(shù)同學(xué)討論幾輪后,結(jié)合平臺(tái)期望,也最終確定了系統(tǒng)結(jié)構(gòu)是怎樣的.

因業(yè)務(wù)情況稍微解釋下,上邊的深藍(lán)色是入口和出口,左邊的黑色是公共技術(shù),采用 dubbo 的 RPC(此處有坑),DAO 用的是 MyBatis,綠色部分代表其他部門提供支持.

這個(gè)系統(tǒng)結(jié)構(gòu),也是結(jié)合平臺(tái)期望來的,這個(gè)完了就要考慮工程結(jié)構(gòu)了.

從上到下,從左到右.采用復(fù)用的設(shè)計(jì)模式,個(gè)人認(rèn)為較為合理的工程結(jié)構(gòu),也是目前我們工程制定的迭代任務(wù)制定的.

整體上完事了,下面到各模塊的了,由于是業(yè)務(wù)獨(dú)特性,這里插播下機(jī)票內(nèi)部的業(yè)務(wù)流程.

先有供應(yīng)商錄入航線和價(jià)格的東西,業(yè)內(nèi)叫政策,錄入完了,采購商就能搜索到,選擇適合的下單,支付和出票,這是售前,采購商拿到供應(yīng)商提供的票號就可以讓 C 端用戶去做飛機(jī)了.

售后,就是退改簽、工單等,也是各大平臺(tái)的收入來源,與本次分享無關(guān),不細(xì)說了.

機(jī)票搜索

下面介紹,搜索報(bào)價(jià)結(jié)構(gòu)類圖：

簡單描述上圖,采購商查詢機(jī)票價(jià)格的條件是：出發(fā)目的地、時(shí)間之類的,業(yè)內(nèi)叫 av.這部分信息通過 OMS 同步模塊將從代理商錄入的政策中航班等信息作為索引放到 Solr 里,匹配到了能取到政策 ID,再去 Redis 里取政策詳情,找到反饋給采購商,當(dāng)然其中有一些處理航司交互的東西.

生單系統(tǒng)

下面介紹,生單結(jié)構(gòu)類圖：

簡單描述下,搜索出報(bào)價(jià),中間有個(gè)確認(rèn)過程叫核價(jià),就是最后看看是不是機(jī)票會(huì)變價(jià),有變價(jià)是否接受.之后就進(jìn)入生單.不同平臺(tái)的理解不一樣,有的平臺(tái)把支付之后叫生單.

由于不同航司,不同 GDS 標(biāo)準(zhǔn),不同處理路徑,所以生單流程是均不一樣的.所以設(shè)計(jì)模式采用的是鏈?zhǔn)?這個(gè)比較成熟,當(dāng)有新的流程,只需要在綠色加上對應(yīng)的 handler,寫邏輯添加到 BizHandleBuilder 里,做好規(guī)則即可,結(jié)合圖二進(jìn)行理解.

支付系統(tǒng)

下面介紹,另外一個(gè)核心模塊,支付類圖：

簡單描述下,生單之后,采購和供應(yīng)都覺得 ok,采購商要支付.

B 端系統(tǒng)一般要支持這么幾個(gè)功能：支持二次或改簽支付、靈活處理各種錯(cuò)誤、支持中斷支付、繼續(xù)支付機(jī)制、明細(xì)查看和導(dǎo)出、管理員權(quán)限支付、用戶級別鎖定、支持作廢正在支付中單子、營收和立減、財(cái)付通支付寶三方等.

要消化這些功能,所以要設(shè)計(jì)出：便于擴(kuò)展,繼承指令參數(shù)拼接類,添加支付類型等抽象思想：

我這邊設(shè)計(jì),采用藍(lán)色模塊表示將支付流程統(tǒng)一處理,綠色代表指令執(zhí)行拼接流程統(tǒng)一處理,橘黃色表示擴(kuò)展部分,一般都是邏輯核心的地方.

比如,如果訂單要支持三次支付,那么就可以多了一個(gè) OrderThirdPayService.比如有個(gè)支付接口要適配,就要做個(gè)新的 XXX 實(shí)現(xiàn)指令拼接流程管理就好.

這里給公司的支付中心點(diǎn)個(gè)贊,無論多晚,他們都有人都在陪著聯(lián)調(diào).

以上列舉了兩、三個(gè)核心模塊介紹,其他核心模塊都類似設(shè)計(jì).

模塊設(shè)計(jì)的原則

簡約的理解,模塊設(shè)計(jì)是要求這樣的,遵循依賴倒置單一原則.

至少三層結(jié)構(gòu),遵循依賴倒置,且實(shí)現(xiàn) service 都有各種方法提供,這也是給合作方很好的支持,想有各種方法都有.缺點(diǎn)是代碼冗余.

異步化設(shè)計(jì)

下面就是邊邊角角的了,異步化的設(shè)計(jì)：

自己寫的,很基礎(chǔ)的,原因是為了都能看懂,也方便擴(kuò)展,仍然是橘黃色的部分,隨便一個(gè)開發(fā)擴(kuò)展使用都可以.當(dāng)然是業(yè)務(wù)不出錯(cuò),對于難以保證數(shù)據(jù)的準(zhǔn)確性,安全性不高,上下文 context switch 開銷,占用本地還更多的資源等缺點(diǎn),不 care.只要可以并列處理一些工作,從而減少一些不必要的等待時(shí)間,從能靈活滿足業(yè)務(wù)需要就行.

關(guān)于其他的架構(gòu)設(shè)計(jì),統(tǒng)一處理要求：

簡單描述下說明下,因?yàn)槭堑谝话?而且人員技術(shù)水平不太高的情況,所以,很多處理都是秉著簡易、好懂出發(fā)的.

• 接口設(shè)計(jì)：這里也考慮了復(fù)用機(jī)制,比如：訂單搜索和訂單導(dǎo)出,都是根據(jù)條件查詢給出結(jié)果的.利用了OOP根據(jù)不同訂單類型,來走不同路徑.
• 依賴倒置：接口高層次的模塊不依賴于低層次的模塊實(shí)現(xiàn).
• 事務(wù)回滾： Service和Dao之間加一層 daohandle @Transactional xxxDaoHandle,這里很有學(xué)問,由于表設(shè)計(jì)的很散,所以在這里遇到很多問題.
• 文件存儲(chǔ)處理：比較好用的是因?yàn)槁窂健⑽募A可配,聽說 FastHFS 也不錯(cuò),也打算后續(xù)對比下.
• 本地緩存：采用 CacheBuilder 限制隊(duì)列,減低 Redis 壓力,響應(yīng)時(shí)間優(yōu)于 Redis.有過期時(shí)間.

按照這個(gè)架構(gòu)設(shè)計(jì),我們實(shí)現(xiàn)大概 2 個(gè)月左右的時(shí)間.

發(fā)布之后

按照以上的需求和架構(gòu)發(fā)布后,基本上較穩(wěn)定成長,期間也有外界的沖擊著,比如：孵化項(xiàng)目不被看好,中途人員流失,市場變動(dòng)需要調(diào)整優(yōu)先級,公司整合等等問題,總之,你是負(fù)責(zé)人,問題抗住并要處理它.

希望這份分享能對大家有所幫助,如有問題可以在本文留言,也可以加講師微信 cpp_wazi?繼續(xù)交流.

文章出處：高可用架構(gòu)(訂閱號ID：ArchNotes)

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4393.html