本文假定你已经阅读过之前的文章:

上一篇文章使用微服务架构重构支付网关 是从横向的角度来分析如何分解服务以及建立微服务之间的关系。这篇文章从纵向详细介绍如何对SSH框架的支付系统实施具体的技改。这里不涉及具体代码写法,重点在于说明方法论。虽然以SSH(Apache Struts + Springframework + Hibernate) 框架为例,也适合各种常用的web架构 (Apache Struts/Spring MVC / Apache Velocity + Springframework + Mybatis/Hibernate) 。

选取入手模块

如果遗留系统规模庞大,那应该如何挑选入手点?以支付系统为例,如前文所述,支付系统一般包括账户,交易,订单,优惠券,钱包,支付渠道,清结算,支付网关,运营系统等模块。模块很多,如何选择突破点? 我们采取的方法是寻找对外依赖最小的模块,由此开始调整。 首先模块依赖关系整理出来。 Image of Portal System 从上图可以看出来,账户系统在依赖树中是处于树根的位置,对它的调整相对容易。只要保持对外接口不变即可。

重构策略

重构如同飞行中更换引擎,必须非常小心,我们采取的策略是:小步快跑,积小胜为大胜。

API网关

在SSH架构下,对API网关一般是通过NGINX的rewtite模块来实现,逻辑简单,人工维护即可。而一旦接口层按照业务来拆分后,网关路由逻辑复杂多了,通过人工维护配置文件难度激增,需要调整成自动注册更新路由的方式。也就是每个服务需要将自己提供的服务和API注册到API网关上, API网关需要自动识别并加载新的路由。

针对这个需求,我们开发了一个connector, 其工作原理如下: Image of Portal System

在服务关闭时,执行类似的操作。第一步是在服务关闭前,将服务从zookeeper上删除。注意必须在服务关闭前删除,否则会发生服务不可用的错误。 服务注册项从zookeeper上删除,并且本地服务没有流量后,才能关闭服务。connector可以和nginx部署在同一台机器上。

服务接口调整

使用Spring MVC实现的Controller或者使用Apache Struts实现的Action,需要按照业务进行组合,拆分到具体项目中,原则上,一个项目不应该有超过5个接口,避免接口过于复杂。本次调整需要做的工作包括:

业务逻辑层调整

在springframework框架下,业务逻辑层被实现为服务层和DAO层之间的桥梁。 对于绝大多数应用来说,业务逻辑层都是非常薄的一层封装,调整为微服务架构下,业务逻辑层有三种处理方式:

DAO层的重构

DAO层的重构的工作量比较大。 需要将原来访问数据库的逻辑,调整为远程RPC调用:

  1. 针对DAO的接口,开发RPC服务,将数据访问逻辑通过RPC来隔离;
  2. 提供DAO的RPC接口客户端,替换原DAO服务接口的实现。
    这样在业务逻辑层和服务层中调用的DAO,调整为RPC调用,将数据访问逻辑和业务逻辑分离。这样在DAO层就可以根据业务需要选用合适的存储数据库。

性能优化

完成上述调整,这才是万里长征走完的第一步。接下来就是码农们最心爱的性能优化了。 对于大部分线上应用来说,性能优化主要的工作是选择合适的存储介质来满足性能的需求。

  1. 数据可以直接写入MySQL或者其他的持久化存储。这个库也会被称之为主库。但是如果写入性能要求高,可以调整为先写入内存数据库,再同步到持久化存储中。
  2. 线上数据访问,指根据ID或者其他的某个属性值来读取1-2条数据。一般不要直接从MySQL等持久化存储中出,需要采用couchbase,redis等内存数据库。
  3. 线上数据检索,检索和访问需要分开。按照关键字、时间等条件的检索,一般用Elastic来满足。
  4. 线上数据列表,如最新、最热、推荐等,都需要将数据预先计算好,放在couchbase或者redis等内存数据库中,读取的时候直接从库中出数据,不能执行实时计算。
    通过这几个步骤,就可以优化线上服务的性能,最终呢,瓶颈应该不是在数据库或者CPU上,而是在带宽上。 那这就是砸钱的商务行为了。 这样处理,带来的最大的问题是空间浪费,是典型的以空间换时间的做法。 技术上的挑战,那就是数据一致性问题。 对于一致性要求不强的需求,这个做法是没问题的。 那如何在不同存储之间同步数据呢?主要的做法有:

  5. 使用数据库本身自带的同步机制。好处是一般不需要开发,问题是数据库的同步机制,如MysQL、HBase的replication机制,仅支持少数类型的备库,对数据库本身也有压力。
  6. 使用公共同步工具,如阿里的canal。
  7. 使用消息中间件来实现数据同步。

采用消息中间件目前主流的做法,适合于对数据实时性要求不高的场景。 如下图所示,在数据写入的服务中,完成写入后,抛出消息。其他数据库通过接受消息来更新数据。 优点是系统灵活,无论是同DC还是跨DC的情况都可以正常工作。 对数据同步的情况,可以通过MQ提供的监控系统也能够了解。 缺点是开发工作量大,数据同步实时性不高。 Image of Database Sync

如果时间不够

上述重构是非常理想的场景了,那如果时间不足,只能部分重构,应该如何处理?一种方式是针对DAO层来改进。 一般来说,重构往往意味着数据结构的变更。另一方面,由于数据写入的服务相对数据读取服务要少得多,所以可以采用的策略是:

  1. 调整DAO服务中数据写入操作,将数据写入到新的库表中;
  2. 采用MQ来实现新库表和老库表的数据同步。 参见上图。
  3. 老的DAO服务中数据读取的操作保持不变。

毕竟大部分的服务并不需要太高的性能需求。 只需要将性能要求高的服务进行重构,实现读写分离即可。重构方式如上描述。

总之,技改的难度在于如何梳理出头绪来。 本文算是抛砖引玉,欢迎大家热烈讨论。