我有幸参与了一个中型数字货币交易平台的架构设计和开发。 从平台产品设计、架构选型、系统设计开发历时半年多时间。 在这个过程中，我踩过很多坑，也学到了很多知识。 ，在这里我想和大家分享一下当时的架构设计、技术选型过程以及经验教训。
先说业务架构设计。 数字货币交易平台一般包括三个子系统：门户网站、会员端交易系统（PC网页版+手机APP版）和运营平台。
门户网站主要是品牌展示的简单内容。 核心内容是实时市场行情的展示。 它对性能要求不高，因此不涉及太多技术：
会员终端一般包括网页版和移动版。 您可以根据不同的需求选择一种。 核心模块主要包括登录注册、行情查看、交易订单、账户管理、存取款等功能，交易类型可配置和删除。 根据配置是根据交换机所在地的法律要求进行配置的。 一般包括币币交易、法币交易、衍生品交易等，详细功能设置如下：
操作平台用于交易平台的日常操作。 一般包括产品管理、交易管理、资产管理、会员管理、一些基础用户、权限、数据字典功能、报表分析系统等光学模块来辅助运营：
我们来谈谈技术架构设计。 交易平台的技术架构主要考虑安全性、分布式、易扩展、容错、低延迟、高并发等特性。 我们考察了比较主流的分布式微服务架构、熔断机制、服务注册与发现、消息服务、服务网关、安全认证、内存数据库、关系数据库等选项，最终得出以下技术选型：
1. 分布式基础设施和Dubbo之间进行选择。 由于团队经验较多，更容易招募程序员，有利于系统的长期运维升级。 也是基于开发，比较友好，所以选择了，其实由于阿里巴巴系统的影响力比较强，Dubbo在国内的使用比较广泛，不同的团队可以根据自己的情况进行选择。
2、引入断路器作为容错保护模块，防止单个服务的故障耗尽整个配套系统容器的线程资源，避免分布式环境下出现大量级联故障。 当通过第三方客户端访问依赖服务失败、被拒绝、超时或短路时，执行回退逻辑。
3、用它作为服务注册和发现中心，实现中间层服务，实现负载均衡和中间层服务故障转移。
4、服务网关Cloud和Zuul的选择，我选择Zuul，因为名字比较短。
5、引入安全认证模块，构建安全的应用和服务。 基于Boot和 ，可以快速创建和实现常见的安全认证方法，例如单点登录、令牌中继、令牌交换等。
6、引入Redis作为内存数据库，同时兼作系统数据缓存和内存计算。
7.将其用作关系数据库。 这是因为合伙人恰好是合伙人。 其实当时在关系数据库的选型上也考虑过阿里云。 性能测试非常通过，对于熟悉MYSQL的程序员来说非常友好。 但由于考虑到2018年才投入商用，为了降低选型风险，最终被放弃。
8、采用消息队列中间件MQ，因为团队有使用经验。
综上，经过多次选型会议和讨论，最终的应用技术架构如下图所示：
最后是匹配模块。 我们的撮合上报流程使用netty进行推送，分布式异步非阻塞处理，内存撮合，写入操作使用事务日志同步写入，数据库持久化使用异步线程操作。 整体表现还可以。 吞吐量可达每秒约2W笔交易，单笔交易延迟约100ms。 详细的绩效指标详见绩效报告。 我记不太清楚了。 具体匹配流程如下：
对于撮合交易系统来说，交易吞吐量和延迟始终是核心指标。 根据公开信息（参考这里：/index.php/2019/12/18/2632/）欧意交易所，业内最好的应该是OKEx（okex.me/）平台的2.0撮合系统。 其系统消息传输采用类似于Dubbo的二进制消息格式，消耗的带宽更少。 其解析速度和运行效率均高于传统文本格式HTTP协议。 根据自己基于香港服务器的实时测试和系统数据统计，平均ACK延迟为25ms，平均Live延迟为63ms，平均延迟为180ms，峰值订单处理能力为10万笔/秒，与全球证券市场主流交易系统相媲美。 但毕竟是全球交易量最大的区块链数字资产交易平台，和我参与的平台没有太大可比性，我们的合作伙伴没有这么大的交易量预期欧意交易所，也没有这么高的业绩要求。
以下是2.0的性能指标：
网友评论