交易系统架构演进之路（三）：微服务化

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

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

前言

我们 2.0 版本的交易系统整体架构就如上图所示，划分为了行情服务、客户端服务、撮合服务、管理端服务。行情服务主要对外提供推送行情数据的 API。撮合服务就是一个内存撮合引擎，其输入是一个定序的委托订单队列，而输出包含成交记录和其他各种事件，包括撤单成功、撤单失败、订单进入了 等。撮合服务如果重启，则会从 MySQL 数据库查询出所有未成交订单，重新组成 。客户端服务的核心功能就是接收和处理客户端各种 HTTP 接口请求，管理端则是提供给系统管理人员对整个系统的用户、订单、资产、配置等进行统一查看和管理。

虽然拆解为了 4 个服务，但我觉得，这还不是微服务架构，只能说已经变成分布式架构了，但「分布式」和「微服务」是两个不同的概念。微服务是分布式的，但分布式并不一定用微服务。其实，在实际项目中，从单体应用到微服务应用也不是一蹴而就的，而是一个逐渐演变的过程。而 2.0 版本，只是整个演变过程中的第一个阶段。

现在，好多小团队小项目，一上来就微服务，很多只是为了微服务而微服务，这绝对不是合适的做法。从本质上来说，架构的目的是为了「降本增效」——这四字真言是我从玄姐（真名孙玄）那学来的。项目一开始就采用微服务，一般都达不到降本增效的目的，因为微服务架构应用相比单体应用，其实现成本、维护成本都比单体应用高得多，除非一开始就是构建一个大型应用。

当业务规模和开发人员规模都已经不小的时候，比较适合用微服务，这时候用微服务主要解决两个问题：快速迭代和高并发。当业务和人员规模比较小的时候，用一个或几个单体应用完成整个系统，一般迭代速度会更快。但到了某个临界点，就会开始出现一个或多个痛点，这之后，反而会拖慢迭代速度。

而遇到高并发时，其实，单体应用只要是无状态化的，通过部署多个应用实例，也可以承载一定的并发量。但如果单体应用变得庞大了，承载了比较多业务功能的时候，再对整个单体应用横向扩容，就会严重浪费资源。因为，并非所有业务都是需要扩容的，比如，下单容易产生高并发，需要扩容，但注册并不需要扩容。全部业务都绑定到同个单体中一起扩容，那消耗的资源就会比较庞大。另外，当某一块业务出现高并发，服务器承载不了的时候，影响的是该单体应用的所有业务。因此，拆分微服务就可以解决这些因为高并发而导致的问题。

那么，接下来，就来聊聊我们的交易系统，微服务化的架构是如何逐步演进的。

迭代业务需求

2.0 版本之后，就会进入集中迭代业务需求的阶段了，有大量业务需求有待完善和增加。大的业务板块包括：