6种常用的架构设计模式(上)

原创高可用架构2020-10-19 12:36:23

许多现代应用都需要在企业级规模上进行构建,有时甚至需要在互联网规模上进行构建。这些应用都需要满足可扩展性、可用性、安全性、可靠性和弹性需求。

在本文中,我将谈论一些设计模式,这些模式可以帮助你轻松实现上述能力。我将讨论每个模式,他们如何在云原生环境中使用,以及何时使用和何时不使用。

有些模式也并不是什么新发明,但它们在当前互联网规模的云世界中非常有用。

以下是我将在本文中讨论的模式列表。

  1. 熔断器

  2. 命令和查询责任分离(CQRS)

  3. 事件溯源(Event Sourcing)

  4. Sidecar

  5. 后端对前端

  6. Strangler

下面进入正文。

熔断器

分布式系统在设计时应考虑到故障问题。目前微服务已经得到了广泛应用,这些服务大多依赖于其他远程服务。远程服务可能会因为网络、应用负载等各种原因而不能及时响应。在大多数情况下,通过重试应该可以解决这些问题。

但也有极端情况,比如服务降级或服务本身完全失效。在这种情况下,继续重试是没有意义的。因此熔断器模式就可以派上用场了。

熔断器

上图展示了熔断器模式的实现,当服务1了解到在调用服务2时有连续的故障/超时时,服务1不再重试,而是跳过调用服务2,并立即返回响应。

有一些流行的开源库,比如 Netflix 的 Hystrix,可以用来非常容易地实现这种模式。

如果你使用的是 API 网关或像 Envoy 这样的 sidecar 代理,那么可以在代理级别本身实现。

注意:非常重要的一点是,当熔断器打开时,要有足够的日志记录和警报,以便跟踪这段时间内收到的请求,并让运维团队了解到这些信息。

你也可以在半开的情况下实现熔断器,以继续为能容忍服务降级的客户提供服务。

何时使用此模式

  • 当一个服务依赖另一个远程服务,并且在某些情况下很可能失败时;

  • 当一个服务有很强依赖性时(例如:主数据服务)。

何时不使用此模式

  • 当你在处理本地依赖关系时,熔断器可能会产生开销。

命令和查询责任隔离(CQRS)

CQRS 对于现代使用数据存储的应用来说是一个非常有用的模式。它的原理是将数据存储中的读(查询)和写/更新(命令)操作分开。

假设你正在构建一个应用程序,需要将数据存储在 MySQL/PostgreSQL 数据库中。大家都知道,当向数据存储中写入数据时,一个操作需要经过几个步骤,比如验证、模型和持久化,因此典型的写/更新操作比简单的读操作需要更长的时间。

当使用单个数据存储同时执行读和写操作,并且访问量很大时,那么可能会开始遭遇性能问题。

在这种情况下,CQRS 模式可能很有用。CQRS 模式建议使用单独的数据存储来进行读和写操作。

CQRS

注:现在大多数 PaaS 数据库都提供了创建数据存储的读复制(Google Cloud SQL、Azure SQL DB、Amazon RDS等)的能力,这有助于更容易实现CQRS。

如果你处理的是私有数据库,很多企业数据库也提供了这个功能。

注:如今有些人也喜欢为读复制使用速度快、性能好的 NoSQL 数据库,比如 MongoDB 和 Elasticsearch。

什么时候使用这种模式

  • 当你正在考虑扩展一个期望有大量读和写的应用程序时。

  • 当你想分别调整读和写操作的性能时

  • 当你的读操作可以接受接近实时或最终一致性时

何时不使用此模式

  • 当你正在构建一个常规的 CRUD 应用程序,并不是每次都有大量的读和写的时候

事件溯源(Event Sourcing)

事件溯源是一种有意思的设计模式,在这种模式下,域事件的序列被存储为日志,日志的聚合视图给出了应用程序的当前状态。

这种模式通常用于那些无法承受数据存储锁的系统,并且需要维护事件的审计和历史记录,例如,酒店/会议/座位预订等应用。

事件溯源

比如一个酒店客房预订系统,其中用户需要预订或取消预订。在这里,你需要将预订和取消预订存储为一系列事件。在每次预订之前,通过查看事件日志,聚合视图显示可用房间。

注:大多数云服务提供商都支持消息服务,如 Google Pub/Sub、Azure Service Bus、AWS SQS 等。这些服务与强大的一致数据存储相结合,可以用来实现这个模式。

何时使用此模式

  • 常规的 CRUD 操作不能很好的满足需求时。

  • 通常适用于座位预定系统,如公交车、火车、会议、电影院等,或由购物车操作、支付等事件组成的电商系统。

  • 当需要强大的审计和事件回放来创建应用的当前和过去的状态时。

何时不使用此模式

  • 常规的 CRUD 操作足以满足用户需求时。

(待续)

原文链接:

https://medium.com/better-programming/modern-day-architecture-design-patterns-for-software-professionals-9056ee1ed977

本文由高可用架构翻译,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

(0)

相关推荐

  • 微服务架构及其最重要的 10 个设计模式!

    性能与架构 431篇原创内容 公众号 来源:Java日知录 软件设计模式是解决软件设计中常见问题的通用.可复用的解决方案.设计模式让我们可以分享通用词汇并使用经实战检验的方案,以免重复造轮子.现在,我 ...

  • 微服务设计模式

    https://www.shengchulai.com/blog-QEFWfPcRJ6.htm 微服务架构已经成为现代应用程序开发的主流.虽然说它能够解决某些问题,但却也不是万金油.而我们在使用这个体 ...

  • 微服务架构设计中的设计模式、原则及最佳实践

    作者 | Mehmet Özkaya 译者 | 平川 策划 | 闫园园 来源丨AI前线(ID:ai-front) 本文既有理论知识,又有实用信息:我们将学习每一种具体的模式,为什么以及应该在什么地方使 ...

  • 18种常用的抢救药物(上)

    18种常用的抢救药物 急诊常用的急救药物有哪些?应该如何使用?使用上需要注意哪些事情呢?本期飞哥说急救栏目就来和大家讲讲18种急诊科常用的抢救药物以及它们的用法和注意事项. 一.中枢神经兴奋药 尼可刹 ...

  • 风水上的七种常用水法

    十二长生水法 水口在:丁未坤申庚酉,生在甲卯,旺在乾亥,墓在丁未.水口在:癸丑艮寅甲卯,生在庚酉,旺在巽已,墓在癸丑.水口在:辛戌乾亥壬子,生在丙午,旺在艮寅,墓在辛戌.水口在:乙辰巽已丙午,生在壬子 ...

  • [转]几种常用的假设图像边界条件用于抑制振铃效应及实现(上)

    一 介绍 传统的图像复原方法可能会给复原图像引入振铃效应,并且以边界振铃为主:产生这种现象的原因简单地来讲主要是由于模糊核的 不精确或者信息丢失. [图片来自论文<光学合成孔径系统成像性能优化与 ...

  • 4种常用Java线程锁的特点,性能比较、使用场景 – mikechen的互联网架构师之路

    多线程的缘由 在出现了进程之后,操作系统的性能得到了大大的提升.虽然进程的出现解决了操作系统的并发问题,但是人们仍然不满足,人们逐渐对实时性有了要求. 使用多线程的理由之一是和进程相比,它是一种非常花 ...

  • 这23种常用农药,瓜菜、果树上慎用

    这23种常用农药,瓜菜、果树上慎用

  • 几种常用苹果树平衡树势的基本手法,保准用的上!

    一.按树势分. 分清树势找对策,分势合势勿用反,树势弱了用合势,枝量少了树自强.树势强了用分势,枝留多了势自缓. 二.前强后弱. 主枝前强后部弱,一般原因分两种,其一前部大枝多,其二肯定角度小.解决办 ...

  • 220种常用中药材(含饮片)鉴别彩图(上)

    二.茎木类中药 茎木类中药性状鉴定,需注意形状.大小.粗细.颜色.表面特征.质地.折断面.及气.味.如是带叶的茎枝,其叶则按叶类中药的要求进行观察. 三.皮类中药 皮类中药因植物来源.取皮部位.采集和 ...

  • 〖用药方案〗120种药店常用黄金搭配(上)3之1

    小/22 胃食管反流病[黄金搭配方案]1.吗丁啉+雷尼替丁2.吗丁啉+兰索拉唑 3.胃复安+奥美拉唑急性胃炎[黄金搭配方案]1.雷尼替丁+硫糖铝+胃复安2.吗丁啉+雷尼替丁+胶体果胶铋3.西咪替丁 ...

  • 微进程:微服务中后台作业的一种新架构设计模式

    实现微服务时,后台进程是最容易被忽略的元素,而绝大多数应用程序都需要后台进程. 微服务领域的大多数参考书目都着重于如何拆分单体.领域驱动设计.编排与同步.如何拆分数据库等.但人们往往不会提到后台进程, ...