第92篇
极客时间《从0开始学架构》课程笔记。
第一式：有的放矢
只有少部分架构演化可能需要推到重来，绝大部分的架构演化都是通过架构重构来实现的。
架构重构的难点
- 业务已经上线，不能停下来
- 关联方众多，牵一发动全身
- 旧架构的约束
架构重构案例
架构师的首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。
-
后台系统重构：解决不合理的耦合
重构前
重构目标：将游戏数据和业务数据拆分，解开两者的耦合，使得两个系统都能够独立快速发展
重构后
重构后的效果：M 系统和 P 业务后台系统每月上线版本数是重构前的 4 倍。
-
游戏接入系统重构：解决全局单点的可用性问题
重构前
重构目标：实现双中心，使得任意一个机房都能够提供完整的服务，在某个机房故障时，另外一个机房能够全部接管所有业务
重构后
重构后的效果：系统可用性从 3 个 9 提升到 4 个 9，重构前最夸张的一个月有 4 次较大的线上故障，重构后虽然也经历了机房交换机宕机、运营商线路故障、机柜断电等问题，但对业务都没有什么大的影响。
-
X 系统：解决大系统带来的开发效率问题
重构前
重构目标：将各个功能拆分到不同的子系统中，降低单个系统的复杂度
重构后
重构后的效果：各个系统之间通过接口交互，各系统的发展和开发速度比原来快了很多，系统也相对更加简单，也不会出现某个子系统有问题，所有业务都有问题
总结
- 判断到底是采取架构重构还是采取系统优化的简单方法：假设我们现在需要从 0 开始设计当前系统，新架构和老架构是否类似？如果差异不大采取系统优化即可；如果差异很大就进行系统重构
- 非架构重构问题不能放任不管。建议在重构完成后，启动多个优化项目去优化
第二式：合纵连横
合纵
- 推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通，要和利益相关方沟通好，让大家对于重构能够达成一致共识
- 和非技术人员沟通时不能用技术术语：可扩展性、可用性、性能、耦合、代码很乱……
- 在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键，统计版本讨论时长、开发时长、故障次数、每次影响时长、影响用户数量、客服反馈意见数量等
连横
- 在需要和其他相关或者配合的系统的沟通协调时，都是做技术的，有比较多的共同语言，但主要的阻力来自“这对我有什么好处”和“这部分我这边现在不急”
- 对于“有什么好处”的问题，有效的策略是“换位思考、合作双赢、关注长期”。简单来说就是站在对方的角度思考，重构对他有什么好处，能够帮他解决什么问题，带来什么收益
- 对于“现在不急”的问题，要么是没有达成一致意见，要么是真的有更重要的事情，解决方案除了换位思考统一意见外，还可以分阶段处理，先做其他需要重构的，但最好明确具体的等待时间，如3 个月后开始、6 月份开始
第三式：运筹帷幄
让架构重构落地
- 架构师在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题
- 重构的方法总结：“分段实施”，将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题
- 分阶段的好处：每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易；每个阶段的工作量不会太大，可以和业务并行；每个阶段的改动不会太大，降低了总体风险。
制定分段实施策略
- 优先级排序：将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题
- 问题分类：将问题按照性质分类，每个阶段集中解决一类问题
- 先易后难：简单问题先处理，可以较快的看到成果，可以让难的问题简化，可以及时调整方向
- 循序渐进：按照固定的步骤和节奏，更有利于项目推进。建议每个阶段最少 1 个月，最长不要超过 3 个月，如果评估超过 3 个月的，那就再拆分为更多阶段
X系统架构重构总体策略示例
网友评论