架构师需要具有5项技能：沟通，判断，技术，管理，决策
相比全新的架构设计来说，架构重构对架构师的要求更高，主要体现在：
业务已经上线，不能停下来
关联方众多，牵一发动全身
旧架构的约束
业务上要求架构师能够说服产品经理暂缓甚至暂停业务来进行架构重构；
团队上需要架构师能够与其他团队达成一致的架构重构计划和步骤；
技术上需要架构师给出让技术团队认可的架构重构方案。
重构时要做好预备方案，保证新旧系统并行，时间可控，做好切换时的风险控制
1 重构一：找准核心问题
首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。
重构案例1：解决不合理的耦合
可重构为：
重构案例2：解决全局单点的可用性问题
可重构为：
重构案例3：解决大系统带来的开发效率问题
可重构为：
判断到底是采取架构重构还是采取系统优化的一个简单的做法：假设现在需要从 0 开始设计当前系统，新架构和老架构是否类似？如果差异不大，说明采取系统优化即可；如果差异很大，那可能就要进行系统重构了。
架构优化完毕后，原来发现的那些非架构重构问题则主要由各自负责的团队内部完成优化即可
2 重构二：沟通的技巧
2.1 非技术人员
要想真正推动一个架构重构项目启动，需要花费大量的精力对非技术人员进行游说和沟通。
在与非技术人员沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键，而不是使用技术名词可扩展性、可用性、性能、耦合等进行沟通，这样对非技术人员来说过于抽象
2.2 技术人员
与技术人员的沟通主要的阻力来自“这对我有什么好处”和“这部分我这边现在不急”。
有效的策略是“换位思考、合作双赢、关注长期”。就是站在对方的角度思考，重构对他有什么好处，能够帮他解决什么问题，带来什么收益。
3 重构三
通常情况下，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发；
到了真正要开始重构的时候，架构师识别出系统关键的复杂度问题后，如果只针对这个复杂度问题进行架构重构，可能会发现还是无法落地，因为很多条件不具备或者有的问题没解决的情况下就是不能做架构重构；
因此，架构师在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题。
重构的做法为“分段实施”：将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题。
制定“分段实施”的策略的方法
1 优先级排序
将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题。
2 问题分类
将问题按照性质分类，每个阶段集中解决一类问题。
3 先易后难
4 循序渐进
每个阶段最少 1 个月，最长不要超过 3 个月，如果评估超过 3 个月的，那就再拆分为更多阶段。
如果重构周期太长，如两年，建议直接重写更快