代码重构-业务中台化

摘要

本文主要介绍当随着业务的不断发展,原本一个服务的内容需要抽象出另外的服务,作为中台服务,提供给各个业务前台,提高前台业务开发效率。

业务架构

随着业务的扩展,一个服务的代码越来越多,启动越来越慢,开发的人数越来越多,不得不进行代码拆分,早期有些拆分是按分层拆分,将data,dao层拆分成公共jar,然后很多服务调用,结果导致的就是后期无法维护,业务增长了,分属于不同的开发组了,本来每个开发组的职责都是内敛的,只开发自己那块的就可以,但是现在对于其他组的业务也得熟悉,因为没有共同的服务提供出来,都是自己查库,写库的逻辑改了,有可能会影响到很多地方。所以正确的做法是各个业务按照领域划分,只负责自己的业务部分。
这里写图片描述

重构过程

重构过程一般分两大部分,一个部分是收集现有的需求,进行领域模型设计,成为一个中台服务,另外一个部分就是迁已有的代码。

一. 中台领域模型设计
对于一些业界比较成熟的方案,这个是很容易划分职责,区分边界的,比如电商领域,淘宝都有书籍出版出来了,按照订单,支付,商品,库存,计价等中台设计即可。但是对于自己公司本身的业务,这个可能很难找到现成的参考案例,需要找到公司自己的业务人员,沟通来确定领域设计

二. 迁移老代码
一般按照3步走,将迁移服务的影响降到最低

  1. 迁移写,双写
    先迁移写,确保写入中台的部分不会出错,这一步上线了新服务,确保了前台业务调用正常。
    同时将老数据迁移
    需要有个迁移表,记录两边数据迁移过程
    双写是以写入老服务为准,写入新服务异常,出现异常,都是catch注,打入log,记录异常原因

  2. 迁移读
    首先需要将写改为写入新服务为准,老服务备份。
    同时将读改为从新服务读

  3. 下掉写
    1,2都没问题后,将写入老服务下掉。

需要说明的时,这种迁移和数据库分库分表的迁移有些不同,第一点数据库分库分表的拆分一般是同库,表结构的一般只是增量变更,不会更改已有设计,而中台通常伴随着的是领域重新设计,从数据库,到服务层都会有变更。

重构经验

  1. 代码分层
  2. ut
  3. bean为不为空说明

在这里插入图片描述

©️2020 CSDN 皮肤主题: Age of Ai 设计师: meimeiellie 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值