三 交易系统架构演进之路:微服务化

交易系统架构演进之路(一):1.0版
交易系统架构演进之路(二):2.0版
前言

三  交易系统架构演进之路:微服务化

文章插图
我们 2.0 版本的交易系统整体架构就如上图所示,划分为了行情服务、客户端服务、撮合服务、管理端服务 。行情服务主要对外提供推送行情数据的API 。撮合服务就是一个内存撮合引擎,其输入是一个定序的委托订单队列,而输出包含成交记录和其他各种事件,包括撤单成功、撤单失败、订单进入了等 。撮合服务如果重启,则会从 MySQL 数据库查询出所有未成交订单,重新组成。客户端服务的核心功能就是接收和处理客户端各种 HTTP 接口请求,管理端则是提供给系统管理人员对整个系统的用户、订单、资产、配置等进行统一查看和管理 。
虽然拆解为了 4 个服务,但我觉得,这还不是微服务架构,只能说已经变成分布式架构了,但「分布式」和「微服务」是两个不同的概念 。微服务是分布式的,但分布式并不一定用微服务 。其实,在实际项目中,从单体应用到微服务应用也不是一蹴而就的,而是一个逐渐演变的过程 。而 2.0 版本,只是整个演变过程中的第一个阶段 。
现在,好多小团队小项目,一上来就微服务,很多只是为了微服务而微服务,这绝对不是合适的做法 。从本质上来说,架构的目的是为了「降本增效」——这四字真言是我从玄姐(真名孙玄)那学来的 。项目一开始就采用微服务,一般都达不到降本增效的目的,因为微服务架构应用相比单体应用,其实现成本、维护成本都比单体应用高得多,除非一开始就是构建一个大型应用 。
当业务规模和开发人员规模都已经不小的时候,比较适合用微服务,这时候用微服务主要解决两个问题:快速迭代和高并发 。当业务和人员规模比较小的时候,用一个或几个单体应用完成整个系统,一般迭代速度会更快 。但到了某个临界点,就会开始出现一个或多个痛点,这之后,反而会拖慢迭代速度 。
三  交易系统架构演进之路:微服务化

文章插图
而遇到高并发时,其实,单体应用只要是无状态化的,通过部署多个应用实例,也可以承载一定的并发量 。但如果单体应用变得庞大了,承载了比较多业务功能的时候,再对整个单体应用横向扩容,就会严重浪费资源 。因为,并非所有业务都是需要扩容的,比如,下单容易产生高并发,需要扩容,但注册并不需要扩容 。全部业务都绑定到同个单体中一起扩容,那消耗的资源就会比较庞大 。另外,当某一块业务出现高并发,服务器承载不了的时候,影响的是该单体应用的所有业务 。因此,拆分微服务就可以解决这些因为高并发而导致的问题 。
那么,接下来,就来聊聊我们的交易系统,微服务化的架构是如何逐步演进的 。
迭代业务需求
【三交易系统架构演进之路:微服务化】2.0 版本之后,就会进入集中迭代业务需求的阶段了,有大量业务需求有待完善和增加 。大的业务板块包括: