简论互联网三高架构
马梦佳
（石家庄铁道大学，河北省石家庄市，050043）
摘要：互联网的三高架构就是指设计互联网系统架构时需要满足高可用、高性能、高并发。本文主要论述了互联网三高架构的特点、要求、解决方案等方面的问题。
关键字：互联网、分布式架构设计、并发性、可用性、性能
互联网三高架构包括高并发、高性能、高可用，简称三高即3H。这三者都是互联网分布式系统架构设计中必须考虑的因素之一，目前所有集群分布式，微服务，云原生，中台，数据湖，大数据等等，包括SpringCloud一系列解决方案组件等等，最终目的都是为了这三点。
1 定义
1.1 高并发
高并发即High Concurrency，通常是指通过设计保证系统能够同时并行处理很多请求。 也就是指设备并发能力强，具有同时处理多种事务的能力。
而对于高并发来说，它的指标一是响应时间，即系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间。二是吞吐量是指每秒能处理多少请求数量，好比你吃饭，每秒能吃下多少颗米饭。秒查询率：秒查询率是指每秒响应请求数，和吞吐量差不多。并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
1.2 高性能
高性能是指程序处理速度非常快，所占内存少，cpu占用率低。高性能的指标经常和高并发的指标紧密相关，想要提高性能，那么就要提高系统发并发能力，两者互相捆绑在一起。应用性能优化的时候，对于计算密集型和IO密集型还是有很大差别，需要分开来考虑。还有可以增加服务器的数量，内存，IO等参数提升系统的并发能力和性能，但不要浪费资源，要考虑硬件的使用率最高才能发挥到极致。要提高性能，就要避免因为IO阻塞让CPU闲置，导致CPU的浪费避免多线程间增加锁来保证同步，导致并行系统串行化免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上。
1.3 高可用
高可用通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。高可用注意如果使用单机，一旦挂机将导致服务不可用，可以使用集群来代替单机，一台服务器挂了，还有其他后备服务器能够顶上。或者使用分布式部署项。比如现在redis的高可用的集群方案有： Redis单副本，Redis多副本（主从），Redis Sentinel（哨兵），Redis Cluster，Redis自研。
2 分布式架构设计
架构的目的与架构师的目的一样都是降本增效，架构是对场景抽象后得出的支撑骨架，场景包括：业务复杂度、数据规模大小、人员技术研发水平、时间成本、运维能力等。分布式架构，即Distributed Architecture，是分布式计算技术的应用和工具，成熟的技术包括J2EE, CORBA和.NET(DCOM)，这些技术牵扯的内容非常广，相关的技术，相关的书籍也非常多，本文不介绍这些技术的内容，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。
3 提升系统能力
互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。
垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：
（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；
（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。
水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的。
互联网分层架构中，各层次水平扩展的实践又有所不同：
（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；
（2）站点层可以通过nginx来进行水平扩展；
（3）服务层可以通过服务连接池来进行水平扩展；
（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；
各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。
4 架构策略
4.1 高并发架构策略
4.1.1 负载均衡
高并发的首选架构策略是集群化部署，一台服务器承载的QPS有限，多台服务器叠加效果就不一样了。如何将流量转发到服务器集群，这里面就要用到负载均衡，比如：LVS 和 Nginx。常用的负载算法有轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接数法等。
4.1.2 池化技术
复用单个连接无法承载高并发，如果每次请求都新建连接、关闭连接，考虑到TCP的三次握手、四次挥手，有时间开销浪费。池化技术的核心是资源的“预分配”和“循环使用”，常用的池化技术有线程池、进程池、对象池、内存池、连接池、协程池。Linux 内核中是以进程为单元来调度资源的，线程也是轻量级进程。所以说，进程、线程都是由内核来创建并调度。协程是由应用程序创建出来的任务执行单元，比如 Go 语言中的协程“goroutine”。协程本身是运行在线程上，由应用程序自己调度，它是比线程更轻量的执行单元。
4.1.3流量漏斗
互联网高并发流量并不都是纯净的，也有很多恶意流量（比如黑客攻击、恶意爬虫、黄牛、秒杀器等），我们需要设计流量拦截器，将那些非法的、无资格的、优先级低的流量过滤掉，减轻系统的并发压力。
4.2 高性能架构策略
性能直接影响用户的感官体验，访问一个系统，如果超过5秒没有响应，绝大数用户会选择离开。影响系统性能的因素主要有用户网络环境、请求/响应的数据包大小、业务系统 CPU、内存、磁盘等性能、业务链路的长度、下游系统的性能、算法实现是否高效等。
4.2.1 高性能缓存
对一些热点数据每次都从 DB 中读取，会给 DB 带来较大的压力，导致性能大幅下降。所以，我们需要用缓存来提升热点数据的访问性能，比如将活动信息数据在浏览器的缓存中保存一段时间。缓存根据性能由高到低分为：寄存器、L1缓存、L2缓存、L3缓存、本地内存、分布式缓存。上层的寄存器、L1 缓存、L2 缓存是位于 CPU 核内的高速缓存，访问延迟通常在 10 纳秒以下。L3 缓存是位于 CPU 核外部但在芯片内部的共享高速缓存，访问延迟通常在十纳秒左右。高速缓存具有成本高、容量小的特点，容量最大的 L3 缓存通常也只有几十MB。本地内存是计算机内的主存储器，相比 CPU 芯片内部的高速缓存，内存的成本要低很多，容量通常是 GB 级别，访问延迟通常在几十到几百纳秒。
4.2.2 日志优化，避免IO瓶颈
当系统处理大量磁盘 IO 操作的时候，由于 CPU 和内存的速度远高于磁盘，可能导致 CPU 耗费太多时间等待磁盘返回处理的结果。对于这部分 CPU 在 IO 上的开销，我们称为 “iowait”。在IO中断过程中，如果此时有其他任务线程可调度，系统会直接调度其他线程，这样 CPU 就相应显示为 Usr 或 Sys；但是如果此时系统较空闲，无其他任务可以调度，CPU 就会显示为 iowait（实际上与 idle 无本质区别）。磁盘有个性能指标：IOPS，即每秒读写次数，性能较好的固态硬盘，IOPS 大概在 3 万左右。对于秒杀系统，如果单节点QPS在10万，每次请求产生3条日志，那么日志的写入QPS在 30W/s，磁盘根本扛不住。
Linux 有一种特殊的文件系统：tmpfs（临时文件系统），它是一种基于内存的文件系统，由操作系统管理。当我们写磁盘的时候实际是写到内存中，当日志文件达到我们的设置阈值，操作系统会将日志写到磁盘中，并将tmpfs中的日志文件删除。
4.3 高可用架构策略
高可用指标是指用来衡量一个系统可用性有多高。MTBF（Mean Time Between Failure）是系统可用时长。MTTR（Mean Time To Repair）是系统从故障后到恢复正常所耗费的时间。SLA（Service-Level Agreement），服务等级协议，用于评估服务可用性等级。
4.3.1主备切换，缩减故障时间
当系统出现故障时，首要任务不是立马查找原因，考虑到故障的复杂样，定位排查要花些时间，等问题修复好，SLA也降了好几个档。有没有更快的方式解决这个问题？那就是故障转移。当发现故障节点的时候，不是尝试修复它，而是立即把它隔离，同时将流量转移到正常节点上。这样通过故障转移，不仅减少了 MTTR 提升了 SLA，还为修复故障节点赢得了足够的时间。
4.3.2 熔断，提供过载保护
所谓过载保护，是指负载超过系统的承载能力时，系统会自动采取保护措施，确保自身不被压垮。熔断就是在系统濒临崩溃的时候，立即中断服务，从而保障系统稳定避免崩溃。它类似于电器中的“保险丝”，当电流过大的时候，“保险丝”会先被烧掉，断开电流，以免电路过热烧毁电器引起火灾。
4.3.3 限流，提供过载保护
限流的原理跟熔断有点类似，都是通过判断某个条件来确定是否执行某个策略。但是又有所区别，熔断触发过载保护，该节点会暂停服务，直到恢复。限流，则是只处理自己能力范围之内的请求，超量的请求会被限流。
4.3.4 降级
比如电商大促，业务在峰值时刻，系统抵挡不住全部的流量时，系统的负载、CPU 的使用率都超过了预警水位，可以对一些非核心的功能进行降级，降低系统压力，比如把商品评价、成交记录等功能临时关掉。弃车保帅，保证 创建订单、支付 等核心功能的正常使用。当然不同业务、不同公司处理方式也各不相同，需要结合实际场景，和业务方一块讨论，最后达成一个统一认可的降级方案。总结来说降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性
参考文献
[1]房辉,常盛. 大型网站高性能架构研究[J]. 信息系统工程,2015(12):76-77.
[2]刘洋. 分布式架构简述[J]. 中国科技纵横,2019(3):18-19,23.
[3]徐顺,王武,张鉴,等. 面向异构计算的高性能计算算法与软件[J]. 软件学报,2021,32(8):2365-2376.
[4]朱革,余浩源,王先全,等. 高并发Java服务器设计研究[J]. 电脑知识与技术