建站
咨詢
售后
建站咨詢
新聞中心
是微服務(wù)重構(gòu)支付系統(tǒng)的系列文章。 之前的文章請參考：
公司主營業(yè)務(wù)：做網(wǎng)站、成都做網(wǎng)站、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出梅列免費(fèi)做網(wǎng)站回饋大家。
- 為什么要重構(gòu)到微服務(wù)
-
重構(gòu)中的外部和內(nèi)部準(zhǔn)備工作
在支付系統(tǒng)改進(jìn)中，我們對原有系統(tǒng)做了整體的評估，選擇支付網(wǎng)關(guān)作為入手點(diǎn)來進(jìn)行微服務(wù)架構(gòu)的改進(jìn)。這里詳細(xì)介紹我們針對該模塊的改進(jìn)過程，供參考。
原有系統(tǒng)情況
早期啟動(dòng)的時(shí)候，對接的支付渠道不多，所有支付渠道和支付網(wǎng)關(guān)都實(shí)現(xiàn)在一個(gè)項(xiàng)目中，部署在一起。其中支付網(wǎng)關(guān)是整個(gè)項(xiàng)目的核心和入手點(diǎn)。它為各個(gè)業(yè)務(wù)方提供支付全流程的調(diào)用接口，簽約、代扣、支付、驗(yàn)證，都是通過這個(gè)接口來實(shí)現(xiàn)的。整個(gè)系統(tǒng)使用SSH框架，架構(gòu)如下：
業(yè)務(wù)流程如下：
- 當(dāng)接口被調(diào)用時(shí)， 首先執(zhí)行參數(shù)校驗(yàn)，確認(rèn)輸入的參數(shù)的合法性，驗(yàn)證參數(shù)簽名是否正確。確認(rèn)過程包括調(diào)用賬戶、用戶、支付方式、路由等服務(wù)來驗(yàn)證用戶ID、賬戶、支付卡號、支付金額等參數(shù)。
- 根據(jù)輸入的支付方式，調(diào)用支付路由服務(wù)，獲取對應(yīng)的支付渠道。
- 調(diào)用風(fēng)控接口進(jìn)行驗(yàn)證，如果有交易風(fēng)險(xiǎn)，則阻斷本次交易。
- 生成交易記錄;
- 調(diào)用支付渠道提供的服務(wù)執(zhí)行支付。
- 根據(jù)支付結(jié)果，更新訂單狀態(tài);
- 通知商戶訂單執(zhí)行結(jié)果。
在實(shí)現(xiàn)上，原有系統(tǒng)實(shí)現(xiàn)的類結(jié)構(gòu)圖如下：
- 采用SSH架構(gòu)，支付網(wǎng)關(guān)實(shí)現(xiàn)為一個(gè)大Apache Struts Action類，和支付相關(guān)的所有業(yè)務(wù)邏輯都實(shí)現(xiàn)在一個(gè)項(xiàng)目中。
- 支付網(wǎng)關(guān)承載大量的功能，實(shí)際上，它是將API網(wǎng)關(guān)和業(yè)務(wù)邏輯都混在在一起實(shí)現(xiàn)。 簽約、支付、代扣、驗(yàn)證，都在這一個(gè)類中實(shí)現(xiàn)，代碼行數(shù)超過1000行，邏輯十分復(fù)雜。
- 除了風(fēng)控是進(jìn)程外調(diào)動(dòng)，其他的服務(wù)都是進(jìn)程內(nèi)調(diào)用，通過springframework來管理各個(gè)service。
- 最終落地調(diào)用的支付渠道，是通過抽象的接口來對網(wǎng)關(guān)封裝渠道的差異。
在這個(gè)系統(tǒng)中對接了有30多個(gè)渠道，類規(guī)模達(dá)到2000個(gè)。隨著業(yè)務(wù)發(fā)展，問題越來越多。高峰期同時(shí)有5個(gè)渠道在并行開發(fā)，還有大量的其他渠道對接問題需要修復(fù)。多個(gè)人同時(shí)修改一個(gè)項(xiàng)目代碼導(dǎo)致版本控制的工作驟增。上線頻發(fā)引起服務(wù)中斷也讓業(yè)務(wù)方很不滿。對支付網(wǎng)關(guān)的改進(jìn)是一個(gè)循序漸進(jìn)的過程。這里參考Arun Gupta的微服務(wù)六種設(shè)計(jì)模式，來描述我們所做的改進(jìn)。
新網(wǎng)關(guān)設(shè)計(jì) (Chain Pattern)
為了分解舊網(wǎng)關(guān)的功能， 我們設(shè)計(jì)了新的網(wǎng)關(guān)。在處理流程上，將其分為三個(gè)步驟，采用的是chain模式。
鏈?zhǔn)侥Ｊ?，如上圖所示，它調(diào)用服務(wù)A來獲取結(jié)果，而服務(wù)A是通過服務(wù)B來交互，B則會和C有交互。 整個(gè)過程類似同步的HTTP請求、響應(yīng)處理。 這其中每個(gè)階段的調(diào)用，都是阻塞式的同步調(diào)用。每一步都會增加一些業(yè)務(wù)邏輯處理。
原支付網(wǎng)關(guān)難以維護(hù)的一個(gè)重要原因是其所承載的功能過多。我們首先根據(jù)用戶的使用場景，將支付網(wǎng)關(guān)承載的功能，按照支付產(chǎn)品來進(jìn)行切分。 支付產(chǎn)品包括快捷支付、網(wǎng)銀支付、外卡支付等。 不同的產(chǎn)品，其對應(yīng)的操作所使用的參數(shù)和流程也不一樣。以快捷產(chǎn)品為例， 新網(wǎng)關(guān)接收到請求后，根據(jù)用戶所選擇的支付類型，分發(fā)到快捷支付產(chǎn)品接口。快捷支付產(chǎn)品接口調(diào)用工行借記卡通道來執(zhí)行支付，通道最終落地到工行接口的調(diào)用來實(shí)現(xiàn)支付。 支付操作完成后，工行接口通知到通道，通道通知到產(chǎn)品，最終逆向傳遞到網(wǎng)關(guān)接口，并最終發(fā)送給調(diào)用方。 在這里面，支付網(wǎng)關(guān)負(fù)責(zé)分發(fā)、驗(yàn)簽等基本功能，支付產(chǎn)品負(fù)責(zé)參數(shù)校驗(yàn)、路由、生成交易記錄等功能。最終的支付操作是落地到支付渠道去執(zhí)行。
網(wǎng)關(guān)拆分(Proxy Pattern)
如上所述，支付網(wǎng)關(guān)按照使用場景進(jìn)行拆分。我們采用完善一個(gè)、接入一個(gè)的原則，在保留舊網(wǎng)關(guān)的功能的同時(shí)，開發(fā)完善新的網(wǎng)關(guān)和支付產(chǎn)品。等所有流量都打到新網(wǎng)關(guān)上去之后，舊網(wǎng)關(guān)就直接廢棄了。為了達(dá)到這個(gè)目標(biāo)，我們引入了代理模式：
代理模式和聚合模式類似，不同點(diǎn)在于，它會根據(jù)業(yè)務(wù)邏輯需要僅選擇一個(gè)微服務(wù)來調(diào)用。微服務(wù)中，我們經(jīng)常會用代理模式來構(gòu)建API網(wǎng)關(guān)。
我們首先按照所支持的支付方式，對支付網(wǎng)關(guān)做分解，拆分為為網(wǎng)銀、快捷、話費(fèi)、賬戶、外卡、虛幣等支付產(chǎn)品。新網(wǎng)關(guān)接口模塊是一個(gè)proxy，本身并未實(shí)現(xiàn)任何業(yè)務(wù)邏輯，它的工作是將用戶請求發(fā)送給合適的支付產(chǎn)品去處理。如果這個(gè)產(chǎn)品還沒有實(shí)現(xiàn)，則將其轉(zhuǎn)發(fā)到老網(wǎng)關(guān)去執(zhí)行。這樣帶來的好處是，我們不需要對老網(wǎng)關(guān)做任何改動(dòng)。而且，如果某個(gè)支付產(chǎn)品在重構(gòu)過程中出現(xiàn)問題，我們可以很快切回到老網(wǎng)關(guān)去。
支付產(chǎn)品 (Aggregator Pattern)
支付產(chǎn)品是對原有支付網(wǎng)關(guān)的業(yè)務(wù)流程實(shí)現(xiàn)的一個(gè)重構(gòu)，按照各個(gè)支付產(chǎn)品所支持的功能以及流程來簡化原混合在一起的設(shè)計(jì)。比如快捷支付需要簽約和支付，而網(wǎng)銀支付則不需要簽約。 在支付產(chǎn)品本身的實(shí)現(xiàn)上，我們使用的是聚合模式。
聚合是最常見的微服務(wù)設(shè)計(jì)模式，它是一個(gè)高層次的微服務(wù)組合，供其他服務(wù)調(diào)用。 在這種情況下，聚合器會從其他的微服務(wù)中收集數(shù)據(jù)，做業(yè)務(wù)邏輯處理，然后發(fā)布成一個(gè)服務(wù)終端。其他有需要的服務(wù)可以調(diào)用它。 聚合器設(shè)計(jì)的要點(diǎn)是要遵循DRY(Don’t Repeat Yourself)原則。如果有多個(gè)服務(wù)需要訪問A，B，C服務(wù)，那建議的處理方式是，針對這些使用，提煉一個(gè)處理邏輯出來，將A、B、C封裝為一個(gè)新的服務(wù)，這個(gè)服務(wù)可以獨(dú)立的演化。
支付產(chǎn)品中調(diào)用的各個(gè)服務(wù)，包括支付方式管理， 支付服務(wù)管理，支付路由管理、支付記錄管理等，都被重構(gòu)為微服務(wù)，在支付產(chǎn)品的實(shí)現(xiàn)中，通過Aggregator 模式進(jìn)行調(diào)用。
在支付產(chǎn)品的實(shí)現(xiàn)流程中，首先需要對參數(shù)進(jìn)行校驗(yàn)，校驗(yàn)成功后，調(diào)用風(fēng)控檢查該交易是否可以放行。這兩個(gè)操作，在處理上可以并行，使用的是分支模式。
分支模式是聚合模式的擴(kuò)展，可以允許同時(shí)調(diào)用兩個(gè)或者更多的微服務(wù)。
如上，采用分支模式， 使得數(shù)據(jù)校驗(yàn)和風(fēng)控可以并發(fā)執(zhí)行。由于風(fēng)控相對耗時(shí)較長，而訂單中需要校驗(yàn)的數(shù)據(jù)較多，這兩個(gè)操作有必要并發(fā)執(zhí)行。
支付通道 (Aggregator Pattern)
支付路由根據(jù)用戶選擇的支付方式對支付通道進(jìn)行篩選，選取合適的支付通道。支付產(chǎn)品調(diào)用該通道的接口來最終落地完成支付服務(wù)。 每個(gè)支付通道對接也被實(shí)現(xiàn)為微服務(wù)，在支付產(chǎn)品中調(diào)用。
通知商戶 (Asynchronous Messaging Pattern)
支付產(chǎn)品執(zhí)行的***一個(gè)步驟是通知調(diào)用方支付的結(jié)果。 原系統(tǒng)實(shí)現(xiàn)是將這個(gè)步驟耦合在原有代碼中，容易受到調(diào)用方接口的穩(wěn)定性的影響。 為此，這里采用異步消息的模式來進(jìn)行重構(gòu)：
異步消息一般用于對流程中可以異步執(zhí)行的操作做分解，將它從原流程中分離出來，通過消息機(jī)制來異步執(zhí)行。 支付產(chǎn)品在完成支付服務(wù)后，發(fā)出消息到訂單消息隊(duì)列中。 商戶回調(diào)處理程序接收到消息后，調(diào)用商戶回調(diào)接口告知支付結(jié)果。 此外，風(fēng)控、BI系統(tǒng)等，也可以使用這個(gè)消息來同步訂單數(shù)據(jù)。
總結(jié)
這里簡單介紹了支付網(wǎng)關(guān)重構(gòu)的過程，以及如何使用微服務(wù)設(shè)計(jì)模式。 當(dāng)然，這里我們也忽略了很多細(xì)節(jié)，比如支付網(wǎng)關(guān)所依賴的基礎(chǔ)服務(wù)的開發(fā)。 最終的支付網(wǎng)關(guān)的架構(gòu)，參考《支付網(wǎng)關(guān)設(shè)計(jì)》一文。這里涉及到的支付路由、支付記錄、支付風(fēng)控等模塊的設(shè)計(jì)，后續(xù)也會在本博客中做介紹。 微服務(wù)化改造并不難，需要的是對原有系統(tǒng)有深入的了解，然后運(yùn)用各種模式來拆分，庖丁解牛。拆分的每一步都需要注意，在設(shè)計(jì)上，需要考慮一旦出現(xiàn)問題即可回滾。
【本文為專欄作者“鳳凰牌老熊”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號“鳳凰牌老熊”聯(lián)系作者本人】
本文題目：使用微服務(wù)架構(gòu)重構(gòu)支付網(wǎng)關(guān)
網(wǎng)站路徑：http://www.5511xx.com/article/ccdhjep.html
