首页 ›存档› 技术 › 查看内容

对SSH框架系统进行微服务改进

2018-3-30 13:00 |来自: 互联网 919 0

摘要: 本文假定你已经阅读过之前的文章：为什么要重构到微服务重构中的外部准备工作重构中的内部准备工作使用微服务架构重构支付网关上一篇文章使用微服务架构重构支付网关是从横向的角度来分析如何分解服务以及建 ...

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

为什么要重构到微服务
重构中的外部准备工作
重构中的内部准备工作
使用微服务架构重构支付网关

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

选取入手模块

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

重构策略

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

每一个改进点，需在1~3天内完成，不能超过一个周。
每次改进，均可直接上线运行，不需要长时间的AB测试。
在功能也就是对外接口不变的前提下，开始进行拆分工作。在结构上，原SSH系统是一个大项目，所有代码分层分模块堆在一起。微服务系统需要将它们拆分。直观的拆分方法是按层，按模块同构的拆分成各个独立运行和维护的系统。由此带来了一系列的调整。在SSH架构下，重构可以采用自上而下的方法进行，这样可以确保每一层的重构都有明确的输入输出，并且是可测试的。整体上，重构分为三个步骤：

参考原有系统的DAO层和业务逻辑层，实现基础服务，一般是使用RPC来实现.
将对外的接口层进行重构，调整为调用RPC服务。
将原有服务切一部分流量到新服务上进行试运行。
试运行成功，全部流量都切过来。旧服务废弃。

API网关

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

针对这个需求，我们开发了一个connector，其工作原理如下：

服务在启动完成后，注册到zookeeper上。
connector监听 zookeeper，一旦有变更，则获取服务列表，更新nginx.conf文件
connector在更新完成nginx.conf文件后，执行nginx的reload命令，让配置生效。
load balancer 将服务打到nginx上，nginx可以按照新配置来执行服务路由。

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

服务接口调整

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

增加服务注册机制，在服务启动时将服务注册到zookeeper上；
增加服务退出机制，在服务关闭时将服务解除注册；
将服务按照业务组合，建立对应的项目；
将服务依赖的业务逻辑层打包到同一个jar中，作为后续改进的基础。
服务上线，替换掉现有的服务。

业务逻辑层调整

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

抽象为独立的RPC服务，对于功能比较复杂业务逻辑，可以使用这种方式。
下沉到DAO层，如果逻辑上涉及数据访问操作多，或者需要事务处理的，可以合并到DAO中，一同实现为RPC。
上浮到接口层。如果业务逻辑比较简单，也可以上浮。

DAO层的重构

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

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

性能优化

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

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

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