文章目录
前言一、分层架构1.1基本模型1.2优缺点分析二、事件驱动架构2.1基本模型2.2简化模型2.3作用机理2.4优缺点分析2.5评价三.微服务架构3.1基本模型3.2作用机理3.3优缺点分析3.4 评价四. 总结前言
回顾几十年以来计算机应用软件的演变过程，应用程序逐渐由单层体系结构发展为多层体系结构。最初的应用软件只是在大型机上的单层应用，大都采用文件系统存储数据。20世纪70年，随着数据库的普及，原来的单层结构发展为双层结构，即应用层和数据库层，这种方式实现了数据存放与应用程序的分离。但是，负责用户界面交互的代码与业务逻辑混杂在一起，小的系统尚可维护，一旦上升到企业级应用，长期的维护就成了一件十分困难的事情。因此，三层体系结构应运而生，在三层结构中，把原来的应用程序层分成了视图层(UI)和业务逻辑层，数据库层保持不变，进一步解耦了应用程序开发工作。
今天的应用系统，正在产生、收集以及处理前所未有的不断增加的数据，它们正在应对高度复杂的处理流程，并且往往要在跨越典型组织界限的系统和设备之间集成。在这一背景下，一方面应用系统功能体系越发复杂，另一方面其对于可靠性、安全性、可扩展性(如服务器扩容)、可定制化(同一套软件，可根据用户群体的不同和市场需求的变化进行调整)、可伸缩(在新的技术出现时，一个软件应允许导入新的技术，从而对现有系统进行功能和性能扩展)、可维护性(排除现有错误，加入新的功能)、客户体验以及开发效率要求也在不断提升，单纯的层次结构已不能完全满足要求，一些全新的架构被设计出来，用以满足不同场景的软件设计需求，如事件驱动架构、微服务架构、云架构等。本文仅选择分层架构、事件驱动架构、微服务架构进行简要介绍与分析。
一、分层架构
分层架构，是最常见的软件架构。这种架构将应用分成若干个水平层，每一层都有明确的角色和分工，不需要知道其他层的细节，层与层之间通过API通信。
1.1基本模型
分层架构中，层数并没有明确的标准，但四层结构最为常见，如下图所示，从上到下依次为：
表现层（presentation）：用户界面，负责视觉和用户互动业务层（business）：实现业务逻辑持久层（persistence）：提供数据，SQL 语句就放在这一层数据库（database） ：保存数据
有的软件在逻辑层和持久层之间增加了一个服务层(service)，提供不同业务逻辑需要的一些通用接口。采用分层架构的软件在运行时，用户请求将依次通过4层，不能跳过其中任何一层。
1.2优缺点分析
优点
结构简单，容易理解和开发不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构每一层都可以独立测试，其他层的接口通过模拟解决
缺点
一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布软件升级时，可能需要整个服务暂停扩展性差。用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难
二、事件驱动架构
对于事件驱动架构（event-driven architecture,EDA）事件的捕获、通信、处理和持久保留是解决方案的核心，这点和传统的请求驱动模型有很大不同。许多现代应用设计都是由事件驱动的，例如必须实时利用客户数据的客户互动框架。事件驱动应用可以用任何一种编程语言来创建，因为事件驱动本身就是一种编程方法。
事件是指系统硬件或软件的状态出现任何重大改变，而事件的来源可能是内部也可能是外部。事件可以来自用户(例如点击鼠标或按键)、外部源(例如传感器输出)或系统(例如加载程序)。
2.1基本模型
事件驱动架构分成四个部分。
事件队列（event queue）：接收事件的入口分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元事件通道（event channel）：分发器与处理器之间的联系渠道事件使用者(事件处理器)（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作。
事件驱动架构定义了事件发起者和事件使用者两个角色。事件发起者会检测或感知事件，将其加入事件队列，以消息的形式来表示事件，利用分发器判断使用者(根据使用者订阅信息)，并通过事件通道传输给事件使用者(事件处理器)，而事件使用者则会在该通道中以异步方式处理事件。事件发生时，事件使用者可能会处理事件，也可能只是受事件的影响。
事件驱动架构可以最大程度减少耦合度，因为事件发起者并不知道哪个事件使用者在监听事件，也不知道事件引起的后续结果。
2.2简化模型
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件发起者、事件代理和使用者(事件处理器)三部分。
2.3作用机理
事件驱动架构有两种实现模型：
1）发布/订阅模型
这是一种基于事件流订阅的消息传递基础架构。对于该模型而言，在事件发生或公布之后，系统会将相应的消息发送给需要通知的订阅用户。
2）事件流模型
借助事件流模型，事件将被写入日志。事件使用者无需订阅事件流。相反，它们可以从流的任何部分读取并随时加入流。
事件流有几种不同的类型：
事件流处理。使用诸如 Apache Kafka 等数据流平台来提取事件并处理或转换事件流。事件流处理可用于检测事件流中有用的模式。简单事件处理。指事件立即在事件使用者中触发操作。复杂事件处理。需要事件使用者处理一系列事件以检测模式。
2.4优缺点分析
优点
分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好适用性广，各种类型的项目都可以用性能较好，因为事件的异步本质，软件不易产生堵塞事件处理器可以独立地加载和卸载，容易部署
缺点
涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚分布式和异步特性导致这个架构较难测试
2.5评价
事件驱动架构是一种具有高可扩展性的架构，能够有效增加系统应变能力。此架构中，事件发布者和事件代理实际上构建了一个事件信息权威数据源平台，事件处理器以异步的方式从这个平台中获取所需要的数据并采取相关措施，实现业务目标。其优点是事件处理器可以相互解耦，稳定性高；企业可根据需求变化实时增加、删除、修改事件处理器，灵活性高。设计重点是需要支持高数据吞吐量，需考虑数据传输中出错的情况，需以极快的速度完成事件数据分发和处理降低系统延迟，因此分布式、容错、高容量和高速的事件代理是系统性能的关键。此框架适用范围很广，比如物联网(IoT)、数字孪生体(DW)等需数据实时获取、传递和分析处理的系统实现。
三.微服务架构
微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级，既是一种架构，也是一种软件构建方法。微服务采用分布式、松散耦合结构，各服务之间不会相互影响这对于动态可扩展性和容错能力都有一定的好处。
3.1基本模型
在此架构中，应用程序被拆分成最小的组件，彼此独立。其中每一个组件或流程都是一个独立的部署单元（separately deployed unit），互相解耦，通过远程通信协议（比如REST、SOAP）联系，并提供相应的功能服务。
3.2作用机理
RESTful API 模式：服务通过 API 提供，云服务就属于这一类RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部。集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。一个典型的网站微服务架构如下图所示
3.3优缺点分析
优点
扩展性好，各个服务之间低耦合容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级易于测试，可以单独测试每一个服务
缺点
由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。
3.4 评价
微服务与事件驱动框架有区别，但在我看来不明显。微服务与事件驱动框架都属分布式框架，具有低耦合、高容错的优势，事件驱动框架存在消息代理，通过消息流传递数据，典型微服务框架则没有消息代理，但实际应用中也有采用消息代理的情况，如3.2节中所述“集中消息”模式。
四. 总结
以上就是今天要讲的内容，本文简单介绍了三种典型应用软件框架的基本模型，并对其特点进行简析。必须注意到，应用架构既是软件设计方法，也是开发编程方法，一套应用程序可以采用一种架构作为主架构，但其中的功能模块也可根据实际需要采用不同的架构。
架构与应用开发目标，是形式与内容的关系，内容决定形式，形式反过来有利于内容更好地呈现。在实际开发中，当我们在决定新应用的架构或评估当前的架构时，首先一定要分析并确定我们的开发目标是什么，包括应用场景、市场环境、用户需求，设计团队能力边界等，然后再选择合适的应用架构，而不是先选择架构再尝试让应用来适应该架构。
这里是参考文献
[link] /zh/topics/cloud-native-apps/what-is-an-application-architecture
[link] /doit8791/p/9343826.html
