交易系统架构演进之路（二）：2.0版

欢迎关注「Keegan小钢」公众号获取更多文章

---

交易系统架构演进之路（一）：1.0版

---

回顾 1.0 版

我们来回顾下 1.0 版 的内容，需求上经过分析，最终 1.0 版只是做一个 MVP——最小可行性产品，只完成最简化的核心流程，即：注册 ——> 登录 ——> 入金 ——> 交易 ——> 出金 。架构设计上，从 API 设计到关键流程设计，再到数据库设计，最后服务端的设计，基本都以节省开发成本为考虑因素，采用了最低成本的设计方案。

总的来说，MVP 版本整体设计是前后端分离的。API 统一采用 HTTP 通信协议 + JSON 传输协议，并加上 TLS 对传输数据进行加密。用户鉴权采用了 JWT 方案，可实现为无状态化。API 接口总共定义了 19 个，按业务领域划分为了 用户、账户、交易、行情 4 个模块。查询类的读请求统一用 GET 方法，非查询类请求统一用 POST 方法。实现流程上，也没用缓存，没用 MQ 等中间件，数据库只用了 MySQL，交易撮合也采用了实现简单的数据库撮合的方案。接入了两个第三方平台，一个是阿里云邮箱推送平台，用于发送邮件；一个是用于对接以太坊区块链的 infura 平台。数据库设计方面还提了一些设计规范和原则，按照 DDD 的设计思想，最后设计出了 9 张表。服务端是个单体应用，内部采用了简单的三层架构，分为了 API 层、Service 层、DAO 层。

整体的架构图大致如下：

这 1.0 版本，专业的人应该能看出来，存在一些比较重要的问题有待解决：

• 有些业务功能是缺失的，包括找回密码、修改密码、退出登录、KYC 认证（实名认证）、管理后台。
• 还有些待完善的业务，包括增加更多交易对、增加更多周期的 K 线图数据。
• 接口轮询请求行情数据，并从数据库读取，延迟高、效率低、性能差。
• 数据库撮合的性能太差。

接下来，我们就来研究下解决这些问题的设计方案。

迭代业务需求

对于缺失的业务功能，找回密码、修改密码、退出登录，这几个就是单纯地增加 API 接口并实现业务逻辑即可，很简单。KYC 认证需要上传证件照片，可以接入一个第三方的文件存储服务。管理后台目前比较重要的功能应该包括：用户管理、KYC 审核、提现审核、订单管理、交易对管理等。

而待完善的业务功能，增加更多交易对的支持，主要也是对接多几个主流的区块链 API，如今主流区块链基本都有比较成熟的第三方 API 的，接入也比较容易。增加更多周期的 K 线图数据也简单，根据不同周期的计算公式将数据累加计算并记录即可。

下面，还有相关的其他一些比较重要的设计点需要进行补充。

先对密码相关的设计进行补充，从用户在客户端输入密码，到网络传输，再到服务端数据存储，在整个流程中，为了保证密码的安全性，最佳实践的方案应该是怎样的？以下是我总结出来的几个要点：

1. TLS 是基础；
2. 密码再进行单独加密，加密算法要用非对称加密，比如 RSA、ECC；
3. 如果用户登录时密码错误，那错误提示语不要直接提示“密码错误”，只需要给出一个大概的提示，比如“用户名或密码错误”；
4. 密码错误次数连续超过 N 次，比如 6 次，则将用户锁定一段时间；
5. 数据库用 慢哈希 + Salt 的方案进行存储，不同用户用不同 Salt 值，慢哈希算法主要有：Argon2、Scrypt、Bcrypt、PBKDF2；
6. 增加多重校验，比如登录设备检测、指纹识别、人脸识别、手机验证码等。

不少人觉得已经有 TLS 就可以不对密码再进行单独加密了，这其实是不对的。TLS 能保证的只是传输过程中第三方抓包看到的是密文，但防不了在客户端和服务端截取数据的黑客，要在服务端截取数据比较难，但在客户端截取还是比较容易的。最简单的，你在浏览器访问知乎、京东等知名网站并用抓包工具抓取请求，就会发现，虽然是 HTTPS 请求，但看到的数据并非密