许多现代应用都需要在企业级规模上进行构建,种常有时甚至需要在互联网规模上进行构建。架构这些应用都需要满足可扩展性、设计可用性、模式安全性、种常可靠性和弹性需求。架构 在本文中,设计我将谈论一些设计模式,模式这些模式可以帮助你轻松实现上述能力。种常我将讨论每个模式,架构他们如何在云原生环境中使用,设计以及何时使用和何时不使用。模式 有些模式也并不是种常什么新发明,但它们在当前互联网规模的架构云世界中非常有用。 以下是设计我将在本文中讨论的模式列表。 下面进入正文。 熔断器 分布式系统在设计时应考虑到故障问题。目前微服务已经得到了广泛应用,这些服务大多依赖于其他远程服务。远程服务可能会因为网络、应用负载等各种原因而不能及时响应。在大多数情况下,通过重试应该可以解决这些问题。 但也有极端情况,比如服务降级或服务本身完全失效。在这种情况下,继续重试是没有意义的。因此熔断器模式就可以派上用场了。源码下载 熔断器 上图展示了熔断器模式的实现,当服务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。 什么时候使用这种模式 何时不使用此模式 事件溯源(Event Sourcing) 事件溯源是一种有意思的设计模式,在这种模式下,域事件的序列被存储为日志,日志的聚合视图给出了应用程序的当前状态。 这种模式通常用于那些无法承受数据存储锁的系统,并且需要维护事件的审计和历史记录,例如,酒店/会议/座位预订等应用。 事件溯源 比如一个酒店客房预订系统,其中用户需要预订或取消预订。在这里,你需要将预订和取消预订存储为一系列事件。在每次预订之前,通过查看事件日志,聚合视图显示可用房间。 注:大多数云服务提供商都支持消息服务,如 Google Pub/Sub、Azure Service Bus、AWS SQS 等。这些服务与强大的一致数据存储相结合,可以用来实现这个模式。 何时使用此模式 何时不使用此模式 (待续) 原文链接: https://medium.com/better-programming/modern-day-architecture-design-patterns-for-software-professionals-9056ee1ed977 本文转载自微信公众号「高可用架构」,可以通过以下二维码关注。转载本文请联系高可用架构公众号。