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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: 从零打造聚合支付系统 系列文章链接如下从零打造聚合支付系统:一、浅谈聚合支付的核心价值从零打造聚合支付系统:二、建立领域模型从零打造聚合支付系统:三、应用微服务架构上一篇建立了聚合支付的领域模型,本篇将讨论聚合支付系统的具体实现方案。

从零打造聚合支付系统 系列文章链接如下

从零打造聚合支付系统:一、浅谈聚合支付的核心价值
从零打造聚合支付系统:二、建立领域模型
从零打造聚合支付系统:三、应用微服务架构

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

设计策略

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

  • 为商户提供支付的一站式接入,由商户发起支付,在支付机构和银行落地。
  • 将商户的支付、查询、退款信息,通过系统调用的方式传递给支付机构和银行。
  • 提供一些辅助功能,如对账、结算、商户注册、交易管理等。

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

  1. 对外提供HTTP(或HTTPS)接口:首先,没有比这个更通用的协议;其次,这是由落地方决定的,聚合支付系统只是商户与支付机构间的中介,不破坏两者之间原有的协议是最省事的;
  2. 第一要务是信息传递:作为一个中介,聚合支付既不管理资金账户,也不持有商品订购的数据,这与许多业务系统是有区别的。设计重心要放在为商户与支付机构之间提供稳定的信道与准确的信息传递。而数据的管理,可以放在第二位考虑。
  3. 摒弃有状态的设计:既然数据不在第一位考虑,那么也就意味着,数据的一致性要求可以适当降低,参考CAP的约束,可以让我们在保证可用性和分区容错性上有更多的发挥空间。

微服务架构

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

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

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

  • RESTful API是微服务中进程间通信标配:为什么选用HTTP做信道?不仅因为HTTP协议足够灵活,更因为不需要处理在引入特定的通信组件(如Thrift)带来的复杂性。
  • 微服务架构擅长于消息的可靠传递:在微服务特点的论述中,有大量篇幅用于探讨如何传递息,包括外部通信、进程间通信、容错处理等。同时,为了适应众多的场景,微服务架构也发展出了各式各样的通信组件可供使用。
  • 聚合支付免去微服务中关于数据分区的挑战:微服务会导致数扰分区,即相关数据被分在不同的数据库中,这让保持多个服务数据的一致性成为挑战。所幸聚合支付对数据一致性的要求不高,这就让我们实现微服务变的简单,采用对账来保证最终一致性即可;

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

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

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

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

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

构建最小系统

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

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

服务划分

img_77045d59d41e6e1cf721d217e5cea96a.png

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

  • 支付后台:支付的核心功能,处理来自于商户后台的支付与退款请求,是整个聚合支付消息传递的关键。
  • 收银台:考虑支付请求并不一定来自于后台。在实际支付场景中,请求可以由客户端APP或浏览器跳转过来,它与后台请求所使用的网络通常是不一样的,某些场景下,还要提供让客户选择支付方式的页面。
  • 支付机构:支付落地在支付机构或银行,意味着最终是调用他们提供的接口,但支付机构的接口并不是一成不变的,经常会升级改造。将每个支付机构的接口包装成一个服务,可以减少支付机构接口改造核心业务模块的影响。
    对账结算模块:
  • 账户服务:为了实时记账而存在的服务,将支付金额按规则进行分账,并与外部账户保持同步。

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

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

必要的辅助组件

img_e16612c45153b37b1b4496e33dc77983.png
  • 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. 将单体应用改造为微服务
相关文章
|
4天前
|
Cloud Native 持续交付 云计算
云原生之旅:从传统应用到容器化微服务
随着数字化转型的浪潮不断推进,企业对IT系统的要求日益提高。本文将引导你了解如何将传统应用转变为云原生架构,重点介绍容器化和微服务的概念、优势以及实施步骤,旨在帮助读者掌握将应用迁移到云平台的关键技巧,确保在云计算时代保持竞争力。
14 5
|
3天前
|
监控 负载均衡 应用服务中间件
探索微服务架构下的API网关设计与实践
在数字化浪潮中,微服务架构以其灵活性和可扩展性成为企业IT架构的宠儿。本文将深入浅出地介绍微服务架构下API网关的关键作用,探讨其设计原则与实践要点,旨在帮助读者更好地理解和应用API网关,优化微服务间的通信效率和安全性,实现服务的高可用性和伸缩性。
14 3
|
7天前
|
存储 Java Maven
从零到微服务专家:用Micronaut框架轻松构建未来架构
【9月更文挑战第5天】在现代软件开发中,微服务架构因提升应用的可伸缩性和灵活性而广受欢迎。Micronaut 是一个轻量级的 Java 框架,适合构建微服务。本文介绍如何从零开始使用 Micronaut 搭建微服务架构,包括设置开发环境、创建 Maven 项目并添加 Micronaut 依赖,编写主类启动应用,以及添加控制器处理 HTTP 请求。通过示例代码展示如何实现简单的 “Hello, World!” 功能,并介绍如何通过添加更多依赖来扩展应用功能,如数据访问、验证和安全性等。Micronaut 的强大和灵活性使你能够快速构建复杂的微服务系统。
26 5
|
6天前
|
传感器 Cloud Native 物联网
Micronaut在物联网中的应用探索:轻盈架构赋能万物互联新时代
【9月更文挑战第6天】Micronaut是一个现代、轻量级的Java框架,以其高效、易用及对云原生环境的支持,在物联网开发中展现出独特优势。它通过AOT编译技术优化应用,减少内存消耗,适合资源受限的设备。Micronaut支持反应式编程和HTTP/2,提升并发处理能力和网络传输效率。本文通过一个温度传感器数据收集服务的例子,展示了如何利用Micronaut简化物联网应用开发,使其成为该领域的理想选择。
18 3
|
11天前
|
C# 微服务 Windows
模块化革命:揭秘WPF与微服务架构的完美融合——从单一职责原则到事件聚合器模式,构建高度解耦与可扩展的应用程序
【8月更文挑战第31天】本文探讨了如何在Windows Presentation Foundation(WPF)应用中借鉴微服务架构思想,实现模块化设计。通过将WPF应用分解为独立的功能模块,并利用事件聚合器实现模块间解耦通信,可以有效提升开发效率和系统可维护性。文中还提供了具体示例代码,展示了如何使用事件聚合器进行模块间通信,以及如何利用依赖注入进一步提高模块解耦程度。此方法不仅有助于简化复杂度,还能使应用更加灵活易扩展。
29 0
|
11天前
|
数据库 Java 数据库连接
Hibernate 实体监听器竟如魔法精灵,在 CRUD 操作中掀起自动化风暴!
【8月更文挑战第31天】在软件开发中,效率与自动化至关重要。Hibernate 通过其强大的持久化框架提供了实体监听器这一利器,自动处理 CRUD 操作中的重复任务,如生成唯一标识符、记录更新时间和执行清理操作,从而大幅提升开发效率并减少错误。下面通过示例代码展示了如何定义监听器类,并在实体类中使用 `@EntityListeners` 注解来指定监听器,实现自动化任务。这不仅简化了开发流程,还能根据具体需求灵活应用,满足各种业务场景。
21 0
|
11天前
|
前端开发 微服务 API
微服务浪潮下的JSF革新:如何在分散式架构中构建统一而强大的Web界面
【8月更文挑战第31天】随着微服务架构的兴起,企业将应用拆分成小型、独立的服务以提高系统可维护性和可扩展性。本文探讨如何在微服务架构下构建和部署JavaServer Faces (JSF) 应用,通过RESTful服务实现前后端分离,提升灵活性和适应性。
29 0
|
11天前
|
微服务 API Java
微服务架构大揭秘!Play Framework如何助力构建松耦合系统?一场技术革命即将上演!
【8月更文挑战第31天】互联网技术飞速发展,微服务架构成为企业级应用主流。微服务将单一应用拆分成多个小服务,通过轻量级通信机制交互。高性能Java Web框架Play Framework具备轻量级、易扩展特性,适合构建微服务。本文探讨使用Play Framework构建松耦合微服务系统的方法。Play采用响应式编程模型,支持模块化开发,提供丰富生态系统,便于快速构建功能完善的微服务。
22 0
|
12天前
|
负载均衡 监控 JavaScript
探索微服务架构下的API网关模式
【8月更文挑战第31天】在微服务的大潮中,API网关不仅是流量的守门人,更是服务间通信的桥梁。本文将带你深入理解API网关的核心概念、设计要点及其在微服务架构中的重要作用,同时通过代码示例揭示如何利用API网关提升系统的灵活性与扩展性。
|
12天前
|
Cloud Native 架构师 持续交付
探索云原生之旅:从传统应用到微服务的转型之路
【8月更文挑战第31天】本文是一篇深入浅出的指南,旨在帮助开发者和架构师理解如何将传统应用迁移到云原生架构。我们将通过一个实际的案例,展示如何使用容器化、服务网格和持续集成/持续部署(CI/CD)等技术,实现应用的现代化改造。文章不仅提供理论指导,还包含代码示例,确保读者能够获得实践知识。无论你是云原生新手,还是希望深化理解的资深人士,这篇文章都将为你开启一段新的旅程。