23 重构：烟囱式、平台化、中台化的架构

上一讲里，我们介绍了两大类型的系统升级重构方案，还介绍了如何进行重构版本的上线，以及如何平滑地完成新老版本切换的方案。在本讲里，将会具体介绍如何判断系统发展到什么阶段需要重构，以及如何实施重构。

系统稳定性的重构升级

简单、通用的微服务架构如下图 1 所示，它包含一个应用服务和一个数据库作为存储。

图 1：简单、通用的微服务架构图

当上图中展示的架构出现如下一些问题时，可以采用上一讲中提到的“微服务中纯代码维度的升级重构”。

• 代码日志打印冗余，且因为直接使用大对象进行 JSON 序列化的方式打印日志，进而导致常常出现 CPU 飙升。

• 代码中未增加监控报警，导致用户先感知线上问题，研发再进行修复。

• 代码可维护性低，开发需求耗时长，且开发时代码“牵一发而动全身”，产生的 Bug 较多。具体的一些表现是：

（1）一个类中有上千或者上万行代码；

（2）一个类中的某一个方法有上百或者上千行代码；

（3）代码中没有注释；

（4）为了防止影响历史业务，新需求开发均需将原有部分能复用的代码拷贝后，才能修改。

此时，可以将出现上述问题的微服务进行代码重构。具体来说，可以采用 23 种设计模式、SOLID 原则将包含上千上万行代码的类进行重