在满足需求、有良好的使用体验(基于真实的用户看法,不是开发者自己觉得)基础上,进一步提更高的要求:
- 接口响应超时
- CPU load 升高
- 内存
- GC 频繁
- 死锁
- 大数据量存储
一、三高(高可用 + 高性能 + 高并发)
1.1 高可用(可用性) Availability
可用性强调的是服务的总体持续时间,比如可用性级别为三个九(99.9%)意味着一年 365 天里总共停止服务 8.76 个小时。
可靠性 Reliability
- 功能如预期运行(宁可抛出异常,不要默默地给错误运行)
- 出现故障的频率
- 出现故障也应该不对系统造成太大的影响
- 可维修性:故障定位容易、修复步骤简单、修复成本低廉
和高可用的区别:
- 大部分时候,这两个指标都是密切相关的
- 如果我有一个电视机,每天都准时看儿童频道的《动漫世界》一个小时,然后过去三年也都用得挺好,没有送去修过(导致我看不了),那可以说高可用了(正常运行时间 / 预期运行时间),但是如果这个电视机每次看的时候可能隔一会儿需要拍一巴掌(中间出雪花的时间可以忽略),那这就不能说这个电视机是可靠了。
-
又比如说,我又买了另一个电视机,不需要拍巴掌了,我看的挺开心,不过才高兴两年,坏了,看不了了,楼下电器维修店的小哥搞不定,联系厂家售后维修,一下就是两周看不了电视。对于一个家用电器,两年坏一次可以说高可靠,但是可用性就有问题了(
(365 - 7) / 365 = 98%
)。 -
MTBF Mean Time Between Failure 无故障时间,每隔多久遇到一次故障
- MTTR Mean Time To Repair 修复时间,每次遇到故障需要维修多久
-
MTTF Mean Time To Failure
-
根据当前的可用性级别,然后指定合理的可行性目标
- 操作规范/最佳实践
- 预防性维护 Preventive Maintenance
- 合理的 PM 计划:可实施,正确的时机
- 重点是影响最大的故障
- 不断的改进和优化
稳定性 Stability
- 系统运行平稳(不一定如预期执行)
连续性 Continuity
故障出现之后的处理能力:故障能否快速修复,能否不影响主要业务的运行。
比如我有两台电视机,坏了一台,我还有另一台可以看,虽然另一台是之前淘汰的一台黑白电视,效果差点,好歹能用啊。
这台电视就是我们常说的灾难备份,或者说容灾备份。
1.2 高性能 HP Performance
- 处理速度快
- 资源占用低
1.3 高并发 HC Concurrency
- 响应时间
- 吞吐量
- 并发用户数
二、安全性
- 基础设施安全:操作系统、网络、数据库
- 数据安全
- 脱敏:降低数据泄漏所产生的消极影响
三、易用性
四、其他
3.1 可测试性
3.2 可维护性
运维方便,运营方便,二次开发方便
- 代码注释与文档
- 合理的日志
- 监控与数据统计
- 误操作发生率低
- 可理解性:代码可读性,合理的技术框架/系统架构
- 可拓展性:新增功能不需要修改现有结构的能力。分层,合理的耦合度(尽可能的高内聚、低耦合),合理的功能抽象,数据结构可拓展
3.3 可伸缩性 Scalable/Scalability
在系统不需要修改(顶多改改配置)的前提下,通过增加或减少硬件资源来动态提升或降低系统各项能力。
- 通常采用服务器集群的方式。
- 集群一上来,就和高可用有很大关联。
3.4 可扩展性 Extensibility
通过合理的设计,使得新增功能时,不需要改动现有功能,或者只需要对现有系统进行少量调整就行。
总之,将新功能对现有业务逻辑的影响降到最低。
3.5 可观测性
能够方便快捷的了解到程序运行情况。
合理的日志,指标数据的暴露(Pull/Push)。