好莱坞电影有多少情节？一些影评人说只有五部。您可以在多少种架构中实施您的应用程序？今天的大多数程序都使用下面提到的五种体系结构中的一种。在本文中，我提炼了五种软件架构模式的优缺点，以及适合的场景，以供快速参考。您可以在单个系统中使用多种架构模式，它们的组合既是一门艺术，也是一门计算机科学。1.分层架构这种方法可能是最常见的，因为它通常围绕数据库构建，并且业务中的许多应用程序自然倾向于将信息存储在RDBMS的表中。许多较大的软件框架（如JavaEE、Drupal和Express）都是在这种架构下实现的，因此使用它们构建的许多应用程序自然来自分层架构。模型-视图-控制器(MVC)分层结构是大多数流行的Web框架提供的标准软件开发方法，并且显然是分层架构。数据持久层之上是服务层，它通常包含业务逻辑和有关数据库中数据类型的信息。视图层位于顶部，通常是带有动态嵌入代码的CSS、JavaScript和HTML。中间有一个控制层，其中包含用于转换在视图和模型之间移动的数据的各种规则和方法。分层架构的优点：每一层只能专注于自己的功能实现。这使得应用程序：易于维护易于单元测试易于分配单独的“角色”易于更新和扩展适当的分层架构将开发层与其他层的更改隔离开来，使重构更容易。划分任务和定义单独的层对架构师来说是一个挑战。当需求非常适合模式时，这些层很容易解耦或分层开发。适用于：需要快速构建的新应用程序具有传统IT部门和流程的企业或业务应用程序尚不了解其他架构的缺乏经验的开发人员团队需要严格的可维护性和可测试性标准的应用程序驱动架构事件驱动架构生成一个基于数据的“事件”，事件统一由“消息中间件”或“事件分发管理中心单元”接收，并分配给特定类型的代码进行处理。使用JavaScript对网页进行编程涉及编写对鼠标单击或击键等事件做出反应的小模块。浏览器本身协调所有输入并确保只有正确的代码才能获得正确的事件。许多不同类型的事件在浏览器中很常见，但模块只与相关事件交互。这与所有数据通常都会通过所有层的分层架构非常不同。总体而言，事件驱动架构：轻松适应复杂、混乱的业务环境易于在出现新事件类型时进行扩展注意事项：[如果模块可以相互影响，测试可能会很复杂如果发生故障，中央单元（或消息中间件）必须有一个事件备份计划。当消息传递中间件必须缓冲突发到达的消息时，消息传递开销会减慢处理速度。当事件具有非常不同的需求时，为事件开发数据结构可能会很复杂。维护基于事务的一致性机制是困难的，因为接收事件的模块是解耦和独立的。适用于：具有异步数据流的异步系统应用程序用户界面，其中单个数据块仅与多个模块中的少数几个交互3.微内核-多插件架构许多应用程序都有一组核心代码，驻留在不同的模块下重复使用。例如，开发工具Eclipse会打开文件、注释、编辑文件并启动后台处理器。显示文件和编辑文件的代码是微内核的一部分。其他插件扩展了Eclipse，从而扩展了它的功能。具体的解决方案是将一些基础的核心任务代码推送到微内核中。然后，不同的业务部门可以根据不同类型的声明编写插件。注意事项：确定微内核中的代码通常是一门艺术。它应该保留经常使用的代码。一旦许多插件依赖于微内核，即使不是不可能，修改微内核也是非常困难的。唯一的解决办法是修改插件。为内核函数选择正确的粒度很难预先完成，以后几乎不可能更改。适用于：工具软件核心代码和边缘代码区分明确的应用有一套固定的核心功能和一套动态规则的应用4.微服务架构小宝宝很可爱很好玩，但是一旦长大就难了操纵和难以维护。微服务架构旨在帮助开发人员避免让他们的婴儿长大后变得笨拙、僵硬和烦人。它的目标不是创建一个大程序，而是创建多个不同的小程序。避免需要重新部署整个大型应用程序来修复一个小错误。这种方法类似于事件驱动和微内核方法，但主要用于解耦不同的模块和任务。在许多情况下，不同的任务可能需要不同的处理量，并且可能用于不同的目的。因此，微服务具有易于修改和扩展的特点。利用负载均衡和服务发现机制，在用户使用高峰期部署更多的微服务，保证服务的高可用；在低频用户服务时段减少微服务，节省服务器资源。注意：并不是所有的应用都可以拆分成相对独立的微服务单元。当任务分布在不同的微服务中时，通信成本甚至更高。个别请求的响应时间增加。适合：快速开发新业务团队大型Web应用5.缓存架构很多网站都是围绕数据库构建的，只要数据库跟得上负载就可以正常运行。但是当使用量达到顶峰时，数据库跟不上用户请求，整个站点就会崩溃。将数据存储在内存中可以让很多任务更快，从而大大提高用户并发访问的支持能力。注意：对于内存数据库，事务支持比较困难。开发专业的缓存数据程序，往往对程序员的技术水平要求更高（至少比只会写增删改查的程序员要高）。适用于：高频点击数据流和用户日志等大量数据处理有时会丢失但不会造成重大后果的低价值数据（如用户访问数据）读多写少的数据。例如，新闻数据写入后几乎没有变化，但有很多人阅读它。
