-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Non Function
(草稿版，请勿转载)
- 服务组件： 子系统内的服务节点
- 定时任务组件：子系统内的定时任务节点
- 三方组件： 子系统内的其他节点，包括数据库，缓存，Zookeeper，消息系统等
- 依赖服务： 子系统外的被依赖服务
日常不同时段的流量模型 / 大促时的流量模型
针对主要API的QPS，响应时间，并发连接数
从API的流量模型，以及缓存命中率等估算，推算数据库/缓存/消息系统的流量模型(读/写QPS分开估算)
吞吐量(QPS，或其他的度量单位如每天2TB日志)
响应时间(包括不同吞吐量下的平均响应时间，99%，99.9%等分位数响应时间)
并发连接数
服务组件是否全部支持水平扩展（考虑服务如何进行负载均衡/服务注册与发现，是否sharing nothing/stateless架构）
三方组件是否全部支持水平扩展（考虑分区策略，对读/写请求的伸缩性要分开评估）
如何进行扩容，是否需要停止服务（静态配置还是动态注册发现，存储层要考虑如何进行重新分区，数据迁移，缓存失效等）
是否支持节点收缩(scale-in)
当前硬件配置下的系统总容量
QPS，响应延时，并发数
数据容量，数据保存的时长等
目前系统总容量与大促峰值流量对比的资源利用率
资源占用估算，指按照流量模型估算的各组件的资源占用情况 (包括CPU，内存，磁盘，IO，网络带宽等)
资源占用估算与各组件实际部署的硬件资源对比的资源利用率
资源占用估算与各组件所提供的性能数据对比的资源性价比
年度/季度/月度的可用性(999.9%, 99.99%, 99.999%)
平均故障间隔时间(MTBF)，平均故障修复时间(MTTR)
系统是否存在单点故障节点，是否都是主备或集群节点（热备，冷备，主动－主动，主动－被动等形式）
故障包含组件自身故障，操作系统或服务器crash，网络故障（网络抖动，网络中断，脑裂，防火墙配置异常）以及依赖服务故障（崩溃，慢响应）
服务组件，三方组件发生故障时，如何进行故障发现和转移（如前端LB如何发现故障并进行转移，Master节点重新选举，数据重新分区，冗余节点启动等)，人工还是自动化，所需的时长
如何隔离依赖服务的故障，防止雪崩效应（如超时控制，熔断，心跳等）
故障发生时的影响，用户无感知（重试），还是有短暂时间内的请求会失败
各组件与依赖服务恢复后，如何重新加入集群提供服务(系统如何将流量重新切换到恢复的节点上，是否需要进行数据的重新同步，是否需要考虑会话）
服务能否隔离屏蔽部分非重要功能降级运行
服务能否隔离有问题的数据分区，其他数据分区继续运行
服务能否使用备用数据源继续运行，如使用Memcached、JVM内存、文件中的缓存等
对异常请求的处理（比如参数值超出边界阀值，超大请求/结果集）
数据／日志有没有冗余备，故障发生时会不会丢失，如果会丢失，会丢失多少数据（数据如何进行实时复制，归档备份的频率）
如何实现故障转移／恢复时保持数据一致性
数据恢复所需的时间
事务支持：
- 是否支持回滚或补偿操作
- 是否支失败自动重试（重试的策略），或日志记录后人工重试
对正常突发峰值的应对（比如限流，异步队列或关闭部分非主要功能）
对DDoS攻击的过滤
跨站点数据复制（备份的方式，频率等）
跨站点流量切换（切换的方式，需要的时间，影响，比如用户的会话数据会否丢失等）
应用traffic数据的监控 （QPS, 延时，错误率）
应用状态的监控（JVM数据，应用内部的指标如线程池/连接池情况，异步队列长度，其他的metrics如重试次数，超时次数等）
组件有否提供健康度检查接口
能否根据以上监控数据，进行自动告警
用于诊断问题的日志及其他信息是否足够
API调用的认证，授权，签名，传输加密
管理界面的认证，授权，审计，传输加密
数据保密性
敏感信息过滤
服务启动、关闭的时长
升级、回滚的时长
能否零停机时间升级（比如滚动升级），如果不能，停机升级窗口是多长
比如更新配置是否需要重新启动系统
有否提供API，运维可通过自动化脚本而不是界面I进行管理
有否需要手工定期执行的任务
API的向后兼容性，API是否带有版本标示，能否多版本并存
服务扩展功能是否需要必须修改的客户端节点
数据结构扩展是否方便
能否通过插件，SPI进行扩展
系统间的耦合度也对可扩展性影响很大，是否存在不通过服务API，直接访问其他系统的内部数据，有否通过消息系统对服务进行解耦
跨平台的访问支持 (Linux，Windows等)
跨语言的访问支持 (Java, Php, Python, Node.js等)