架构重构定义
代码重构
定义
对软件代码做任何改变以增加可读性或者简化结构而不影响输出结果
目的
增加可读性、增加可维护性、可扩展性
关键点
- 不影响输出
- 不修正错误
- 不增加新的功能性
架构重构
定义
通过调整系统结构（Rank、Role、Relation、Rule）来修复系统质量问题而不影响整体系统能力
目的
修复质量问题（性能、可用性、可扩展。。。）
关键点
- 修复质量问题，提升架构质量
- 不影响整体系统功能
- 架构本质没有发生变化
代码重构vs架构重构
| 代码重构 | 架构重构 | |
|---|---|---|
| 基本做法 | 调整代码 | 调整架构 |
| 目的 | 优化代码，增加代码的可读性、可维护性、可扩展性 | 修复架构质量问题 |
| 是否修复问题 | 否 | 是 |
| 是否改变系统能力 | 否 | 否 |
| 手段 | 引入设计模式 | 引入缓存，分库分表 |
架构重构技巧
架构重构手段
技巧
技巧1-先局部优化后架构重构
局部优化
定义
对部分业务或者功能进行优化，不影响系统架构
常见手段
- 数据库添加索引，优化索引
- 某个数据缓存更新策略采用后台更新
- 增加负载均衡服务数量
- 优化代码里面并发的逻辑
- 修改InnoDB buffer pool配置，分配更多内存
- 服务间的某个接口增加参数
架构重构
定义
优化系统架构，整体提升质量，架构重构会影响架构的4R定义
常见手段
- 引入消息队列（增加Role）
- 去掉Zookeeper，改为内置的Raft算法实现（删除Role）
- 将Memcached改为Redis（改变Role）
- 按照稳定性拆分微服务（拆分Role）
- 将粒度太细的微服务合并（合并Role）
- 将服务间的通信方式由HTTP改为gRPC（修改Relation）
- SDK从读本地配置文件改为从配置系统读取配置（修改Rule）
技巧2-有的放矢
要素
明确目标
不要试图解决所有问题，抓住关键问题
技巧
问题分类：问题收集列表可能有100条，不要全部想着通过架构重构解决，分门别类，找出需要架构重构解决的问题
明确时间
要有明确的时间点和里程碑，不要说“慢慢优化”
技巧
独立版本：不要混在业务版本里面做架构重构，否则不好协调资源
明确结果
需要有量化的指标来衡量，不能说“提升xxx质量”
技巧
- 先收集系统已有相关数据，适合项目投入、时间等
- 调查问券：适合效率、复杂度等
案例
- 开发效率很慢，P业务和M系统互相影响
- 线程问题很多，尤其是数据类问题
- M系统性能很低
有的放矢：重构只解决第1个问题
技巧3-合纵连横
要素
合纵
说服业务方和老板
以数据说话
把“可扩展性”转换为“版本开发速度很慢”，然后给出对应的项目数据
以案例说话
如果没有数据，就举极端案例，例如某个小功能，开发测试只需要1周，但是因为其他系统等原因，等了1个月才上线
连横
说服其他团队
换位思考
思考对其他团队的好处，才能让人配合
合作双赢
汇报和总结的时候，把其他团队也带上
案例
合纵：告诉产品经理和项目经理极端案例，设计2周、开发5天、1个月才能上线
连横：P业务线上问题大大减少，P业务不会被其他业务影响
技巧4-运筹帷幄
要素
问题分类
将问题分类，一段时间集中处理一类问题
避免对照Excel表格，一条一条的解决
问题排序
分类后排序，按照优先级顺序来落地
避免见缝插针式的安排重构任务
逐一攻破
每一类问题里面先易后难
把容易的问题解决掉，增强信心
架构重构的一些典型问题
架构重构是否可以引入新技术？—>可以，但尽量少，架构重构要求快准
业务不给时间重构怎么办？—>会哭的孩子有奶吃
其他团队不配合怎么办？—>学会利用上级力量
业务进度很紧，人力不够怎么办？—>收集需要重构的证据，技术汇报的时候有理有据
