首页 > 其他分享 >1111

1111

时间:2023-04-28 22:56:47浏览次数:32  
标签:缓存 架构 系统 1111 并发 分层 Scale

。Scale-out(横向扩展):分而治之是一种常见的高并发系统设计方法,采用分布式部署 的方式把流量分流开,让每个服务器都承担一部分并发和流量。 缓存:使用缓存来提高系统的性能,就好比用“拓宽河道”的方式抵抗高并发大流量的冲 击。 异步:在某些场景下,未处理完成之前,我们可以让请求先返回,在数据准备好之后再通 知请求方,这样可以在单位时间内处理更多的请求。 简单介绍了这三种方法之后,我再详细地带你了解一下,这样当你在设计高并发系统时就可 以有考虑的方向了。当然了,这三种方法会细化出更多的内容,我会在后面的课程中深入讲 解。 首先,我们先来了解第一种方法:Scale-out。 Scale-up vs Scale-out 著名的“摩尔定律”是由 Intel 的创始人之一戈登·摩尔于 1965 年提出的。这个定律提到, 集成电路上可容纳的晶体管的数量约每隔两年会增加一倍。 后来,Intel 首席执行官大卫·豪斯提出“18 个月”的说法,即预计 18 个月会将芯片的性能 提升一倍,这个说法广为流传。 摩尔定律虽然描述的是芯片的发展速度,但我们可以延伸为整体的硬件性能,从 20 世纪后 半叶开始,计算机硬件的性能是指数级演进的。 直到现在,摩尔定律依然生效,在半个世纪以来的 CPU 发展过程中,芯片厂商靠着在有限 面积上做更小的晶体管的黑科技,大幅度地提升着芯片的性能。从第一代集成电路上只有十 几个晶体管,到现在一个芯片上动辄几十亿晶体管的数量,摩尔定律指引着芯片厂商完成了 技术上的飞跃。 但是有专家预测,摩尔定律可能在未来几年之内不再生效,原因是目前的芯片技术已经做到 了 10nm 级别,在工艺上已经接近极限,再往上做,即使有新的技术突破,在成本上也难 以被市场接受。后来,双核和多核技术的产生拯救了摩尔定律,这些技术的思路是将多个 CPU 核心压在一个芯片上,从而大大提升 CPU 的并行处理能力。我们在高并发系统设计上也沿用了同样的思路,将类似追逐摩尔定律不断提升 CPU 性能的 方案叫做 Scale-up(纵向扩展),把类似 CPU 多核心的方案叫做 Scale-out,这两种思路 在实现方式上是完全不同的。 Scale-up,通过购买性能更好的硬件来提升系统的并发处理能力,比方说目前系统 4 核 4G 每秒可以处理 200 次请求,那么如果要处理 400 次请求呢?很简单,我们把机器的 硬件提升到 8 核 8G(硬件资源的提升可能不是线性的,这里仅为参考)。 Scale-out,则是另外一个思路,它通过将多个低性能的机器组成一个分布式集群来共同 抵御高并发流量的冲击。沿用刚刚的例子,我们可以使用两台 4 核 4G 的机器来处理那 400 次请求。 那么什么时候选择 Scale-up,什么时候选择 Scale-out 呢?一般来讲,在我们系统设计初 期会考虑使用 Scale-up 的方式,因为这种方案足够简单,所谓能用堆砌硬件解决的问题就 用硬件来解决,但是当系统并发超过了单机的极限时,我们就要使用 Scale-out 的方式。 Scale-out 虽然能够突破单机的限制,但也会引入一些复杂问题。比如,如果某个节点出现 故障如何保证整体可用性?当多个节点有状态需要同步时,如何保证状态信息在不同节点的 一致性?如何做到使用方无感知的增加和删除节点?等等。其中每一个问题都涉及很多的知 识点,我会在后面的课程中深入地讲解,这里暂时不展开了。 说完了 Scale-out,我们再来看看高并发系统设计的另一种方法:缓存。 使用缓存提升性能 Web 2.0 是缓存的时代,这一点毋庸置疑。缓存遍布在系统设计的每个角落,从操作系统 到浏览器,从数据库到消息队列,任何略微复杂的服务和组件中,你都可以看到缓存的影 子。我们使用缓存的主要作用是提升系统的访问性能,那么在高并发的场景下,就可以支撑 更多用户的同时访问。 那么为什么缓存可以大幅度提升系统的性能呢?我们知道数据是放在持久化存储中的,一般 的持久化存储都是使用磁盘作为存储介质的,而普通磁盘数据由机械手臂、磁头、转轴、盘 片组成,盘片又分为磁道、柱面和扇区,盘片构造图我放在下面了。 盘片是存储介质,每个盘片被划分为多个同心圆,信息都被存储在同心圆之中,这些同心圆 就是磁道。在磁盘工作时盘片是在高速旋转的,机械手臂驱动磁头沿着径向移动,在磁道上读取所需要的数据。我们把磁头寻找信息花费的时间叫做寻道时间。 普通磁盘的寻道时间是 10ms 左右,而相比于磁盘寻道花费的时间,CPU 执行指令和内存 寻址的时间都在是 ns(纳秒)级别,从千兆网卡上读取数据的时间是在μs(微秒)级别。 所以在整个计算机体系中,磁盘是最慢的一环,甚至比其它的组件要慢几个数量级。因此, 我们通常使用以内存作为存储介质的缓存,以此提升性能。 当然,缓存的语义已经丰富了很多,我们可以将任何降低响应时间的中间存储都称为缓存。 缓存的思想遍布很多设计领域,比如在操作系统中 CPU 有多级缓存,文件有 Page Cache 缓存,你应该有所了解。 异步处理 异步也是一种常见的高并发设计方法,我们在很多文章和演讲中都能听到这个名词,与之共 同出现的还有它的反义词:同步。比如,分布式服务框架 Dubbo 中有同步方法调用和异步 方法调用,IO 模型中有同步 IO 和异步 IO。 那么什么是同步,什么是异步呢?以方法调用为例,同步调用代表调用方要阻塞等待被调用 方法中的逻辑执行完成。这种方式下,当被调用方法响应时间较长时,会造成调用方长久的阻塞,在高并发下会造成整体系统性能下降甚至发生雪崩。 异步调用恰恰相反,调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑,在被 调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。 异步调用在大规模高并发系统中被大量使用,比如我们熟知的 12306 网站。当我们订票 时,页面会显示系统正在排队,这个提示就代表着系统在异步处理我们的订票请求。在 12306 系统中查询余票、下单和更改余票状态都是比较耗时的操作,可能涉及多个内部系 统的互相调用,如果是同步调用就会像 12306 刚刚上线时那样,高峰期永远不可能下单成 功。 而采用异步的方式,后端处理时会把请求丢到消息队列中,同时快速响应用户,告诉用户我 们正在排队处理,然后释放出资源来处理更多的请求。订票请求处理完之后,再通知用户订 票成功或者失败。 处理逻辑后移到异步处理程序中,Web 服务的压力小了,资源占用的少了,自然就能接收 更多的用户订票请求,系统承受高并发的能力也就提升了。 既然我们了解了这三种方法,那么是不是意味着在高并发系统设计中,开发一个系统时要把 这些方法都用上呢?当然不是,系统的设计是不断演进的。 罗马不是一天建成的,系统的设计也是如此。不同量级的系统有不同的痛点,也就有不同的 架构设计的侧重点。如果都按照百万、千万并发来设计系统,电商一律向淘宝看齐,IM 全 都学习微信和 QQ,那么这些系统的命运一定是灭亡。因为淘宝、微信的系统虽然能够解决同时百万、千万人同时在线的需求,但其内部的复杂程 度也远非我们能够想象的。盲目地追从只能让我们的架构复杂不堪,最终难以维护。就拿从 单体架构往服务化演进来说,淘宝也是在经历了多年的发展后,发现系统整体的扩展能力出 现问题时,开始启动服务化改造项目的。 我之前也踩过一些坑,参与的一个创业项目在初始阶段就采用了服务化的架构,但由于当时 人力有限,团队技术积累不足,因此在实际项目开发过程中,发现无法驾驭如此复杂的架 构,也出现了问题难以定位、系统整体性能下降等多方面的问题,甚至连系统宕机了都很难 追查到根本原因,最后不得不把服务做整合,回归到简单的单体架构中。 所以我建议一般系统的演进过程应该遵循下面的思路: 最简单的系统设计满足业务需求和流量现状,选择最熟悉的技术体系。 随着流量的增加和业务的变化,修正架构中存在问题的点,如单点问题,横向扩展问题, 性能无法满足需求的组件。在这个过程中,选择社区成熟的、团队熟悉的组件帮助我们解 决问题,在社区没有合适解决方案的前提下才会自己造轮子。 当对架构的小修小补无法满足需求时,考虑重构、重写等大的调整方式以解决现有的问 题。 以淘宝为例,当时在业务从 0 到 1 的阶段是通过购买的方式快速搭建了系统。而后,随着 流量的增长,淘宝做了一系列的技术改造来提升高并发处理能力,比如数据库存储引擎从 MyISAM 迁移到 InnoDB,数据库做分库分表,增加缓存,启动中间件研发等。 当这些都无法满足时就考虑对整体架构做大规模重构,比如说著名的“五彩石”项目让淘宝 的架构从单体演进为服务化架构。正是通过逐步的技术演进,淘宝才进化出如今承担过亿 QPS 的技术架构。 归根结底一句话:高并发系统的演进应该是循序渐进,以解决系统中存在的问题为目的和驱 动力的。 课程小结 在今天的课程中,我带着你了解了高并发系统设计的三种通用方法:Scale-out、缓存和异 步。这三种方法可以在做方案设计时灵活地运用,但它不是具体实施的方案,而是三种思 想,在实际运用中会千变万化。就拿 Scale-out 来说,数据库一主多从、分库分表、存储分片都是它的实际应用方案。而 我们需要注意的是,在应对高并发大流量的时候,系统是可以通过增加机器来承担流量冲击 的,至于要采用什么样的方案还是要具体问题具体分析。02 | 架构分层:我们为什么一定要这么做? 在系统从 0 到 1 的阶段,为了让系统快速上线,我们通常是不考虑分层的。但是随着业务 越来越复杂,大量的代码纠缠在一起,会出现逻辑不清晰、各模块相互依赖、代码扩展性 差、改动一处就牵一发而动全身等问题。 这时,对系统进行分层就会被提上日程,那么我们要如何对架构进行分层?架构分层和高并 发架构设计又有什么关系呢?本节课,我将带你寻找答案。 什么是分层架构 软件架构分层在软件工程中是一种常见的设计方式,它是将整体系统拆分成 N 个层次,每 个层次有独立的职责,多个层次协同提供完整的功能。我们在刚刚成为程序员的时候,会被“教育”说系统的设计要是“MVC”(Model-View Controller)架构。它将整体的系统分成了 Model(模型),View(视图)和 Controller(控制器)三个层次,也就是将用户视图和业务处理隔离开,并且通过控制器连 接起来,很好地实现了表现和逻辑的解耦,是一种标准的软件分层架构。 另外一种常见的分层方式是将整体架构分为表现层、逻辑层和数据访问层: 表现层,顾名思义嘛,就是展示数据结果和接受用户指令的,是最靠近用户的一层; 逻辑层里面有复杂业务的具体实现; 数据访问层则是主要处理和存储之间的交互。 这是在架构上最简单的一种分层方式。其实,我们在不经意间已经按照三层架构来做系统分 层设计了,比如在构建项目的时候,我们通常会建立三个目录:Web、Service 和 Dao, 它们分别对应了表现层、逻辑层还有数据访问层。 章节小插曲:本篇只总结了"高并发系统设计"的一部分内容,还有更多资源正在整理中包含 JVM、Tomcat、MySQL、Spring、Mybatis、Redis、MongoDB、Mycat、Zookeeper Nginx、RabbitMq、RocketMq、Kafka、Dubbo、Docker 分布式(架构设计,事务场景策略,场景解决方案,任务调度场景实现) 高并发场景应对方案、性能调优实战、海量数据场景实现、消息服务总线MQ等。 不定期更新中获取可添加助理QQ:【2986706524】 备注:【Java】审核通过后私信:【资料】 即可获取。除此之外,如果我们稍加留意,就可以发现很多的分层的例子。比如我们在大学中学到的 OSI 网络模型,它把整个网络分了七层,自下而上分别是物理层、数据链路层、网络层、传 输层、会话层、表示层和应用层。 工作中经常能用到 TCP/IP 协议,它把网络简化成了四层,即链路层、网络层、传输层和应 用层。每一层各司其职又互相帮助,网络层负责端到端的寻址和建立连接,传输层负责端到 端的数据传输等,同时呢相邻两层还会有数据的交互。这样可以隔离关注点,让不同的层专 注做不同的事情。Linux 文件系统也是分层设计的,从下图你可以清晰地看出文件系统的层次。在文件系统的 最上层是虚拟文件系统(VFS),用来屏蔽不同的文件系统之间的差异,提供统一的系统调 用接口。虚拟文件系统的下层是 Ext3、Ext4 等各种文件系统,再向下是为了屏蔽不同硬件 设备的实现细节,我们抽象出来的单独的一层——通用块设备层,然后就是不同类型的磁 盘了。 我们可以看到,某些层次负责的是对下层不同实现的抽象,从而对上层屏蔽实现细节。比方 说 VFS 对上层(系统调用层)来说提供了统一的调用接口,同时对下层中不同的文件系统 规约了实现模型,当新增一种文件系统实现的时候,只需要按照这种模型来设计,就可以无 缝插入到 Linux 文件系统中。那么,为什么这么多系统一定要做分层的设计呢?答案是分层设计存在一定的优势。 分层有什么好处 分层的设计可以简化系统设计,让不同的人专注做某一层次的事情。想象一下,如果你要设 计一款网络程序却没有分层,该是一件多么痛苦的事情。 因为你必须是一个通晓网络的全才,要知道各种网络设备的接口是什么样的,以便可以将数 据包发送给它。你还要关注数据传输的细节,并且需要处理类似网络拥塞,数据超时重传这 样的复杂问题。当然了,你更需要关注数据如何在网络上安全传输,不会被别人窥探和篡 改。 而有了分层的设计,你只需要专注设计应用层的程序就可以了,其他的,都可以交给下面几 层来完成。 再有,分层之后可以做到很高的复用。比如,我们在设计系统 A 的时候,发现某一层具有 一定的通用性,那么我们可以把它抽取独立出来,在设计系统 B 的时候使用起来,这样可 以减少研发周期,提升研发的效率。最后一点,分层架构可以让我们更容易做横向扩展。如果系统没有分层,当流量增加时我们 需要针对整体系统来做扩展。但是,如果我们按照上面提到的三层架构将系统分层后,那么 我们就可以针对具体的问题来做细致的扩展。 比如说,业务逻辑里面包含有比较复杂的计算,导致 CPU 成为性能的瓶颈,那这样就可以 把逻辑层单独抽取出来独立部署,然后只对逻辑层来做扩展,这相比于针对整体系统扩展所 付出的代价就要小的多了。 这一点也可以解释我们课程开始时提出的问题:架构分层究竟和高并发设计的关系是怎样 的?在“01 | 高并发系统:它的通用设计方法是什么?”中我们了解到,横向扩展是高并 发系统设计的常用方法之一,既然分层的架构可以为横向扩展提供便捷, 那么支撑高并发 的系统一定是分层的系统。 如何来做系统分层 说了这么多分层的优点,那么当我们要做分层设计的时候,需要考虑哪些关键因素呢? 在我看来,最主要的一点就是你需要理清楚每个层次的边界是什么。你也许会问:“如果按 照三层架构来分层的话,每一层的边界不是很容易就界定吗?” 没错,当业务逻辑简单时,层次之间的边界的确清晰,开发新的功能时也知道哪些代码要往 哪儿写。但是当业务逻辑变得越来越复杂时,边界就会变得越来越模糊,给你举个例子。 任何一个系统中都有用户系统,最基本的接口是返回用户信息的接口,它调用逻辑层的 GetUser 方法,GetUser 方法又和 User DB 交互获取数据,就像下图左边展示的样子。 这时,产品提出一个需求,在 APP 中展示用户信息的时候,如果用户不存在,那么要自动 给用户创建一个用户。同时,要做一个 HTML5 的页面,HTML5 页面要保留之前的逻辑, 也就是不需要创建用户。这时逻辑层的边界就变得不清晰,表现层也承担了一部分的业务逻 辑(将获取用户和创建用户接口编排起来)。 章节小插曲:本篇只总结了"高并发系统设计"的一部分内容,还有更多资源正在整理中包含 JVM、Tomcat、MySQL、Spring、Mybatis、Redis、MongoDB、Mycat、Zookeeper Nginx、RabbitMq、RocketMq、Kafka、Dubbo、Docker 分布式(架构设计,事务场景策略,场景解决方案,任务调度场景实现) 高并发场景应对方案、性能调优实战、海量数据场景实现、消息服务总线MQ等。 不定期更新中获取可添加助理QQ:【2986706524】 备注:【Java】审核通过后私信:【资料】 即可获取。那我们要如何做呢?参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0(详尽版)》,我们 可以将原先的三层架构细化成下面的样子:我来解释一下这个分层架构中的每一层的作用。 终端显示层:各端模板渲染并执行显示的层。当前主要是 Velocity 渲染,JS 渲染, JSP 渲染,移动端展示等。 开放接口层:将 Service 层方法封装成开放接口,同时进行网关安全控制和流量控制等。 Web 层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理 等。 Service 层:业务逻辑层。 Manager 层:通用业务处理层。这一层主要有两个作用,其一,你可以将原先 Service 层的一些通用能力下沉到这一层,比如与缓存和存储交互策略,中间件的接入;其二,你 也可以在这一层封装对第三方接口的调用,比如调用支付服务,调用审核服务等。 DAO 层:数据访问层,与底层 MySQL、Oracle、Hbase 等进行数据交互。 外部接口或第三方平台:包括其它部门 RPC 开放接口,基础平台,其它公司的 HTTP 接 口。在这个分层架构中主要增加了 Manager 层,它与 Service 层的关系是:Manager 层提供 原子的服务接口,Service 层负责依据业务逻辑来编排原子接口。 以上面的例子来说,Manager 层提供创建用户和获取用户信息的接口,而 Service 层负责 将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一到了 Service 层,每 一层的边界就非常清晰了。 除此之外,分层架构需要考虑的另一个因素,是层次之间一定是相邻层互相依赖,数据的流 转也只能在相邻的两层之间流转。 我们还是以三层架构为例,数据从表示层进入之后一定要流转到逻辑层,做业务逻辑处理, 然后流转到数据访问层来和数据库交互。那么你可能会问:“如果业务逻辑很简单的话可不 可以从表示层直接到数据访问层,甚至直接读数据库呢?” 其实从功能上是可以的,但是从长远的架构设计考虑,这样会造成层级调用的混乱,比方说 如果表示层或者业务层可以直接操作数据库,那么一旦数据库地址发生变更,你就需要在多 个层次做更改,这样就失去了分层的意义,并且对于后面的维护或者重构都会是灾难性的。 分层架构的不足 任何事物都不可能是尽善尽美的,分层架构虽有优势也会有缺陷,它最主要的一个缺陷就是 增加了代码的复杂度。 这是显而易见的嘛,明明可以在接收到请求后就可以直接查询数据库获得结果,却偏偏要在 中间插入多个层次,并且有可能每个层次只是简单地做数据的传递。有时增加一个小小的需 求也需要更改所有层次上的代码,看起来增加了开发的成本,并且从调试上来看也增加了复 杂度,原本如果直接访问数据库我只需要调试一个方法,现在我却要调试多个层次的多个方 法。 另外一个可能的缺陷是,如果我们把每个层次独立部署,层次间通过网络来交互,那么多层 的架构在性能上会有损耗。这也是为什么服务化架构性能要比单体架构略差的原因,也就是 所谓的“多一跳”问题。 那我们是否要选择分层的架构呢?答案当然是肯定的。你要知道,任何的方案架构都是有优势有缺陷的,天地尚且不全何况我们的架构呢?分层架 构固然会增加系统复杂度,也可能会有性能的损耗,但是相比于它能带给我们的好处来说, 这些都是可以接受的,或者可以通过其它的方案解决的。我们在做决策的时候切不可以偏概 全,因噎废食。 课程小结 今天我带着你了解了分层架构的优势和不足,以及我们在实际工作中如何来对架构做分层。 我想让你了解的是,分层架构是软件设计思想的外在体现,是一种实现方式。我们熟知的一 些软件设计原则都在分层架构中有所体现。 比方说,单一职责原则规定每个类只有单一的功能,在这里可以引申为每一层拥有单一职 责,且层与层之间边界清晰;迪米特法则原意是一个对象应当对其它对象有尽可能少的了 解,在分层架构的体现是数据的交互不能跨层,只能在相邻层之间进行;而开闭原则要求软 件对扩展开放,对修改关闭。它的含义其实就是将抽象层和实现层分离,抽象层是对

标签:缓存,架构,系统,1111,并发,分层,Scale
From: https://www.cnblogs.com/shan13936/p/17363339.html

相关文章

  • 1111
    1、运维故障复盘,进行技术改进,开复盘会。2、关键运维技术进行难点进行攻克,在测试环境进行测试验证,在生产环境执行。指导其他运维进行难点问题处理。3、对公司关键运维技术难题进行架构设计,例如由于服务器服务机房老化迁移、服务器高可用风险防范、服务器应急故障处理。4、运......
  • 1111
    ......
  • 111111111
    33MEHOB8W0-eyJsaWNlbnNlSWQiOiIzM01FSE9COFcwIiwibGljZW5zZWVOYW1lIjoiUG9saXRla25payBNZXJsaW1hdSBNZWxha2EiLCJhc3NpZ25lZU5hbWUiOiJtYWdnaWUgc2VyIiwiYXNzaWduZWVFbWF......
  • 11113344
    世界上没有一个静止不动的时刻,技术也在不断地变化,那么,作为开发者和博主,我们如何才能跟上时代的步伐?答案很简单,就是不被定义,不受限制,勇于追求自己想要成为的样子。人生当中,我......
  • 11111
    #include<stdio.h>intmain(){printf("OO\n");printf("<H><H>\n");printf("IIII\n");}  #include<stdio.h>intmain(){......
  • Codeforces Round #723 (Div. 2)B. I Hate 1111(完全背包)
    problemB.IHate1111timelimitpertest1secondmemorylimitpertest256megabytesinputstandardinputoutputstandardoutputYouaregivenanintegerx.Cany......
  • 11111
    昨日内容回顾序列化类的常用字段ListFieldDictFieldCharFieldSerializerMethodField字段参数max_lengthmin_valuerequired,default,error_messages,validatorrea......
  • 111111
    一不小心将注册表中的HKEY_CLASSES_ROOT\.exe删除,导致.exe文件全部打不开。本想重新添加一个值到注册表,却发现就连注册表都打不开。win+R,输入regedit都打不开。还好网上教......
  • 1111111
    1.参考文档见同目录下的.mhtml文件在第一步安装JDK那一步中我选择直接安装了jdk17,因为官网和国内镜像的OpenJDK始终都下载不下来。1.1.配置文件基本信息spring:data......
  • 《软件方法》第9章 分析之分析类图—案例篇Part1(20211114更新)
    鸳鸯扣,宜结不宜解《身似摇红烛影》,词:唐涤生,曲:王粤生,唱:红线女,1954​9.1本书案例介绍9.1.1案例更换《软件方法(上)》以及下册2018年发布的电子版本,使用的案例是“UMLChina系统......