架构实战——架构重构内功心法第一式(有的放矢)
目录
-
- 一、引入前提
- 二、具体的重构案例
-
- 2.1、后台系统重构——解决不合理的耦合
- 2.2、游戏接入系统重构——解决全局单点的可用性问题
- 2.3、X 系统——解决大系统带来的开发效率问题
- 三、具体重构案例总结
-
- 3.1、判断到底是采取架构重构还是采取系统优化
- 3.2、原来发现的那些非架构重构问题怎么办
本文来源:极客时间vip课程笔记
一、引入前提
- 通常情况下,当系统架构不满足业务的发展时,其表现形式是系统不断出现各种问题,轻微一点的如系统响应慢、数据错误、某些用户访问失败等,严重的可能是宕机、数据库瘫痪、数据丢失等,或者系统的开发效率很低。
- 开始的时候,技术团队可能只针对具体的问题去解决,解决一个算一个,如果持续了半年甚至一年情况都不见好转,此时可能有人想到了系统的架构是否存在问题,讨论是否是因为架构原因导致了各种问题。一旦确定需要进行架构重构,就会由架构师牵头来进行架构重构的分析。
- 当架构师真正开始进行架构重构分析时,就会发现自己好像进了一个迷雾森林,到处都是问题,每个问题都需要解决,不知道出路在哪里,感觉如果要解决所有这些问题,架构重构其实也无能为力。
- 有的架构师一上来搜集了系统当前存在的问题,然后汇总成一个 100 行的 Excel 表格,看到这样一个表格就懵了:这么多问题,要到猴年马月才能全部解决完啊?
- 期望通过架构重构来解决所有问题当然是不现实的,所以架构师的首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题,集中力量快速解决,而不是想着通过架构重构来解决所有的问题。
二、具体的重构案例
2.1、后台系统重构——解决不合理的耦合
-
M 系统是一个后台管理系统,负责管理所有游戏相关的数据,重构的主要原因是因为系统耦合了 P 业务独有的数据和所有业务公用的数据,导致可扩展性比较差。其大概架构如下图所示: