建筑模式入门
的大泥球指缺乏任何结构设计，从而导致复杂、紧密耦合和相互依赖代码的体系结构。
不幸的是，它是最流行的软件设计方法，它的普遍采用通常是无意的。它的出现是由于缺乏对架构原则的理解、无章法的开发实践、零零碎碎的增长以及随着时间的推移技术债务的积累。
你知道这种系统，我们都知道!!
可怕的是，这些系统构成了现实世界中软件的重要部分!但是有一种解决方法:架构模式!
一个n体系结构模式是特定问题的可重用解决方案，可帮助定义应用程序的基本特征和行为。为您的问题选择正确的模式，您可以避免重复工作和潜在的麻烦，如果您试图提出一个新的解决方案，可能会导致麻烦。
让我们探索每个开发人员，架构师或数据科学家需要熟悉的七种最常见的模式。
1¼ - 图层
层模式是最常用(和被滥用)的模式之一，它依赖于将代码划分为不同和独立的层，从而降低了它们之间的耦合。每一层被标记为关闭，这意味着请求必须通过它下面的层才能进入下一层。它也有自己的责任提供一个隔离级别因为它使我们能够在不影响其他层的情况下修改一个层的组件。
➕优势：它在概念上易于实现，并且在代码中清楚地实现和表示层。它促进了关注点、可维护性、可重用性和可测试性的分离。➖缺点:每一层之间引入了抽象的最高和最低层可以增加应用程序的复杂性和性能,会导致所谓的“架构天坑”反模式,通过多层,请求流与很少或没有逻辑简单直通处理在每一层执行。它还可能导致一个难以分割的整体应用程序。
此模式有许多变体，但它通常具有四层：呈现/ UI层，服务层，业务逻辑/域层，数据访问层。它也是其他主要模式的灵感。MVC.(模型、视图、控制器)。
2⃣ - 管道和过滤器
在管道和过滤器模式中，每个过滤器负责单个数据操作或转换。数据是流从一个过滤器到下一个过滤器，通过管道和操作并行发生。这意味着滤波器一旦可用，直到消耗所有输入直到所有输入都会产生输出。滤波器松散耦合，因此可以重复使用并重新组装以创建新的管道。
此模式的典型用法是UNIX管道命令。
➕优势：它促进了性能，可重用性/组成和可扩展性。➖缺点:可靠性可能是一个问题，好像一个组件发生故障，此问题在管道上传播，但可以通过具有用于错误处理的滤波器来控制。该范例的并行运行性质可以计算地昂贵，甚至可以在处理所有输入之前产生输出时导致死锁（例如，例如排序操作）
批处理顺序模式类似于管道和过滤器，主要的区别是前者不流数据，但通常将所有数据写入磁盘，以便下一阶段读取——相当老派:)。
3⃣——客户机-服务器
在客户机-服务器模式中，系统的功能被组织成服务，每种类型的服务都由单独的服务器交付。客户端访问服务器来使用这些服务服务．
服务器永久处于活动状态，监听客户机的请求。一旦接收到请求，服务器就会通过特定的协议与客户端打开连接，处理请求并返回。请求的发送超出了进程和机器的边界，这意味着客户机和服务器可能驻留在不同的机器上。
➕的优势:拥有一组共享和分布式的服务使得管理、修改和重用软件模块更加容易。提供互操作性，因为不管平台、拓扑或技术堆栈如何，都可以构建客户机-服务器应用程序。➖弱点：当请求过多时，服务器可能会过载，导致性能瓶颈，并且可以成为一个故障点。
一个休息(Representational State Transfer)架构是一种客户端-服务器架构，客户端和服务器通过统一的接口分开，服务器提供可寻址的端点(例如URL)，通过HTTP进行无状态通信(没有先前请求留下的信息或内存)。REST api(应用程序编程接口)是基于web的应用程序的行业标准。
4⃣-面向服务的体系结构(SOA)
对于一些组织来说，SOA是取代单一应用程序的垫脚石，提供了更灵活和敏捷的环境。它提供了一组模块化服务，这些服务可以相互“交谈”，以支持应用程序及其部署。
服务接口提供了松散耦合，这意味着可以在不了解集成如何在底层实现的情况下调用它们。传统上，SOA涉及到企业服务总线(ESB)作为协调和控制这些服务的方法。
➕的优势：SOA生产更易于维护和缩放的可互操作性，松散耦合的系统，因此它降低了总体拥有成本（TCO）。它还允许它通过以敏捷方式提供软件来响应变化的市场状况。➖弱点：要实现服务集成，ESB必须监督从初到目的地的消息，这导致整体性能降低。在不知道在快照及时运行的服务时，还无法确定不可能确定SOA系统的版本。
并不是所有的应用程序都适合这种类型的架构，例如需要严格执行响应时间的情况。
5⃣- Microservices
微服务体系结构模式采用构建小型、单一目的和自给自足相互通信以保证整个系统正常工作的服务。每个服务都是独立部署的，因此提供了高度的解耦，并且在与其他服务保持清晰的接口/契约的同时也可以自主发展。
DevOps可以用来帮助组织从SOA过渡到微服务，因为后者通常是在容器中操作的，这使得它们更具有可伸缩性和可移植性。
➕的优势:它促进了高度可重用、可维护和可独立部署的(单元)可测试服务。它们提供了改进的故障隔离，因为一个微服务的故障不会影响其他微服务的工作。使用多语言api，开发人员可以根据自己的需要轻松地选择最好的技术和语言。➖弱点:服务之间复杂的通信使得测试它们的交互更加困难。编目、测试和修复版本兼容性需要更多的努力。
微服务提供的api的粒度通常与客户机的需求不同。在这些情况下API网关是所有客户机的单一入口点，并以两种方式之一处理请求:要么将它们简单地路由到适当的服务，要么甚至将它们编排到多个服务。
6⃣-事件驱动架构(EDA)
事件驱动架构是最常见的异步以描述事件及其处理(即产生、检测和消费)的消息为中心的模式。事件是不可变(即它们不能被更改或删除)，它们是按时间顺序排列的。它们用于实时触发服务之间的通信(即服务不轮询更新，而是接收更新)。
事件可以通过多种方式发布，其中最流行的两种方式是:
⇾一消息队列这保证了将事件交付给适当的消费者，或者，
⇾一代理，其中一个事件未定位某个收件人，但允许访问“主题”的所有感兴趣的各方（AKA订阅者）。PUB /子消息传递系统通常被描述为一个事件流式架构．
➕的优势:提供异步通信，允许事件排队或缓冲，从而避免阻塞。在出现故障的情况下，丢失的工作可以通过“重播”过去的事件来恢复。依赖于Broker，它可以提高可用性、可靠性和可伸缩性。➖弱点：由于其异步性质，EDA系统必须仔细处理不一致或重复的事件或不兼容的版本。此外，它们不支持酸事务。
EDA中最流行的一种实践称为CQRS（命令查询责任分离），允许使用不同的模型来更新和读取域数据。
涉及交易原子性的另一个重要做法是事件的采购更新和删除永远不会直接对数据执行;相反，实体的状态更改被保存为一系列事件—这使得可以在任何时间点重构应用程序的状态。
EDA被进一步标准化被动的宣言这就要求设计具有这4个特征的系统:响应性、弹性、弹性和消息驱动。
7⃣- Serverless
上面描述的所有体系结构都有一个共同的特点:它们的对基础设施的依赖．
在无服务器体系结构中，云提供商可以轻松地按需管理服务器的供应。应用程序驻留在容器中，并部署在云．Developers do not have to worry about planning the servers’ resources (memory, CPU, IO), or designing such a topology that results in a highly available and automatically scalable application — the cloud provider takes care of this by essentially virtualising the runtime and operational management. Therefore, such providers usually charge their customers based on the total number of requests, the frequency of requests over a specified period or the total time spent to serve all of the requests.
➕的优势:不受基础设施规划的限制;成本效益，因为定价取决于执行的数量;易于部署和持续交付。➖弱点:作为一项技术，无服务器技术仍处于起步阶段，在IT社区中只有一小部分知识基础。由于很难从一个平台迁移到另一个平台，厂商锁定是一个高风险的风险。由于后端流程的可见性较低，因此调试很复杂。对于长时间运行的进程(推荐使用专用服务器或虚拟机)，无服务器是没有效率的。
无服务器包括两个不同但重叠的领域:
⇾函数作为服务（法斯):运行在临时容器中的自定义代码。
⇾作为服务的后端（Baas.):在后端方面严重依赖第三方服务的应用程序(如数据库、云存储、用户认证等)。
结束票据
不存在适用于每个项目的通用体系结构，因此理解体系结构模式的优缺点，以及它们最常见的一些设计决策是创建最佳设计的重要部分。同样值得注意的是，这些模式并不是相互排斥的;事实上，它们是互补的!
“架构是你希望在项目早期就能正确做出的决定。”- - -拉尔夫约翰逊
我希望这篇文章是您学习旅程的良好起点。以下矩阵总结了上面探索的模式：
感谢你的阅读!
我经常写关于媒体上的领导力、技术和数据的文章，如果你愿意阅读我未来的文章，请阅读“跟随”我！
