解码 | 25 分钟开发分布式架构的转账小程序-CSDN博客

如今，转账场景深入在我们生活的方方面面，也有很多技术团队在独立开发转账的小程序。

本文将给大家对比常见的小程序和分布式小程序的优劣，最后借助 SOFAStack 的能力，提供 25 分钟实现稳定的分布式架构的转账小程序的 Demo。

背景

2017 年 12 月，蚂蚁金服发布自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA ），并提出金融机构进行业务突破和创新的关键是：行业 IT 架构从传统的集中式架构向分布式架构转型。

2018 年 4 月，蚂蚁金服 SOFA 启动开源计划，并开放多个组件，这一系列的动作受到大家的关注和支持，同时，SOFA 社区也日益壮大，除了积极参加开源社区的分享之外，目前已经在杭州、北京、深圳的 Meetup 与大家相见。

2018 年 9 月，杭州蚂蚁金服 ATEC（Ant Technology Exploration Conference），SOFA 再次与开发者们相约，联合支付宝小程序推出《 25 分钟开发分布式架构的转账小程序》的体验课程，大家可在杭州云栖小镇国际会展中心场馆 B 场馆- ATEC 开发者乐园 CodeLab 来现场动手实践，时间为 2018/9/19 - 9/22。

场景介绍

一个精简的转账业务，一般会包含几个部分：

用户发起转账
系统记录用户的支出记录
将资金从 A 用户转 B 用户
返回给用户“操作成功”提醒，并且定期会给用户发送一些日结或者月结的收支账单

这里涉及到账户、转账、账单三个功能模块。

小程序集中式后台架构

常见的集中式架构如下图所示，转账涉及的账户、转账、账单等功能模块都集中在一个后台系统中，所有的数据都在同一个数据库里面。在业务量不大的情况下，集中式后台系统设计简单，部署方便，没有太多复杂的场景。

但是在大业务量的情况下，集中式架构的缺点也一一体现，例如成本较高、系统容量有限、扩展能力受限、代码繁重、故障影响面大等等。

小程序分布式后台架构

在上图中，可以看到原来集中式的系统已经拆分为多个后台系统，原来的集中式数据库也已经拆分为两个数据库，原来进程内的系统交互也变成了进程间的系统交互。

分布式后台架构很好的解决了集中式架构的问题的同时，但是也带来了一些新的挑战。

例如：

系统间的同步调用、异步调用
分布式数据源的数据库访问
分布式事务

我们来举个例子，假设转账业务的前端是小程序，其完整的流程图如下：

用户扫描二维码进行登录，成功后可以查看当前的余额
选取另一个用户进行转账，输入金额并提交，同时会做限额的校验
转账应用记录流水明细
转账应用调用账号应用，进行两个账号余额增减
转账应用发送成功消息给用户

采用以上的方案，可能会面对一些问题，比如：

如何保证转账应用跟账号应用之间的事务一致性？
转账的明细库容量不够了如何动态水平扩容？
数据如何由单库迁移到多库？如何保证消息发送的可靠性？等等

这时候，需要一套成熟的中间件来为用户解决分布式架构下的问题。业内有不少不错的中间件产品，比如开源的 Spring Cloud 、SOFAStack 框架等。

今天，我们现场体验一下「基于 SOFAStack 中间件的转账小程序」的特别之处

蚂蚁金融科技的 SOFAStack 中间件从蚂蚁内部演变发展而来，经历了数 10 年金融级业务的发展。

SOFAStack 可以帮忙用户快速构建健壮的系统：

分布式事务 DTX 可以解决转账链路上 payment 跟 account 之间跨资源的分布式事务问题，业务代码几乎不用调整；
数据访问代理 DBP 可以解决 payment 数据库容量的问题，用户像使用单库单表一样访问分库分表的数据访问代理 DBP 实例，并且可以跟分布式事务 DTX 集成使用；
任务调度及消息队列可以解决账单系统（Bill）复杂的账单任务以及发送可靠的账单消息、支付成功消息给用户。

图中提到的 SOFAStack 产品如下，结合这些产品的能力，我们便能很好地解决普通的分布式小程序带来的问题：