入职之后发现代码居然是祖传代码肿么办？（SSH-＞微服务）

🐓 序言：

什么是“祖传代码”？

“祖传代码”通常指的是那些历史悠久、经过多代程序员修改和维护的代码库。这些代码库可能包含大量的历史遗留问题、复杂的业务逻辑和难以理解的代码结构，因此经常被认为是程序员接手项目时的一个巨大挑战。

🐓 故事分享

我刚入职的时候公司让我去做一个功能模块的性能优化，当我把那个模块down下来的时候，我发现公司这个模块的代码上次修改时间是2016年的“远古版本”，我心想使用的肯定不是微服务，再仔细一看，好家伙还不是SSM框架，就知道这次遇到硬茬了，最后实锤是“SSH框架”，只能说单走一个6。

🐓 祖传代码与现代开发的融合

重构目标

主要是确定本模块重构的目标，也就是通过重构，将达到什么样的结果。目标的制定也变的很重要。

1.功能泛化：即让相同的接口支持更加通用的功能，比如将代扣和充值功能完善并重构为支付产品商务系统，建立支付商品，出入库，订单等子系统。

2.功能完善：对现有功能进行完善， 将原来未实现的功能补充完成。 比如建立和完善账户系统，为清结算工作提供支持。

3.性能提升：这是最容易说服人的一个理由了。 比如：在存储上，调整原依赖单一依赖mysql数据库的问题，接口可以根据需求选择合适的数据库，实现读写分离，比如对高性能需求的接口采用内存数据库。

重构策略

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

1.每一个改进点，需在1~3天内完成，不能超过一个周。

2.每次改进，均可直接上线运行，不需要长时间的AB测试。

在功能也就是对外接口不变的前提下，开始进行拆分工作。 在结构上，原SSH系统是一个大项目，所有代码分层分模块堆在一起。微服务系统需要将它们拆分。直观的拆分方法是按层，按模块同构的拆分成各个独立运行和维护的系统。由此带来了一系列的调整。

基于层的全面重构

如果遗留接口不多老板又认可，需要执行全面的系统重构了。 在SSH架构下，重构可以采用自上而下的方法进行，这样可以确保每一层的重构都有明确的输入输出，并且是可测试的。

API网关（接入公司微服务的网关）

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

1.服务在启动完成后，注册到ZooKeeper上。

2.Connector监听ZooKeeper，一旦有变更，则获取服务列表，更新nginx.conf文件。

3.Connector在更新完成nginx.conf文件后，执行Nginx的reload命令，让配置生效。

4.load balancer 将服务打到Nginx上，Nginx可以按照新配置来执行服务路由。

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

服务接口调整

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

1.增加服务注册机制，在服务启动时将服务注册到ZooKeeper上；

2.增加服务退出机制，在服务关闭时将服务解除注册；

3.将服务按照业务组合，建立对应的项目；

4.将服务依赖的业务逻辑层打包到同一个jar中，作为后续改进的基础；

5.服务上线，替换掉现有的服务。

业务逻辑层调整

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

1.抽象为独立的RPC服务，对于功能比较复杂业务逻辑，可以使用这种方式。

2.下沉到DAO层，如果逻辑上涉及数据访问操作多，或者需要事务处理的，可以合并到DAO中，一同实现为RPC。

3.上浮到接口层。如果业务逻辑比较简单，也可以上浮。

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等内存数据库中，读取的时候直接从库中出数据，不能执行实时计算。

当我们如果遇见不同存储之间的同步数据了，该怎么办？

1.使用数据库本身自带的同步机制。好处是一般不需要开发，问题是数据库的同步机制，如MysQL、HBase的Replication机制，仅支持少数类型的备库，对数据库本身也有压力。

2.使用公共同步工具，比如阿里的Canal。

3.使用消息中间件来实现数据同步。

总结

总之，重构往往意味着数据结构的变更，重构往往意味着数据结构的变更，在于对业务的快速上手和熟悉，解决之后对自己的提升也会很高。