互联网三高架构综述
郭智昊
(1. 石家庄铁道大学，河北省 石家庄市 056001)
摘要：近年来，"三高"(高并发,高性能,高可用)平台,已经成为了大型互联网站点的主流需求。文章主要从互联网三高架构的技术特点、要求以及设计方案三个方面展开。综述三高架构在互联网网站中的应用以及三者之间紧密的联系。
关键词：高并发；高可用；高性能；架构
中图分类号： 文献标识码：A
1 高并发
高并发是互联网系统架构的性能指标之一，它通常是指单位时间内系统能够同时处理的请求数目。
1.1 特点
高并发绝不意味着只追求高性能，这是很多人的一种片面的理解。从宏观角度上来看，高并发系统设计的目标有三个：高性能、高可用，以及高可扩展。
高性能体现了系统的并行处理能力，在有限的硬件投入下，提高性能意味着节省成本。同时，性能也反映了用户体验，响应时间分别是100毫秒和1秒，给用户的感受是完全不同的。
高可用表示系统可以正常服务的时间。一个全年不停机、无故障；另一个隔三岔五出线上事故、宕机，用户肯定选择前者。另外，如果系统只能做到90%可用，也会大大拖累业务。
高扩展表示系统的扩展能力，流量高峰时能否在短时间内完成扩容，更平稳地承接峰值流量，比如双11活动、明星吸毒、明星偷税等热点事件。
图1 高并发系统目标
这3个目标是需要通盘考虑的，因为它们互相关联、甚至也会相互影响。
比如说：考虑系统的扩展能力，你会将服务设计成无状态的，这种集群设计保证了高扩展性，其实也间接提升了系统的性能和可用性。再比如说：为了保证可用性，通常会对服务接口进行超时设置，以防大量线程阻塞在慢请求上造成系统雪崩。
1.2 要求
1.2.1 性能指标
通过性能指标，可以度量目前存在的性能问题，同时作为性能优化的评估依据。一般来说，会采用一段时间内的接口响应时间作为目标。
1、平均响应时间：最常用，但是缺陷很明显，对于慢请求不敏感。比如1万次请求，其中9900次是1ms，100次是100ms，则平均响应时间为1.99ms，虽然平均耗时仅增加了0.99ms，但是1%请求的响应时间已经增加了100倍。
2、TP90、TP99等分位值：将响应时间按照从小到大排序，TP90表示排在第90分位的响应时间， 分位值越大，对慢请求越敏感。
3、 吞吐量：和响应时间呈反比，比如响应时间是1ms，则吞吐量为每秒1000次。
通常，设定性能目标时会兼顾吞吐量和响应时间，比如这样表述：在每秒1万次请求下，AVG控制在50ms以下，TP99控制在100ms以下。对于高并发系统，AVG和TP分位值必须同时要考虑。
1.2.2 可用性指标
高可用性是指系统具有较高的无故障运行能力，可用性 = 平均故障时间 / 系统总运行时间，一般使用几个9来描述系统的可用性。
对于高并发系统来说，最基本的要求是：保证3个9或者4个9。原因很简单，如果你只能做到2个9，意味着有1%的故障时间，像一些大公司每年动辄千亿以上的GMV或者收入，1%就是10亿级别的业务影响。
1.2.3 可扩展性指标
面对突发流量，不可能临时改造架构，最快的方式就是增加机器来线性提高系统的处理能力。
对于业务集群或者基础组件来说，扩展性 = 性能提升比例 / 机器增加比例，理想的扩展能力是：资源增加几倍，性能提升几倍。通常来说，扩展能力要维持在70%以上。
但是从高并发系统的整体架构角度来看，扩展的目标不仅仅是把服务设计成无状态就行了，因为当流量增加10倍，业务服务可以快速扩容10倍，但是数据库可能就成为了新的瓶颈。
像MySQL这种有状态的存储服务通常是扩展的技术难点，如果架构上没提前做好规划（垂直和水平拆分），就会涉及到大量数据的迁移。
因此，高扩展性需要考虑：服务集群、数据库、缓存和消息队列等中间件、负载均衡、带宽、依赖的第三方等，当并发达到某一个量级后，上述每个因素都可能成为扩展的瓶颈点。
1.3 设计方案
互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。
垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：
（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；
（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。
不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。
水平扩展：只要增加服务器数量，就能线性扩充系统性能。
2 高性能
2.1 特点
高性能是指程序处理速度快，所占内存少，CPU占用率低。高性能与高并发是紧密相关的，提高应用的性能，是肯定可以提高系统的并发能力的。
2.2 要求
2.2.1 并发数
并发数指的是系统同时能处理的请求数量，同样反应了系统的负载能力。这个数值可以分析及其1s内访问日志数量来得到。此数值越大，表示系统的并发数越多，系统性能也就越好。
2.2.2 吞吐量
吞吐量是指系统单位时间内处理请求的数量，TPS、QPS都是吞吐量的常用量化指标。系统的吞吐量越大，系统的性能同样也就越好。
2.3 设计方案
2.3.1 分布式缓存
缓存的本质是通过key-value形式的Hash表提升读写速度，一般情况是O(1)的读写速度。读写量比较高，变化量不大的数据比较适合使用缓存。业内比较成熟的分布式缓存系统有redis/memcache。
一般的缓存设计架构如下：用户第一次请求应用程序时，通过存储服务直接读取数据，然后将数据存储到缓存系统去，用户第二次请求的时候就直接从缓存系统读取，从而提升读取速度。
2.3.2 服务分层
在经典的三层（接入层、逻辑层和存储层）后台服务架构中，三层的划分的原则就是同层次的系统专注处理自己的事情。接入层专注于处理前端和后台服务的接入连通、安全认证和数据转发。逻辑层专注于处理不同业务的无状态逻辑服务。存储层专注于处理业务数据的存储。这样分层的好处在于各个层次能够依据业务特点专注于自己的事情，提高系统复用性，降低业务间的耦合性。在中小型网站中三层架构的典型实现是Nginx（接入层）、Apache Web（逻辑层）、Mysql/Redis（存储层）。
图2 服务分层
2.3.3 操作异步化
目前大型系统中普遍消息队列来将调用异步化，不仅可以提升系统性能还可以提升系统的扩展性。对于大量的数据库写请求，对于数据库的压力很大，同时也会造成数据库响应不及时。可以考虑使用消息队列，数据库的写请求可以直接写入到消息队列，然后通过多线程或多进程从消息队列中读取数据慢慢写入到数据库。消息队列服务器的处理速度会远远快于数据库，所以用户在写入操作时会感觉到很快的写入速度。
此外，消息队列对于请求不均衡的系统，还具有削峰填谷的作用，将短时间内的高峰请求，逐步平摊到更长的时间里去，从而避免短时间内大量请求压跨系统。
图3 操作异步化
2.3.4 分布式集群化
分布式集群化是指将不同的业务用集群化的方式部署到不同的机器上去，对于每一个业务都具备大规模集群化的能力，从而提升系统的扩展性和高性能。
对于无状态化的被调服务A，在基于负载均衡的技术下，可以通过集群化部署成倍的提升服务性能，比如A1服务的性能是1万请求每秒，那么部署3台A服务机器，那么A服务的性能就是3万请求每秒了。
3 高可用
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。
百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。
3.1 特点
所谓业务可用性(availability)也即系统正常运行时间的百分比，架构组最主要的 KPI (Key Performance Indicators ，关键业绩指标)。对于我们提供的服务（web，api）来说，现在业界更倾向用 N 个9 来量化可用性，最常说的就是类似“4个9(也就是99.99%)” 的可用性。
3.2 要求
我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。所以，为了保证系统高可用，架构设计的核心准则是：冗余。
有了冗余之后，还不足以保证系统的高可用，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。
3.3 设计方案
3.3.1 DNS负载均衡
是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。
3.3.2 隔离法
隔离是指将系统或资源分割开，系统隔离是为了在系统发生故障时，能限定传播范围和影响范围，即发生故障后不会出现滚雪球效应，从而保证只有出问题的服务不可用，其他服务还是可用的。资源隔离通过隔离来减少资源竞争，保障服务间的相互不影响和可用性。
在实际生产环境中，比较多的隔离手段有线程隔离、进程隔离、集群隔离、机房隔离、读写隔离、快慢隔离、动静隔离等。
线程隔离
线程隔离主要指的是线程池隔离，请求分类，交给不同的线程池进行处理。 一个请求出现异常，不会导致故障扩散到其他线程池，这样就保证系统的高可用性。
图4 线程隔离
进程隔离
把项目拆分为一个个的子项目，然后让这些子项目进行物理隔离，项目与项目之间没有调用关系。
图5 进程隔离
引用
[1]陈伟. 构建高并发,高性能,高可用平台实战——总体架构与技术选型[J]. IT经理世界, 2020.
[2]张立刚. 1号店11.11:从应用架构落地点谈高可用高并发高性能.