局部架构重构
1. 架构重构的驱动力
- 坏味道驱动
- 规划驱动
- 架构组织与架构过程中的重构
2. 坏味道如何判断
以下情况，可能是架构的问题引起的
- 增加人员但开发效率没有提升
随着项目的扩展需要增加人员，但整体的开发效率反而降低了
- 系统可用性
不稳定，可靠性降低
- 系统扩展性
不易于扩展支持新业务接入
3. 坏味道有哪些
- 组件臃肿
一个组件里包含太多功能：拆分
- 组建贫血
一个组建的功能太单一，比如只是简单转发器：砍掉
- 组建缺失
找出公共的功能点，抽象为组建
- 组建冗余
相同功能的组建应该抽象、整合为一个组建
- 组建抽象不足
一直随着业务新增或变化频繁变更
- 组建反向依赖
底层组建依赖高层组建
- 循环依赖
- 网状依赖
-长链依赖 - 强依赖
要完成一个事情一连串的组建都需要随之修改
- 资源瓶颈
一个组建成功全部依赖业务的瓶颈，如DB、cache、身份校验组建
- 单一故障点
一个组建失效后，全部依赖的业务都出现故障
4. 客观评价架构重构方案
以10分制来划分，制定可量化的评判标准
根据业务的重要性要求，选出主要目标，确定权重
制定方案，依据选择的标准去评分，分值不能低于下限
- 一个组建需要提供很多业务依赖，有两种方案
工程依赖，逻辑抽象并实现打包为jar，其他业务引入依赖：可伸缩性不足
搭建公共服务，给全部业务调用及访问和处理资源的逻辑：原业务的迁移成本高（需要大全部依赖的业务都改造）、增加故障点
5. 控制架构重构风险
重构就是做高速公路上换轮胎
重构前
原则：消除风险、获得支持
- 关键技术准备
做好技术预研
做好物理资源和运维能力的支持度
- 架构概念验证原型POP
用于验证架构设计是否满足业务需求
- 确定重构项目的目标与范围
一定要做好预判，根据待重构业务紧迫性、时间要求、关键技术、人力、新业务支持等现状，设定可行的目标与范围
- 明确业务影响
重构过程中，因为投入人力和兼容性原因，新业务研发肯定需要停下来一段时间，不停下来怎么换轮胎，需要预判停下来多长时间，接下来这段时间有哪些紧急的业务要去做，有哪些关键商务合作在进行中，都要去关心和提前沟通好
- 晒项目
把业务损失风险向上汇报，要有人承担，需要团队内、外都知晓，必须有领导知道并支持
- 组建项目团队
需要各种角色搭配，这样有利于培养新人
- 创造业务需求真空期
详细制定重构计划，需要人力和时间，告知业务方，这段时间不接收新的业务，并承诺什么时间点会重构好
重构中
原则：短、平、快
- 前置重构
把一些小的重构项目先做掉，竟可能的消除项目重构的风险
- 严格控制项目的扩展
如果有非常必须支持的需求，必须在老系统上改造，而不是重构过程不成熟的系统上实现，重构后把新业务再合入新系统
- 项目切割
项目尽可能的切分，组成一些列迭代，迭代的上线
重构发布
原则：稳、平滑
- 非停机发布
- 可快速回滚
- 新旧系统并行运行
平滑切换，流量逐步放开，并做好监控和验证，有技术、性能、用户体验的风险
- 监控方案
- 所有方案必须经过测试
- 检查项目目标是否达到
- 复盘
是否达到目标，有哪些不足，有哪些值得我们吸取
二、 全局架构重构
如何让架构重构交付最大价值
1. 理解全局架构
- 经典架构模式、视图
架构= 组建 + 关系 + 原则/约束
RUP的4+1视图：逻辑、进程、物理、开发、用例
- 更宏观的架构视图
多视角：业务、数据、应用、技术
描述多个视角之间的关系，数据如何支持技术，技术如何支持应用，应用如何支持业务
自顶向下，分而治之：用一张大图全局描述，必须分层，比如：
2. 建立全局架构基线
- 从业务入手：建立L0层基线全局架构，必须包含完整的业务、应用、技术、数据、各种协议
- 选择最关键的1级架构域，简历完整的L0-L3业务、应用、数据、技术架构视图
- 建立L0-->L2完整业务、应用、数据、技术架构视图，构建完整产品、应用、数据集清单
- 以产品为单元完成L3全面建设
3. 案例
- 建立样板文档，挪列关键元素，统一用wiki管理
- 把应用等各种依赖关系可视化
- 团队紧密交流，每天分享梳理出来的业务和技术，相互了解及借鉴
识别全局架构关键问题
- 容量
- 稳定
- 新业务支持
- 相应速度
确定目标架构
设计架构演进路线的经验
- 顺势而为
与业务发展路线合拍
- 分而治之
边界优先
-专注主线
按住关键业务、技术
辐射周边业务
- 步步为营
逐步交付价值
不要停留在危险的中间状态
- 安全试错
创造生产环境的架构实验室
三、更深层次的架构重构
架构组织：专职架构 + 业务架构融合
资料
链接: https://pan.baidu.com/s/1nbVX1jzLvBa4iDwzlw4mmQ 提取码: 2egc
