架构师最常使用的5种架构模式及其适用场景分析

好莱坞电影中有多少情节？一些电影评论家说只有五个。您可以采用几种架构来实现应用程序？目前大多数程序都使用下面提到的五种架构之一。

在本文中，我将五种软件架构模式的优缺点以及适合场景提炼出来作为快速参考。你可以在单个系统中使用多个架构模式，它们的组合既是计算机科学，也是一门艺术。

一、分层架构

这种方法可能是最常见的方法，因为它通常围绕数据库构建，并且业务中的许多应用程序自然会倾向于将信息存储在RDBMS的表中。许多比较大的软件框架（例如Java EE，Drupal和Express）都是在这种架构下实现的，因此使用它们构建的许多应用程序自然都来自分层体系结构。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tsvei5Hg-1647603558250)(images/screenshot_1594936165234.png)]

Model-View-Controller（MVC）分层结构是大多数流行的Web框架提供的标准软件开发方法，显然是分层体系结构。数据持久层上方是服务层，它通常包含业务逻辑和有关数据库中数据类型的信息。视图层位于顶层，通常是CSS，JavaScript和带有动态嵌入式代码的HTML。在中间有一个控制层，该控制层具有用于转换在视图和模型之间移动的数据的各种规则和方法。

分层架构的优点：每个层可以只集中于自己的功能实现。这使得应用程序：

• 容易维护
• 容易单元测试
• 易于分配单独的“角色”
• 易于更新和扩展

适当的分层体系结构将开发层面进行隔离，这些层不受其他层的更改的影响，从而使重构更加容易。划分任务并定义单独的层是架构师面临的挑战。当需求很好地适应了模式时，这些层将易于解耦或分层开发。

适合：

• 需要快速构建的新应用程序
• 传统IT部门和流程的企业或业务应用程序
• 具有尚不了解其他架构的经验不足的开发人员的团队
• 需要严格的可维护性和可测试性标准的应用

二、事件驱动架构

事件驱动的体系架构根据数据生成一个“事件”，事件由“消息中间件”或“事件分发管理的中央单元”统一接收，并将事件分配特定类型的代码处理。

使用JavaScript编程网页涉及编写对诸如鼠标单击或击键之类的事件做出反应的小模块。浏览器本身会协调所有输入，并确保只有正确的代码才能得到正确的事件。浏览器中常见许多不同类型的事件，但是模块仅与相关的事件进行交互。这与分层体系结构非常不同，在分层体系结构中，所有数据通常都将穿过所有层。总体而言，事件驱动的体系结构：

• 容易适应复杂，混乱的业务环境
• 当出现新的事件类型时，很容易扩展

注意事项：

• 如果模块之间可以相互影响，则[测试可能会很复杂
• 当模块发生故障时，中央单元（或消息中间件）必须有一个事件备份计划。
• 消息传递开销可能会降低处理速度，消息中间件必须缓冲以突发形式到达的消息时。
• 当事件有非常不同的需求时，为事件开发数据结构可能会很复杂。
• 维护基于事务的一致性机制很困难，因为接收事件的模块是解耦和独立的。

适合：

• 具有异步数据流的异步系统
• 各个数据块仅与多模块中的少数模块交互的应用程序
• 用户界面

三、微内核-多插件架构

许多的应用程序都具有一组核心代码，这些代码在不同的模块下反复使用。例如，开发工具Eclipse将打开文件，批注，编辑文件并启动后台处理器。用于显示文件和对其进行编辑的代码是微内核的一部分。其他的插件扩展了Eclipse，从而扩展了其功能。

具体到解决方案就是将一些基本的核心的任务代码推入微内核。然后，不同的业务部门可以根据不同类型的声明编写插件。

注意事项：

• 确定哪些代码是微内核中的内容通常是一门艺术。它应该保留经常被使用的代码。
• 一旦许多插件依赖微内核，修改微内核可能非常困难，甚至不可能。唯一的解决方案就是修改插件。
• 为内核函数选择正确的粒度很难事先完成，也几乎不可能在后期进行更改。

适合：

• 工具类软件
• 在核心代码与边缘代码之间有清晰区分的应用程序
• 具有一组固定的核心函数和一组动态规则的应用程序

四、微服务架构

小宝宝既可爱又有趣，但是一旦变大，就很难操纵并且难以维护。微服务架构旨在帮助开发人员避免让自己的宝宝长大，笨拙，僵硬，烦人。它的目标不是创建一个大型程序，而是创建多个不同的小型程序。避免修改一个小bug，就需要重新部署整个大型应用的情况出现。

这种方法类似于事件驱动和微内核方法，但是主要用于解耦不同模块及任务。在许多情况下，不同的任务可能需要不同的处理量，并且用途可能会有所不同。所以微服务的特点是便于修改、便于扩展。使用负载均衡及服务发现的机制，在用户使用高峰期部署更多的微服务，保证服务的高可用；在用户低频服务时段缩减微服务，从而节省服务器资源。

注意事项：

• 并非所有应用程序都可以拆分为相对独立的微服务单元。
• 当任务分散在不同的微服务之间时，通信成本会更大。单个请求的响应时长会增加。

适合：

• 快速发展新业务团队
• 大型Web应用程序

五、高速缓存架构

许多网站都是围绕数据库构建的，只要数据库能够满足负载，它们就可以正常运行。但是当使用量达到顶峰，并且数据库无法跟上用户请求的速度时，整个网站就会瘫痪。将数据存储在内存中可以使许多工作更快，从而大幅度提高用户并发访问的支撑能力。

注意事项：

• 对于内存数据库，事务的支持更加困难。
• 开发专业的高速缓存数据的程序，对程序员的技术水平往往要求更高一些（至少比只会写增删改查的程序员要高）

适合：

• 高频点击数据流和用户日志之类的大量数据处理
• 低价值数据，有时可能会丢失而不会造成重大后果（比如用户访问量数据）
• 读多写少的数据。比如新闻数据，写完之后几乎不改，但是有很多的人看。

文章来源: zimug.blog.csdn.net，作者：字母哥哥，版权归原作者所有，如需转载，请联系作者。

原文链接：zimug.blog.csdn.net/article/details/107423214