如何建设一个健壮性系统

1. 如何保证系统的可靠性

1. 以最小出错的方式来设计系统 思考: 不提供类似万能接口, 能最大限度的减少外部错误调用带来的风险. 但缺点是复用性的降低, 因此我们在实际中还需要权衡. .
2. 想办法分离最容易出错的地方、容易引起故障的接口 思考: 针对复杂的业务流, 增加关键节点日志, 将正常业务流分开, 减少耦合度. 方便排查改造.
3. 充分测试 思考: 边界测试、自动化测试
4. 出现错误时, 提供快速的恢复机制以尽量减少故障的影响 思考: 日常代码回滚, 定时任务数据比对处理、报警手段
5. 监控(性能、错误率) 思考: 不仅仅是机器系统指标的监控, 我们业务类的监控也应当完善起来
6. 推行管理流程并加以培训

2. 负载

通常我们说负载, 指的大部分都是机器的负载. 但是对于系统的负载, 可能不仅仅包含机器的负载.

负载根据系统的不同主要维度也不太一样, 比如web服务器每秒请求次数、数据库的写入比率、聊天室同时活动的用户.

比如Twitter发推文, 每个用户关注者分布情况, 就是关键的负载参数.

3. 性能指标

负载增加后我们重点关注的是性能问题了. 根据系统的不同关注的角度也不一样.

比如在大数据系统中我们更关注吞吐量(每秒钟处理数或处理总时间), 而类似电子商务等在线系统通常更看重服务的响应时间.

4. 如何准确评估一个系统的性能

即使所有请求相同, 也会因为网络抖动、进程调度、网络数据包丢失和GC、磁盘IO、刷脏页等因素会影响到响应时间.

通常我们会采用百分位数来进行系统性能评估, 搜集到响应信息将其从响应最快到最慢排序

约定可接受响应时长比如 200ms, 如果我们响应排序里面有百分之八十都在200ms以内, 那我们当前系统指标为 p80.

百分位数通常用于描述、定义服务质量目标(SLO)和服务质量协议(SLA)

5. 如何做一个可维护的系统

通常我们发现随着时间、业务、人员的变化, 项目问题越来越大, 导致目前 “重构” 这个词成了公司的热词, 如何从一开始就避免重构的死循环呢.

软件系统设计三原则

1. 可运维性 系统设计要充分考虑当前运维、监控, 具有足够能力应对可能的突发情况是我们必须考虑的. 保持相关知识的传承, 不能因为人员变动导致新人对系统理解不同 行为可预测
2. 简单性 简化系统复杂性, 让每个工程师都能轻松理解系统 我们构建系统最大目标之一应该是保持简单性, 将现实中复杂的业务抽象后实现, 好的设计抽象能隐藏大量实现细节, 对外提供干净、易懂的接口.
3. 可演化性 其实也是应对新业务的变更能力是否足够强

6. 总结

一个业务系统必须完成预期多种需求, 包括功能性需求(大部分为产品需求) 和 一些非功能性需求.

1. 功能性需求

即系统需要实现什么, 各种存储、检索、数据处理等.

2. 非功能性需求

常规如安全性、可靠性、合规性、可伸缩性、兼容性、可维护性等

通过上面罗列的一些隐性需求, 下次面对产品质疑排期的时候, 希望你可以硬起来.

参考资料:

《数据密集型应用系统设计》