文章目录
- 一、互联网系统三高概述
- 1、互联网的三高
- 2、高并发
- 3、高可用
- 4、高性能
- 二、高并发、高性能技术解决方案
- 1、多高的并发才算高并发？
- 2、水平扩展
- 3、负载均衡思想
- 4、缓存思想
- 5、池化复用思想
- 6、异步思想
- 7、预处理-惰性更新思想
- 8、分而治之思想
- 三、高可用技术解决方案
- 1、总览
- 1、集群架构
- 2、熔断降级
- 3、限流
- 4、隔离
- 5、多活架构
- 四、总结
一、互联网系统三高概述
1、互联网的三高
高并发、高性能、高可用，它们是互联网系统架构设计永恒的主题。
三高并不是孤立的，而是相互支撑，相互影响的，随着并发量的提高，请求延迟肯定会增大，就越考验系统的可用性和性能。
2、高并发
高并发是指互联网系统能够同时处理大量请求的能力。随着互联网业务的快速发展和用户数量的增加，系统需要处理的数据和请求量也越来越大。为了应对这种场景，互联网系统需要具备高并发的能力，以避免请求的拥堵和延迟。
高并发相关常用指标有每秒查询率QPS、每秒事务数TPS、并发用户数等。
QPS：Queries Per Second，每秒查询数，指一台服务器每秒能够 响应的查询次数。
并发用户数：同时承载正常使用系统功能的用户数量。
TPS：Transactions Per Second每秒事务数，可以是一个接口、多个接口、一个业务流程，包括增删改操作。
3、高可用
高可用是指互联网系统能够持续提供服务，不受到故障或宕机的影响。互联网系统一旦出现故障或宕机，将会导致用户无法使用业务或者造成数据丢失等严重后果。因此，互联网系统需要具备高可用的能力，以保证服务的连续性和稳定性。
通常使用SLA衡量一个系统可用性有多高，目标系统7 x 24小时不间断服务：
时间维度：系统可以正常使用时间与总时间之比（全年），1年=365天=8760小时。
999系统全年不可用时间：99.9 = 8760 * 0.001 = 8.76小时 9999系统全年不可用时间：99.99 = 8760 * 0.0001 = 52.6分钟 99999系统全年不可用时间：99.999 = 8760 * 1.00001 = 5.26分钟 ……
请求次数维度：请求总次数和失败的占比（1000次请求为例，相对简单）
系统可用性99%：表示1000个请求中允许10个出错。
……
通常以时间维度来判断一个服务的高可用性。9越多代表全年服务可用时间越长，服务更可靠，停机时间越短。
但往往存在网络/机房问题，应用更新发版导致服务不可用。
大厂多数业务4个9是刚需，5个9是目标，6个9是理想。
4、高性能
高性能是指互联网系统能够快速响应和处理多种事务的能力。互联网系统的性能是用户体验的重要保障，如果系统响应速度慢或者无法支持多种事务，将会导致用户流失和业务损失。因此，互联网系统需要具备高性能的能力，以满足用户的需求和业务要求。
通常使用RT响应时间、吞吐量数等来衡量系统的响应速度，程序处理速度非常快延迟低，所占内存少、CPU占用率低，说明性能高。
响应时间：系统对请求做出响应的时间。
吞吐量：单位时间内处理的请求数量。
二、高并发、高性能技术解决方案
1、多高的并发才算高并发？
这需要结合具体的场景和资源投入。
比如说，1万QPS的商品列表查看，这不属于高并发，稍微结合缓存即可实现。
比如说，5K的TPS下单接口，就属于高并发。
基本上读并发都可以通过缓存来解决，写并发的解决才相对比较难。
2、水平扩展
无状态的业务，可以通过水平扩展（Scale Out），只要增加服务器的数量，就能线性的扩充系统性能。
但是整个系统，整个链路，由于木桶的短板效应，并不是都可以通过增加服务器的数量提高性能的。
全链路的水平扩展很难，因为有状态的业务（数据库等）。
但是一些全链路都是无状态的服务，是可以通过水平扩容的方式提高性能的。
比如视频的编解码服务（依赖机器内存、CPU）就可以无限的水平扩展。
再比如短信服务，运营商对一个ip，每秒最大允许几百次请求，运营商这里就成了性能瓶颈（可以扩ip、多帐号）。
3、负载均衡思想
负载均衡有很多算法：轮询、随机、加权轮询、节点固定hash等。
全链路可以用到负载均衡的地方很多：
网络DNS解析IP轮询；
网关分发请求后端服务；
应用服务内部RPC、Feign调用；
数据存储，分库分表。
4、缓存思想
前端浏览器会缓存静态资源；
网络DNS解析缓存；
应用程序使用 本地缓存（JVM）/分布式缓存（Redis）。
数据存储MySql Query Cache。
5、池化复用思想
池化思想：线程池、对象池、连接池、内存池等等。基本用的就是单例模式/享元模式。
比如：
java线程池；
jdbc、redis、httpClient连接池；
SpringIOC容器对象池；
Integer对象的内存池。
6、异步思想
多线程/消息队列；
前端ajax异步请求；
RockerMQ/Kafka同步双写-异步刷盘；
应用程序多线程异步处理。
7、预处理-惰性更新思想
定时任务/懒加载。
报表数据通过定时任务提前计算好，定期刷新。
缓存预加载。
8、分而治之思想
Master-Worker思想。
Handoop中的MapReduce；
JDK fork/join；
消息队列的广播消息；
归并排序等。
三、高可用技术解决方案
1、总览
高可用的解决方案，归根结底就是冗余、集群化+自动故障转移failover
1、集群架构
将多个相同的应用程序集中起来提供同一种服务，某个节点故障并不影响系统的使用。
可以通过横向扩展增加节点，提高并发处理能力。
实际应用：
微服务集群；
Redis集群/Kafka/Nginx集群；
Nacos集群/MySql集群/ZK集群等。
2、熔断降级
熔断服务，就是为了防止整个系统故障，抛弃一些非核心的接口和数据，返回兜底数据。
3、限流
当访问频率或者并发请求超过其承受范围的时候，考虑限流来保证接口的可用性。
限流算法有很多：令牌桶、漏桶等。
4、隔离
服务和资源互相隔离，比如网络资源、机器资源、线程资源等，不会因为某个服务的资源不足而抢占其他服务的资源。
5、多活架构
同城双活-双机房：
两个机房部署在同城，物理距离较近，两个机房通过专线网络连接，比单个机房内延迟大一些，但整体的延迟是可以接受的。
比如：同机房0.1ms，同城双机房1ms（100公里内），北京到广州55ms。
异地多活-两地三中心：
两地是指2个城市，三中心是指有3个机房，其中2个机房在同一个城市。
同时提供服务，第三个机房部署在异地，只做数据灾备。
多活架构会导致架构非常复杂，
四、总结
三高方案不是简单的一字一句就能说明白的，是需要日积月累，一步步踩坑踩出来的。
只不过现在有一些大厂的案例，供我们来参考，实际落地的时候，还需要根据各个公司不同场景进行不同的设计。
