马云、李彦宏、马斯克等都说了啥？

5)超时/重试

钉钉不回怎么办?每 10 分钟 ping 一次，超过 1 小时打电话。

• 超时：避免调用端陷入永久阻塞。
• 超时时间设置：全链路自上而下规划

Timeout vs. Deadline：使用绝对时间会更好

重试：确保可重试操作的幂等性。

• 消息去重
• 异步重试
• 指数退避

6)资源设限

双 11 如何避免女友败家?提前把自己信用卡额度调低。

• 目的：防止资源被异常流量耗尽
• 资源类型：线程、队列、DB 连接
• 设限方式：资源池化、有界队列
• 超限处理：返回 ServiceUnavailable / QuotaExceeded

7)资源隔离

双 12 女友还是要败家?得嘞刷你自个的卡吧，别动我的。

• 目的：防止资源被部分异常流量耗尽;为 VIP 客户提供服务质量保证(QoS)。
• 隔离方式：队列划分、独立集群;注意处理优先级和资源分配比例。

8 )安全生产

女友哭着说再让我最后剁一次手吧?安全第一，宁愿心疼也不要肉疼。

程序动态性：开关、配置、热升级。

• Switch：类型安全;侵入性小。

审核机制：代码 Review、发布审批。

灰度发布;分批部署;回滚预案。

• DUCT：自动/手动调整 HSF 节点权重。

3 可维护性优化

前人栽树，后人乘凉。

前人挖坑，后人凉凉。

维护的英文是 maintain，也能翻译成：维持、供给。所以软件维护能有多重要?它就是软件系统的呼吸机和食物管道，维持软件生命的必要供给。

系统开发完成上线，不过只是把它“生”下来而已。软件真正能发挥多大价值，看的是交付后持续的价值兑现过程 —— 是不断茁壮成长，为用户发光发热?还是慢慢堕落，逐渐被用户所遗忘?这并不是取决于它当下瞬时是否足够优秀(性能)和靠谱(稳定)，而是取决于未来 —— 能否在不断变化的市场环境、客户需求和人为因素中，始终保持足够优秀和靠谱，并且能越来越好。

相比性能和稳定性而言，可维护性所体现的价值往往是最长远、但也最难在短期内可兑现的，因此很多软件项目都选择了在前期牺牲可维护性。这样决策带来的后果，就跟架构设计一样，是几乎无法(或者需要非常高的成本)去弥补和挽回的。太多的软件项目，就是因为越来越不可维护(代码改不动、bug 修不完、feature 加不上)，最后只能慢慢沦落为一个谁都不想碰的遗留项目。

衡量指标

相比性能和稳定性而言，可维护性确实不太好量化(艺术成分 > 科学成分)。这里我选取了几个偏定性分析的指标：

1)复杂度(Complexity)：是否复杂度可控?

• 编码：简洁度、命名一致性、代码行数等。
• 架构：组件耦合度、层次清晰度、职责单一性等。

2)可扩展性(Extensibility)：是否易于变更?

• 需要变更代码或配置时，是否简单优雅、不易出错。

3)可运维性(Operability)：是否方便运维?

• 日志、监控是否完善;部署、扩容是否容易。

重要性

这里给了几个观点，进一步强调可维护性的重要性。

• 软件生命周期：维护周期 >> 开发周期。
• 破窗效应、熵增定律：可维护性会趋向于越来越差。
• 遗留系统的危害：理解难度，修改成本，变更风险;陷入不断踩坑、填坑、又挖坑的循环。

（编辑：保山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!