高并发架构经验, 9种高性能可用高并发的技术架构

Yanyan 2018 2023-11-06

高并发架构经验

高并发架构经验, 9种高性能可用高并发的技术架构

一、高并发的说明和背景

高并发解决的核心问题是在同一时间上有大量的请求过来,然后我们的系统要怎么抗住这些请求带来的压力。比如在线直播服务,同时有上百万甚至上千万人观看。比如秒杀品,同时有大量用户涌入。

高并发是从业务角度去描述系统的能力,实现高并发的手段可以采用分布式,也可以采用缓存等,当然也包括多线程、协程,但远远不仅如此;高并发的基本表现为单位时间内系统能够同时处理的请求数,高并发的核心是对资源的有效压榨,有限的资源应对大量的请求。

现代互联网服务,基本上都要考虑高并发问题,因为一般的产品,用户的请求量都很大。

二、高并发架构设计经验

高并发架构设计,需要从三大层来建设和分析

基础设施层:这个是最基础的依赖,主要是一些服务的部署。针对大公司而言,一般都有成熟的系统和基础设施来承载,可能针对业务开发的同学来看,平时关注的的细节并不深入,但是不妨碍我们从全局角度来剖析高并发的设计。

服务端架构层:这个是我们重点要关注的架构设计,架构设计不合理,就很难抗住高并发,主要包括各种架构和模块的设计。

服务应用层:这个主要是针对我们写的代码来进行优化改进。从代码架构、代码性能等方便去抗并发。

1、基础设施层

部署:多 IDC + 异地多活

基础设施层一般包含了服务器、IDC、部署方式等等。目前而言,我们一般都用容器部署的方式,而容器的底层能力基本也都是建立在 k8s 容器层之上的,服务本身的部署管理已经有成熟的设施帮我们实现了。具体到部署方式,包括但不限于:

多 IDC 部署。比如服务同时在广州、上海两地部署。这个依赖我们的服务是无状态的

 其他的参考下 异地多活架构等相关部署。

监控:可观测性

系统的可观测性主要包含三个部分: logging、tracing、metrics。这个一般都要引入可观测系统,这样才能帮助我们在异常的时候能够快速定位问题。属于必备设施,一般而言,公司应该都有专门的团队去做这个事情。

2、服务端架构层

服务端架构层是我们重点要关注的,这个也是考量个人架构能力的最关键部分。

系统分层设计:分层、分割、分布式

架构分层

应用层:网站首页,用户中心,商品中心,购物车,红包业务,活动中心等,负责具体业务和视图展示

服务层:订单服务,用户管理服务,红包服务,商品服务等,为应用层提供服务支持

数据层:关系数据库,nosql数据库 等,提供数据存储查询服务

将系统在横向维度上切分成几个部分,每一层的功能职责要足够单一,然后通过上层对下层的依赖和调度组成一个完整的系统

比如把电商系统分成:应用层,服务层,数据层。(具体分多少个层次根据自己的业务场景)

业务分割

在纵向方面对业务进行切分,将一块相对复杂的业务分割成不同的模块单元,对应的是模块的划分,通过合理的模块划分,使得每个模块都能可以满足 高内聚低耦合 的设计要求,这样不同的模块可以分布式部署,也能提高并发处理能力和功能扩展

比如用户中心可以分割成:账户信息模块,订单列表模块,充值模块,优惠券模块等

分布式

分布式应用和服务,将分层或者分割后的业务分布式部署,独立的应用服务器,数据库,缓存服务器,当业务达到一定用户量的时候,再进行服务器均衡负载,数据库,缓存主从集群

集群架构设计:应用集群、数据集群

应对高并发系统,不管是应用层面还是数据层面,单机都不可能搞定,因此都需要搭建集群架构,然后通过负载均衡来对外提供服务。同时集群架构还能保证系统的可用性,当某台服务或者机器异常,负载均衡会自动剔除,不会影响对外服务。

应用服务器集群

nginx 反向代理

slb

LVS …

数据集群(关系/nosql数据库)

主从分离,一主多从

数据读写分离

数据库设计:读写分离+分库分表+冷热分离

应对高并发,数据的存储,首先就要做好预估,先进行分库分表 和 读写分离,最后可以根据情况来看是否冷热分离:

读写分离。互联网系统大多数都是读多写少,因此读写分离可以帮助主库抗量。一般我们都是一主多从的架构,可以抗量,也可以保证数据不丢。分库分表只能解决 QPS 高,但是无法解决 TPS 高,比如写入的量足够大的话(TPS 高),就得读写分离。

分库分表。数据存储量大的时候,就需要通过分库分表来存储。先分,避免后期要拆,后期拆的话,就面临洗数据的问题,就需要采用双写模式来搞定。

分库分表模式虽然能显著提升数据库的容量,但会增加系统复杂性,而且由于只能支持少数的几个维度读写,从某种意义上来说对业务系统也是一种限制,因此在设计分库分表方案的时候需要结合具体业务场景,更全面的考虑。

冷热分离。针对业务场景而言,如果数据有冷热之分的话,可以将历史冷数据与当前热数据分开存储,这样可以减轻当前热数据的存储量,可以提高性能。

不过,既然是高并发系统,不能应用层直接读写 DB 的,一定有一个缓存在上面,如果直接读写 DB 能够搞定,其实不能叫高并发了,只能说是并发有点高。在非互联网系统里面还是可以的。

缓存设计:多级缓存架构和本地缓存

缓存的最大作用是可以提升系统性能,保护后端存储不被大流量打垮,增加系统的伸缩性。缓存的设计,需要分多个思路并行

首先要考虑的,就是必须在数据库之上,增加一层分布式缓存,比如 Redis 或者 Memcached。

这里需要考虑一下缓存和数据库一致性的问题。

其次需要考虑的是多级缓存架构。分几级缓存设计,同时设计热点缓存架构。

在分布式缓存之上,还可以加一个本地缓存,来缓存最热的数据

采用多个分布式缓存来搭建多级缓存。

消息队列设计:MQ 抗量和削峰

针对流量突峰,仅仅有缓存来抗量可能还不够,还需要使用消息队列来削峰。使用消息队列后,可以将同步处理的请求改为 通过消费 MQ 消息来异步消费,这样可以大大减少系统处理的压力,增加系统的并发量。常用的消息队列比如 kafka。

服务治理设计:超时、熔断、降级、限流等

超时、熔断、降级、限流等都是常规策略,可以在另外服务治理章节去细看。

资源隔离设计:SET 部署

资源隔离有各种类型,物理层面的服务器资源、中间件资源,代码层面的线程池、连接池,这些都可以做隔离。

一般我们最常见的就是应用部署层面的,比如 SET 化部署。一个服务对外的使用方可能有 A 业务、B 业务,那么如何保证 AB 业务不会相互影响,那么就是 SET 化部署。SET 化部署也可以防止非关键业务来影响关键核心业务。一个隔离的维度可以是按业务场景区分,分为关键集群、次关键集群和非关键集群三类,这样能避免关键和非关键业务互相影响。

SET 化部署就是把业务系统分为多个可扩展的逻辑分区,每个 SET 化的逻辑分区都可以独立部署并提供服务,SET 也可以理解为 ”逻辑机房“ ,主要目的就是为了进行独立部署并且做到业务上的逻辑隔离。

关于 SET 的具体例子:微信红包用户发一个红包时,微信红包系统生成一个ID作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作,都根据这个ID关联。红包系统根据这个红包ID,按一定的规则(如按ID尾号取模等),垂直上下切分。切分后,一个垂直链条上的逻辑Server服务器、DB统称为一个SET。各个SET之间相互独立,互相解耦。并且同一个红包ID的所有请求,包括发红包、抢红包、拆红包、查详情详情等,垂直stick到同一个SET内处理,高度内聚。通过这样的方式,系统将所有红包请求这个巨大的洪流分散为多股小流,互不影响,分而治之,

3、服务应用层

多线程、线程同步、协程

并发问题一直是服务端编程中的重点和难点问题,为了优化系统的并发量,单机解决高并发问题从最初的 Fork 进程开始,到进程池/线程池,再到 Epoll 事件驱动(Nginx),再到协程(如 Goroutine)。

对于 Go 语言,尽可能的多使用协程去提高并发能力。

异步化

消息队列也是一种异步化操作,但是除了依赖外部的中间件如消息队列,在应用内我们也可以通过线程池、协程的方式做异步化,能异步的尽量异步处理,这样可以提高并发。

预处理:预加载、预热

系统的预热一般有JVM预热、缓存预热、DB预热等,通过预热的方式让系统先“热”起来,为高并发流量的到来做好准备。预热实际应用的场景有很多,比如在电商的大促到来前,我们可以把一些热点的商品提前加载到缓存中,防止大流量冲击DB。

还有一种预热的思路是利用业务的特性做一些预加载,比如 feeds 流刷新的时候,提前加载 1-2 页数据,这样用户往下刷新的时候,就感觉不到卡顿。


9种高性能可用高并发的技术架构

1、分层

分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统。

在网站的分层架构中,常见的为3层,即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等。

分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层结构分别部署在不同的服务器上,是网站拥有更多的计算资源以应对越来越多的用户访问。

所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护,但在网站的发展过程中,分层结构对网站支持高并发向分布式方向的发展至关重要。

2、冗余

网站需要7×24小时连续运行,那么就得有相应的冗余机制,以防某台机器宕掉时无法访问,而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。

3、分隔

如果说分层是将软件在横向方面进行切分,那么分隔就是在纵向方面对软件进行切分。

网站越大,功能越复杂,服务和数据处理的种类也越多,将这些不同的功能和服务分隔开来,包装成高内聚低耦合的模块单元,不仅有助于软件的开发维护也便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力。

大型网站分隔的粒度可能会很小。比如在应用层,将不同业务进行分隔,例如将购物、论坛、搜索、广告分隔成不同的应用,有对立的团队负责,部署在不同的服务器上。

4、异步

使用异步,业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方法异步执行进行协作。

具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理;在分布式系统中可用通过分布式消息队列来实现异步。

异步架构的典型就是生产者消费者方式,两者不存在直接调用。

5、分布式

对于大型网站,分层和分隔的一个主要目的是为了切分后的模块便于分布式部署,即将不同模块部署在不同的服务器上,通过远程调用协同工作。分布式意味着可以使用更多的计算机完同样的工作,计算机越多,CPU、内存、存储资源就越多,能过处理的并发访问和数据量就越大,进而能够为更多的用户提供服务。

在网站应用中,常用的分布式方案有一下几种.

分布式应用和服务:将分层和分隔后的应用和服务模块分布式部署,可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。

分布式静态资源:网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署,并采用独立的域名,即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载的速度。

分布式数据和存储:大型网站需要处理以P为单位的海量数据,单台计算机无法提供如此大的存储空间,这些数据库需要分布式存储

分布式计算:目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算,其特点是移动计算而不是移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算。

6、安全

网站在安全架构方面有许多模式:通过密码和手机校验码进行身份认证;登录、交易需要对网络通信进行加密;为了防止机器人程序滥用资源,需要使用验证码进行识别;对常见的XSS攻击、SQL注入需要编码转换;垃圾信息需要过滤等。

7、自动化

具体有自动化发布过程,自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。

8、集群

对于用户访问集中的模块需要将独立部署的服务器集群化,即多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务。

服务器集群能够为相同的服务提供更多的并发支持,因此当有更多的用户访问时,只需要向集群中加入新的机器即可;另外可以实现当其中的某台服务器发生故障时,可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上,因此可以提高系统的可用性。

9、缓存

缓存目的就是减轻服务器的计算,使数据直接返回给用户。在现在的软件设计中,缓存已经无处不在。具体实现有CDN、反向代理、本地缓存、分布式缓存等。

使用缓存有两个条件:访问数据热点不均衡,即某些频繁访问的数据需要放在缓存中;数据在某个时间段内有效,不过很快过期,否在会因为数据过期而脏读,影响数据的正确性。



版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:多线程高并发如何优化?
下一篇:MySQL如何做到高并发处理,数据库的高并发和高可用方案
相关文章