论微服务架构设计及其应用

摘要

  2021年3月，我参与了某金融科技公司的基金网上交易系统的开发工作。系统旨在为不同层次用户提供优质的在线挑选并购买基金的服务，主要包括开户、风险测评、交易下单、资产明细查询、电子合同签署等功能。我在项目中担任系统架构师，主要负责系统的架构设计和技术选型。本文以基金网上交易系统为例，主要论述了微服务架构在项目中的具体应用。系统在进行细粒度的服务拆分后，使用Zookeeper作为注册中心实现了服务注册与发现，各服务通过RPC的方式进行调用，通信时使用轻量级的Rest协议和Json数据格式，部分服务使用了不同的技术实现并进行了水平扩展，同时系统还引入了RabbitMQ、Redis、Seata等中间件解决具体问题。最终系统顺利上线，取得用户一致好评。

正文

  近几年来，基金市场逐渐变得火爆，部分基金的管理规模突破千亿大关，购买基金的人也越来越多。鉴于业务量的暴增，我司现有的基金网上交易系统已不能满足客户的需求，于是在2021年3月决定对原有系统进行升级改造，后续逐步将客户数据迁移到新的系统。原有系统采用的是单体架构，所有业务功能模块耦合在一起，修改某个功能时往往涉及到多个模块，工作难度高，且单个功能模块很难在水平方向进行按需扩展，系统每次发版变得十分“臃肿”。经过讨论分析，我们决定采用微服务架构对系统进行升级改造。
  微服务架构将单个应用划分为多个细粒度的服务组件，各服务间通过轻量级的通信协议进行交互，其特点有：1、单个服务的功能职责单一，支持独立开发、测试与部署，配合mock技术使得多个服务的开发可以并行，提升开发效率；2、具有技术异构特性，每个服务可采用不同的技术选型，开发人员不再受技术限制，提升开发质量；3、故障隔离，单个服务故障并不会影响整个系统的运行，避免了单点故障；4、弹性伸缩，单个服务可以很容易在水平方向进行扩展，减少并发成本。下面我将以基金网上交易系统为例，论述项目中涉及到的微服务架构及其应用。
  1、 服务拆分与交互
  网上交易系统主要包括开户、风险测评、基金列表查询、交易下单、资产明细查询、交易记录查询、电子合同签署等功能，根据不同的业务功能，我们将系统划分为账户服务、产品服务、交易服务和电子签章服务。其中，账户服务负责集中管理用户信息；产品服务主要负责导入基金行情数据，数据来源包括直销系统、数据中心和其他三方数据源等；交易服务负责处理下单请求，包括申购、认购、赎回等；电子签章服务负责对接其他签章平台，实现交易下单时用户需要签署合同的功能。一个服务交互的例子是申购下单时调用电子签章服务，这是一个典型的同步调用场景，交易服务属于服务调用方，电子签章服务属于服务提供方。具体我们使用Dubbo框架实现服务的透明RPC调用，服务通信时采用Rest协议，数据格式选用Json格式，二者都属于轻量级的代表，增加了服务间通信的效率。除此之外，也存在一些异步调用的场景，例如多个产品服务间的基金内存缓存同步，这里我们采用了消息队列RabbitMQ的发布-订阅模式，实现一个服务发布新的基金信息，所有服务更新基金缓存的功能。
  2、 服务注册与发现
  在服务拆分的基础上，单个服务直接寻址访问其他服务是不现实的，故需引入注册中心实现服务的统一管理。具体的，我们选用了Zookeeper作为注册中心，各服务在启动时，根据配置的注册中心参数，将自身需要暴露的服务提供给Zookeeper作为服务提供方，并与之维护一个“心跳”连接，以实现当服务挂掉时及时更新注册信息的目的，这也是实现微服务熔断降级功能的基础。当一个服务需要调用其他服务时，先访问注册中心获取服务提供方的地址，然后服务调用方根据获取的地址与服务提供方建立连接并交互。但当服务数量增加时，通过命令行和日志的方式去维护服务注册信息同样是不现实的，故我们引入了ZkUI插件对服务注册信息进行了网页端的可视化管理，减少了运维压力。此外，我们通过引入全局一致的traceId，实现了每次服务调用的全链路追踪，增加了系统故障时快速定位和排查问题的能力。同时为了避免注册中心的单点故障问题，我们使用双机热备技术部署了主从两台Zookeeper服务器，当主服务器宕机时从服务器能自动完成替换操作，从而保证业务系统的不间断执行。
  3、 技术异构与服务扩展
  微服务统一了各服务的API标准，并通过规范的通信协议进行通信，这使得每个服务可以使用不同的技术实现具体的业务功能，极大地增加了系统的灵活性。例如，产品服务存储了大量的基金数据，查询请求频繁，故我们选用了性能较高的Oracle数据库；而电子签章服务的数据量较少，我们选用了开源的mysql数据库，以减轻服务器压力。同时，微服务架构使得我们可以很方便地对系统中并发量较高的服务进行水平扩展，这得益于前文中提到的对服务的细粒度划分。具体的，鉴于业务场景考虑，大量的请求来自基金列表查询和基金详情数据的浏览，以及基金交易下单，于是我们对产品服务与交易服务进行了水平扩展，二者均同时部署在两台不同的服务器上，以减轻系统的并发压力。而在扩展后，同一个服务会存在多个提供方，我们采用负载均衡机制对每次服务调用请求进行分发，具体的负载均衡算法采用了加权轮询法，通过给不同配置的物理机器设置不同的权重，使得每个机器的资源都能得到充分利用。
  历时10个月的开发，系统最终于2022年1月正式上线，目前仍在正常运行，并受到用户的一致好评。项目实现过程中也遇到了一些问题，例如微服务在分布式环境下带来的分布式事务问题，我们通过引入开源的分布式事务中间件Seata，使用侵入性较低的AT模式，对部分业务代码进行了改造，依靠经典的二阶段提交法解决了该问题。又例如接口幂等性问题，尤其是交易类接口，即使前端进行了一定程度的拦截，但仍有可能出现重复提交的问题，我们通过将用户标识、接口标识与序列化入参的组合作为唯一标识存入Redis中，并设置相应的过期时间，根据唯一标识对重复提交进行拦截，从而解决了该问题。
  实践证明，一个系统的稳定运行离不开良好的架构。经过这次对微服务架构的应用，我加深了自己对服务拆分、服务治理和服务容错等技术的理解，也加强了自身面对未来各种技术挑战的信心。