架构治理

驱动架构变化的有业务、技术、人员

架构数字化

数字化:将所有东西信息化

现实世界 -> 数字世界(突破物理世界的限制)-> 改造现实世界的流程

研发过程数字化、使用过程数字化、管理过程数字化

平台化

技术栈统一

公司基础 + 领导人擅长 = 选型

不统一的技术栈,会使团队未来的成本花费过高,主要体现是在基础设施的建设上。这就导致了技术无法沉淀,关键人员的离去会导致技术断崖,不一致的技术栈也难以考核与管理

统一化的成本:

性能治理

有意识的设计时考虑性能可以降低后续改进成本

流量问题

热点问题

数据问题

日志打印

依赖治理

依赖瘦身

依赖冲突

版本治理

发布

运营

依赖升级

版本清退

依赖管理

链路治理

发现问题、修复问题

平滑链路:消除请求的异常、毛刺,使之平滑

子调用:消除不合理的循环、子调用,过慢的子调用

链路成功率:超时问题、中间件成功率、压力异常

环境治理

监控环境水位:资源使用情况

敏感性分析:分析机器投入产出比

弹性收益:预测低谷高峰 按需分配

环境统一:非标准环境的风险

技术债务治理

债务类型:

债务会降低迭代速度、质量下滑、问题频繁出现问题

欠的越久最后还的就要越多,当接手了一个屎山项目,没办法只能跑路了

重构与新功能独立分开,避免交融

偿还债务很难一次性还完,使用分阶段的方式逐渐偿还,并在偿还的过程中尽量不要引入新债务。另外一条路就是另起炉灶,重写项目,但这种方式很容易走老路,变成新的屎山。

解决技术债务的原则:

风险治理

风险感知 -> 设计中注意 -> 验证

联调

开始 -> 约定流程行为 -> 准备数据、说明 -> 执行、验证 -> 反馈

执行验证:接口数据就位 -> 原型验证 -> 联调回归 -> 修复问题、资料更新

回归:

联调的风险:

流程卡点

从软件小作坊到软件工厂的转换过程中,势必要加入一些流程卡点,来保障软件的质量

但如果从没有任何流程卡点一下转换为各种各样的卡点,那团队一下子没有那么容易适应,所以早期这种卡点的部署要是渐进式的,保持进度与质量的平衡

对于必须卡的节点,要考虑节点的执行效率问题,对于一些不太重要的卡点,可以进行延后及使用异步的方式来进行