从零打造聚合支付系统:三、应用微服务架构
从零打造聚合支付系统 系列文章链接如下
从零打造聚合支付系统:一、浅谈聚合支付的核心价值
从零打造聚合支付系统:二、建立领域模型
从零打造聚合支付系统:三、应用微服务架构
上一篇建立了聚合支付的领域模型,本篇将讨论聚合支付系统的具体实现方案。
设计策略
在决定采用什么样的架构之前,不妨先回顾一下聚合支付的功能。
- 为商户提供支付的一站式接入,由商户发起支付,在支付机构和银行落地。
- 将商户的支付、查询、退款信息,通过系统调用的方式传递给支付机构和银行。
- 提供一些辅助功能,如对账、结算、商户注册、交易管理等。
实现这些功能可以采取如下的设计策略:
- 对外提供HTTP(或HTTPS)接口:首先,没有比这个更通用的协议;其次,这是由落地方决定的,聚合支付系统只是商户与支付机构间的中介,不破坏两者之间原有的协议是最省事的;
- 第一要务是信息传递:作为一个中介,聚合支付既不管理资金账户,也不持有商品订购的数据,这与许多业务系统是有区别的。设计重心要放在为商户与支付机构之间提供稳定的信道与准确的信息传递。而数据的管理,可以放在第二位考虑。
- 摒弃有状态的设计:既然数据不在第一位考虑,那么也就意味着,数据的一致性要求可以适当降低,参考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的微服务系列文章。
以下是原文与译文的链接。
- 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
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
从零打造聚合支付系统:二、建立领域模型
从零打造聚合支付系统 系列文章链接如下 从零打造聚合支付系统:一、浅谈聚合支付的核心价值从零打造聚合支付系统:二、建立领域模型从零打造聚合支付系统:三、应用微服务架构 上一篇分析了聚合支付为什么能做,本篇开始讲讲聚合支付系统怎么入手。 前言 在针对特定业务进行分析设计时,首要的事情便是建立业务模型(又称领域模型)。 领域模型,通常是业务人员与软件工程师沟通的桥梁。 为了避免陷入专业名词的泥沼中,我并不打算运用严格的领域模型语言来描述聚合支付系统的分析设计。尽管如此,但建模的思路的做法依然重要。 关于领域建模的重要性及基本原则,Eric Evans大神在《领域驱动设计——软件核心复杂性应对之道》一书中有详细阐述,有兴趣的小伙伴可以阅读的第一部分。 系统功能 上一篇中介绍过,聚合支付是为商户提供支付“一站式”的服务。 聚合支付系统位于商户与支付机构或银行之间,收敛商户与支付机构及银行间的一切交互。 一个聚合支付系统,首先要具备支付、查询、退款三个基本功能,对应用户使用支付的三种基本操作;其次,为了确保各方交易记录一致,通常要以天为单位对账,实现业务闭环;最后,根据对账结果,定期完成资金结算...
- 下一篇
项目经验不丰富、技术不突出的程序员怎么打动面试官?
前言 相信不少的程序员都有过类似的困惑:如果我没有大型的项目经历,也不能靠技术征服面试官,那我要怎么才能给面试官留下一个好印象呢? 按照本人的面试经验来说,面试主要看几点:项目经验+基本技术+个人潜力 说到这里,也给大家推荐一个架构交流学习群:835544715,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,相信对于已经工作和遇到技术瓶颈的码友,在这个群里会有你需要的内容。 关于项目经验 我认为方腾飞老师讲的一段话非常好: 介绍产品时面试官会考察应聘者的沟通能力和思考能力,我们大部分情况都是做产品的一个功能或一个模块,但是即使是这样,自己有没有把整个系统架构或产品搞清楚,并能介绍清楚,为什么做这个系统?这个系统的价值是什么?这个系统有哪些功能?优缺点有哪些?如果让你重新设计这个系统你会如何设计? 我觉得这就已经足以概括了。也许你仅仅工作一年,也许你做的是项目中微不足道的模块,当然这些一定是你的劣势且无法改变,但是如何弥补这个劣势,从...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合Redis,开启缓存,提高访问速度
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)