服务高并发、高性能、高可用实现方案
高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。
1、高并发
高并发是现在互联网分布式框架设计必须要考虑的因素之一，保证系统能同时并发处理很多请求。
对于高并发来说，它的指标有：
1、平均响应时长AVG RT：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间
2、吞吐量：吞吐量指每秒能处理多少请求数量，与响应时间呈反比，比如响应时间是1ms，则吞吐量为每秒1000次。
3、每秒查询率（QPS，Queries Per Second）：每秒响应请求数，和吞吐量差不多
4、并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数
QPS VS TPS
-
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
互联网中，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。比如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。
2、高性能
高性能指程序处理速度非常快，所占内存少，且CPU占用率低。高性能的指标经常和高并发的指标紧密相关，想要提升性能，那么就要提高系统并发能力，两者互相捆绑在一起。
性能体现了系统的并行处理能力，在有限的硬件投入下，提高性能意味着节省成本。同时，性能也反映了用户体验，响应时间分别是100毫秒和1秒，给用户的感受是完全不同的。
高性能指标要求：
| 指标 | 请求耗时 |
|---|---|
| TP50 | 50ms |
| TP75 | 75ms |
| TP90 | 90ms |
| TP99（百分之99的请求） | 100ms |
TP50: 即中位数值。100个请求按照响应时间从小到大排列，位置为50的值，即为P50值
TP95：响应耗时从小到大排列，顺序处于95%位置的值即为P95值
通常，设定性能目标时会兼顾吞吐量和响应时间，比如这样表述：在每秒1万次请求下，AVG RT控制在50ms以下，TP99控制在100ms以下。对于高并发系统，AVG RT和TP99必须同时要考虑。
另外，从用户体验角度来看，200毫秒被认为是第一个分界点，用户感觉不到延迟，1秒是第二个分界点，用户能感受到延迟，但是可以接受。
因此，我们系统在压测时，TP9999要低于200ms。
3、高可用
可用性：指一个系统处在可用工作状态的时间的比例
具体衡量指标：
MTBF（Mean Time Between Failure）：平均故障间隔时间，平均无故障工作时间，即系统可用时长，单位为小时
MTTR（Mean Time To Repair）：系统从故障到恢复正常所耗费的时间
SLA（Service-Level Agreement）：服务等级协议，用于评估服务可用性等级。计算公式是 MTBF/(MTBF+MTTR)
我们常说的可用性高于99.99%（4个9），是指指标SLA高于99.99%。
| 可用性 | 年故障时间 | 日故障时间 |
|---|---|---|
| 90% （1个9） | 36.5天 | 2.4小时 |
| 99% （2个9） | 3.65天 | 14.4分钟 |
| 99.9% （3个9） | 0.365天，8小时 | 1.44分钟 |
| 99.99% （4个9） | 0.0365天，52分钟 | 8.6秒 |
| 99.999% （5个9） | 0.00365天，5分钟 | 0.86秒 |
可用性级别：
| 级别 | 可用性级别 | 通俗说法 | 年度停机时间 | 配套措施 |
|---|---|---|---|---|
| 基本可用性 | 99% | 2 个 9 | 3d-15h-39m-29s | 服务在一个数据中心里有冗余，简单基础的自动化运维 |
| 高可用性 | 99.9% | 3 个 9 | 8h-45m-56s | 大量的自动化故障工具，以及各种控制调度系统等基础设施要做好 |
| 具有故障自动恢复 | 99.99% | 4 个 9 | 52m-35s | 本地多机房（像 AWS 一样每个地方都有三个可用区） |
| 极高可用性 | 99.999% | 5 个 9 | 5m-15s | 远程多机房，异地多活 |
高可用设计要素：
冗余：确保对系统操作至关重要的任何元素都有一个额外的冗余组件，这些组件可以在发生故障时接管。
监控：从正在运行的系统中收集数据，并检测组件何时发生故障或停止响应。
故障转移：一种手动或自动机制。如果监控显示活动组件发生故障，该机制可以从当前活动的组件切换到冗余组件。
上述三要素逻辑也很清晰：要实现高可用，不管是否存在状态，要先有冗余或备份；当真正出现故障的时候，要有监控手段监控到故障发生；故障发生后，可以通过故障转移组件快速转移到之前的冗余组件中，保证服务不中断。
高可用方案设计需要从哪些角度讨论和思考？
3.1 应用侧
高可用除了可以通过上述提到的冗余、集群、负载均衡等做到快速的故障转移，还包括熔断、限流、容错、降级、应急等保障手段，框架组件的超时及重试策略、异步调用、幂等性设计来补充。
3.2 支撑侧（或称基础设施平台）
支撑侧需要一整套高可用相关的监控指标，满足故障的提前预警、快速报警、可视化监控和分析。常见指标包括请求量、请求错误率、平均延时、HTTP状态，以及系统资源消耗相关指标等。
3.2 运维侧
运维侧中关键一点是DevOps，自动化发布、灰度发布、优雅发布、版本控制、健康检查等能力，可以在业务发生故障前和发生故障时，帮助应用最大程度减小服务不可用时长。
