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

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

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

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

• 代码日志打印冗余，且由于直接使用大对象进行 JSON 序列化的方式打印日志，进而导致常常出现 CPU 飙升。
  
  
• 代码中未增加监控报警，导致用户先感知线上问题，研发再进行修复。
  
  
• 代码可维护性低，开发需求耗时长，且开发时代码“牵一发而动全身”，产生的 Bug 较多。具体的一些表现是：
  

（1）一个类中有上千或者上万行代码；
（2）一个类中的某一个方法有上百或者上千行代码；
（3）代码中没有解释；
（4）为了防止影响汗青业务，新需求开发均需将原有部分能复用的代码拷贝后，才气修改。
此时，可以将出现上述问题的微服务进行代码重构。具体来说，可以采用 23 种设计模式、SOLID 原则将包罗上千上万行代码的类进行重

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。