什么是可扩展性-如何设计一个扩展性强的系统 一

什么是可扩展性-如何设计一个扩展性强的系统 一

系统设计中非常重要的概念之一就是可扩展性。

在系统设计中,可扩展性是指系统使其性能和成本适应应用程序和系统处理需求的新变化的能力。

用于构建服务、网络和流程的架构在以下两个条件下是可扩展的:

  1. 当需求/工作量增加时轻松添加资源。
  2. 当需求/工作负载减少时,轻松删除资源。

可扩展性基本上是衡量系统对资源添加和删除以满足我们的要求的响应能力的指标。这也就是我们在开发系统的时候对系统进行需求分析,并确保系统具有适应性和可扩展性的中药作用。

如何实现可扩展性

现在可扩展性是通过系统中的两种方法实现的:

  1. 垂直缩放
  2. 水平缩放

现在让我们讨论上面提到的和上面展示的两种将系统扩展至更高深度的方法,如下所示:

什么是垂直缩放?

通过添加更多配置或硬件以实现更好的计算或存储,垂直扩展可以扩展系统的规模。实际上,这包括升级处理器、增加内存、磁盘、带宽或进行其他增加功率的更改。在这种情况下,使用多核扩展来通过在 CPU 和 RAM 资源之间分配负载来进行扩展。

垂直缩放

垂直扩展的优点

  1. 它比维护多台服务器消耗更少的能源。
  2. 需要较少的管理工作,因为只需管理一台机器。
  3. 具有较低的冷却成本。
  4. 降低软件成本。
  5. 实施起来更简单。
  6. 保留应用程序兼容性。

垂直扩展的缺点

  1. 硬件故障的可能性很高,这可能会导致更严重的问题。
  2. 系统升级空间很小,可能会成为单点故障(SPOF)
  3. RAM 的大小是有限制的。
  4. 内存存储可以立即添加到机器上。

什么是水平扩展?

通过添加新机器的行为,系统可以水平扩展。必须聚集并连接多个设备才能处理更多的系统请求。

水平扩展的优点

  1. 它比扩大规模更便宜,并且可以使用更小的系统。
  2. 升级简单。
  3. 离散的多个系统的存在提高了弹性。
  4. 容错管理起来很简单。
  5. 通过支撑线性来增加容量。

水平扩展的缺点

  1. 相关费用较高。
  2. 它在数据中心内占用的空间更大,这增加了冷却和能源等公用设施的成本。
  3. 它需要更多的网络硬件。
  4. 维护成本增加

可扩展代码通常计算效率低下。这是一个痛苦的事实,因为我们将大而复杂的代码拆分为一组小的关联操作,以便水平扩展,因为垂直扩展是有限制的。

垂直扩展与水平扩展

我们已经讨论了每种扩展类型的细节,我们根据不同的参数对它们进行比较:

影响范围 水平扩展 垂直扩展
数据库 数据分区 数据在单台机器上,并且跨多核进行扩展,此后负载将在 CPU 和 RAM 之间分配。
停机时间 添加机器可以减少停机时间。 调用单台机器会增加停机时间。
数据共享 由于存在分布式网络结构,因此通过消息传递进行数据共享变得相当复杂 在单台机器上工作可以实现消息传递,从而使数据共享变得非常容易。

如何避免在可伸缩性过程中出现故障?

正如上面通过可扩展性概念所研究的那样,我们在设计系统架构时,我们不能选择极端的设计,即要么过度使用(更多数量的资源)资源,要么未充分利用(更少数量的资源)每个资源收集并分析需求。

现在这里有一个问题,即使我们可以设计一个永久完美的系统,也会出现失败(如上面的架构师设计原则规则中所讨论的)。正如上面提到的,在最佳设计的系统中确实存在故障,但我们可以防止它们在全球范围内妨碍我们的系统。 这是因为我们保持系统冗余并复制数据以保留数据。

现在让我们更深入地理解这些术语,如下所示:

  1. 冗余
  2. 复制

什么是冗余?

冗余无非是节点或组件的复制,以便在某个节点或组件发生故障时,备份节点可以继续为消费者提供服务。为了维持可用性、故障恢复或故障管理,冗余很有帮助。冗余的目标是创建快速、有效且可访问的备份通道。

它有两种类型:

  1. 主动冗余
  2. 备用或被动冗余

什么是复制?

复制是对各种数据存储的管理,其中每个组件都保存在不同服务器上托管的多个副本中。它只是在许多设备之间复制数据。它涉及同步各种机器。复制通过确保冗余资源之间的一致性来提高容错能力和可靠性。

另外,它有两种类型:

  1. 主动复制
  2. 被动复制

现在,在掌握了负载平衡和缓存的先决知识后,让我们深入研究负载平衡和哈希的概念。

提示: 到目前为止,我们已经通过复制检查在服务器中高效存储数据,实现了高效存储数据。但如果我们仔细观察,到目前为止,我们只强调适当地扩展系统,但这些系统效率非常低。

这是因为我们只是通过冗余来扩展系统,以检查数据库中单点故障引起的节点故障(SPOF 在本地和全局范围内对系统架构师造成损害),而不是根据扩展来寻找边界,例如:

  • 根据可扩展性增加延迟
  • 吞吐量较小

可扩展性设计原则

每当设计系统时,都应牢记以下原则来解决可扩展性问题:

  1. 可扩展性与性能: 在构建可扩展系统时,系统的性能应始终与其可扩展性成正比。这意味着当系统规模扩大时,性能应该提高,而当性能要求较低时,系统应该缩小。
  2. 异步通信: 系统的各个组件之间应该始终进行异步通信,以避免任何故障。
  3. 并发: 这与编程的概念相同,在系统中,如果我们的控制器需要向用户发送多个查询,那么它们会同时启动,从而大大缩短(减少)响应时间。
  4. 数据库: 如果查询被一个接一个地触发,则整体延迟不应增加,数据库也不应开始出现问题。
  5. 最终一致性: 最终一致性是分布式计算中用于实现高可用性的一致性模型,它非正式地保证,如果没有对给定数据项进行新的更新,最终对该项目的所有访问都将返回最后更新的值。
  6. 非规范化: 第三范式描述了计算比 HDD 空间更昂贵,还导致更高的延迟。
  7. 缓存: 它是获取缓存命中/未命中和 LRU 缓存的重要支柱。
  8. 故障: 系统中的一切永远无法保持在控制之下,因为当我们使系统执行阈值时会发生故障。但失败确实会发生。在这里,我们使用这种方法来隔离问题并防止它们在全球范围内传播。
  9. 监控: 在复制阶段确实会发生一些错误,这是最糟糕的阶段,因为在这里我们没有足够的证据支持逻辑的发生,因此在监控的帮助下,我们间接地不断回顾整个事件的全部过程。
  10. 容量平衡: 假设负载急剧增加,我们之前收到 1000 个请求,分配到20个机器中,平均请求时间为100 毫秒现在,如果发生故障 = 1000/20 = 500ms。这意味着 900 个请求将失败。这就是为什么有时我们会调整断路器设置以平衡实际情况,也就是容灾。
  11. 服务器: 小容量服务器适合容量平滑的曲线,而大型服务器则适合调用监控、延迟、负载平衡的繁重计算。
  12. 部署: 应始终存在并维护旧代码,以应对所有导致停机的大规模且不可逆转的更改。如果不可能,则将更改分开,但在系统架构扩展时进行部署时必须遵循这些实践。
相关推荐
亦世凡华、几秒前
【启程Golang之旅】从零开始构建可扩展的微服务架构
开发语言·经验分享·后端·golang
河西石头1 分钟前
一步一步从asp.net core mvc中访问asp.net core WebApi
后端·asp.net·mvc·.net core访问api·httpclient的使用
2401_8574396913 分钟前
SpringBoot框架在资产管理中的应用
java·spring boot·后端
怀旧66614 分钟前
spring boot 项目配置https服务
java·spring boot·后端·学习·个人开发·1024程序员节
洛卡卡了32 分钟前
从单层到 MVC,再到 DDD:架构演进的思考与实践
架构·mvc
阿华的代码王国34 分钟前
【SpringMVC】——Cookie和Session机制
java·后端·spring·cookie·session·会话
德育处主任Pro1 小时前
『Django』APIView基于类的用法
后端·python·django
乌恩大侠1 小时前
O-RAN Fronthual CU/Sync/Mgmt 平面和协议栈
5g·平面·fpga开发·架构
哎呦没3 小时前
SpringBoot框架下的资产管理自动化
java·spring boot·后端
2401_857600954 小时前
SpringBoot框架的企业资产管理自动化
spring boot·后端·自动化