体系结构模式的底漆
的大泥球指的是一种体系结构,没有任何结构设计,因此导致了复杂的,紧密耦合,相互依赖的代码。
不幸的是,它是最受欢迎的软件设计方法,及其普遍采用通常是无意的。由于普遍缺乏了解,出现架构原则,没有纪律的开发实践,零碎的增长和技术债务的积累。
你知道这种系统…我们都做! ! !
可怕足够这些系统组成的很大一部分软件在现实世界中!但有一个解毒剂:架构模式!
一个n体系结构模式是一个可重用的解决一个具体问题,帮助定义应用程序的基本特征和行为。为您的问题选择正确的模式,可以避免重新发明轮子和潜在的陷阱,可能引起麻烦你试图提出一个新的解决方案。
让我们探索七最常见的模式,每一个开发人员,架构师,或数据科学家需要熟悉。
1⃣-层
分层模式是最常用和滥用模式依赖于代码分割成不同的和独立的层,减少它们之间的耦合。每一层都被标记为关闭,这意味着请求必须通过以下层对下一层去。它提供了一种也有自己的责任隔离级别因为它使我们能够修改层的组件在不影响其他层。
➕优点:在概念上很容易实现和层显然是实现和代码中表示。它促进关注点分离、可维护性、可重用性和可测试性。➖缺点:每一层之间引入了抽象的最高和最低层可以增加应用程序的复杂性和性能,会导致所谓的“架构天坑”反模式,通过多层,请求流与很少或没有逻辑简单直通处理在每一层执行。它也可以导致单一的应用程序难以分割。
这种模式有很多变种,但它通常有四层:表示/ UI层、服务层、业务逻辑/领域层、数据访问层。它也被其他主要模式的灵感。MVC(模型、视图、控制器)。
2⃣-管道和过滤器
在管道和过滤器模式中,每个过滤器负责单个数据操作或转换。数据是流从一个过滤器通过管道和下一个操作发生在平行。这意味着一个过滤器产生输出就没有等到所有输入消耗可用。过滤器是松散耦合的,所以他们可以重用和重新创建新的管道。
这种模式的典型用法是Unix管道命令。
➕优点:它促进性能/组合、可重用性和可扩展性。➖缺点:可靠性可以一个问题,如果一个组件失败,问题是传播管道,但可以控制通过过滤器用于错误处理。并联运行的本质这个模式可以计算昂贵,甚至可以导致死锁在一个过滤器不能产生输出前处理所有输入(例如排序操作)
批顺序模式类似于管道和过滤器的主要区别在于,前者是不流的数据,但通常为下一阶段将所有数据写入磁盘读——很老派:)。
3⃣——客户机-服务器
在客户机-服务器模式中,系统的功能组织成服务,与每一种类型的服务从一个单独的服务器。利用这些客户端访问服务器服务。
服务器永久积极倾听客户的请求。一旦收到请求,服务器打开一个连接与客户在一个特定的协议,处理请求和响应。过程和机器的界限以外的请求被发送这意味着客户端和服务器可以驻留在不同的机器上。
➕的优势:有一组共享和分布式服务更易于管理,修改和重用软件模块。提供互操作性平台的构建客户机-服务器应用程序可以不管,拓扑结构或技术堆栈。➖弱点:服务器超载当有太多的请求,导致性能瓶颈,可以成为一个单点故障。
一个休息(Representational State Transfer)架构是一个客户机-服务器体系结构,其中客户端是分开服务器由一个统一的界面,服务器提供了可寻址端点通过一个URL(例如)和沟通是无状态的(没有任何信息或内存从先前的请求)通过HTTP。REST api(应用程序编程接口)的行业标准是基于web的应用程序。
4⃣——面向服务的体系结构(SOA)
对于一些组织,SOA是一个垫脚石来取代独立应用程序,提供一个更灵活和敏捷环境。它提供了一组模块化服务可以彼此“交谈”来支持应用程序和它们的部署。
服务接口提供松散耦合,这意味着它们可以被称为与很少或没有知识集成是如何实现的。传统上,SOA是一个企业服务总线(enterprise service bus, ESB)的协调和控制这些服务。
➕的优势:SOA生产可互操作的、松散耦合的系统易于维护和规模,因此降低了总拥有成本(TCO)。它还允许交付软件应对市场环境变化的敏捷方法。➖弱点:实现服务集成,ESB必须监督从开始到目的地的消息,导致整体性能降低。也确定SOA系统的版本是不可能不知道服务是运行在一个快照。
并不是所有的应用程序是适合这种类型的架构如需要严格执行的情况下的响应时间。
5⃣- Microservices
microservices架构模式需要建立小的方法,专用和自包含的相互通信的服务对整个系统的工作。每个服务独立部署,从而提供一个高度的解耦,并自主发展的同时保持清晰的接口与其他/合同。
DevOps可以用来帮助一个组织从SOA过渡到Microservices,后者经常运行在容器中,使其更具有可伸缩性和便携式。
➕的优势:它促进高度可重用、维护和独立部署(单位)可测试的服务。他们提供了改进的故障隔离故障的microservice并不影响其他人的工作。通晓多种语言的api,开发人员可以很容易地根据他们的需要选择最好的技术和语言。➖弱点:复杂的服务之间的通信使测试他们的交互更加困难。需要增加工作目录、测试和修复版本兼容性。
api所提供的粒度microservices往往是不同客户的需求。在这些情况下一个API网关实现单一入口点的所有客户和处理请求以两种方式之一:要么简单路由到适当的服务,甚至策划到多个服务。
6⃣-事件驱动架构(EDA)
事件驱动架构是最常见的异步模式是围绕消息描述事件以及他们处理(即生产、检测和消费)。事件是不可变的(即他们不能更改或删除),他们命令顺序。他们用于触发或实时服务之间的通信(即服务不轮询更新但接收)。
事件可以发表在几个方面,两个最受欢迎的是:
⇾一消息队列保证交付事件到适当的消费者,或者,
⇾一代理,一个事件不目标特定收件人但允许访问的主题感兴趣的各方(即用户)。发布/订阅消息传递系统常常被描述为一个事件流体系结构。
➕的优势:提供异步通信允许排队的事件或缓冲,从而避免阻塞。在错误的情况下,失去工作是恢复了从过去的“重放”事件。依赖于代理,它可以促进的可用性、可靠性和可伸缩性。➖弱点:因为它的异步本性EDA系统必须谨慎处理不一致的或重复的事件或不兼容的版本。同时,他们不支持ACID事务。
最流行的一种实践EDACQRS(命令查询责任隔离),它允许使用不同的模型更新和读取域数据。
另一个重要的实践,处理事务的原子性事件的采购更新和删除在哪里不要直接执行的数据;相反,一个实体的状态更改保存为一系列的事件——这使得重建应用程序在任何时候的状态。
EDA是进一步标准化被动的宣言需要设计系统,这四个特点:响应性、弹性、弹性和消息驱动的。
7⃣- Serverless
上面描述的所有体系结构有一个共同点:他们的依赖的基础设施。
Serverless架构,云提供商可以轻松地管理服务器的配置按需的基础。应用程序驻留在容器和部署云。开发人员不需要担心计划服务器的资源(内存、CPU、IO),或者设计一个这样的拓扑自动结果在一个高度可用和可伸缩的应用程序,这个基本上由虚拟化的云提供商负责运行和操作管理。因此,这样的供应商通常收取顾客基于请求的总数,请求的频率在指定或一段时间内的总时间为所有的服务请求。
➕的优势从基础设施规划:自由;成本效益的定价取决于执行的数量;易于部署和持续交付。➖弱点:Serverless仍在起步阶段作为一个技术和有一个小知识基础在社区。供应商是一个高风险,从一个平台迁移到另一个地方是很困难的。调试很复杂,由于能见度的后端流程。Serverless不是有效的长时间运行的流程(专用服务器或虚拟机推荐)。
Serverless包含两个不同的但是重叠区域:
⇾函数作为服务(法斯):自定义代码运行在短暂的容器。
⇾后端服务(老板):应用程序明显依赖于第三方服务端方面(例如数据库、云存储、用户身份验证等)。
关闭笔记
不存在放之四海而皆准的架构,可以适用于每个项目理解体系结构模式的优点和缺点,和他们的一些最常见的设计决策是创造最好的设计的一个重要组成部分。还值得注意的是,这些模式并不相互排斥;事实上,他们相辅相成!
“建筑是正确的决定,你希望你能得到早期的项目。”- - -拉尔夫•约翰逊
我希望这篇文章是一个很好的起点,你的学习旅程。以下矩阵总结上面的模式探索:
感谢你的阅读!
我经常写领导、技术和数据中——如果你想看我未来的帖子请“跟随”我!
