架构治理
- 架构的变化是不可避免的
驱动架构变化的有业务、技术、人员
架构数字化
数字化:将所有东西信息化
现实世界 -> 数字世界(突破物理世界的限制)-> 改造现实世界的流程
- 业务全面在系统中在线完成
- 变化自适应
- 自动化智能化
- 度量
研发过程数字化、使用过程数字化、管理过程数字化
平台化
- 业务平台化:系列产品
- 技术平台化:快速响应业务变化,为业务的横向发展提供集中的技术解决方案
技术栈统一
公司基础 + 领导人擅长 = 选型
不统一的技术栈,会使团队未来的成本花费过高,主要体现是在基础设施的建设上。这就导致了技术无法沉淀,关键人员的离去会导致技术断崖,不一致的技术栈也难以考核与管理
统一化的成本:
- 沟通
- 改造
- 沉没
- 管理
性能治理
有意识的设计时考虑性能可以降低后续改进成本
流量问题
- 缓存建设
- 缓存预热
- 流量控制
- 异步化
热点问题
- 分散热点数据、热点代码
数据问题
- 避免大Key、大表
- 慢SQL优化
日志打印
- 打印性能
- 流量回放开启日志开关
- 日志异步化
依赖治理
依赖瘦身
- 去除未使用依赖 maven dependency plugin
依赖冲突
- mvn dependency:tree
版本治理
发布
- 发版周期
- 版本粒度
运营
- 版本分布监控
- 并行版本管理
- 长尾版本 一直在用 没升级的欲望
依赖升级
- 谨防升级引入的兼容问题
- 统一依赖版本 避免版本差异导致的能力不一致
- 避免间接依赖的移除导致能力偏移
版本清退
- 制定最后期限 广泛通知
- 使用流程驱动清退
- 制订静默期 避免僵尸应用诈尸
依赖管理
- BOM 由BOM提供方制定依赖版本
- dependencyManagement 子项目统一使用父项目定义的依赖版本
链路治理
发现问题、修复问题
- 链路追踪
- 链路识别
- 链路健康
- 链路评估
平滑链路:消除请求的异常、毛刺,使之平滑
子调用:消除不合理的循环、子调用,过慢的子调用
链路成功率:超时问题、中间件成功率、压力异常
环境治理
监控环境水位:资源使用情况
敏感性分析:分析机器投入产出比
弹性收益:预测低谷高峰 按需分配
环境统一:非标准环境的风险
技术债务治理
代码坏味道 注释缺失 当时限制原因 进度压力 指定背景下的选型 高复杂度残留 历史问题 行业发展限制 不合理的代码 人员能力问题 交接缺失 业务理解缺失 无用代码残留 临时方案 重构缺失 架构耦合
债务会降低迭代速度、质量下滑、问题频繁出现问题
欠的越久最后还的就要越多,当接手了一个屎山项目,没办法只能跑路了
- 重构
- 立即重构
- 阶段性重构
重构与新功能独立分开,避免交融
偿还债务很难一次性还完,使用分阶段的方式逐渐偿还,并在偿还的过程中尽量不要引入新债务。另外一条路就是另起炉灶,重写项目,但这种方式很容易走老路,变成新的屎山。
风险治理
- 架构在迭代,风险也在迭代
风险感知 -> 设计中注意 -> 验证
联调
开始 -> 约定流程行为 -> 准备数据、说明 -> 执行、验证 -> 反馈
执行验证:接口数据就位 -> 原型验证 -> 联调回归 -> 修复问题、资料更新
回归:
- 业务流程
- 边界
- 异常处理
- 降级方案
联调的风险:
- 进度风险
- 尽量异步联调 做好mock 不要被对方所阻塞
- 可用性风险
- 联调后的修改要及时回归
- 变化要及时通知依赖方
- 边界风险
- 保证部分边界可用 避免核心不可用
- 保护风险
- 处理好异常降级并对外告知
流程卡点
从软件小作坊到软件工厂的转换过程中,势必要加入一些流程卡点,来保障软件的质量
但如果从没有任何流程卡点一下转换为各种各样的卡点,那团队一下子没有那么容易适应,所以早期这种卡点的部署要是渐进式的,保持进度与质量的平衡
对于必须卡的节点,要考虑节点的执行效率问题,对于一些不太重要的卡点,可以进行延后及使用异步的方式来进行