架构二。。

news2024/11/24 17:48:23

1、CAP

只能3选2
1)一致性(Consistency)
客户每次读都是返回最新的写操作结果
2)可用性(Availability)
非故障节点在合理的时间内返回合理的响应
3)分区容忍性(Partition Tolerance)
当出现网络分区故障时,系统还能发挥作用

网络分区(network partition)是指网络故障或中断导致系统中的各个部分无法相互通信的情况。

CAP 应用

对于分布式系统,现实只能时CP 或者 AP 架构。CA是不可能的
1)CP
如下图所示,为了保证一致性,当发生分区现象后,N1 节点上的数据已经更新到 y,但由于 N1 和 N2 之间的复制通道中断,数据 y 无法同步到 N2,N2 节点上的数据还是 x。这时客户端 C 访问 N2 时,N2 需要返回 Error,提示客户端 C“系统现在发生了错误”,这种处理方式违背了可用性(Availability)的要求,因此 CAP 三者只能满足 CP。
在这里插入图片描述
2) AP - Availability/Partition Tolerance

如下图所示,为了保证可用性,当发生分区现象后,N1 节点上的数据已经更新到 y,但由于 N1 和 N2 之间的复制通道中断,数据 y 无法同步到 N2,N2 节点上的数据还是 x。这时客户端 C 访问 N2 时,N2 将当前自己拥有的数据 x 返回给客户端 C 了,而实际上当前最新的数据已经是 y 了,这就不满足一致性(Consistency)的要求了,因此 CAP 三者只能满足 AP。注意:这里 N2 节点返回 x,虽然不是一个“正确”的结果,但是一个“合理”的结果,因为 x 是旧的数据,并不是一个错乱的值,只是不是最新的数据而已。
在这里插入图片描述
在面对网络分区时,Kubernetes 通常选择优先保证一致性和分区容忍性,而在某些情况下可能会暂时牺牲部分可用性。
如果一个 Kubernetes 集群分布在多个地理位置,某个位置与其他位置之间的网络连接中断,Etcd 将优先保证数据一致性,可能暂时无法进行新的写操作或在某些情况下无法响应读请求,直到网络分区恢复。

CAP原则的三选二是一个理论上的指导,但在实际工程中,我们可以通过多种策略和技术手段来最大化系统在一致性、可用性和分区容忍性三个方面的表现,构建高效可靠的分布式系统。

CAP细节

CAP 关注的粒度是数据,而不是整个系统

以一个最简单的用户管理系统为例,用户管理系统包含用户账号数据(用户 ID、密码)、用户信息数据(昵称、兴趣、爱好、性别、自我介绍等)。通常情况下,用户账号数据会选择 CP,而用户信息数据会选择 AP,如果限定整个系统为 CP,则不符合用户信息数据的应用场景;如果限定整个系统为 AP,则又不符合用户账号数据的应用场景。
每类数据选择不同的策略(CP 还是 AP),而不是直接限定整个系统所有数据都是同一策略。

CAP 理论告诉我们分布式系统只能选择 CP 或者 AP,但其实这里的前提是系统发生了“分区”现象。如果系统没有发生分区现象,也就是说 P 不存在的时候(节点间的网络连接一切正常),我们没有必要放弃 C 或者 A,应该 C 和 A 都可以保证,这就要求架构设计的时候既要考虑分区发生时选择 CP 还是 AP,也要考虑分区没有发生时如何保证 CA

FMEA (Failure mode and effects analysis,故障模式与影响分析)

当我们设计出架构后,再用FMEA去分析
就是列表遇见问题,想出解决方案

2、高可用存储架构:双机架构

如何应对复制延迟和复制中断导致的数据不一致

主备(人工切换主机,备机的角色)

在这里插入图片描述

主从(从负责读)

在这里插入图片描述

还有双机切换等等

3、高可用存储架构:集群和分区

单机存储不了的时候,就需要多台了

一主多备集群

在这里插入图片描述
主机故障后,如何决定新的主机

目前开源的数据集中集群以 ZooKeeper 为典型,ZooKeeper 通过 ZAB 算法来解决上述提到的几个问题,但 ZAB 算法的复杂度是很高的。

数据集中集群架构中,客户端只能将数据写到主机;数据分散集群架构中,客户端可以向任意服务器中读写数据。正是因为这个关键的差异,决定了两种集群的应用场景不同。一般来说,数据集中集群适合数据量不大,集群机器数量不多的场景。例如,ZooKeeper 集群,一般推荐 5 台机器左右,数据量是单台服务器就能够支撑;而数据分散集群,由于其良好的可伸缩性,适合业务数据量巨大、集群机器数量庞大的业务场景。例如,Hadoop 集群、HBase 集群,大规模的集群可以达到上百台甚至上千台服务器。

数据分区

发生大灾,水灾,停电,大地震等等,一个地区的机房全部瘫痪,此时就需要数据分区恢复数据
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

4、如何设计计算高可用架构?

部分硬件坏时,计算仍能正常运行
复杂度在于某台服务器上执行失败后,如何重新分配到其他机器上执行

5、应对接口级故障

接口级故障的典型表现就是系统并没有宕机,网络也没有中断,但业务却出现问题了。例如,业务响应缓慢、大量访问超时、大量访问出现异常(给用户弹出提示“无法连接数据库”),这类问题的主要原因在于系统压力太大、负载太高,导致无法快速处理业务请求,由此引发更多的后续问题。例如,最常见的数据库慢查询将数据库的服务器资源耗尽,导致读写超时,业务读写数据库时要么无法连接数据库、要么超时,最终用户看到的现象就是访问很慢,一会访问抛出异常,一会访问又是正常结果。

降级

降级指系统将某些业务或者接口的功能降低,可以是只提供部分功能,也可以是完全停掉所有功能。例如,论坛可以降级为只能看帖子,不能发帖子;也可以降级为只能看帖子和评论,不能发评论;而 App 的日志上传接口,可以完全停掉一段时间,这段时间内 App 都不能上传日志。

降级的核心思想就是丢车保帅,优先保证核心业务。例如,对于论坛来说,90% 的流量是看帖子,那我们就优先保证看帖的功能;对于一个 App 来说,日志上传接口只是一个辅助的功能,故障时完全可以停掉。

熔断

假设一个这样的场景:A 服务的 X 功能依赖 B 服务的某个接口,当 B 服务的接口响应很慢的时候,A 服务的 X 功能响应肯定也会被拖慢,进一步导致 A 服务的线程都被卡在 X 功能处理上,此时 A 服务的其他功能都会被卡住或者响应非常慢。这时就需要熔断机制了,即:A 服务不再请求 B 服务的这个接口,A 服务内部只要发现是请求 B 服务的这个接口就立即返回错误,从而避免 A 服务整个被拖慢甚至拖死。

限流

降级是从系统功能优先级的角度考虑如何应对故障,而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来,超出系统访问能力的请求将被丢弃。

例如某个直播间限制总用户数上限为 100 万,超过 100 万后新的用户无法进入;某个抢购活动商品数量只有 100 个,限制参与抢购的用户上限为 1 万个,1 万以后的用户直接拒绝

排队

排队实际上是限流的一个变种,限流是直接拒绝用户,排队是让用户等待一段时间,全世界最有名的排队当属 12306 网站排队了。排队虽然没有直接拒绝用户,但用户等了很长时间后进入系统,体验并不一定比限流好。
由于排队需要临时缓存大量的业务请求,单个系统内部无法缓存这么多数据,一般情况下,排队需要用独立的系统去实现,例如使用 Kafka 这类消息队列来缓存用户请求。

6、可扩展性

首先 — 流程 服务 功能(就是服务的细节)来考虑架构。拆分后哪个部分出错,范围不会波及太广

这几个系统架构并不是非此即彼的,而是可以在系统架构设计中进行组合使用的。以学生管理系统为例,我们最终可以这样设计架构:
1)整体系统采用面向服务拆分中的“微服务”架构,拆分为“注册服务”“登录服务”“信息管理服务”“安全服务”,每个服务是一个独立运行的子系统。
2)其中的“注册服务”子系统本身又是采用面向流程拆分的分层架构。
3)“登录服务”子系统采用的是面向功能拆分的“微内核”架构。

分层架构

分层架构是很常见的架构模式,它也叫 N 层架构,通常情况下,N 至少是 2 层。例如,C/S 架构、B/S 架构。常见的是 3 层架构(例如,MVC、MVP 架构)、4 层架构,5 层架构的比较少见,一般是比较复杂的系统才会达到或者超过 5 层,比如操作系统内核架构。

SOA和微服务

SOA 更加适合于庞大、复杂、异构的企业级系统,这也是 SOA 诞生的背景。这类系统的典型特征就是很多系统已经发展多年,采用不同的企业级技术,有的是内部开发的,有的是外部购买的,无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大,只能采用兼容的方式进行处理,而承担兼容任务的就是 ESB。

微服务更加适合于快速、轻量级、基于 Web 的互联网系统,这类系统业务变化快,需要快速尝试、快速交付;同时基本都是基于 Web,虽然开发技术可能差异很大(例如,Java、C++、.NET 等),但对外接口基本都是提供 HTTP RESTful 风格的接口,无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。
微服务要和devops一起 “快速交付” 才行,否则超过20个微服务,部署成本太高
在这里插入图片描述

通过前面的详细分析和比较,似乎微服务本质上就是一种比 SOA 要优秀很多的架构模式,那是否意味着我们都应该把架构重构为微服务呢?
其实不然,SOA 和微服务是两种不同理念的架构模式,并不存在孰优孰劣,只是应用场景不同而已。我们介绍 SOA 时候提到其产生历史背景是因为企业的 IT 服务系统庞大而又复杂,改造成本很高,但业务上又要求其互通,因此才会提出 SOA 这种解决方案。如果我们将微服务的架构模式生搬硬套到企业级 IT 服务系统中,这些 IT 服务系统的改造成本可能远远超出实施 SOA 的成本。

微服务的缺点

分的太细,系统复杂度指数级增长
调用链太长,性能下降
调用链太长,问题定位困难

微服务的应该怎么用

1个服务对应3人

首先,从系统规模来讲,3 个人负责开发一个系统,系统的复杂度刚好达到每个人都能全面理解整个系统,又能够进行分工的粒度;如果是 2 个人开发一个系统,系统的复杂度不够,开发人员可能觉得无法体现自己的技术实力;如果是 4 个甚至更多人开发一个系统,系统复杂度又会无法让开发人员对系统的细节都了解很深。

其次,从团队管理来说,3 个人可以形成一个稳定的备份,即使 1 个人休假或者调配到其他系统,剩余 2 个人还可以支撑;如果是 2 个人,抽调 1 个后剩余的 1 个人压力很大;如果是 1 个人,这就是单点了,团队没有备份,某些情况下是很危险的,假如这个人休假了,系统出问题了怎么办?

最后,从技术提升的角度来讲,3 个人的技术小组既能够形成有效的讨论,又能够快速达成一致意见;如果是 2 个人,可能会出现互相坚持自己的意见,或者 2 个人经验都不足导致设计缺陷;如果是 1 个人,由于没有人跟他进行技术讨论,很可能陷入思维盲区导致重大问题;如果是 4 个人或者更多,可能有的参与的人员并没有认真参与,只是完成任务而已。

“三个火枪手”的原则主要应用于微服务设计和开发阶段,如果微服务经过一段时间发展后已经比较稳定,处于维护期了,无须太多的开发,那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题,每个微服务最好都安排 2 个人维护,每个人都可以维护多个微服务。

基础设施们

在这里插入图片描述
要做好微服务,这些基础设施都是必不可少的,否则微服务就会变成一个焦油坑,让业务和团队在里面不断挣扎且无法自拔。因此也可以说,微服务并没有减少复杂度,而只是将复杂度从 ESB 转移到了基础设施。

虽然建设完善的微服务基础设施是一项庞大的工程,但也不用太过灰心,认为自己团队小或者公司规模不大就不能实施微服务了。第一个原因是已经有开源的微服务基础设施全家桶了,例如大名鼎鼎的 Spring Cloud 项目,涵盖了服务发现、服务路由、网关、配置中心等功能;第二个原因是如果微服务的数量并不是很多的话,并不是每个基础设施都是必须的。通常情况下,我建议按照下面优先级来搭建基础设施:

  1. 服务发现、服务路由、服务容错:这是最基本的微服务基础设施。

  2. 接口框架、API 网关:主要是为了提升开发效率,接口框架是提升内部服务的开发效率,API 网关是为了提升与外部服务对接的效率。

  3. 自动化部署、自动化测试、配置中心:主要是为了提升测试和运维效率。

  4. 服务监控、服务跟踪、服务安全:主要是为了进一步提升运维效率。

以上 3 和 4 两类基础设施,其重要性会随着微服务节点数量增加而越来越重要,但在微服务节点数量较少的时候,可以通过人工的方式支撑,虽然效率不高,但也基本能够顶住。

7、微内核架构

基本架构就是:核心系统(core system)和插件模块(plug-in modules)
在这里插入图片描述

OSGi

OSGi(Open Services Gateway initiative) 是一种用于 Java 平台的模块化系统和服务平台。它提供了一种动态的组件模型,使得应用程序可以被分解为许多小的、独立的模块(称为“bundles”),这些模块可以在运行时被安装、启动、停止、更新和卸载。OSGi 主要用于构建灵活、可扩展的应用程序和系统,尤其适用于需要长期运行的嵌入式系统、服务器和桌面应用程序。

OSGi 的核心概念

  1. Bundles(捆绑包)
    Bundles 是 OSGi 中的基本部署单元,相当于 Java 中的 JAR 文件。每个 bundle 包含一组相关的类和资源,并具有自己的生命周期管理。

  2. Services(服务)
    OSGi 平台提供一个动态服务注册和查找的框架,bundle 可以发布服务,也可以查找和使用其他 bundle 发布的服务。

  3. Lifecycle Management(生命周期管理)
    OSGi 提供一套标准的 API 用于管理 bundle 的生命周期,包括安装、启动、停止、更新和卸载。

  4. Modules(模块)
    OSGi 通过定义模块化系统,使得每个 bundle 可以有明确的依赖关系,并且能够实现版本管理和模块间的隔离。

  5. Service Registry(服务注册表)
    OSGi 平台维护一个全局的服务注册表,所有的 bundle 可以在这个注册表中发布和查找服务。

OSGi 的实际应用例子

1. Eclipse IDE

Eclipse 是一个流行的集成开发环境(IDE),它就是基于 OSGi 构建的。Eclipse 的插件系统使用 OSGi 来管理各种功能模块(如代码编辑器、调试工具、版本控制插件等)。每个功能模块都是一个 OSGi bundle,这使得 Eclipse 可以动态加载和卸载插件,提供一个高度可扩展和灵活的开发环境。

举例

  • 开发者可以在使用 Eclipse 时动态安装或卸载插件而无需重启 IDE。例如,安装一个新的版本控制插件(如 Git 插件)时,Eclipse 可以在后台加载该插件,并立即提供相应的功能。
2. Apache Karaf

Apache Karaf 是一个基于 OSGi 的轻量级容器,旨在运行 OSGi bundles。Karaf 提供了许多管理和部署 OSGi 应用的工具,如命令行控制台、远程管理、动态配置管理等。

举例

  • 在一个企业应用中,开发人员可以将不同的业务模块(如用户管理、订单处理、报告生成等)打包为独立的 OSGi bundles,并部署在 Karaf 容器中。业务需求变化时,可以动态更新或替换某个模块,而不会影响整个应用的运行。
3. 家庭自动化系统

OSGi 被广泛应用于智能家居系统中,这些系统通常由许多不同的设备和服务组成,需要高度的灵活性和可扩展性。例如,一个家庭自动化系统可以包含照明控制、安全监控、温度调节等功能,每个功能都可以作为一个独立的 OSGi bundle。

举例

  • 用户可以在智能家居系统中添加新的设备(如智能灯泡、温控器等),相应的 OSGi bundle 会动态加载并注册新的服务,使得这些设备能够与现有系统无缝集成。

通俗易懂的解释

可以把 OSGi 想象成一个大商场,每个商店就是一个 bundle。商场(OSGi 平台)提供基础设施来管理这些商店,包括店铺的开业、营业、关门、升级和撤销。每个商店独立经营,但可以相互提供和使用服务(例如,一家咖啡店可以使用隔壁打印店的打印服务)。如果需要引入新的店铺或升级某个店铺,整个商场不需要关闭,这样商场可以持续运营。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/1689861.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

零基础代码随想录【Day42】|| 1049. 最后一块石头的重量 II,494. 目标和,474.一和零

目录 DAY42 1049.最后一块石头的重量II 解题思路&代码 494.目标和 解题思路&代码 474.一和零 解题思路&代码 DAY42 1049.最后一块石头的重量II 力扣题目链接(opens new window) 题目难度:中等 有一堆石头,每块石头的重量都是正整…

第七步 实现打印函数

文章目录 前言一、如何设计我们的打印函数?二、实践检验! 查看系列文章点这里: 操作系统真象还原 前言 现在接力棒意见交到内核手中啦,只不过我们的内核现在可谓是一穷二白啥都没有,为了让我们设计的内核能被看见被使用…

fyne网格包裹布局

fyne网格包裹布局 与之前的网格布局一样,网格环绕布局以网格模式创建元素排列。但是,此网格没有固定数量的列,而是为每个单元格使用固定大小,然后将内容流到显示项目所需的行数。 layout.NewGridWrapLayout(size) 您可以使用其中…

Mac维护神器CleanMyMac X成为你的苹果电脑得力助手

在数字化时代,Mac电脑已成为众多用户的首选。然而,随着频繁的使用和数据量的日益增长,许多Mac用户面临着系统杂乱、存储空间不足以及隐私保护等问题。幸运的是,"CleanMyMac X"这款优化和清理工具应运而生,它…

「网络流浅谈」最大流的应用

更好的阅读体验 二分图匹配 考虑如何将二分图匹配问题,转化为流网络。设置 1 1 1 个汇点和源点,从源点向二分图一侧的每一个点连边,从另一侧向汇点连边,边权均为 1 1 1,二分图中的边也全部加入,权值设为…

【Linux取经路】基于信号量和环形队列的生产消费者模型

文章目录 一、POSIX 信号量二、POSIX 信号量的接口2.1 sem_init——初始化信号量2.2 sem_destroy——销毁信号量2.3 sem_wait——等待信号量2.4 sem_post——发布信号量 三、基于环形队列的生产消费者模型3.1 单生产单消费模型3.2 多生产多消费模型3.3 基于任务的多生产多消费模…

构建健壮的机器学习大数据平台:任务实现与数据治理的关键

随着数据驱动决策成为现代企业的核心,构建安全、可靠且可扩展的大数据平台变得至关重要。这样的平台不仅需要支持复杂的机器学习任务,还需要在数据质量、合规性和分发方面提供严格的控制。本文旨在探讨构建大型企业机器学习大数据平台时需要考虑的关键要…

项目如何有效做资源管理?易趋项目管理软件让资源管理可视化

在项目管理的过程中,有效的资源管理能够确保资源得到合理的分配和使用,避免资源的浪费和冗余,进而提高整体工作效率、确保项目的成功;同时降低组织的运营成本。 但在项目推进过程中,项目经理总会面临各种资源管理的难…

基于Tensorflow卷积神经网络人脸识别公寓人员进出管理系统

欢迎大家点赞、收藏、关注、评论啦 ,由于篇幅有限,只展示了部分核心代码。 文章目录 一项目简介 二、功能三、系统四. 总结 一项目简介 一、项目背景与意义 随着科技的快速发展和智能化水平的提高,公寓管理面临着越来越多的挑战。传统的公寓…

HTML静态网页成品作业(HTML+CSS)——我的家乡云南保山介绍网页(3个页面)

🎉不定期分享源码,关注不丢失哦 文章目录 一、作品介绍二、作品演示三、代码目录四、网站代码HTML部分代码 五、源码获取 一、作品介绍 🏷️本套采用HTMLCSS,未使用Javacsript代码,共有3个页面。 二、作品演示 三、代…

轻松同步:将照片从三星手机传输到iPad的简便方法

概括 想要在新 iPad 上查看三星照片吗?但是,如果您不知道如何将照片从三星手机传输到 iPad,则无法在 iPad 上查看图片。为此,本文分享了 7 个有用的方法,以便您可以使用它们在不同操作系统之间轻松发送照片。现在&…

leetcode-盛水最多的容器-109

题目要求 思路 1.正常用双循环外循环i从0开始,内循环从height.size()-1开始去计算每一个值是可以的,但是因为数据量太大,会超时。 2.考虑到超时,需要优化一些,比如第一个选下标1,第二个选下标3和第一个选下…

【笔记】从零开始做一个精灵龙女-素模阶段

事前准备 1.在ps标记好位置先,斜方肌,腰线,耻骨,膝盖,脚 2.导入素模,对好位置 软选择 1.原画上半身很短,所以这里把上半身做的也短一些 选择上半身的点-软选择-衰减调整-箭头调整 如果要调整…

mysql数据库innodb体系结构(一、内存结构 与二、物理存储结构)

文章目录 InnoDB存储引擎结构图innoDB体系结构一、内存结构1.Buffer Pool2.Change Pool3.Log Buffer 二、物理存储结构1.系统表空间2.独立表空间3.Redo日志1、redo 日志 4.Undo日志1、undo 日志 回滚段中的UNDO日志分为两种:UNDO 日志存储结构 InnoDB存储引擎结构图…

Flat Ads获广东电视台报道!CEO林啸:助力更多企业实现业务全球化增长

近日,在广州举行的第四届全球产品与增长展会(PAGC2024)上,Flat Ads凭借其卓越的一站式全球化营销和创新的变现方案大放异彩,不仅吸引了众多业界目光,同时也在展会上斩获了备受瞩目的“金帆奖”,展现了其在全球化营销推广领域的卓越实力和专业服务。 在大会现场,Flat Ads的CEO林…

差分约束题解

目录 注意点: 思路: SPFA和Dij的不同点: Dij: SPFA: AC代码: 扩展: 题目链接:【模板】差分约束 - 洛谷 注意点: 注意这一题不能用Dij,只能用SPFA 因为这样子才可以得出这个不…

【简单介绍下近邻算法】

🌈个人主页: 程序员不想敲代码啊 🏆CSDN优质创作者,CSDN实力新星,CSDN博客专家 👍点赞⭐评论⭐收藏 🤝希望本文对您有所裨益,如有不足之处,欢迎在评论区提出指正,让我们共…

全域运营是割韭菜吗?常见套路有哪些?

随着全域运营赛道的全面开启,全域运营服务商和全域运营系统的数量迅速增加,持续激发赛道活力的同时,也让一些试图用全域运营割韭菜的人有了可趁之机。 值得庆幸的是,由于当前全域运营赛道刚兴起不久,因此,割…

Raylib 绘制自定义字体的一种套路

Raylib 绘制自定义字体是真的难搞。我的需求是程序可以加载多种自定义字体,英文中文的都有。 我调试了很久成功了! 很有用的参考,建议先看一遍: 瞿华:raylib绘制中文内容 个人笔记|Raylib 的字体使用 - …

Nginx - 健康检查终极指南:探索Upstream Check模块

文章目录 概述upstream_check_module模块安装和配置指南模块安装步骤基本配置示例详细配置说明检查类型和参数常见问题及解决方案 SSL检查和DNS解析功能SSL检查配置示例和说明配置示例 DNS解析配置示例和说明配置示例 结合实际应用场景的高级配置示例综合SSL检查与DNS解析 总结…