架构治理

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

架构数字化

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

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

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

平台化

技术栈统一

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

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

统一化的成本：

性能治理

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

流量问题

热点问题

数据问题

日志打印

依赖治理

依赖瘦身

依赖冲突

版本治理

发布

运营

依赖升级

版本清退

依赖管理

链路治理

发现问题、修复问题

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

子调用：消除不合理的循环、子调用，过慢的子调用

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

环境治理

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

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

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

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

技术债务治理

债务类型：

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

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

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

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

解决技术债务的原则：

风险治理

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

联调

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

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

回归：

联调的风险：

流程卡点

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

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

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