面试前必须了解的7 种架构设计模式（译文）

【关于TalkX】

TalkX是一款基于GPT实现的IDE智能开发插件，专注于编程领域，是开发者在日常编码中提高编码效率及质量的辅助工具，TalkX常用的功能包括但不限于：解释代码、中英翻译、性能检查、安全检查、样式检查、优化并改进、提高可读性、清理代码、生成测试用例等。

TalkX建立了全球加速网络，不需要考虑网络环境，响应速度快，界面效果和交互体验更流畅。并为用户提供了OpenAI的密钥，不需要ApiKey，不需要自备账号，不需要魔法。

TalkX产品支持：JetBrains (包括 IntelliJ IDEA、PyCharm、WebStorm、Android Studio)、HBuilder、VS Code、Goland.

If you landed on this blog, I believe you know what modern architecture design patterns are. But for some of our less experienced friends here, think of architecture design patterns as the way you design your application(s) such that they scale and don’t need your resignation for that.

如果你来到这个博客，相信你已经知道什么是现代架构设计模式了。但是，对于一些经验不足的朋友来说，架构设计模式就是设计应用程序的方法，使它们能够扩展，而不需要你的辞职。

Architecture Design Patterns, in a nutshell, are design patterns for High Level Design.

简而言之，架构设计模式就是高层设计的设计模式。

Modern problems demand modern solutions. For applications to cater to enterprises or even an internet-level audience, they need to be scalable, available, secure, and resilient. Without a doubt, all major league companies are looking for developers who can grasp and solve these difficulties.

现代问题需要现代解决方案。应用程序要满足企业甚至互联网用户的需求，就必须具有可扩展性、可用性、安全性和弹性。毫无疑问，所有大公司都在寻找能够掌握并解决这些难题的开发人员。

The question now is: how do developers solve these problems? One way is to follow good architectural design patterns. Here I present you 7 deadly Sins:-

现在的问题是：开发人员如何解决这些问题？方法之一就是遵循良好的架构设计模式。在此，我向您介绍 7 宗罪：-

Circuit Breaker Pattern

断路器模式*

Michael Nygard’s book, Release It!, popularized the Circuit Breaker pattern, which can prevent an application from continually attempting to execute an action that is likely to fail, allowing it to proceed without waiting for the problem to be corrected or spending CPU cycles while determining the fault’s duration.

The Circuit Breaker pattern also allows an application to determine whether or not the issue has been remedied. If the problem appears to be resolved, the program can attempt to perform the operation.

The Circuit Breaker pattern serves a distinct purpose than the Retry pattern. The Retry pattern allows an application to retry an operation in the hope that it will succeed the next time.

The Circuit Breaker design prohibits an application from doing a risky activity. An application can use the Retry pattern to trigger an action through a circuit breaker to combine these two patterns. The retry logic, on the other hand, should be alert to any exceptions supplied by the circuit breaker and should cease repeat attempts if the circuit breaker indicates that a fault is not temporary.

迈克尔-尼加德（Michael Nygard）在《Release It!》一书中推广了断路器模式，该模式可以防止应用程序不断尝试执行可能会失败的操作，使其无需等待问题得到纠正或在确定故障持续时间时耗费 CPU 周期即可继续运行。

断路器模式还允许应用程序确定问题是否已得到解决。如果问题似乎已经解决，程序就可以尝试执行操作。

断路器模式的作用与重试模式不同。重试模式允许应用程序重试操作，希望下一次能够成功。

断路器设计禁止应用程序进行有风险的活动。应用程序可以使用重试模式通过断路器触发操作，从而将这两种模式结合起来。另一方面，重试逻辑应警惕断路器提供的任何异常，如果断路器显示故障不是暂时的，则应停止重复尝试。

Event Sourcing Pattern

事件溯源模式

Most apps operate with data, and the common method is for the program to keep the data in its present state by updating it when users interact with it. In the classic create, read, update, and delete (CRUD) architecture, for example, a typical data operation is to receive data from the store, make some changes to it, and then update the current state of the data with the new values— often by utilizing transactions that lock the data.

The Event Sourcing design defines a method for handling data activities that are triggered by a series of events, each of which is recorded in an append-only store. Application code delivers a series of events to the event store, where they are persisted, that must describe each action that has occurred on the data. Each event describes a collection of data changes (for example, “AddedItemToOrder”

大多数应用程序都使用数据进行操作，常见的方法是程序在用户与数据交互时通过更新数据来保持数据的当前状态。例如，在经典的创建、读取、更新和删除（CRUD）架构中，典型的数据操作是从存储中接收数据，对其进行一些更改，然后用新值更新数据的当前状态–通常是利用事务锁定数据。

事件源设计定义了一种处理数据活动的方法，这些数据活动由一系列事件触发，每个事件都被记录在只附加的存储中。应用程序代码会将一系列事件发送到事件存储区，并在那里进行持久化，这些事件必须描述数据上发生的每个操作。每个事件都描述了数据变化的集合（例如，"已添加订单项目”）

The events are saved in an event store, which serves as the system of record (the official data source) for the data’s present state. These events are often published by the event retailer so that consumers are aware and can handle them if necessary. Consumers may, for example, start tasks that apply the operations in the events to other systems, or they could execute any other associated action required to finish the process. It’s worth noting that the application code that generates the events is separate from the systems that subscribe to them.

这些事件被保存在事件存储中，作为数据当前状态的记录系统（官方数据源）。这些事件通常由事件零售商发布，以便消费者了解并在必要时进行处理。例如，消费者可以启动任务，将事件中的操作应用到其他系统，也可以执行完成流程所需的任何其他相关操作。值得注意的是，生成事件的应用代码与订阅事件的系统是分开的。

SideCar Pattern

边车模式

Monitoring, logging, configuration, and networking services are frequently required by applications and services. These extraneous chores might be carried out as distinct components or services.

应用程序和服务经常需要监控、日志记录、配置和网络服务。这些不相干的工作可以作为不同的组件或服务来执行。

A sidecar service is not always part of the application, but it is linked to it. It follows the parent application everywhere it goes. Sidecars are procedures or services that are delivered alongside the principal application. The sidecar on a motorbike is coupled to one motorcycle, and each motorcycle can have its own sidecar. A sidecar service, similarly, mirrors the fate of its parent application. A sidecar instance is deployed and hosted alongside each instance of the application.

侧车服务并不总是应用程序的一部分，但与应用程序有关联。它跟随父应用程序到达任何地方。副驾是与主应用程序一起交付的程序或服务。摩托车的挎斗与一辆摩托车相连，每辆摩托车都可以有自己的挎斗。同样，副驾服务也会反映其父应用程序的命运。每个应用程序实例旁边都部署和托管了一个副驾实例。

They can execute in the same process as the application if they are tightly integrated, making optimal use of shared resources. This, however, implies that they are not properly separated, and a failure in one of these components can affect other components or the entire application. Furthermore, they must normally be written in the same language as the parent program. As a result, the component and the application are highly dependent on one another.

如果它们能紧密集成，充分利用共享资源，就能与应用程序在同一进程中执行。但是，这意味着它们没有适当分离，其中一个组件的故障可能会影响其他组件或整个应用程序。此外，这些组件通常必须使用与父程序相同的语言编写。因此，组件和应用程序彼此高度依赖。

CQRS（“Command Query Responsibility Segregation”）

命令查询责任分离

CQRS stands for Command and Query Responsibility Segregation, a pattern that isolates data store read and update processes. CQRS implementation in your application can improve its performance, scalability, and security. The flexibility gained by moving to CQRS enables a system to evolve more effectively over time and prevents update instructions from triggering merge conflicts at the domain level.

CQRS 是命令和查询责任隔离（Command and Query Responsibility Segregation）的缩写，是一种隔离数据存储读取和更新过程的模式。在应用程序中实施 CQRS 可以提高性能、可扩展性和安全性。转用 CQRS 所获得的灵活性可使系统随着时间的推移更有效地发展，并防止更新指令引发域级别的合并冲突。

Separate query and update models make design and implementation easier. although, CQRS code cannot be automatically generated from a database schema using scaffolding techniques such as O/RM tools (although, you can add your customised on top of the generated code).

You can physically split the read and write data for more isolation. In that instance, the read database can utilise its own query-optimized data schema. It can, for example, store a materialised view of the data to avoid complex joins or O/RM mappings. It may even employ a different sort of data storage. For example, the write database could be relational, and the read database could be a document database.

不过，CQRS 代码无法使用脚手架技术（如 O/RM 工具）从数据库模式中自动生成（不过，您可以在生成的代码之上添加自定义代码）。

您可以对读写数据进行物理分割，以实现更高的隔离性。在这种情况下，读取数据库可以使用自己的查询优化数据模式。例如，它可以存储数据的物化视图，以避免复杂的连接或 O/RM 映射。它甚至可以采用不同的数据存储方式。例如，写入数据库可以是关系数据库，而读取数据可以是文档数据库。

Rate Limiting Pattern

速率限制模式

To prevent excessive resource consumption, some services impose limits on how fast other applications or services can access them. This is called throttling. You can use a rate limiting pattern to reduce or avoid throttling errors caused by these limits and to estimate throughput more accurately.

A rate-limiting pattern can be useful in many situations, but it is especially helpful for large-scale repetitive automated tasks such as batch processing.

By limiting the amount of records supplied to a service during a specific time, rate limiting can lower your traffic and possibly increase throughput.

为防止过度消耗资源，某些服务会限制其他应用程序或服务访问它们的速度。这就是所谓的节流。您可以使用速率限制模式来减少或避免这些限制造成的节流错误，并更准确地估计吞吐量。

速率限制模式在很多情况下都很有用，但对于批处理等大规模重复性自动任务尤其有用。

通过限制特定时间内提供给服务的记录量，速率限制可以降低流量，并有可能提高吞吐量。

Various measures may be used to throttle a service over time, including:

随着时间的推移，可采用各种措施对服务进行节流，包括：

— the quantity of actions (60 requests, for instance).

- 操作量（例如 60 个请求）。

— the volume of data (50 GB per minute, for instance).

- 数据量（例如每分钟 50 GB）。

— the relative expense of operations (42,000 RUs per second, for instance).

- 运行的相对费用（例如每秒 42,000 RU）。

Regardless of the metric employed for throttling, the rate limiting approach you choose will include regulating the volume and/or size of operations delivered to the service over a predetermined time frame in order to maximize your use of the service without going over the throttling limit.

无论采用哪种指标进行节流，您选择的速率限制方法都将包括在预定的时间范围内调节交付到服务的操作量和/或大小，以便在不超过节流限制的情况下最大限度地使用服务。

Strangler Fig

在编程中，“Strangler Fig” 是一种软件架构模式或重构策略的称呼，用于逐步重写或重构一个较大的、遗留的应用系统。这个术语源自于自然界中的 Strangler Fig（榕树）植物，它以相似的方式逐渐覆盖和替换宿主树。

在编程中，Strangler Fig 模式通过逐步替换应用程序的不同部分来实现系统的演进。新的代码和功能被引入并替换原有的代码，最终形成一个全新的应用系统。这种模式通常用于处理庞大而复杂的遗留系统，避免一次性重建带来的风险和成本。

Strangler Fig 模式的目标是逐渐减少遗留系统的依赖，并在重构过程中保持系统的稳定性和可用性。这种方式允许团队逐步改进系统，同时提供新的功能和价值，最终实现全面的系统重构或重写。

Migrate a legacy system incrementally by gradually replacing certain functionalities with new apps and services. The old system is eventually choked by the new system, which eventually replaces all of the features of the legacy system, enabling you to decommission it.

Replace specific functionalities in stages with fresh software and services. Make a façade that catches requests headed for the legacy backend system. These requests are forwarded by the façade to either the new services or the legacy application. Customers can use the same interface while existing functionality are progressively moved to the new system, completely ignorant of the transition.

通过用新的应用程序和服务逐步取代某些功能，以渐进的方式迁移旧系统。旧系统最终会被新系统扼杀，而新系统最终会取代旧系统的所有功能，使您能够将其退役。

用全新的软件和服务分阶段替换特定功能。制作一个 “立面”（façade），以捕获向传统后端系统发出的请求。这些请求将由立面转发给新服务或旧应用程序。客户可以使用相同的界面，而现有功能则会逐步转移到新系统中，完全不知道这一过渡。

This method helps spread out the development work across time and reduce migration risk. You may add functionality to the new system at any rate you like while ensuring the legacy application continues to work because the façade safely directs users to the appropriate application. The legacy system gradually becomes “strangled” and is no longer required over time as features are transferred to the new system. After finishing this procedure, the legacy system can be safely retired.

这种方法有助于分散开发工作的时间，降低迁移风险。您可以以任何速度向新系统添加功能，同时确保原有应用程序继续运行，因为 "立面 "可以安全地将用户引导到相应的应用程序。随着时间的推移，旧系统会逐渐被 “扼杀”，不再需要新系统的功能。完成这一过程后，遗留系统就可以安全地退役了。

Health Endpoint Monitoring Pattern

健康终端监测模式

The Health Endpoint Monitoring pattern can be used to ensure that programmes and services are operating properly. This pattern outlines how functional checks should be used in an application. Through open endpoints, external tools have regular access to these checks.

Sending requests to an endpoint on your application will enable health monitoring. After running all essential tests, the programme should indicate its state.

Usually, a health monitoring check combines two elements:

健康端点监控模式可用于确保程序和服务正常运行。该模式概述了应如何在应用程序中使用功能检查。通过开放端点，外部工具可以定期访问这些检查。

向应用程序的端点发送请求就能实现健康监控。在运行所有基本测试后，程序应显示其状态。
健康监控检查通常包含两个要素：

When a request is made to a health verification endpoint, the application or service executes checks, if any.

The evaluation of the outcomes by the system or tool that conducts the health verification check

当向健康检查端点发出请求时，应用程序或服务会执行检查（如果有的话）。

执行健康检查的系统或工具对结果进行评估。

The response code indicates the application’s status. The status of the app’s components and services may optionally be provided in the response code. The latency or reaction time check is carried out by the monitoring tool or framework.

The pattern is seen in the following figure.

响应代码显示应用程序的状态。响应代码中可选择提供应用程序组件和服务的状态。延迟或反应时间检查由监控工具或框架执行。

这种模式如下图所示。

The CAP Theorem has to be understood in order to have a working knowledge of databases, checkout my take on CAP.

CAP Theorem — Cheap, Fast or Easy?

CAP 定理–便宜、快速还是简单？

This is part one of the “Cloud Patterns” series; please read the second blog article, in which I attempted to describe 3 Must know Messaging Patterns.

本文是 "云模式 "系列文章的第一部分；请阅读第二篇博客文章，在这篇文章中，我试图描述 3 种必须了解的消息传递模式。

I have used most of these patterns while working in my company, so I know they will come in handy not only for interviews but also when you join your dream company.

我在公司工作时使用过其中的大部分模式，所以我知道它们不仅会在面试时派上用场，而且在你加入梦想公司时也会派上用场。

Keep Hustling, Keep Dreaming. \m/

继续努力，继续梦想。\m/

【参考文献】

上述译文仅供参考，原文请查看下面链接，解释权归原作者所有

文章：《7 Architecture Design Patterns — You wish you knew before interview》

作者：[deToxic Dev]

发布日期：2023.04.13

⚠️：文章翻译如有语法不准确或者内容纰漏，欢迎各位评论区指正。

【关于TalkX】

TalkX是一款基于GPT实现的IDE智能开发插件，专注于编程领域，是开发者在日常编码中提高编码效率及质量的辅助工具，TalkX常用的功能包括但不限于：解释代码、中英翻译、性能检查、安全检查、样式检查、优化并改进、提高可读性、清理代码、生成测试用例等。

TalkX建立了全球加速网络，不需要考虑网络环境，响应速度快，界面效果和交互体验更流畅。并为用户提供了OpenAI的密钥，不需要ApiKey，不需要自备账号，不需要魔法。

TalkX产品支持：JetBrains (包括 IntelliJ IDEA、PyCharm、WebStorm、Android Studio)、HBuilder、VS Code、Goland.