背景
系统软件功能和我们的知识框架一样，需要不断迭代完善，有些仅仅涉及到功能实现层面的问题可以通过较小的迭代改动完善，而有些问题是底层架构就决定必然存在，如果要进行修复的话则需要修改架构，改动程度不亚于重新开发。如软件信息树与漏洞管理系统，经过几年的线上使用后，暴露出几个致命问题： （1）性能达到了瓶颈。即使经过各种手段进行优化还是无济于事，分析发现是由于架构层面，通过文件方式在系统不同微服务间进行传输导致多次重复解析引起的；（2）数据不一致。不同微服务间数据是割裂的，从而导致在不同微服务中会重复维护相同数据，在数据更新时是异步操作，页面会从不同微服务读取数据展示，因此用户可能看到不一致的数据。
在用户强烈要求下，架构调整不可避免。
分析
性能瓶颈：首先需要统计，整个流程中各个阶段的耗时；然后分析耗时原因；针对这些原因哪些是调整架构能解决的，哪些是常规优化能解决的。
数据一致性：多个微服务重复维护相同数据的目的是什么？能不能一份数据只在一个微服务中维护？
方案
架构变动
数据迁移
上下半身
上线策略：白名单、引流
用户无感知：最好是先保证功能没有大的变动，切到新系统后，再逐渐调整
数据一致性（数据同步、新旧数据兼容）
用户体验：第一次上一定要保证用户体验，性能至少要跟老系统持平，否则用户后面就不愿意上新系统了
用户试点：可以先切一些友好用户到新系统进行试用，看一下效果
资源申请、环境部署、初始化配置脚本
