https://ravindraelicherla.medium.com/10-design-patterns-every-software-architect-must-know-b33237bc01c2
存在任何解决实际人类问题的业务。它可能是提高速度，降低成本，提高便利性，增加生活乐趣或使知识触手可及。通常用于解决这些业务问题的技术。但是，为什么设计模式很重要？IT系统的典型挑战是可用性，可伸缩性，弹性，数据管理，性能和安全性。在进入设计模式之前，弄清楚这些词很重要。
可用性： Availabilit Ÿ是一次系统的比例高达在定义的时间段。系统可能由于多种原因而停机，例如软件错误，网络问题，负载问题，DDoS（分布式拒绝服务）攻击和基础架构硬件问题。可用性按以下百分比表示。
可扩展性：2014年，印度在线零售商Flipkart继续向客户道歉，因为十亿美元的大额销售由于可扩展性问题而无法满足客户的需求。可伸缩性是计算资源，数据存储需求，消息传递基础结构和成本的一个因素。有两种方法可以解决可伸缩性问题。第一个是垂直扩展，您将继续增加资源的容量，第二个是水平可扩展性，在此添加更多节点。这两种方法都各有利弊。通常，垂直缩放速度更快，但是在一定的时间点之外仍具有局限性，水平缩放会花费更多时间，并且接近无穷大缩放。
可伸缩性是系统资源如何应对不可预测的客户需求。
弹性：您继续在电子商务网站上购买手表。您不喜欢该设计，并且想要寻找更多选择。您选择了几个带有设计，颜色，价格过滤器的下拉框，然后单击搜索按钮。现在您会期望看到手表的图片，价格数据，一些规格，例如表带材料类型，手表机芯，颜色，交货日期。如果交货时间微服务那段时间该怎么办？您现在有多个选择。完全不要显示该字段，而是显示一条静态消息“我们正在计算准确的交货日期，请耐心等待”，否则您将选择一个日期范围并显示给客户。
弹性是系统能够妥善处理故障并尽快从故障中恢复的能力。
数据管理：数据管理在可伸缩性，可用性，安全性和弹性方面起着至关重要的作用。与数据管理相关的架构决策取决于您要构建的应用程序类型。它是繁重的（更多的用户事务），繁重的（报告），旨在进行分析（预测，客户细分），时间序列（日志处理）还是Datawarehouse（数据分析）。影响数据一致性，数据可用性，数据存储和归档策略的其他因素很少。
性能：可伸缩性和性能是相互关联的。如果与系统可以处理的用户相比，有更多的用户，则系统自然会遇到性能问题。怎么处理呢？您增加资源或减少用户数量。当然，第二选择不是理想的选择，因为您最终将失去业务。实际上，当您解决可伸缩性问题时，我们将解决这些性能问题。我只想提醒您，可伸缩性不能解决所有性能问题，但可以解决一些问题。例如，如果性能问题是错误编写的DB查询的结果，那么在不对查询进行微调的情况下扩展资源将被证明是灾难性的决定。
安全性：建立安全的系统可确保用户的数据安全无虞。数据完整性和数据持久性同样重要。这与将钱存入银行非常相似。如果您将一百万美元存入银行，您不想损失那笔钱（安全），您会希望银行总是说您存了一百万美元-这里没有错（诚信），即使十年后您也去了银行，您仍然会有那一百万美元的钱（耐用性）。
现在您已经掌握了正确的基础知识，让我们一一介绍重要的模式。没有设计模式可以解决所有问题。需要根据用例进行选择。
可扩展性和性能
CQRS —命令查询职责隔离
数据管理，安全性
2.反腐败层模式：此模式最初由Eric Evans描述在域驱动设计（DDD）中。让我用一个故事来介绍一下。Martin和Sheela在零售连锁店工作。Martin在客户订单团队中工作，Sheela在会员卡团队中工作。从DDD的角度来看，Martin和Sheela属于两个不同的领域，通常它们不会相互影响。一天，Sheela希望对自己的系统进行更改。更改是要知道客户的位置，以便她可以根据位置提供其他忠诚度积分。但是，她不认识马丁。即使她知道，Martin也可能不同意她的更改，因为他必须更改其API。但是，她知道Srinivas是Martin的经理。她找斯里尼瓦斯做改变。在这种情况下，Srinivas是一个反腐败层。当您拥有旧系统和现代应用程序并且正在迁移时，通常使用此模式。该层包含转换现代系统的请求所需的所有逻辑。引入这一层的最大挑战是，它将为用户增加一跳并增加延迟。必须在速度与数据之间做出决定。
反腐败层
可靠性，容错能力
3.断路器模式：在飞行中旅行时，有一个氧气面罩和一个向西的生活，除了热情洋溢的空姐外，很少有人注意。原因很明显。这些仅在发生故障时使用。您的基本假设是您的飞行不会失败，不需要使用，因此您不会关注。但这对于IT系统而言并非如此。
“一切总是失败” – AWS CTO Werner Vogels
我确定您听说过许多著名网站由于各种原因而倒闭。在分布式环境中，任何时候都可能会失败。
作为架构师，您无法避免失败。您只能设计用来处理故障。
断路器模式可防止应用程序执行几乎肯定会失败的操作。让我解释一下。您的系统突然遇到负载，并且API请求超出其处理能力。例如，服务的典型响应时间阈值为5秒，现在请求所花费的时间超过了该阈值，您的服务开始向后发送500个响应。除了给用户带来不好的体验外，如果超出某个点的负载更多，您的系统可能会完全放弃。现在该停止更多请求了。
让我们将其与断路器的工作方式进行比较。你有没有遇到过？您刚打开电源插头，突然就没电了。现在，您可能需要转到地下室或大厅中的总机，然后关闭已关闭的交换机。这是现实世界中断路器起作用的地方。这是在做什么 当负载很高时，将停止供电以防止进一步损坏。
现在让我们回到我们的世界。断路器模式具有三种状态。封闭，开放和半开放。在关闭状态下，一切正常，并且系统按预期工作。出现问题时，断路器打开，数据流中断。这意味着没有向用户提供预期的请求。Half Open在等待一段时间后尝试测试水域，以查看问题是否仍然存在。如果成功，状态将变为关闭，以便系统恢复正常。如果不成功，它将返回到打开状态。
断路器-闭合状态
断路器-开路状态
可扩展性，弹性和性能
4.事件源：随着数据成为新石油，这种模式在最近几天变得很流行。这种模式表明，不仅要存储动作的状态，还应存储整个历史记录。假设您正在构建银行应用程序。客户在一段时间内将有多个借方和贷方。假设客户的起价为$ 1000。第1天存入$ 50，第2天存入$ 100，第3天存入$ 150。在第3天结束时，她将获得$ 1100。但是，在使用事件来源的情况下，您可以存储所有事务而不会丢失任何操作。拥有此数据后，可以用于多种目的。通过运行中的快速计算，您绝对可以在任何时间分辨出她的银行余额是多少，但您也可以了解她的银行模式，否则这是不可能的。
活动采购
让我们再看一个例子。您正在构建电影票预订系统。对于一部受欢迎的电影，观众会看到很多匆忙，这将导致可伸缩性问题。客户可以预订，取消或持有座位。假设剧院有200个座位。您需要不断计算可用席位，以使下一个客户可以看到该席位。在这里，事件采购将很方便。您不必经过所有活动，最后得出一个数字，而不用像CRUD操作那样计算可用座位。
可伸缩性，弹性，容错性和性能
5.发布者-订阅者模式
这通常被称为发布/订阅模式。在基于云的系统中，一个系统的模块需要与同一系统或另一系统的模块异步通信。让我举个例子。您正在建立一个休假管理系统。每当员工申请请假时，您都需要同时通知时间表模块，计划模块和薪资模块。这可以通过异步调用来完成。这些模块仅消耗数据。他们将不会验证数据。但是，当员工申请请假时，余额验证必须是同步调用（通常是REST Api调用），因为在没有余额的情况下员工不得申请请假（当然，要遵循组织的人力资源政策）
这里还有一个例子。想象您是一家新闻采购公司，并且您通过各种输入机制收集新闻。您的最终用户是报纸和出版公司。然后，您可以捕获新闻并发布给客户。如果您的客户是体育杂志，那么他们只会消费与体育相关的新闻；或者，如果您的客户是财经网站，那么他们只会使用与数据相关的财经。您的责任是捕捉世界上正在发生的事情而不会丢失任何事件。由客户决定他们要消费什么。您还可以创建实例化视图以供进一步使用。
如图所示的消息代理最适合用于异步通信。每当需要弹性和容错应用程序时，Pub-Sub模式就派上用场。消息代理，Apache Kafka，Apache Active MQ，AWS Kinesis和IBM MQ有很多选项。Apache Kafka最受欢迎，以高性能和零数据丢失而著称。
可扩展性，数据管理和性能
6.分片模式：如果您投资股票市场，这是一种久经考验的策略，即您不会将所有资金都投入到一只股票中。您将创建股票投资组合并进行投资。通过这种方法，如果一只股票价格下跌，您仍然会让其他股票赚钱。
不要把所有的鸡蛋放在一个篮子里。
分片采用类似的方法。在这种模式下，您将数据划分为多个分区或碎片。这极大地提高了可伸缩性。这种模式属于水平可伸缩性，而不是垂直可伸缩性。如果数据存储在单个数据存储中会发生什么？与上述示例中的单个股票相同。如果数据存储出现故障，您的用户将无法访问数据，从而造成很多麻烦。超过某个点，您将遇到存储问题，计算能力，网络和带宽问题。如果您要为不同位置的用户提供服务，则只有一个数据存储会增加延迟问题。
分片可提高可伸缩性，性能和容错能力。分片策略有多种方法。该策略与您的用例一起使用。
基于范围的分片：假设您要存储客户数据，则可以考虑根据个人识别码或邮政编码范围进行存储。此模型的缺点是您的客户数据可能分布不均
垂直分片：如果要构建电子商务应用程序，则可以将客户人口统计详细信息存储在一个分片中，并将客户购买交易存储在另一个分片中。这为您提供了按需扩展的机会。
基于哈希的分片：这是一种广泛使用的策略。如果您有5个分片来存储客户数据。您以客户唯一ID为例，并应用模5。
现在为您提供一些有趣的数学。
如何计算任意数量的Modulo 5。很简单。假设数字为23。将该数字除以5。您将得到4.6。现在取4乘以5。得到20。现在得到23–20，得到3。因此，答案为“什么是23 mod 5？” 是3。
从长远来看，基于哈希的分片将面临挑战。如果您希望在一年后再添加一个碎片，该怎么办。您需要更改分片逻辑，并且数据存储中的容量会乱扔。解决方案是一致的哈希。
数据管理
7. Strangler模式： Wikipedia的意思是Strangler是附生植物，其气生根最终将其生长的树木勒死。今天，几乎每个组织都从单片服务过渡到微服务。无论如何，这一旅程都不容易。从旧系统迁移到新系统时，系统地将功能迁移到新系统，而不是大手大脚的方法。如果要将遗留的单片应用程序迁移到云微服务应用程序，此模式将很方便。最终，迁移结束后，用户将直接与现代应用程序进行交互。在这种模式下，构建并迁移的小型功能（或微服务）最终会杀死主系统。从中查找有关此模式的更多详细信息Martin Fowler的博客。
数据管理，安全性
8. Saga模式：这是管理分布式系统中数据一致性的最佳模式。在使用Internet和WhatsApp之前，人们曾经亲自去亲戚和亲戚家旅行并发出结婚邀请。这被视为令人敬重。无论如何，撇开这一点，如果婚姻突然取消怎么办？您不希望那天的亲戚和朋友来。最好的方法是您再次前往每个人的住所，告诉他们婚姻已经取消。（不是一个积极的例子。但这就是生活）。这正是Saga模式。关于Saga模式的第一篇论文发表于1987年。
有两种方法可以实现Sagas模式。事件/编排设计和命令/编排排序逻辑。编排设计非常复杂。让我们看一下命令/编排排序逻辑。我现在以机票预订应用程序为例。这是您预订航班的顺序。
让我们看一下事件的顺序：
假设付款服务失败。您不想为客户提供免费座位和免费餐点。现在，BSO发送命令回滚座位预订和用餐预订。可以在此处找到Saga模式的非常详细的说明
可用性，弹性
9.节流模式：如果您在美好的一天去过任何著名的印度庙宇，将有5万至10万奉献者。Darshan时间（在上帝面前的时间）仅持续几秒钟，但他们在队列中花费4到8个小时之间的任何时间。寺庙管理通常通过将人群放在带有一些座位设施的小隔间中来控制人群。Lets说，在“ darshan”之前有20个隔室和一个最后的队列。一个隔间可容纳约200人。随着时间的流逝，人们从隔间1移到隔间2，依此类推，直到到达最后的队列。这称为节流。
对于IT应用程序，大部分时间都是可以预测的，除非出现一些黑天鹅事件。电子商务网站在节日期间或销售时会增加负载。对于银行系统，在计入工资期间可能会有更多的负担。对于时间捕获系统，在早上，下午和晚上时间将出现峰值负载。处理这些峰值负载的一种方法是自动扩展资源。第二种选择是限制系统可以处理的事务数量，并开始限制剩余的事务。这样，就可以满足SLA，并且系统可以继续按预期运行。
节流
可用性，性能
10.静态内容托管模式：在典型的网站上，不变的内容称为静态内容。通常使用html，css和JAVAscript创建。JavaScript不是强制性的，也可以仅使用HTML和CSS（或Sass）。动态网站将具有在Web服务器上运行的逻辑，并且通常会对静态网站无法提供的数据执行CRUD操作。动态网站取决于服务器端处理，包括服务器端脚本，例如php，JSP或ASP.NET或Node.js。例如，您想在购买前知道产品的价格，想支付电费，想在朋友的时间轴上发布生日快乐，或者甚至很复杂，您想实施一个选择策略股票。所有这些都需要一个动态的网站。随着AWS的出现，Azure和google云平台的静态托管不需要您自己的服务器即可运行。例如，您可以在Amazon S3上托管静态网站（简单存储服务），而无需分拆新服务器。此外，您可以使用Cloudfront加快网站速度，该服务会将文件存储在靠近用户的边缘位置。
京公网安备 11010802035086号