從零打造聚合支付系統(tǒng) 系列文章鏈接如下
從零打造聚合支付系統(tǒng)：一龟虎、淺談聚合支付的核心價值
從零打造聚合支付系統(tǒng)：二、建立領(lǐng)域模型
從零打造聚合支付系統(tǒng)：三匠璧、應(yīng)用微服務(wù)架構(gòu)
上一篇建立了聚合支付的領(lǐng)域模型桐款，本篇將討論聚合支付系統(tǒng)的具體實現(xiàn)方案。
設(shè)計策略
在決定采用什么樣的架構(gòu)之前夷恍，不妨先回顧一下聚合支付的功能魔眨。
- 為商戶提供支付的一站式接入，由商戶發(fā)起支付酿雪，在支付機構(gòu)和銀行落地遏暴。
- 將商戶的支付、查詢指黎、退款信息朋凉，通過系統(tǒng)調(diào)用的方式傳遞給支付機構(gòu)和銀行。
- 提供一些輔助功能醋安，如對賬杂彭、結(jié)算墓毒、商戶注冊、交易管理等亲怠。
實現(xiàn)這些功能可以采取如下的設(shè)計策略：
- 對外提供HTTP（或HTTPS）接口：首先所计，沒有比這個更通用的協(xié)議；其次团秽，這是由落地方?jīng)Q定的主胧，聚合支付系統(tǒng)只是商戶與支付機構(gòu)間的中介，不破壞兩者之間原有的協(xié)議是最省事的习勤；
- 第一要務(wù)是信息傳遞：作為一個中介踪栋，聚合支付既不管理資金賬戶，也不持有商品訂購的數(shù)據(jù)图毕，這與許多業(yè)務(wù)系統(tǒng)是有區(qū)別的己英。設(shè)計重心要放在為商戶與支付機構(gòu)之間提供穩(wěn)定的信道與準確的信息傳遞。而數(shù)據(jù)的管理吴旋，可以放在第二位考慮。
- 摒棄有狀態(tài)的設(shè)計：既然數(shù)據(jù)不在第一位考慮厢破，那么也就意味著荣瑟，數(shù)據(jù)的一致性要求可以適當降低，參考CAP的約束摩泪，可以讓我們在保證可用性和分區(qū)容錯性上有更多的發(fā)揮空間笆焰。
微服務(wù)架構(gòu)
無論是追捧還是質(zhì)疑，微服務(wù)架構(gòu)擁有巨大優(yōu)勢见坑，尤其是它讓敏捷開發(fā)和復雜的企業(yè)應(yīng)用交付成為可能嚷掠。———— 引用自「Chris Richardson 微服務(wù)系列」《微服務(wù)架構(gòu)概念解析》
Chris Richardson 如何理解微服務(wù)架構(gòu)荞驴？微服務(wù)架構(gòu)有什么優(yōu)缺點不皆？請參考文末附錄的的文章。
我認為熊楼，微服務(wù)架構(gòu)與聚合支付的契合度頗高霹娄，列舉幾點：
- RESTful API是微服務(wù)中進程間通信標配：為什么選用HTTP做信道？不僅因為HTTP協(xié)議足夠靈活鲫骗，更因為不需要處理在引入特定的通信組件（如Thrift）帶來的復雜性犬耻。
- 微服務(wù)架構(gòu)擅長于消息的可靠傳遞：在微服務(wù)特點的論述中，有大量篇幅用于探討如何傳遞息执泰，包括外部通信枕磁、進程間通信、容錯處理等术吝。同時计济，為了適應(yīng)眾多的場景茸苇，微服務(wù)架構(gòu)也發(fā)展出了各式各樣的通信組件可供使用。
- 聚合支付免去微服務(wù)中關(guān)于數(shù)據(jù)分區(qū)的挑戰(zhàn)：微服務(wù)會導致數(shù)擾分區(qū)峭咒，即相關(guān)數(shù)據(jù)被分在不同的數(shù)據(jù)庫中税弃，這讓保持多個服務(wù)數(shù)據(jù)的一致性成為挑戰(zhàn)。所幸聚合支付對數(shù)據(jù)一致性的要求不高凑队，這就讓我們實現(xiàn)微服務(wù)變的簡單则果，采用對賬來保證最終一致性即可；
另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)漩氨。同時更新多個業(yè)務(wù)主體的事務(wù)很普遍西壮。這種事務(wù)對于單體式應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫叫惊。在微服務(wù)架構(gòu)應(yīng)用中款青，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式事務(wù)并不一定是好的選擇霍狰，不僅僅是因為 CAP 理論抡草，還因為當前高擴展性的 NoSQL 數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法蔗坯，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)康震。———— 引用自「Chris Richardson 微服務(wù)系列」《微服務(wù)架構(gòu)概念解析》
- 優(yōu)秀的橫向擴展能力滿足未來的性能要求：應(yīng)用微服務(wù)架構(gòu)的一個要點就是將服務(wù)設(shè)計為無狀態(tài)宾濒，使得每個服務(wù)都能簡單地橫向擴展腿短，規(guī)模化部署绘梦。這樣橘忱，即便單個服務(wù)實例的處理性能不夠強，也可以通過部署更多的實例來迅速滿足業(yè)務(wù)增長的需求卸奉。
微服務(wù)架構(gòu)模式使得每個服務(wù)獨立擴展钝诚。你可以根據(jù)每個服務(wù)的規(guī)模來部署滿足需求的實利。甚至于择卦，你可以使用更適合于服務(wù)資源需求的硬件敲长。 ———— 引用自「Chris Richardson 微服務(wù)系列」《微服務(wù)架構(gòu)概念解析》
- 優(yōu)秀的解耦能力滿足未來分工的要求
這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團隊來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)秉继，提供 API 服務(wù)祈噪。……甚至于尚辑，因為服務(wù)都是相對簡單辑鲤，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情「懿纾———— 引用自「Chris Richardson 微服務(wù)系列」《微服務(wù)架構(gòu)概念解析》
構(gòu)建最小系統(tǒng)
接下來根據(jù)我們在上一篇文章中描述的領(lǐng)域模型月褥，應(yīng)用微服務(wù)架構(gòu)的思想構(gòu)建聚合支付系統(tǒng)弛随。
“最小系統(tǒng)”特指以下描述的每個部分都是不可缺少的。
服務(wù)劃分
橙色部分就是微服務(wù)架構(gòu)中的“服務(wù)”了宁赤。
- 支付后臺：支付的核心功能舀透，處理來自于商戶后臺的支付與退款請求，是整個聚合支付消息傳遞的關(guān)鍵决左。
- 收銀臺：考慮支付請求并不一定來自于后臺愕够。在實際支付場景中，請求可以由客戶端APP或瀏覽器跳轉(zhuǎn)過來佛猛，它與后臺請求所使用的網(wǎng)絡(luò)通常是不一樣的惑芭，某些場景下，還要提供讓客戶選擇支付方式的頁面继找。
-
支付機構(gòu)：支付落地在支付機構(gòu)或銀行遂跟，意味著最終是調(diào)用他們提供的接口，但支付機構(gòu)的接口并不是一成不變的婴渡，經(jīng)常會升級改造幻锁。將每個支付機構(gòu)的接口包裝成一個服務(wù)，可以減少支付機構(gòu)接口改造核心業(yè)務(wù)模塊的影響边臼。
對賬結(jié)算模塊： - 賬戶服務(wù)：為了實時記賬而存在的服務(wù)越败，將支付金額按規(guī)則進行分賬，并與外部賬戶保持同步硼瓣。
值得說明的是，對賬結(jié)算模塊中除了賬戶服務(wù)之外置谦，比對與結(jié)算功能通常不需要設(shè)計為服務(wù)堂鲤。比對通常使用批處理技術(shù)（如Spark或MapReduce），而結(jié)算模塊由于與會計系統(tǒng)對接媒峡，通常按指定的規(guī)范來實現(xiàn)瘟栖。
- 商戶服務(wù)：負責提供商戶交互的UI界面，融合商戶使用過程中所需的功能谅阿。
必要的輔助組件
- API網(wǎng)關(guān)：API 網(wǎng)關(guān)可以說是進入系統(tǒng)的唯一節(jié)點半哟。這與面向?qū)ο笤O(shè)計模式中的 Facade 模式很像。主要用來收斂后面的服務(wù)實現(xiàn)签餐。
- 注冊中心：實現(xiàn)服務(wù)自動發(fā)現(xiàn)寓涨，從而實現(xiàn)客戶端負載均衡。
- 配置中心：集中管理所有服務(wù)的配置氯檐，簡化配置過程戒良。
應(yīng)用微服務(wù)架構(gòu)，以上是三個必要的輔助組件冠摄，需要配套部署糯崎，缺一不可几缭。
部署到云
對于小團隊，為了降低運維成本沃呢，方便擴展年栓，通常會租用云服務(wù)器。正巧薄霜，微服務(wù)架構(gòu)是云友好和容器（如Docker）友好的某抓，尤其是現(xiàn)在許多云平臺服務(wù)商都提供了容器技術(shù)，更方便我們將聚合支付系統(tǒng)部署到云上黄锤。
如果你的團隊己經(jīng)做了聚合支付搪缨，而且己經(jīng)有業(yè)務(wù)在跑了，那么我強烈建議參考《將單體應(yīng)用改造為微服務(wù)》 一文鸵熟，盡快應(yīng)用微服務(wù)架構(gòu)副编。要小心，不要大規(guī)模重構(gòu)代碼流强，正如 Martin Fowler 所言痹届，“大規(guī)模重寫唯一能夠保證的只有大規(guī)模！”打月。眼光要看的足夠遠队腐，但步子不能一下子邁的太大。
最后奏篙，選擇語言
好了柴淘，我們打算動手寫代碼了。
但在這之前秘通，還有一件事我們要確定一下为严。
我們應(yīng)該構(gòu)建在什么語言平臺上？雖然微服務(wù)號稱對各種語言都兼容肺稀，但一個小團隊最重要的還是保持技術(shù)棧相對單一第股。
首先被排除的是C/C++，在初期话原，語言的效率就是團隊的效率夕吻，真的玩不起。
PHP雖然足夠簡單繁仁，但由于對微服務(wù)支持不佳涉馅，也被我們排除。
Nodejs與GO在國內(nèi)受眾仍然較少黄虱，考慮到招程序員的要求控漠，雖然看起來很酷，但我們還是別折騰了。
Python最近由于人工智能而大熱盐捷，但在微服務(wù)方面的支持還不是那么完善偶翅，還需要發(fā)展一下。
Java體系中有個非常硬霸的框架叫Spring Cloud碉渡，不只是對微服務(wù)支持很好聚谁，還喊出了“連接一切”的口號。
所以滞诺，沒有什么特別原因的話形导，建議還是選 Java 和 Spring Cloud吧。
附錄：微服務(wù)架構(gòu)的圭臬
本文反復提到了微服務(wù)架構(gòu)习霹，但微服務(wù)架構(gòu)并非本文重點朵耕。關(guān)于微服務(wù)的論述，我在此附上Chris Richardson的微服務(wù)系列文章淋叶。
以下是原文與譯文的鏈接阎曹。
- Introduction to Microservices
- Building Microservices: Using an API Gateway
- Building Microservices: Inter-Process Communication in a Microservices Architecture
- Service Discovery in a Microservices Architecture
- Event-Driven Data Management for Microservices
- Choosing a Microservices Deployment Strategy
- Refactoring a Monolith into Microservices
