【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

针对架构设计的几个痛点,我总结出的架构原则和模式

  • 2016-03-29
  • 本文字数:4065 字

    阅读完需:约 13 分钟

【编者的话】本文来自 Firat Atagun 的《架构演化中的软件设计原则》,文中给出了软件架构演化过程中出现的 4 种经典架构,就每种架构,分析了其主要特点并在几个度量维度给出结论。在文章的最后,Firat Atagun 给出了 4 种架构的多维对比。本文的完整演讲稿是架构演化中的软件设计原则

1 分层架构

分层架构是最常见的架构,也被称为 n 层架构。多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师、开发者和软件设计者所熟知。

分层架构中的层次和组件是水平方向的分层,每层扮演应用程序中特定的角色。根据需求和软件复杂度,我们可以设计 N 层,但大多数应用程序使用 3-4 层。有太多层的设计会很糟糕,将导致复杂度的上升,因为我们必须维护每一层。在传统的分层架构中,分层包括表现层、业务或者服务层,以及数据访问层。 表现层负责应用程序的用户交互和用户体验(外观和视觉)。通常我们会使用 ** 数据传输对象(Data Transfer Object)将数据带到这一层,然后使用视图模型(View Model)** 渲染到客户端。业务层接收请求并执行业务规则。数据访问层负责操作各种类型的数据库,每个访问数据库的请求都要经过这一层。

分层无需知道其他层如何去做,比如业务层无需知道数据访问层是如何查询数据库的,相反,业务层在调用数据层的特定方法时,只需关注需要部分数据还是全部数据。这就是我们所说的关注点分离。这是非常强大的功能,每层负责其所负的责任。

分层架构中的核心概念是管理依赖。如果我们使用依赖倒置原则和测试驱动开发 (Test Driven Development),我们的架构会有更好的健壮性。因为,我们要保证所有可能的用例都有测试用例。

我们需要这样的冗余,即使业务层没有处理业务规则,也要通过业务层来调用数据层,这叫分层隔离。对于某些功能,如果我们从表现层直接访问数据层,那么数据层后续的任何变动都将影响到业务层和表现层。

分层架构中的一个重要的概念就是分层的开闭原则。如果某层是关闭的,那么每个请求都要经过着一层。相反,如果该层是开放的,那么请求可以绕过这一层,直接到下一层。

分层隔离有利于降低整个应用程序的复杂度。某些功能并不需要经过每一层,这时我们需要根据开闭原则来简化实现。

分层架构是 SOLID 原则的通用架构,当我们不确定哪种架构更合适的时候,分层架构将是一个很好的起点。我们需要注意防止架构陷入污水池反模式。这种反模式描述了请求经过分层,但没做任何事或者只处理了很少的事。如果我们的请求经过所有分层而没有做任何事,这就是污水池反模式的征兆。如果 20% 的请求只是经过各层,而 80% 的请求实际做事,这还好,如果这个比率不是这样的,那么我们已经患上反模式综合征

此外,分层架构可以演变为巨石应用(Monolith),导致代码库难以维护。

分层架构分析:

  • 敏捷性:总体敏捷性是指对不断变化的环境作出反应的能力。由于其整体风格(Monolith)的性质,可能会变得难以应对通过所有层的变化,开发者需要注意依赖性和分层分离。
  • 易于部署:大型应用程序的部署会是个麻烦。一个小要求,可能需要部署整个应用程序。如果能做好持续交付,可能会有所帮助。
  • 可测试性:使用 Mocking 和 Faking,每一层可以独立测试,因此测试上很容易。
  • 性能:虽然分层应用程序可能表现良好,但是因为请求需要经过多个分层,可能会存在性能问题。
  • 可伸缩性:因为耦合太紧以及整体风格(Monolith)的天生特质,很难对分层应用程序进行伸缩。然而,如果分层能够被构建为独立的部署,还是可以具备伸缩能力的。但是,这样做的代价可能很昂贵。
  • 易于开发:这种模式特别易于开发。许多企业采用这种模式。大多数开发者也都知道、了解,并且可以轻松学习如何使用它。

2 事件驱动架构

事件驱动架构(Event Driven Architecture)是一种流行的分布式异步架构模式,用于创建可伸缩的应用程序。这种模式是自适应的,可用于小规模或者大规模的应用程序。事件驱动架构可以与 ** 调停者拓扑(Mediator Topology)或者代理者拓扑(Broker Topology)** 一起使用。理解拓扑的差异,为应用程序选择正确的拓扑是必不可少的。

调停者拓扑

调停者拓扑需要编排多种事件。比如在交易系统中,每个请求流程必须经过特定的步骤,如验证、订单、配送,以及通知买家等。在这些步骤中,有些可以手动完成,有些可以并行完成。

通常,架构主要包含 4 种组件,事件队列(Event Queue)、调停者(Mediator)、事件通道(Event Channel)和事件处理器(Event Processor)。客户端创建事件,并将其发送到事件队列,调停者接收事件并将其传递给事件通道。事件通道将事件传递给事件处理器,事件最终由事件处理器处理完成。

事件调停者不会处理也不知道任何业务逻辑,它只编排事件。事件调停者知道每种事件类型的必要步骤。业务逻辑或者处理发生在事件处理器中,事件通道、消息队列或者消息主题用于传递事件给事件处理器。事件处理器是自包含和独立的,解耦于架构。理想情况下,每种事件处理器应只负责处理一种事件类型。

通常,企业服务总线、队列或者集线器可以用作事件调停者。正确选择技术和实现能够降低风险。

代理者拓扑

不像调停者拓扑,代理者拓扑不使用任何集中的编排,而是在事件处理器之间使用简单的队列或者集线器,事件处理器知道处理事件的下一个事件处理器。

因其分布式和异步的性质,事件驱动架构的实现相对复杂。我们需要面对很多问题,比如网络分区、调停者失败、重新连接逻辑等。由于这是一个分布式且异步的模式,如果你需要事务,那就麻烦了,你得需要一个事务协调器分布式系统中的事务非常难以管理,很难找到标准的工作单位模式。

另一个充满挑战的概念是契约。架构师声称服务的契约应该预先定义,而应变是非常昂贵的。

事件驱动架构分析

  • 敏捷性:由于事件和事件处理器之间解耦,并且可独立维护,因此这种模式的敏捷性很高。变化可以快速、轻松地完成,而不会影响整个系统。
  • 易于部署:由于架构是解耦的,因此很容易部署。组件可以独立部署,并且可以在调停者上注册。部署在代理者拓扑上也相当简单。
  • 可测试性:虽然独立测试组件很容易,但测试整个应用程序很有挑战。因此端到端的测试是很难的。
  • 性能:事件驱动架构性能非常好,因为它是异步的。此外,事件通道和事件处理器可以并行工作,因为它们是解耦的。
  • 可伸缩性:事件驱动架构的伸缩性非常好,因为组件之间解耦,组件可以独立扩展。
  • 易于开发:这种架构的开发不是很容易。需要明确定义契约,错误处理和重试机制得处理得当。

3 微内核架构

微内核架构(Microkernel architecture)模式也被称为插件架构(plugin architecture)模式。这是产品型应用程序的理想模式,由两部分组成:核心系统插件模块。核心系统通常包含最小的业务逻辑,并确保能够加载、卸载和运行应用所需的插件。许多操作系统使用这种模式,因此得名微内核。

插件彼此独立,因此解偶。核心系统持有注册器,插件将自己注册其上,因此核心系统知道哪里可以找到它们以及如何运行它们。

这种模式非常适合桌面应用程序,但是也可以在 Web 应用程序中使用。事实上,许多不同的架构模式可以作为整个系统的一个插件。对于产品型应用程序来说,如果我们想将新特性和功能及时加入系统,微内核架构是一种不错的选择。

微内核架构分析

  • 敏捷性:由于插件可以独立开发并注册到核心系统,微内核架构具有很高的敏捷性。
  • 易于部署:依赖于核心系统的实现,能做到不需要重新启动整个系统来完成部署。
  • 可测试性:如果插件开发是独立的,测试就可以独立且隔离地进行。还可以 Mock 核心系统来测试插件。
  • 性能:这取决于我们有多少插件在运行,但性能可以调优。
  • 可伸缩性:如果整个系统被部署为单个单元,这个系统将难以扩展。
  • 易于开发:这种架构不容易开发。实现核心系统和注册会很困难,而且插件契约和数据交换模型增加了难度。

4 微服务架构

尽管微服务的概念还相当新,但它确实已经快速地吸引了大量的眼球,以替代整体应用和面向服务架构(SOA)。其中的一个核心概念是具备高可伸缩性、易于部署和交付的独立部署单元(Separately Deployable Units)。最重要的概念是包含业务逻辑和处理流程的服务组件(Service Component)。拿捏粒度设计服务组件是必要而具有挑战性的工作。服务组件是解耦的、分布式的、彼此独立的,并且可以使用已知协议来访问。

微服务的发展是因为整体应用和面向服务应用程序的缺陷。整体应用程序通常包含紧耦合的层,难以部署和交付。比如,如果应用程序总在每次应对变化时垮掉,这是一个因耦合而产生的大问题。微服务将应用程序分解为多个部署单元,因此很容易提升开发和部署能力,以及可测性。虽然面向服务架构非常强大,具有异构连接和松耦合的特性,但是性价比不高。它很复杂、昂贵,难于理解和实现,通常对于大多数应用程序来说矫枉过正。微服务简化了这种复杂性。

跨服务组件的代码冗余是完全正常的。开发微服务时,为了受益于独立的部署单元,以及更加容易的部署,我们可以违反 DRY 原则。其中的挑战来自服务组件之间的契约,以及服务组件的可用性。

微服务架构分析

  • 敏捷性:由于服务组件可以各自独立开发,彼此没有耦合,因此微服务架构具有很高的敏捷性。独立部署单元能够对变化作出迅速的反应。
  • 易于部署:相比其他的架构模式,微服务的优势是服务组件即是单独部署单元。
  • 可测试性:服务组件的测试可以独自完成。微服务的可测试性很高。
  • 性能:依赖于服务组件和这种特定模式的分布式性质。
  • 可伸缩性:独立部署单元天然具备很好的伸缩性。
  • 易于开发:每个服务组件可以各自独立实现。

编后语

《博文共赏》是 InfoQ 中文站新推出的一个专栏,精选来自国内外技术社区和个人博客上的技术文章,让更多的读者朋友受益,本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。

原文英文链接: http://www.firatatagun.com/blog/2016/01/09/analysis-of-software-architectures


感谢郭蕾对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-03-29 17:5518781

评论

发布
暂无评论
发现更多内容

裸辞在家闭关修炼,意外发现一份据说是从阿里内部泄露出来的《Java程序员金三银四面试秘籍》

Java架构之路

Java 程序员 架构 面试 编程语言

MySQL常用引擎及优缺点

Sakura

4月日更

【全网首发】2021年移动开发iOS进阶提升方案,内附详细视频知识点解析和思维导图!【强烈建议收藏!】

flutter swift 数据结构与算法 ios开发 iOS逆向

一天下载量突破9000000!限时分享:阿里Java架构师成长笔记(2021版)

比伯

Java 架构 面试 程序人生 计算机

全球案例 | 霍尼韦尔:Atlassian 帮助我们在疫情期间拯救生命

Atlassian

敏捷 Atlassian Jira 远程协作 霍尼韦尔

裸辞还可以吊打大厂面试官?四面拿到阿里、字节offer后我还是选择了美团!

Java架构师迁哥

疫情影响到底有多大?《2020年移动互联网报告》深度解读垂直行业变化趋势

Lily

聪明人的训练(二十)

Changing Lin

4月日更

低代码:正在改变软件的开发方式

华为云开发者联盟

软件开发 低代码 低代码平台 华为云应用魔方 AppCube

三色标记原理,我给应聘者问懵了...

华为云开发者联盟

Java 节点 三色标记 SATB算法 回收器

Rust从0到1-枚举-if let控制流

rust 枚举 if let

抢购倒计时自定义控件的实现与优化

vivo互联网技术

动画 安卓 自定义控件 倒计时

计算机原理学习笔记Day11

穿过生命散发芬芳

计算机原理 4月日更

面试加分项!为了跳槽强刷1000道Android真题,附小技巧

欢喜学安卓

android 程序员 面试 移动开发

GitHub开源:100美元自制激光雷达

不脱发的程序猿

GitHub 开源 DIY 4月日更 激光雷达

iMazing 一款替代iTunes的数据备份软件

懒得勤快

ios Mac imazing 手机管理

这几道面试题,难倒了牛客网98%的程序员,刷完后直接斩获9个大厂offer

Java架构师迁哥

多源数据即席查询Trino(Presto)引擎剖析

小舰

4月日更

神级Android进阶笔记!一次关于JVM的面试经历,建议收藏

欢喜学安卓

android 程序员 面试 移动开发

华为云PB级数据库GaussDB(for Redis)揭秘第八期:用高斯 Redis 进行计数

华为云开发者联盟

redis GaussDB(for Redis) 计数器 计数

我很久没写代码了,但我是个好架构师

四猿外

Java 程序员 系统架构 架构师 代码

破十亿浏览量的阿里最新Java架构师成长笔记开源!

Java架构追梦

Java 阿里巴巴 架构 面试 成长笔记

【只要努力,方能成功。】四面字节跳动Java研发岗,成功斩获Offer。分享4面技术面真题及复习资料!

Java架构之路

Java 程序员 架构 面试 编程语言

【签约计划】行业分析能力考核成绩公布

InfoQ写作社区官方

签约计划 热门活动

阿里员工:最惨P7,33岁才28K,感觉没有前途了。网友调侃:最美逆行者

程序员生活志

凡尔赛?拿到阿里offer只用了29天?

Java架构师迁哥

Redis持久化方案介绍之RDB方案

大数据技术指南

redis 4月日更

架构实战营 - 模块 2- 总结

吴建中

架构实战营

Linux tree命令

一个大红包

Linux linux命令 4月日更

腾讯万字Code Review规范出炉!别再乱写代码了

程序员生活志

《专访阿里研究员吴翰清:大数据时代下,如何保障网络安全和用户隐私》(采访提纲)

三掌柜

调查采访能力考核

针对架构设计的几个痛点,我总结出的架构原则和模式_架构_韩陆_InfoQ精选文章