互联网三高特性、要求和其设计方案

互联网三高特性、要求和其设计方案

梁鹏波

（石家庄铁道大学 河北省石家庄市  050000）

摘要: 互联网三高包括：高并发、高性能、高可用。面对互联网大型网站的业务要求不断增长，对系统设计提出了更高的要求，其中高并发，高性能，高可用的系统设计越来越耳熟能详了。

关键词: 互联网三高；高并发；高性能；高可用

1 引言

随着各互联网大厂业务需求的井喷式增长，业务架构早已不是个新词。企业业务的高速发展、业务体量的不断增长，业务场景的日益复杂化与差异化，以及不断持续变化的业务需求，都对平台化的架构演进以及系统设计提出了更多的挑战和更高的要求。架构师在进行系统设计时需兼顾业务功能的实现以及同时保证系统的高并发、高可用。系统设计是一个不断迭代的持续过程，但再优秀的架构师也无法在一开始的基础设计中就尽善尽美，那么到底如何设计出综合了高可用架构、灵活易用性、业务拓展性以及数据安全建设性等要求的系统呢？又有哪些必要的规划设计以及核心原则能够规避掉一些未来的风险呢？

2 三高各自的特征

2.1 高并发

互联网分布式系统架构设计中必须考虑的因素之一，它一般是指，经过设计保证系统可以同时并行处理不少请求。

高并发相关经常使用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

2.2 高性能

高性能的架构是以用户为中心，提供快速的网页访问体验，主要参数有较短的响应时间、较大的并发处理能力、较高的吞吐量与稳定的性能参数。计算机软件工程技术在互联网时代取得了高速发展，软件工程技术与大数据技术相结合，提升了软件工程服务 社会的能力。大数据技术的专业实用性对软件工程技术提 出了更高要求，数据处理能力兼顾安全有效性。

2.2 高可用

大型网站应该在任何时候都可以正常访问，正常提供对外服务。因为大型网站的复杂性，分布式，廉价服务器，开源数据库，操作系统等特点，要保证高可用是很困难的，也就是说网站的故障是不可避免的。

3 三高系统设计要求

3.1 高并发要求

互联网分布式架构设计，提升系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。

垂直扩展：提高单机处理能力。垂直扩展的方式又有两种：

（1）加强单机硬件性能，例如：增长CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

（2）提高单机架构性能，例如：使用Cache来减小IO次数，使用异步来增长单服务吞吐量，使用无锁数据结构来减小响应时间；

不论是提高单机硬件性能，仍是提高单机架构性能，都有一个致命的不足：单机性能老是有极限的。因此互联网分布式架构设计高并发终极解决方案仍是水平扩展。

水平扩展：只要增长服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践，是本文重点讨论的内容。

3.2 高性能要求

性能直接影响用户的感官体验，访问一个系统，如果超过5秒没有响应，绝大数用户会选择离开。

满足了高并发，系统压力增大，平均请求延迟也会增大，如此情况下可采用高性能缓存、日志优化，避免IO瓶颈

高性能缓存

对一些热点数据每次都从 DB 中读取，会给 DB 带来较大的压力，导致性能大幅下降。所以，我们需要用缓存来提升热点数据的访问性能，比如将活动信息数据在浏览器的缓存中保存一段时间。

缓存根据性能由高到低分为：寄存器、L1缓存、L2缓存、L3缓存、本地内存、分布式缓存

上层的寄存器、L1 缓存、L2 缓存是位于 CPU 核内的高速缓存，访问延迟通常在 10 纳秒以下。L3 缓存是位于 CPU 核外部但在芯片内部的共享高速缓存，访问延迟通常在十纳秒左右。高速缓存具有成本高、容量小的特点，容量最大的 L3 缓存通常也只有几十MB。

本地内存是计算机内的主存储器，相比 CPU 芯片内部的高速缓存，内存的成本要低很多，容量通常是 GB 级别，访问延迟通常在几十到几百纳秒。

日志优化，避免IO瓶颈

当系统处理大量磁盘 IO 操作的时候，由于 CPU 和内存的速度远高于磁盘，可能导致 CPU 耗费太多时间等待磁盘返回处理的结果。对于这部分 CPU 在 IO 上的开销，我们称为 “iowait”。

Linux 有一种特殊的文件系统：tmpfs（临时文件系统），它是一种基于内存的文件系统，由操作系统管理。当我们写磁盘的时候实际是写到内存中，当日志文件达到我们的设置阈值，操作系统会将日志写到磁盘中，并将tmpfs中的日志文件删除。

3.3 高可用要求

高可用指标是指用来衡量一个系统可用性有多高。

主备切换，缩减故障时间

当系统出现故障时，首要任务不是立马查找原因，考虑到故障的复杂样，定位排查要花些时间，等问题修复好，SLA也降了好几个档。有没有更快的方式解决这个问题？那就是故障转移。

当发现故障节点的时候，不是尝试修复它，而是立即把它隔离，同时将流量转移到正常节点上。这样通过故障转移，不仅减少了 MTTR 提升了 SLA，还为修复故障节点赢得了足够的时间。

主备切换大致分为三步：

第一步故障自动侦测（Auto-detect），采用健康检查、心跳等技术手段自动侦测故障节点；

第二步自动转移（FailOver），当侦测到故障节点后，采用摘除流量、脱离集群等方式隔离故障节点，将流量转移到正常节点；

 

第三步自动恢复（FailBack），当故障节点恢复正常后，自动将其加入集群中，确保集群资源与故障前一致。

熔断，提供过载保护

所谓过载保护，是指负载超过系统的承载能力时，系统会自动采取保护措施，确保自身不被压垮。

熔断就是在系统濒临崩溃的时候，立即中断服务，从而保障系统稳定避免崩溃。它类似于电器中的“保险丝”，当电流过大的时候，“保险丝”会先被烧掉，断开电流，以免电路过热烧毁电器引起火灾。

限流，提供过载保护

限流的原理跟熔断有点类似，都是通过判断某个条件来确定是否执行某个策略。但是又有所区别，熔断触发过载保护，该节点会暂停服务，直到恢复。限流，则是只处理自己能力范围之内的请求，超量的请求会被限流。

降级比如电商大促，业务在峰值时刻，系统抵挡不住全部的流量时，系统的负载、CPU 的使用率都超过了预警水位，可以对一些非核心的功能进行降级，降低系统压力，比如把商品评价、成交记录等功能临时关掉。弃车保帅，保证 创建订单、支付 等核心功能的正常使用。

当然不同业务、不同公司处理方式也各不相同，需要结合实际场景，和业务方一块讨论，最后达成一个统一认可的降级方案。

4 三高系统设计要求

最初的架构，应用程序、数据库、文件都部署在一台服务器上，如下图：

 

 

 

搭建三高系统整体解决思路

横向分层、纵向分割、分布式化、集群化、使用缓存、使用异步模式、使用冗余、自动化（发布、部署、监控）

对于各层次常用的技术要求

1. 前端

l 浏览器优化技术：合理布局，页面缓存，减少http请求数，页面压缩，减少 cookie 传输。

l CDN

l DNS[负载均衡]

l 动静分离

l 动态图片独立提供服务

1. 应用层架构

l 业务拆分

l 负载均衡

l 虚拟化服务器、容器化

l 无状态

l 分布式缓存

l 异步、事件驱动架构、[消息队列]

l 多线程

l 动态页面静态化

1. 服务器架构

l 分布式微服务

l 同应用层架构

1. 存储层架构

l DFS

l 关系[数据库]

l No SQL 数据库

l 数据同步

l 数据冗余

1. 安全架构

l Web攻击

l 数据加密

l 密钥管理

1. 发布、运维

l 自动化测试与发布

l 灰度发布

l 浏览器数据采集

l 服务器业务数据采集

l 服务器性能数据采集

l 系统监控

l 系统报警

分布式三高系统各层结构图

 

 

 

5 结语

综上所述，互联网三高很好的满足的目前各互联网大厂对于业务需求的井喷式增长的需求。三高系统设计时兼顾业务功能的实现以及同时保证系统的高并发、高可用。