一个人走的很快，一群人走的更远，欢迎留言点评提出你们的问题和建议。未来的日子里，一起成长，加油！！！
前言
本项目是重学Go语言后的实战项目，主要目的是加深Go学习，并通过此学习，对系统的高可用，高并发，高性能能够进一步的学习。
前面我们将功能性的需求几乎都已经都陈列出来，这些几乎是从外部因素考虑的。但对于运行系统的环境，以及系统的并发能力也是我们需要考虑的，这部分可称为非功能需求。
非功能性需求包括：可用性、并发能力、性能、安全防护能力、水平扩容缩容能力、运维/运营成本等
比如：一个系统的可用性达到99.99%。并发能力达到100万QPS，请求延迟低于500ms，能防范跨站脚本攻击，1分钟快速扩容，总成本控制在10万元每月等等，这些都是非功能需求要满足的。
所以，系统需要满足非功能需求的一些指标，以防止系统在运行时出现重大的故障。
秒杀系统的核心非功能需求主要有：高可用指标、高性能指标、高并发指标
高可用指标
- MTBF(Mean Time Between Failure 平均可用时长) ：系统正常、稳定运行的平均时长
- MTTR（Mean Time to Repair 平均修复时长）：系统从失效后到恢复正常所耗时的平均时间
- SLA（Service-Level Agreement 服务等级协议）：用于评估服务可用性等级，公式是SLA=MTBF/(MTBF+MTTR)。可用性高于99.99%，是指SLA高于99.99%
系统高可用的指标是SLA来判断
系统P 是由四个子系统a、b、c、d构成。那么，系统P的SLA是低于其他四个子系统；下游系统的SLA通常需要高于上游SLA，这样才能保证上游系统的稳定
高并发指标
QPS（Queries Per Second 每秒查询率）是衡量系统的承载能力。
不同的业务对并发能力要求不一致，用户量小的系统对并发要求相对比较低，用户量大的就要求比较高。
评估高并发指标，通常需要从用户增长、用户习惯、业务形态、系统承载能力等方面分析。就比如，秒杀系统，用户量肯定远大于库存量，库存一旦为0则活动就结束。
系统资源在设计上保留10%～20%的余量，以便应对突发流量
评估用户增长情况，需要月/日活用户的量，再加上因推广过程带来的用户增长来预估一个当日活动可能达到一个用户量。然后在业务系统设计上保留余量。
比如评估业务承载最高270万QPS，底层Redis承载能力1万QPS。实际设计中，业务承载服务300万，要高些以防突发突增流量，底层Redis资源8000QPS，低一些，因为底层资源比较固定不容易扩容，需要限制QPS不要超出其最大承载能力
高性能指标
对于电商平台如果访问请求超过2s影响用户体验，超出5s有可能导致流失用户，造成损失。以下因素将会影响性能指标：
- 用户网络环境
- 请求/返回数据大小
- 业务系统CPU、内存、磁盘等性能
- 下游资源的性能
- 算法实现是否高效
- 请求链路长短
为确保满足性能要求，我们对这边流量比较大的系统一般需要做大量的性能测试和性能调优。
场景：用户请求系统的网络环境延迟100ms，请求/返回数据处理为10ms，业务内部磁盘操作30ms，请求下游资源10ms，算法计算5ms。那么，整个请求共耗时将超过155ms。
如果超过155ms对公司造成一定损失，那么我们还需要继续优化性能。当然，优化过程也需要考虑成本等各种问题，并非指标越高越好。
