摘要
本文主要介绍当随着业务的不断发展,原本一个服务的内容需要抽象出另外的服务,作为中台服务,提供给各个业务前台,提高前台业务开发效率。
业务架构
随着业务的扩展,一个服务的代码越来越多,启动越来越慢,开发的人数越来越多,不得不进行代码拆分,早期有些拆分是按分层拆分,将data,dao层拆分成公共jar,然后很多服务调用,结果导致的就是后期无法维护,业务增长了,分属于不同的开发组了,本来每个开发组的职责都是内敛的,只开发自己那块的就可以,但是现在对于其他组的业务也得熟悉,因为没有共同的服务提供出来,都是自己查库,写库的逻辑改了,有可能会影响到很多地方。所以正确的做法是各个业务按照领域划分,只负责自己的业务部分。
重构过程
重构过程一般分两大部分,一个部分是收集现有的需求,进行领域模型设计,成为一个中台服务,另外一个部分就是迁已有的代码。
一. 中台领域模型设计
对于一些业界比较成熟的方案,这个是很容易划分职责,区分边界的,比如电商领域,淘宝都有书籍出版出来了,按照订单,支付,商品,库存,计价等中台设计即可。但是对于自己公司本身的业务,这个可能很难找到现成的参考案例,需要找到公司自己的业务人员,沟通来确定领域设计
二. 迁移老代码
一般按照3步走,将迁移服务的影响降到最低
- 迁移写,双写 先迁移写,确保写入中台的部分不会出错,这一步上线了新服务,确保了前台业务调用正常。 同时将老数据迁移 需要有个迁移表,记录两边数据迁移过程 双写是以写入老服务为准,写入新服务异常,出现异常,都是catch注,打入log,记录异常原因
- 迁移读 首先需要将写改为写入新服务为准,老服务备份。 同时将读改为从新服务读
- 下掉写 1,2都没问题后,将写入老服务下掉。
需要说明的时,这种迁移和数据库分库分表的迁移有些不同,第一点数据库分库分表的拆分一般是同库,表结构的一般只是增量变更,不会更改已有设计,而中台通常伴随着的是领域重新设计,从数据库,到服务层都会有变更。
重构经验
- 代码分层 很多时候在开发的时候会烦分很多层,因为就是一个CRUD操作,但是随着业务的复杂,这个就很有必要了
- ut
- bean为不为空说明 bean在各个层级传递时,没有标明是否为空时,重构时很容易出现空指针