同样是笔记摘录自---极客时间 李运华 《从0开始学架构》。
系统的架构是不断演化的，少部份架构演化可能需要推倒重来进行重写，但绝大部份的系统是通过架构重构来实现的。相比全新系统的架构设计，重构的特殊困难主要体现在：1、业务已经上线，必须保证其正常（至少是照旧，不能更差）运行 2、关联方众多，至少已经有用户在用、运维人员、老板等已经关注；3、新架构必然受到原有架构限制：例如必须考虑旧架构的数据重用或迁移、既有的一些组织结构和人员工作习惯。
所有演化架构的步骤：
1、梳理问题，做到有的放矢。
首先收集系统存在的问题，这一步一般简单，会采到一堆问题，不然就不用重构了；关键是接下来要把问题进行归类，分析出来关键的和需要重点解决的。当然一些问题应该通过优化解决；一些问题是必须采购扩容的；最后一般最难啃的就是要动架构的。把这些架构重构的罗列出来，但别期望一次性解决所有问题。找出最关键的，一般一次重构周期不要超过3个月。可以通过不断演化来逐步解决问题。
2、沟通协调，争取资源支持。
这就是一个合纵连横的事情，要让相关方同意架构重构这件事情，让大家听得明白、看得到好处、干得心甘情愿。
3、分步实施，阶段展现效果。
其实就是前面说的，不要期望一次性解决所有问题，要每一步都让人看到成果。策略如下：
3.1.优先级排序
将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题。例如，架构重构前，先做一些基础性的优化。不要让系统隔三差五出大问题，导致重构项目组的人要同时话费大量的人力和精力去救火，而没法集中精力做重构的事情．
3.2. 问题分类
将问题搜照性质分类，每个阶段集中解决一类问。 例如，X 系统的第二阶段，我们将多个底层 系统切换到公司统一的公共组件，提到整体可用性．
3.3. 先易后难
一般不建议一上来就解决最难的问题，原因是：
- 一开始就做最难的部分，会发现想要解决这个最难的问题，要先解决其他容易的问题．
- 最难的问题解决起来耗时都比较麻烦，占用资源比较多，不容易出成果，时间长了，会影响相关人员对项目的评价和看法，也可能影响团队士气．
- 刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错
而先易后难恰恰有相对的好处：容易见成果，提升士气，形成正反馈。而且有些问题在逐步演进中消失了。
3.4.循序渐进
按照前 3个步骤划分了架构重构的实施阶段后，就需要评估和重新划分工作量。一般尽量把不同阶段的工作计划分解均匀，
按照固定的步骤和节奏，更有利于项目推进 。建议每个阶段在1~3个月，如果评估超过 3个月的，那就再拆为更多阶段。每个阶段还可以划分任务子集，当任务子集比较小的时候，多个任务子集可以并行；当任务子集比较大的时候，就当成一个独立的里程碑推进。其实有点类似SCRUM的以周为单位的工作。
