架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路

这篇具有很好参考价值的文章主要介绍了架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

大并发/大数据的软件有如下特点

大并发/大数据的架构目标有如下几个

大并发/大数据的设计思路与原则

大并发/大数据的分层架构

1 接入层的架构方案:

第二三层:应用层/服务层架构方案

第四层:数据层架构方案

第五层:基础设施层架构

高并发核武器:单元化+异地多活设计


大并发/大数据的软件有如下特点

  • 用户多,分布广泛

  • 大流量,高并发

  • 从小到大,渐进发展

  • 以用户为中心

  • 海量数据,服务高可用

  • 安全环境恶劣,易受网络攻击

  • 功能多,变更快,频繁发布

大并发/大数据的架构目标有如下几个

  • 高性能:提供快速的访问体验。

  • 高可用:网站服务一直可以正常访问。

  • 可伸缩:通过硬件增加/减少,提高/降低处理能力。

  • 扩展性:方便地通过新增/移除方式,增加/减少新的功能/模块。

  • 安全性:提供网站安全访问和数据加密、安全存储等策略。

  • 敏捷性:随需应变,快速响应。

大并发/大数据的设计思路与原则

1.演进原则

优秀的架构和产品都是一步一步迭代出来的,用户量的不断增大,业务的扩展进行不断地迭代升级,最终演化成优秀的架构。

  • 早期项目,由于团队规模有限,技术经验不足,往往使用一个简单的单体架构、单节点DB。

  • 随着流量增加和业务演变,需要不断修正系统架构中的问题点,基于后面的几个原则,一点一点的进行系统演进

演进原则:高并发/大数据系统的演进是循序渐进的,以在高并发、大数据场景下不断优化用户体验为目标。

2.单一职责( Single Responsibility Principle)原则

定义:对一个类而言,应该仅有一个引起它变化的原因。

说明:一个类应该是相关性很高的封装,类只实现一个功能。

很多的时候,我们代码中有大量的上帝类,所谓上帝类

把不应该是一个类的功能也往自己身上揽,大包大揽,导致内聚性就会很差,

内聚性差将导致代码很难被复用,不能复用,只能复制(Repeat Yourself),其结果就是一团乱麻。

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

3.开闭原则(Open Closed Principle)

定义:软件中的对象应该对于扩展是开放的,对于修改是关闭的。面对新需求,对程序的改动应该是通过增加代码实现的而不是修改现有代码来实现

说明:当软件需要变化时,我们尽可能的通过扩展的方式来实现变化,

比如通过继承,通过装饰者模式来增加新的功能,而不是通过修改已有的接口来实现,一旦修改接口,上层调用的地方均需要修改。

开闭原则是面向对象设计的核心所在,遵循开闭原则的最好手段就是抽象

防止变异(Protected Variations)

问题:如何设计对象,子系统和系统,使其内部的变化或不稳定性不会对其他元素产生不良影响?

解决方案:分离变与不变,  识别变化或不稳定的地方,抽象出稳定的接口。

开发人员应该仅对程序中频繁出现变化的那些部分做出抽象,如果对于应用程序中每个部分都做刻意的抽象并不是个好主意。

拒绝不成熟的抽象和抽象本身一样重要。

4.高内聚低耦合/迪米特原则(Law of Demeter)

定义:

  • 如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的互相引用。

  • 如果中间一个类需要调用另一个类的某一个方法,可以通过第三者转发这个调用。

一个对象应该对其他对象有最少的了解也被称为最少知识原则。

该原则首先强调的是在类的结构设计上,应该尽可能低的设计成员的访问权限。

其根本思想是强调了类的松耦合,类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会波及有关系的类。

也就是说,一个类应该对自己需要耦合或调用的类知道的最少,类与类之间的关系越密切,耦合度越大,那么类的变化对其耦合的类的影响也会越大,这也是我们面向对象设计的核心原则:低耦合,高内聚。

什么是直接的朋友?

每个对象都必然与其他对象有耦合关系,两个对象的耦合就成为朋友关系,这种关系的类型很多,例如组合、聚合、依赖、关联等。

其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部

5.横向扩展(Scale-out)原则。

纵向扩展总是有 上限的, 大数据、大并发系统的核心思路之一就是:横向扩展。

横向扩展(Scale-out)的核心思路:采用分布式策略将系统的负载分散到多台服务器上,每台服务器处理一部分并发和流量。

横向扩展(Scale-out)可以充分利用现有硬件资源,提高系统的整体性能,使系统更能应对大规模并发请求。

6.缓存原则

缓存,广泛应用于系统设计的各个方面。

缓存,从操作系统到浏览器,从数据库到消息队列,从应用软件到操作系统,从操作系统到CPU,无处不在。

缓存,几乎所有复杂的服务和组件都在使用。

缓存,是空间换时间的思想。

7.异步原则

同步调用,意味着调用方在调用一个方法后会阻塞等待该方法的逻辑执行完成。

异步调用 与 同步相反。

异步调用 ,  主要是三大步骤:

  • 调用方发出请求后不需要等待,快速返回

  • 被调方可以慢慢执行,

  • 调用方通过回调函数、事件通知等方式获取执行的结果。

异步调用 方式在大规模高并发系统中被广泛采用。

以 12306 网站为例。

  • 当用户订票时,先将请求丢到消息队列中,然后立即告诉用户正在处理,然后立即返回。

  • 系统进行复杂的订票操作,如查询余票、下单、更改余票状态等,这些操作可能需要耗费较长时间

  • 当订票操作完成后,系统再通知用户订票成功或失败。

这种异步处理方式使得系统能够更好地应对高并发,减少了资源占用,提高了系统的性能和可扩展性。

大并发/大数据的分层架构

高并发/大数据的架构设计,一般是分层进行,可以从下面的5大层来建设和分析:

1:接入层

主要流量入口

2:应用层

负责具体业务和视图展示;

网站首页、用户中心、商品中心、购物车、红包业务、活动中心等,

3:服务层

根据业务领域每个子域单独一个服务,分而治之。

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

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

4:数据层

数据库和NoSQL,文件存储等。

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

5:基础设施层

这个是最基础的依赖,主要是一些服务的部署。

基础设施层一般包含了服务器、中间件、部署方式等等。

1 接入层的架构方案:

动静分离,分而治之

  • 动态资源使用  Nginx+LVS+KeepAlive 进行负载均衡

  • 静态资源使用 CDN进行加速

动态资源Nginx+LVS+KeepAlive 进行负载均衡

请参见之前的文章

10Wqps网关接入层,LVS+Keepalived(DR模式)如何搭建?

静态资源使用CDN加速

CDN相当于加上一层缓存, 加载离用户最近的idc机房, 由cdn的运营商提供, 比如电信等

秒杀的静态页面通过到CDN上预热(CDN是内容分发网络,可以简单理解成互联网上的巨大的缓存,用于存放静态页面、图片、视频等,可以显著提高访问速度),

用CDN扛流量,这样大量的商品详情页的访问请求就不用访问自己的网站(源站)。这样既可以提高访问速度,也没有给网站增加压力,同时也减少了网站带宽压力。

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

第二三层:应用层/服务层架构方案

1:业务解耦

对一个复杂的业务,需要分割成不同的模块单元,分而治之

一个大的问题域,需要分解为很多小的问题域,分而治之

就是是微服务划分、微服务架构

微服务架构解决大单体架构的的很多问题,比如扩展性、弹性伸缩能力、小规模团队的敏捷开发等等。

如何进行微服务架构,如何划分微服务:

  • 高内聚低耦合

  • 单一职责

  • 可扩展原则

  • 等等等等

如何进行业务解耦,如何划分微服务?

在实操过程中, 建议使用DDD的建模方法进行建模。

具体请参见以下的文章

《美团面试:微服务如何拆分?原则是什么?》

2:横向扩展设计

横向扩展设计,包括:应用集群、服务集群

应对高并发系统,单节点模式都不可能搞定,因此都需要搭建应用集群、服务集群,

常见的微服务Provider的自动伸缩策略有以下两种:

1)通过Kubernetes HPA组件实现自动伸缩。

2)通过微服务Provider自动伸缩伺服组件实现自动伸缩。

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

3:缓存设计:多级缓存架构

缓存,广泛应用于系统设计的各个方面。

缓存,从操作系统到浏览器,从数据库到消息队列,从应用软件到操作系统,从操作系统到CPU,无处不在。

缓存,几乎所有复杂的服务和组件都在使用。

缓存,是空间换时间的思想。

缓存的可以提升系统性能,保护后端存储不被大流量打垮。

缓存的设计,需要分多个思路并行。

  • 普通数据一级缓存就够了

  • 热点数据要用到多级缓存

缓存的设计方案很多, 很复杂,也是面试的热点和难点

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

4:异步原则:进程内的异步

进程内的异步, 是一个很有深度的问题, 把这个问题归纳为全链路异步

全链路异步,能大大的优化系统的并发量,单机解决高并发问题

从应用层的线程池,再到 IO层的Epoll 事件驱动(Nginx),都需要最大程度的异步。

全链路异步模式改造 具体的内容,请参考深度文章:

全链路异步,让你的性能优化10倍+

另外,对于特殊的高并发场景,可以使用  Go+java的混合架构, 进一步压榨 CPU的性能

借助 Go 语言协程,去提高并发能力。

5:异步原则:进程外的异步

消息队列也是一种异步化操作,是依赖外部的中间件如消息队列,进行的异步。

针对流量突峰,仅仅有缓存来抗量可能还不够,还需要使用消息队列来异步削峰。

使用消息队列后,可以将同步处理的请求改为 通过消费 MQ 消息来异步消费,这样可以大大减少系统处理的压力,增加系统的并发量。

常用的消息队列比如 kafka、Rocketmq。

6:预热原则

预热实际应用的场景有很多,比如在电商的大促到来前,我们可以把一些热点的商品提前加载到缓存中,防止大流量冲击DB。

预热原则一般有JVM预热、缓存预热、DB预热等,

通过预热的方式让系统先“热”起来,为高并发流量的到来做好准备。

第四层:数据层架构方案

1:分库分表

数据存储量大的时候,就需要通过分库分表来存储。

分库分表模式虽然能显著提升数据库的容量,但会增加系统复杂性,因此在设计分库分表方案的时候需要结合具体业务场景,更全面地考虑。

2:读写分离

高并发系统,大多数都是读多写少,因此读写分离可以帮助主库抗量。

一般我们都是一主多从的架构,可以抗量,也可以保证数据不丢。

3:冷热分离

针对业务场景而言,如果数据有冷热之分的话,可以将历史冷数据与当前热数据分开存储,

这样可以减轻当前热数据的存储量,可以提高性能。

4:使用NoSQL完成大数据的存储

当数据库中的数据多到一定规模时,数据库就不适用于复杂的查询了,往往只能满足普通查询的场景。

对于统计报表场景,在数据量大时不一定能跑出结果,而且在跑复杂查询时会导致其他查询变慢,对于全文检索、可变数据结构等场景,数据库天生不适用。

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

第五层:基础设施层架构

基础设施层架构 包含:

  • 监控三大件: logging、tracing、metrics。

  • 各种中间件

  • cicd组件

具体,请参见文章

网易面试:亿级用户,如何做微服务底层架构?

高并发核武器:单元化+异地多活设计

除了前面的高并发常规武器, 还有高并发的核武器::单元化+异地多活设计

1:单元化(Set化)设计

一个服务对外的使用方可能有 A 业务、B 业务,那么如何保证 AB 业务不会相互影响,那么就是单元化(Set化)设计。

所谓单元,是指一个能完成所有业务操作的自包含集合,在这个集合中包含了所有业务所需的所有服务,以及单元的数据分片

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

单元化架构就是把单元作为系统部署的基本单位,在全站所有idc机房中部署数个单元.

每个idc机房里的单元数目不定,任意一个单元都部署了系统所需的所有的服务

任意一个单元的数据是首先拥有分片数据,但是为了切流的方便, 最终需要拥有全量数据

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

传统意义上的 SOA 化(服务化)架构,服务是分层的,每层的节点数量不尽相同,上层调用下层时,随机选择节点。

单元化架构下,服务仍然是分层的,

不同的是每一层中的任意一个节点都属于且仅属于某一个单元,上层调用下层时,仅会选择本单元内的节点。

架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路,架构设计 内容分享,大数据,系统架构

而要做到单元化,必须要满足以下要求:

  • 业务必须是可分片的,如 淘宝按照用户分片, 饿了么按照地理位置分片

  • 单元内的业务是自包含的,调用尽量封闭

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

关于 单元化SET 的具体例子:

  • 微信红包用户发一个红包时,微信红包系统生成一个ID作为这个红包的唯一标识。

  • 接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作,都根据这个ID关联。

  • 红包系统根据这个红包ID,按一定的规则(如按ID尾号取模等),垂直上下切分。

  • 切分后,一个垂直链条上的逻辑Server服务器、DB统称为一个SET。

单元化SET 部署之后,系统将所有红包请求这个巨大的洪流分散为多股小流,互不影响,分而治之。

现在稍微有点体量的公司都在做单元化,单元化的好处

1. 多AZ(可用区) 容灾、异地多活。

2. 服务器体量太大,单一IDC没有足够的机器。

3. 提升用户请求访问速度。

2:多 IDC + 异地多活

基础设施层一般包含了服务器、IDC、部署方式等等。

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

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

3:异地多活的系列问题

异地多活方案复杂, 之前积累过一系列的问题,可供参考:

架构设计内容分享(七):100Wqps异地多活,得物是怎么架构的?_软件项目异地多活-CSDN博客

架构设计内容分享(一百一十二):单元化、异地多活,大厂如何实现?_业务做单元化 是为了双活-CSDN博客


架构设计内容分享(一百五十五):Redis 异地多活的演进历程-CSDN博客文章来源地址https://www.toymoban.com/news/detail-833484.html

到了这里,关于架构设计内容分享(二百一十):设计一个大并发、大数据的系统架构,说说设计思路的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 二百一十九、Hive——HQL报错:Caused by: java.util.regex.PatternSyntaxException: Illegal repetition near index 1

    在海豚调度HQL的脚本任务时报错, Caused by: java.util.regex.PatternSyntaxException: Illegal repetition near index 1 with t1 as( select        get_json_object(queue_json,\\\'$.deviceNo\\\')   device_no,        get_json_object(queue_json,\\\'$.createTime\\\') create_time,        get_json_object(queue_json,\\\'$.laneNum\\\')    lane_num,        ge

    2024年02月01日
    浏览(56)
  • 二百一十八、Hadoop——Hadoop启动报错Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

    在完成Flume拓扑结构之聚合的开发案例,启动了hurys23服务器早已安装好的Hadoop,结果居然报错了 hurys23: Permission denied ( publickey,gssapi-keyex,gssapi-with-mic,password ). 启动Hadoop发现报错后,jps查看一下,发现之启动了ResourceManager服务 [root@hurys23 ~]# jps 4096 ResourceManager 4823 Jps 根据报错提

    2024年02月02日
    浏览(53)
  • JAVA面试题分享五百一十一:Spring Boot基于WebUploader实现超大文件上传和断点续传

    目录 前言 目标 实现思路 大文件分片 合并分片 断点续传 代码实现 1、webuploader组件中,分片上传怎么开启? 2、webuploader组件中,文件的md5值如何计算? 3、webuploader组件中,分片文件的md5值如何计算? 4、webuploader组件中,分片上传的的请求在哪里触发? 5、前端、后端如何校

    2024年02月19日
    浏览(61)
  • 第一百一十八回 如何获取蓝牙连接状态

    我们在上一章回中介绍了如何连接蓝牙设备相关的内容,本章回中将介绍如何获取蓝牙连接状态.闲话休提,让我们一起Talk Flutter吧。 我们在上一章回中介绍如何连接蓝牙设备,但是如何知道蓝牙设备是否连接成功呢?这就需要我们去获取蓝牙设备的连接状态,通过蓝牙设备

    2024年02月12日
    浏览(58)
  • Android之关机/重启/recovery模式(一百一十五)

    1.方式一:App调用系统api 2.方式二:setprop 注意:在init的reboot.c中,           adb reboot -p命令其实就是调用的setprop命令开关机的。  3.方式三:

    2024年02月14日
    浏览(46)
  • 第一百一十九回 如何通过蓝牙设备读写数据

    我们在上一章回中介绍了如何获取蓝牙状态相关的内容,本章回中将介绍 如何通过蓝牙设备读写数据 。闲话休提,让我们一起Talk Flutter吧。 通过蓝牙设备读写数据有两种方法: 一种是读写Characteristics; 一种是读写Descriptor. 我们在本章回中介绍的读写数据本质上是读写 Cha

    2024年02月12日
    浏览(52)
  • 第一百一十二回 flutter_screenutil包

    我们在上一章回中介绍了屏幕适配相关的内容,本章回中将介绍 flutter_screenutil 包,该包主要用来实现屏幕适配.闲话休提,让我们一起Talk Flutter吧。 我们在本章回中介绍的包是 flutter_screenutil ,它主要用来做屏幕和字体大小的适配,它的实现原理和我们在上一章回中介绍的屏幕

    2024年02月13日
    浏览(56)
  • 一百一十三、DBeaver——从hive同步数据到clickhouse

    目标:把hive的DM层结果数据导出到clickhouse数据库,试了kettle、sqoop等多种方法都报错,尤其是kettle,搞了大半天发现还是不行。结果目前就只能用DBeaver同步数据。 准备工作:hive和clickhouse中都建好表 第一步,右击clickhouse中的表,选择导入数据 第二步,在源类型和格式中,由

    2024年02月13日
    浏览(55)
  • Emacs之实现跨程序选中自动复制功能(一百一十八)

    简介: CSDN博客专家,专注Android/Linux系统,分享多mic语音方案、音视频、编解码等技术,与大家一起成长! 优质专栏: Audio工程师进阶系列 【 原创干货持续更新中…… 】🚀 人生格言: 人生从来没有捷径,只有行动才是治疗恐惧和懒惰的唯一良药. 更多原创,欢迎关注:An

    2024年02月15日
    浏览(81)
  • Emacs之改造最快文本搜索工具ripgrep(一百一十九)

    简介: CSDN博客专家,专注Android/Linux系统,分享多mic语音方案、音视频、编解码等技术,与大家一起成长! 优质专栏: Audio工程师进阶系列 【 原创干货持续更新中…… 】🚀 人生格言: 人生从来没有捷径,只有行动才是治疗恐惧和懒惰的唯一良药. 更多原创,欢迎关注:An

    2024年02月15日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包