天画项目-Idgenerator的开源重构（下）

一、背景&痛点

1.1 背景

我在建设一个租房平台，进行基于租房业务的架构实践。在写业务代码的时候发现我需要一个ID生成器用于生成各种ID和单据编号信息。上篇已经说到我找到了一个比较中意的开源项目，并且已经进行了本地化搭建，相对顺利的看到了效果。

1.2 痛点

简单进行尝鲜之后便开始了下一步操作，由于租房业务架构的springboot/cloud版本跟id-generator的版本不一样，同时不支持nacos服务注册，因此这里需要进行改造，或者使其支持nacos注册中心，但是支持的过程并不顺利，在id-generator的分支上改完之后各种不兼容，同时发现代码中的spring bean大部分都是采用构造器注入，service服务层之间的耦合严重，不利于维护。另外一方面由于支持redis和mysql存储，但是缺点在于这种支持也耦合在了单个工程中，只是通过配置进行动态区分，因此增大了维护成本。

二、优化 or 重构

2.1 方案一

主要思路：将id-generator的代码从github上fork一份代码到gitee上，拉取创建新分支，并进行nacos注册中心支持。

优点：兼容官方版本，后续可以合并到官方master中。

缺点：改造成本比较高，涉及到多个服务，同时与已有的租房项目的springboot版本不统一。另外代码维护成本仍然存在。

2.2 方案二

主要思路：将id-generator的代码从github上fork一份到gitee上，同时创建新的代码仓库idgenerator，分别对id-generator中的工程进行迁移改造，同时创建新的子工程，通过架构改造的方式将支持mysql和redis的存储逻辑拆开，独立为两个子工程，打成jar,在使用上面更加灵活容易维护。

优点：改造之后代码更容易维护，增加对整个id-genrator工程核心原理的理解，架构上更加灵活。支持nacos注册中心。

缺点：改造工程量相对比较大，同时可能带来代码漏迁，错迁的风险。如果迁移失败则可能需要放弃这个项目，另寻他法。

2.3 综合决策

经过两个方案的评估，决定采用方案二。原因有以下几点：

1. 方案二可以帮助了解整个项目的源码和核心流程，便于后续在上面增加新特性
2. 由于我已经翻了几次这个项目的源码，同时也知道哪些地方是重点需要调整的，因此改造上难度不高
3. 如果进行改造的话成功了则可以增加参与开源的经验，同时提高修改源码的能力，提高掌控大规模工程的能力
4. 最重要的一个原因是我有信息搞定它

但是也需要正视方案二中的缺点。这里做了一些策略：

1. 优先从核心层进行迁移
2. 迁移之前评估并记录改造点
3. 代码迁移之后对整个pom.xml进行依赖，版本梳理，向租房项目的版本栈进行靠拢
4. 一边迁移一边测试
5. 需要新建的工程需要等到整体pom.xml调整完毕才能开始

三、成果

这里对改造后的工程架构进行简单描述。

3.1 新的工程架构

这里对上图中的工程模块进行一下说明：

1. 增加的模块：

nacos:这里用来替代上篇文章提到的simple工程，作为idgenrator工程的对外api服务，基于nacos注册中心

mysql:这里将对mysql的支持单独作为一个工程，可以动态切换

redis:这里将对redis的支持单独作为一个工程，上图右侧的模块依赖图是默认集成了redis模块

parent:这里做一个空壳的父级工程，统一pom.xml

    2. 去除的模块：

app:原有的app模块支持了dubbo和zk,euraka等，但是在租房架构中的注册中心和技术栈中，这些模块暂时用不到，因此去掉了

plugin:这个模块其实有点鸡肋，虽然相对方便了，但是也增加了使用成本或者理解业务代码的成本，所以可以进行精简

demo:这个模块演示了基于springcloud,dubb,feign的简单样例，但是代码太少，参考价值不大，可以精简

3.2 遗留问题

在重构改造完成之后，基本已经达到了改造的目的了，但是在测试上面还不太全面，因此可能存在一些潜在问题。后续进行跟进。

改造之后的开源git地址：https://gitee.com/sky-painting/idgenerator

我最近整了一个公众号，持续输出原创内容，敬请关注：