架构二。。

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.mzph.cn/pingmian/14538.shtml

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

相关文章

Ribbon负载均衡(自己总结的)

文章目录 Ribbon负载均衡负载均衡解决的问题不要把Ribbon负载均衡和Eureka-Server服务器集群搞混了Ribbon负载均衡代码怎么写ribbon负载均衡依赖是怎么引入的? Ribbon负载均衡 负载均衡解决的问题 首先Ribbon负载均衡配合Eureka注册中心一块使用。 在SpringCloud…

计算机网络之应用层知识点总结

6.1 网络应用模型 (1)应用层概述 (2)网络应用模型的介绍 客户/服务器(C/S)模型 P2P模型 6.2 域名解析系统DNS (1)DNS系统介绍 (2)域名 (3&#…

学习平台|基于Springboot+vue的学习平台系统的设计与实现(源码+数据库+文档)

学习平台系统 目录 基于Springboot+vue的学习平台系统的设计与实现 一、前言 二、系统设计 三、系统功能设计 1系统功能模块 2管理员功能模块 3学生功能模块 4教师功能模块 四、数据库设计 五、核心代码 六、论文参考 七、最新计算机毕设选题推荐 八…

不小心丢失mfc140u.dll文件怎么办?mfc140u.dll丢失的解决办法

当您发现mfc140u.dll文件不见了或者受损,别担心,我们可以一起解决这个问题!首先,您可能会注意到一个小提示,当您尝试打开某些程序时,屏幕上会跳出一个消息说“找不到mfc140u.dll”或者“mfc140u.dll文件缺失…

解决docker中container运行闪退终止的问题

在运行bindmount-test时,点击完运行按钮后闪退结束运行。 第一步查看log日志: 2024-05-18 23:46:18 Error: Cannot find module /app/nodemon 2024-05-18 23:46:18 at Function.Module._resolveFilename (internal/modules/cjs/loader.js:668:15) …

2024-5-24 石群电路-15

2024-5-24,星期五,22:15,天气:晴,心情:晴。今天最后一天上班,终于要放返校假啦,开心!!!!!!不过放假也不能耽误…

【HarmonyOS4学习笔记】《HarmonyOS4+NEXT星河版入门到企业级实战教程》课程学习笔记(八)

课程地址: 黑马程序员HarmonyOS4NEXT星河版入门到企业级实战教程,一套精通鸿蒙应用开发 (本篇笔记对应课程第 15 节) P15《14.ArkUI组件-状态管理state装饰器》 回到最初的 Hello World 案例,首先验证 如果删掉 State…

物理服务器介绍

物理服务器介绍 概述分类按服务器应用分类按服务器结构分类塔式服务器机架式服务器刀片式服务器机架式服务器与刀片式服务器的对比按处理器个数分类按处理器架构分类 主板概述工作原理物理结构技术参数 CPU概述工作原理指令集相关技术技术参数主流产品 内存概述类型相关技术技术…

C语言-atoi()库函数的模拟实现

文章目录 前言一、atoi()库函数的介绍及使用1.1 atoi()库函数介绍1.2 atoi()库函数使用 二、atoi()库函数的模拟实现2.1 函数设计2.2 函数实现思路2.3 具体实现2.4 测试 总结 前言 本篇文章介绍c语言中库函数atoi()的使用,以及模拟实现库函数。 一、atoi()库函数的…

Threes 特效 炫酷传送门HTML5动画特效

基于Three.js的HTML5 3D动画,这个动画模拟了游戏中的一个炫酷的3D场景,支持360度视角查看,也支持鼠标滚轮进行缩放。画面中主要展现了一个游戏中传送门的效果,同时还有路两边的围栏、灯笼、石头,以及星光闪闪的萤火虫&…

IO端口编址

统一编址 特点 独立编址 特点 内存地址分配 区别 应用 IO端口地址译码 硬件上的实现 示例1: 示例2: IO指令 软件上的实现 示例

2024最佳画图软件合集,操作简单无需下载!

随着数字时代的到来,绘画软件已经成为创造性表达和艺术创作不可或缺的工具。无论你是设计师、艺术家,还是只是对创作充满热情,2024年的绘画软件集都为你提供了各种各样的选择,这样你就可以在数字画布上释放你的想法。本文将重点推…

XV4001系列陀螺仪传感器广泛用于车载导航系统

随着汽车电子化趋势的加速,越来越多的汽车配备一系列先进的车载导航系统,这些导航系统功能的实现都依赖于精确的传感器数据(位置、车速、转向角度、车轮转速等)。传感器作为这些系统的核心组件,其准确性和可靠性直接影响到整个导航系统的性能…

大模型时代,掌握Event Stream技术提升Web响应速度

大模型时代,每天搜索都可能会用到一种或多种大模型,在大文本输出的时候,页面是一字一字,一段一段的慢慢输出出来的,这背后是如何实现的呢?我们以KIMI为例 先抓个请求 我们发现界面展示是一句话,但是接口返回的时候是一个字一个字的。 普通请求 多了Event Stream的处理 …

DDoS攻击的最新动态及市场趋势分析

随着数字化转型的加速和网络连接设备的增加,分布式拒绝服务(Distributed Denial of Service, DDoS)攻击已经成为全球网络安全领域的一大威胁。根据最新的市场研究报告,预计到2028年,DDoS防护软件市场的复合年增长率将达到14%以上,…

爬虫实训案例:中国大学排名

近一个月左右的时间学习爬虫,在用所积累的知识爬取了《中国大学排名》这个网站,爬取的内容虽然只是可见的文本,但对于初学者来说是一个很好的练习。在爬取的过程中,通过请求数据、解析内容、提取文本、存储数据等几个重要的内容入…

qmt量化交易策略小白学习笔记第10期【qmt编程之获取股票订单流数据--内置Python】

qmt编程之获取股票订单流数据 qmt更加详细的教程方法,会持续慢慢梳理。 也可找寻博主的历史文章,搜索关键词查看解决方案 ! 感谢关注,需免费开通量化回测与咨询实盘权限,可以和博主联系! 获取股票订单流…

Undet for SketchUp 2023.3 点云建模软件 支持支持草图大师sketchup2021-2022-2023

1.Undet for sketchup 2023.3支持草图大师sketchup2021-2022-2023。支持机载雷达扫描、车载扫描还是地面扫描,对AEC行业用户来说,真正需要的是如何将这些数据快速处理为三维模型,这样才能将这些信息延展到BIM领域发挥效用。因此面对这些海量的…

开源大模型与闭源大模型:谁主沉浮?

目录 🍉引言 🍉数据隐私 🍈开源大模型的优势与挑战 🍍优势: 🍍挑战: 🍈闭源大模型的优势与挑战 🍍优势: 🍍挑战: &#x1f34…

本地idea连接虚拟机linux中的docker进行打包镜像上传--maven的dockerfile-maven-plugin插件

项目名必须是英文,-,.,_,这些数字,idea需要管理员运行,因为idea控制台mvn命令需要管理员权限才能运行(maven需配置环境变量)改linux中的Docker服务文件,使用2375 进行非加密通信,然后加载重启 2.1 #修改Docker服务文件 vi /lib/systemd/system/docker.service ​ # 通常使…