从零打造聚合支付系统：三应用微服务架构

Posted 2021-04-14 交易技术汇

上一篇建立了聚合支付的领域模型，本篇将讨论聚合支付系统的具体实现方案。

设计策略

在决定采用什么样的架构之前，不妨先回顾一下聚合支付的功能。

• 为商户提供支付的一站式接入，由商户发起支付，在支付机构和银行落地。

• 将商户的支付、查询、退款信息，通过系统调用的方式传递给支付机构和银行。

• 提供一些辅助功能，如对账、结算、商户注册、交易管理等。

实现这些功能可以采取如下的设计策略：

1. 对外提供HTTP（或HTTPS）接口：首先，没有比这个更通用的协议；其次，这是由落地方决定的，聚合支付系统只是商户与支付机构间的中介，不破坏两者之间原有的协议是最省事的；

2. 第一要务是信息传递：作为一个中介，聚合支付既不管理资金账户，也不持有商品订购的数据，这与许多业务系统是有区别的。设计重心要放在为商户与支付机构之间提供稳定的信道与准确的信息传递。而数据的管理，可以放在第二位考虑。

3. 摒弃有状态的设计：既然数据不在第一位考虑，那么也就意味着，数据的一致性要求可以适当降低，参考CAP的约束，可以让我们在保证可用性和分区容错性上有更多的发挥空间。

微服务架构

无论是追捧还是质疑，微服务架构拥有巨大优势，尤其是它让敏捷开发和复杂的企业应用交付成为可能。———— 引用自「Chris Richardson 微服务系列」《微服务架构概念解析》

Chris Richardson 如何理解微服务架构？微服务架构有什么优缺点？请参考文末附录的的文章。

我认为，微服务架构与聚合支付的契合度颇高，列举几点：

• RESTful API是微服务中进程间通信标配：为什么选用HTTP做信道？不仅因为HTTP协议足够灵活，更因为不需要处理在引入特定的通信组件（如Thrift）带来的复杂性。

• 微服务架构擅长于消息的可靠传递：在微服务特点的论述中，有大量篇幅用于探讨如何传递息，包括外部通信、进程间通信、容错处理等。同时，为了适应众多的场景，微服务架构也发展出了各式各样的通信组件可供使用。

• 聚合支付免去微服务中关于数据分区的挑战：微服务会导致数扰分区，即相关数据被分在不同的数据库中，这让保持多个服务数据的一致性成为挑战。所幸聚合支付对数据一致性的要求不高，这就让我们实现微服务变的简单，采用对账来保证最终一致性即可；

另外一个关于微服务的挑战来自于分区的数据库架构。同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式事务并不一定是好的选择，不仅仅是因为 CAP 理论，还因为当前高扩展性的 NoSQL 数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。———— 引用自「Chris Richardson 微服务系列」《微服务架构概念解析》

• 优秀的横向扩展能力满足未来的性能要求：应用微服务架构的一个要点就是将服务设计为无状态，使得每个服务都能简单地横向扩展，规模化部署。这样，即便单个服务实例的处理性能不够强，也可以通过部署更多的实例来迅速满足业务增长的需求。

微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的实利。甚至于，你可以使用更适合于服务资源需求的硬件。   ———— 引用自「Chris Richardson 微服务系列」《微服务架构概念解析》

• 优秀的解耦能力满足未来分工的要求

这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供 API 服务。……甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。———— 引用自「Chris Richardson 微服务系列」《微服务架构概念解析》

构建最小系统

接下来根据我们在上一篇文章中描述的领域模型，应用微服务架构的思想构建聚合支付系统。

“最小系统”特指以下描述的每个部分都是不可缺少的。

服务划分

橙色部分就是微服务架构中的“服务”了。

• 支付后台：支付的核心功能，处理来自于商户后台的支付与退款请求，是整个聚合支付消息传递的关键。

• 收银台：考虑支付请求并不一定来自于后台。在实际支付场景中，请求可以由客户端APP或浏览器跳转过来，它与后台请求所使用的网络通常是不一样的，某些场景下，还要提供让客户选择支付方式的页面。

• 支付机构：支付落地在支付机构或银行，意味着最终是调用他们提供的接口，但支付机构的接口并不是一成不变的，经常会升级改造。将每个支付机构的接口包装成一个服务，可以减少支付机构接口改造核心业务模块的影响。
  对账结算模块：

• 账户服务：为了实时记账而存在的服务，将支付金额按规则进行分账，并与外部账户保持同步。

值得说明的是，对账结算模块中除了账户服务之外，比对与结算功能通常不需要设计为服务。比对通常使用批处理技术（如Spark或MapReduce），而结算模块由于与会计系统对接，通常按指定的规范来实现。

• 商户服务：负责提供商户交互的UI界面，融合商户使用过程中所需的功能。

必要的辅助组件

• API网关：API 网关可以说是进入系统的唯一节点。这与面向对象设计模式中的 Facade 模式很像。主要用来收敛后面的服务实现。

• 注册中心：实现服务自动发现，从而实现客户端负载均衡。

• 配置中心：集中管理所有服务的配置，简化配置过程。

应用微服务架构，以上是三个必要的辅助组件，需要配套部署，缺一不可。

部署到云

对于小团队，为了降低运维成本，方便扩展，通常会租用云服务器。正巧，微服务架构是云友好和容器（如Docker）友好的，尤其是现在许多云平台服务商都提供了容器技术，更方便我们将聚合支付系统部署到云上。

如果你的团队己经做了聚合支付，而且己经有业务在跑了，那么我强烈建议参考《将单体应用改造为微服务》 一文，尽快应用微服务架构。要小心，不要大规模重构代码，正如 Martin Fowler 所言，“大规模重写唯一能够保证的只有大规模！”。眼光要看的足够远，但步子不能一下子迈的太大。

最后，选择语言

好了，我们打算动手写代码了。

但在这之前，还有一件事我们要确定一下。

我们应该构建在什么语言平台上？虽然微服务号称对各种语言都兼容，但一个小团队最重要的还是保持技术栈相对单一。

首先被排除的是C/C++，在初期，语言的效率就是团队的效率，真的玩不起。

php虽然足够简单，但由于对微服务支持不佳，也被我们排除。

Nodejs与GO在国内受众仍然较少，考虑到招程序员的要求，虽然看起来很酷，但我们还是别折腾了。

Python最近由于人工智能而大热，但在微服务方面的支持还不是那么完善，还需要发展一下。

Java体系中有个非常硬霸的框架叫Spring Cloud，不只是对微服务支持很好，还喊出了“连接一切”的口号。

所以，没有什么特别原因的话，建议还是选 Java 和 Spring Cloud吧。

附录：微服务架构的圭臬

本文反复提到了微服务架构，但微服务架构并非本文重点。关于微服务的论述，我在此附上Chris Richardson的微服务系列文章。

以下是原文与译文的链接。

1. Introduction to Microservices

2. Building Microservices: Using an API Gateway

3. Building Microservices: Inter-Process Communication in a Microservices Architecture

4. Service Discovery in a Microservices Architecture

5. Event-Driven Data Management for Microservices

6. Choosing a Microservices Deployment Strategy

7. Refactoring a Monolith into Microservices

1. 微服务架构概念解析

2. 构建微服务架构：使用 API Gateway

3. 深入微服务架构的进程间通信

4. 服务发现的可行方案以及实践案例

5. 微服务的事件驱动数据管理

6. 选择微服务部署策略

7. 将单体应用改造为微服务

             

路漫漫其修远兮，吾将上下而求索！

一起分享，一起成长！