1.需求

贝甲基金给用户提供快捷、稳定、安全的基金交易服务。这个项目的重要合作伙伴是恒生电子，它提供的基金业务解决方案的市场占有率很高，雪球基金就是客户之一。

项目预研的时候，部门成员都没接触过基金项目，业务复杂度不好把握。恒生电子派了售后人员介绍了恒生云的架构和业务流程，结合基金业务接口文档，我们对开发方案和可能出现的问题比较清晰了。恒生的解决方案很完善，实现了用户体系、基金交易以及基金行情，并且提供了Windows远程虚拟机，通过可视化的方式配置基金交易。在恒生看来，我们只是它的“API Caller”。

经过评估，我们认为恒生云的服务是成熟、稳定的，但是存在一个情况：

• 恒生云服务可以按需扩容，但是QPS的提升是有限度的，不会改动架构来满足合作方的性能要求。

结合同行的PV数据和未来营销的需要，我们希望在项目第一期的后端服务质量达到：

• 接口服务可用率至少达到99.99%。
• 接口平均响应时间不高于300ms，QPS不低于800。

要做到以上两点，必须把用户的请求尽可能打到我们的系统上，而不能直接透传给恒生云，不然性能瓶颈就在恒生云。

2.详细设计

2.1 微服务架构

基于公司的技术栈和运维资源，我们采用Spring Cloud的相关套件来实现我们的微服务架构，如下图所示：

• 微服务治理：采用Spring Cloud提供的治理套件。
• 微服务网关Kong：在Kong的基础上，定制了用户鉴权和数据加解密功能。
• 监控预警：公司自研监控系统Monitor，原理类似ELK。
• 消息组件：采用RabbitMQ。选择它的原因是公司的运维最熟悉这款MQ。
• 日志采集：架构组提供的ELK，只要日志文件路径合规，就能采集成功。
• MySQL集群：一主两从，读写分离。
• Redis集群：哨兵模式部署，一主两从。
• 阿里云OSS: 存放敏感资料。
• 服务器软硬件：centOS 7.0 / 8核16G

2.2 微服务划分

根据业务领域划分了用户、订单、营销三类服务，每类服务再细分为对外API和核心业务两种，如下图所示：

2.3 微服务网关

Kong是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。

Kong能提供易于使用的RESTful API来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。

我们通过Lua语言定制了Kong的数据加解密功能，算法采用RSA，流程图如下：

通过压测，我们发现开启加解密功能会导致QPS下降50%。预计下一版本采用独立的高性能服务器专门处理数据加解密，但是要评估网络耗时，流程图如下：

2.4 数据一致性

基金交易接口主要有三个：用户开户、购买基金、赎回基金。为了让系统有更大的吞吐量，我们采用消息方式向恒生云发起业务请求，以购买基金订单为例：

• 1. 用户提交订单。
• 2. 后端同步保存订单数据，发送订单消息，返回订单号。
• 3. 后端消费订单消息，提交请求给恒生云。发送延迟消息，5秒后查询订单状态。
• 4. 前端通过订单号轮询订单状态。
• 5. 后端的延迟消息查询到订单结果后，修改订单状态。

订单流程时序图如下：

3.开发问题

• 基金申购接口不支持传递第三方订单号。

基金申购接口不支持合作方订单号，如果提交失败也拿不到恒生订单号，无法通过订单号反查订单状态。沟通后提需求让恒生开发人员修改接口，允许传递我方订单号。

• 代码审查不足

我们规定了对外接口输出字段采用下划线分割单词，但部分接口依然采用驼峰。预计在下一版中统一接口风格，并且提供自动转化工具类。

本文链接：https://www.codingbrick.com/archives/556.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。