事件驱动型流程引擎（事件驱动技术）

本篇文章给大家谈谈事件驱动型流程引擎，以及事件驱动技术对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享事件驱动型流程引擎的知识，其中也会对事件驱动技术进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、事件驱动是什么
• 2、谁能给我讲讲java中的请求驱动和事件驱动？
• 3、传统过程化的应用程序和事件驱动的应用程序有什么区别?
• 4、软件的系统架构和开发平台都有哪些？具体都有哪几种呢？
• 5、什么是VB的事件驱动
• 6、SpringBoot核心原理：自动配置、事件驱动、Condition

事件驱动是什么

其实以前的开发一直都是事件驱动,只是那时候并没有太过细分,除了事件还有数据驱动,对象驱动,接口驱动,委托驱动,只是随着现在的一些优化框架越来越完善,针对某些流程进行了特定优化,所以事件驱动也就演化来了,但事件驱动并不是说就没有其他驱动的影子,只是一种设计理念和编码方向,使代码更容易维护,具体表现就是:把所有的加载,跳链一些业务处理,写成事件的形式,尽量避免页面初始化加载,以此达到快速生成展示页面,减少用户等待数据的时间,之后由用户来驱动事件,决定要展示什么!所以我们编程时要将所有的内容放在事件里,而事件一般由某些特定框架制定,比如react的事件,并非我们js中写的那种初级事件.这些事件是动态生成的,而非事先写好的,避免无关项加载

谁能给我讲讲java中的请求驱动和事件驱动？

什么是事件驱动模型?
在讲解事件驱动模型之前，我们现在看看事件驱动模型的三大要素：
·事件源：能够接收外部事件的源体。
·侦听器：能够接收事件源通知的对象。
·事件处理程序：用于处理事件的对象。
学员应该要理解任何基于事件驱动模型的开发技术都包含以上三大要素，不管是.net还是java技术，甚至是以前我们使用的Visual Basic和Delphi语言都有基于以上三大要素的事件驱动模型开发流程。
现在我们来看一个生活中的示例，假如有一天你走在路上一不小心被天上掉下来的花瓶砸到了，并且晕死了过去。那么整个过程其实就是一个事件处理流程，而且我们可以非常方便的分析出刚才所提到的事件驱动模型中的三大要素。
1.被砸晕的这个人其实就是事件源，因为他是能够接受到外部的事件的源体。
2.侦听器就是这个人的大脑神经，因为它会感知到疼痛。
3.事件处理就是这个人晕死了过去。
由于事件驱动模型在我们日常生活中是无处不在的，因此Java和其他的编程语言都将这一过程运用到了可视化编程中了。

传统过程化的应用程序和事件驱动的应用程序有什么区别?

传统的MS-DOS程序主要采用顺序的、关联的、过程驱动的程序设计方法。一个程序是一系列预先定义好的操作序列的组合，它具有一定的开头、中间过程和结束。程序直接控制程序事件和过程的顺序。这样的程序设计方法是面向程序而不是面向用户的，交互性差，用户界面不够友好，因为它强迫用户按照某种不可更改的模式进行工作。
2\事件驱动程序设计是一种全新的程序设计方法，它不是由事件的顺序来控制，而是由事件的发生来控制，而这种事件的发生是随机的、不确定的，并没有预定的顺序，这样就允许程序的的用户用各种合理的顺序来安排程序的流程。
对于需要用户交互的应用程序来说，事件驱动的程序设计有着过程驱动方法无法替代的优点。
它是一种面向用户的程序设计方法，它在程序设计过程中除了完成所需功能之外，更多的考虑了用户可能的各种输入，并针对性的设计相应的处理程序。
它是一种“被动”式程序设计方法，程序开始运行时，处于等待用户输入事件

软件的系统架构和开发平台都有哪些？具体都有哪几种呢？

一、软件的系统架构

（一）、分层架构

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

表现层（presentation）：用户界面，负责视觉和用户互动

业务层（business）：实现业务逻辑

持久层（persistence）：提供数据，SQL 语句就放在这一层

数据库（database） ：保存数据

有的软件在逻辑层和持久层之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

用户的请求将依次通过这四层的处理，不能跳过其中任何一层。

（二）事件驱动架构

事件（event）是状态发生变化时，软件发出的通知。

事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

事件队列（event queue）：接收事件的入口

分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元

事件通道（event channel）：分发器与处理器之间的联系渠道

事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

（三）微核架构

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

（四）、微服务架构

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

（五）、云架构

云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。

处理单元：实现业务逻辑

虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

二、开发平台

ERP平台、金融电商平台、小程序平台、网站平台、bpm平台、低代码开发平台等等；
厂家有天翎、顶点、天纵、清流、K2等
开发语言有区分：dephp、java。net等；

三、如何选择合适的开发平台?
平台的选型，无非是从客户业务需求的角度，以及对应的品牌形象和案例沉淀几个角度去选择；
建议可以开箱即用，多试用几次，就找到适合的产品，通俗的说，就是货比三家。
管理顾问，每天成长一点点，努力成就自己的优秀。

什么是VB的事件驱动

以下是我在MSDN中摘录的文字，希望对你有帮助。你可以自己编几个小程序来体验一下。
正文开始：
Visual Basic 概念
为了理解应用程序开发过程，先要理解 Visual Basic 赖以创建的一些关键概念。因为 Visual Basic 是 Windows 开发语言，所以有必要与 Windows 环境保持一定的相似性。如果不熟悉 Windows 编程，就需要明白在 Windows 环境下编程和在其它环境下编程的一些根本性的差别。
Windows 的工作方式：窗口、事件和消息
全面地讨论 Windows 的内部工作机制将需要整整一本书的容量。没有必要深入了解所有的技术细节。Windows 的工作机制，简单地说就是三个关键的概念：窗口、事件和消息。
不妨简单地将窗口看做带有边界的矩形区域。也许已经了解几种不同类型的窗口：如，Windows 95 的“资源管理器”窗口、文字处理程序中的文档窗口或者弹出提示有约会信息的对话框。除了这些最普通的窗口外，实际上还有许多其它类型的窗口。命令按钮是一个窗口。图标、文本框、选项按钮和菜单条也都是窗口。
Microsoft Windows 操作系统通过给每一个窗口指定一个唯一的标识号（窗口句柄或 hWnd）来管理所有的窗口。操作系统连续地监视每一个窗口的活动或事件的信号。事件可以通过诸如单击鼠标或按下按键的操作而产生，也可以通过程序的控制而产生，甚至可以由另一个窗口的操作而产生。
每发生一次事件，将引发一条消息发送至操作系统。操作系统处理该消息并广播给其它窗口。然后，每一个窗口才能根据自身处理该条消息的指令而采取适当的操作（例如，当窗口解除了其它窗口的覆盖时，重显自身窗口）。
可以想象，处理各种窗口、事件和消息的所有可能的组合将有惊人的工作量。幸运的是，Visual Basic 使您摆脱了所有的低层消息处理。许多消息由 Visual Basic 自动处理了，其它的作为事件过程由编程者自行处理。这样可以快速创建强大的应用程序而毋需涉及不必要的细节。
事件驱动模型
在传统的或“过程化”的应用程序中，应用程序自身控制了执行哪一部分代码和按何种顺序执行代码。从第一行代码执行程序并按应用程序中预定的路径执行，必要时调用过程。
在事件驱动的应用程序中，代码不是按照预定的路径执行－而是在响应不同的事件时执行不同的代码片段。事件可以由用户操作触发、也可以由来自操作系统或其它应用程序的消息触发、甚至由应用程序本身的消息触发。这些事件的顺序决定了代码执行的顺序，因此应用程序每次运行时所经过的代码的路径都是不同的。
因为事件的顺序是无法预测的，所以在代码中必须对执行时的“各种状态”作一定的假设。当作出某些假设时（例如，假设在运行来处理某一输入字段的过程之前，该输入字段必须包含确定的值），应该组织好应用程序的结构，以确保该假设始终有效（例如，在输入字段中有值之前禁止使用启动该处理过程的命令按钮）。
在执行中代码也可以触发事件。例如，在程序中改变文本框中的文本将引发文本框的 Change 事件。如果 Change 事件中包含有代码，则将导致该代码的执行。如果原来假设该事件仅能由用户的交互操作所触发，则可能会产生意料之外的结果。正因为这一原因，所以在设计应用程序时理解事件驱动模型并牢记在心是非常重要的。
交互式开发
传统的应用程序开发过程可以分为三个明显的步骤：编码、编译和测试代码。但是 Visual Basic 与传统的语言不同，它使用交互式方法开发应用程序，使三个步骤之间不再有明显的界限。
在大多数语言里，如果编写代码时发生了错误，则在开始编译应用程序时该错误就会被编译器捕获。此时必须查找并改正该错误，然后再次进行编译，对每一个发现的错误都要重复这样的过程。Visual Basic 在编程者输入代码时便进行解释，即时捕获并突出显示大多数语法或拼写错误。看起来就象一位专家在监视代码的输入。
除即时捕获错误以外，Visual Basic 也在输入代码时部分地编译该代码。当准备运行和测试应用程序时，只需极短时间即可完成编译。如果编译器发现了错误，则将错误突出显示于代码中。这时可以更正错误并继续编译，而不需从头开始。
由于 Visual Basic 的交互特性，因此可以发现在开发应用程序时，您自己正频繁地运行着您的应用程序。通过这种方式，代码运行的效果可以在开发时进行测试，而不必等到编译完成以后.
===============================================================
事件驱动应用程序的工作方式
事件是窗体或控件识别的动作。在响应事件时，事件驱动应用程序执行 Basic 代码。Visual Basic 的每一个窗体和控件都有一个预定义的事件集。如果其中有一个事件发生，而且，在关联的事件过程中存在代码，则 Visual Basic 调用该代码。
尽管 Visual Basic 中的对象自动识别预定义的事件集，但要判定它们是否响应具体事件以及如何响应具体事件则是编程的责任了。代码部分（即事件过程）与每个事件对应。 想让控件响应事件时，就把代码写入这个事件的事件过程之中。
对象所识别的事件类型多种多样，但多数类型为大多数控件所共有。例如，大多数对象都能识别 click 事件—如果单击窗体，则执行窗体的单击事件过程中的代码；如果单击命令按钮，则执行命令按钮的 click 事件过程中的代码。每个情况中的实际代码几乎完全不一样。
这里是事件驱动应用程序中的典型事件序列：
启动应用程序，装载和显示窗体。
窗体（或窗体上的控件）接收事件。事件可由用户引发（例如键盘操作），可由系统引发（例如定时器事件），也可由代码间接引发（例如，当代码装载窗体时的 Load 事件）。
如果在相应的事件过程中存在代码，就执行代码。
应用程序等待下一次事件。
注意 许多事件伴随其它事件发生。例如，在 DblClick 事件发生时，MouseDown、MouseUp 和 Click 事件也会发生。

SpringBoot核心原理：自动配置、事件驱动、Condition

SpringBoot是Spring的包装，通过自动配置使得SpringBoot可以做到开箱即用，上手成本非常低，但是学习其实现原理的成本大大增加，需要先事件驱动型流程引擎了解熟悉Spring原理。

如果还不清楚Spring原理的，可以先查看博主之前的文章，本篇主要分析SpringBoot的启动、自动配置、Condition、事件驱动原理。

SpringBoot启动非常简单，因其内置了Tomcat，所以只需要通过下面几种方式启动即可：

可以看到第一种是最简单的，也是最常用的方式，需要注意类上面需要标注 @SpringBootApplication 注解，这是自动配置的核心实现，稍后分析，先来看看SpringBoot启动做了些什么？

在往下之前，不妨先猜测一下，run方法中需要做什么？对比Spring源码，事件驱动型流程引擎我们知道，Spring的启动都会创建一个 ApplicationContext 的应用上下文对象，并调用其refresh方法启动容器，SpringBoot只是Spring的一层壳，肯定也避免不了这样的操作。

另一方面，以前通过Spring搭建的项目，都需要打成War包发布到Tomcat才行，而现在SpringBoot已经内置了Tomcat，只需要打成Jar包启动即可，所以在run方法中肯定也会创建对应的Tomcat对象并启动。以上只是我们的猜想，下面就来验证，进入run方法：

SpringBoot的启动流程就是这个方法，先看 getRunListeners 方法，这个方法就是去拿到所有的 SpringApplicationRunListener 实现类，这些类是用于SpringBoot事件发布的，关于事件驱动稍后分析，这里主要看这个方法的实现原理：

一步步追踪下去可以看到最终就是通过SPI机制根据接口类型从 META-INF/spring.factories 文件中加载对应的实现类并实例化，SpringBoot的自动配置也是这样实现的。

为什么要这样做呢？通过注解扫描不可以么？当然不行，这些类都在第三方jar包中，注解扫描实现是很麻烦的，当然你也可以通过 @Import 注解导入，但是这种方式不适合扩展类特别多的情况，所以这里采用SPI的优点就显而易见了。

回到run方法中，可以看到调用了 createApplicationContext 方法，见名知意，这个就是去创建应用上下文对象：

注意这里通过反射实例化了一个新的没见过的上下文对象 AnnotationConfigServletWebServerApplicationContext ，这个是SpringBoot扩展的，看看其构造方法：

如果你有看过Spring注解驱动的实现原理，这两个对象肯定不会陌生，一个实支持注解解析的，另外一个是扫描包用的。

上下文创建好了，下一步自然就是调用refresh方法启动容器：

这里首先会调用到其父类中 ServletWebServerApplicationContext ：

可以看到是直接委托给了父类：

这个方法不会陌生吧，之前已经分析过了，这里不再赘述，至此SpringBoot的容器就启动了，但是Tomcat启动是在哪里呢？run方法中也没有看到。

实际上Tomcat的启动也是在refresh流程中，这个方法其中一步是调用了onRefresh方法，在Spring中这是一个没有实现的模板方法，而SpringBoot就通过这个方法完成了Tomcat的启动：

这里首先拿到 TomcatServletWebServerFactory 对象，通过该对象再去创建和启动Tomcat：

上面的每一步都可以对比Tomcat的配置文件，需要注意默认只支持了http协议：

如果想要扩展的话则可以对 additionalTomcatConnectors 属性设置值，需要注意这个属性没有对应的setter方法，只有 addAdditionalTomcatConnectors 方法，也就是说我们只能通过实现 BeanFactoryPostProcessor 接口的 postProcessBeanFactory 方法，而不能通过 BeanDefinitionRegistryPostProcessor 的 postProcessBeanDefinitionRegistry 方法，因为前者可以通过传入的BeanFactory对象提前获取到 TomcatServletWebServerFactory 对象调用 addAdditionalTomcatConnectors 即可事件驱动型流程引擎；而后者只能拿到BeanDefinition对象，该对象只能通过setter方法设置值。

这段代码会在控制台打印所有的事件名称，按照顺序如下：

以上是正常启动关闭，如果发生异常还有发布 ApplicationFailedEvent 事件。事件的发布遍布在整个容器的启动关闭周期中，事件发布对象刚刚我们也看到了是通过SPI加载的 SpringApplicationRunListener 实现类 EventPublishingRunListener ，同样事件监听器也是在 spring.factories 文件中配置的，默认实现了以下监听器：

可以看到有用于文件编码的（ FileEncodingApplicationListener ），有加载日志框架的（ LoggingApplicationListener ），还有加载配置的（ ConfigFileApplicationListener ）等等一系列监听器，SpringBoot也就是通过这系列监听器将必要的配置和组件加载到容器中来，这里不再详细分析，感兴趣的读者可以通过其实现的 onApplicationEvent 方法看到每个监听器究竟是监听的哪一个事件，当然事件发布和监听我们自己也是可以扩展的。

SpringBoot最核心的还是自动配置，为什么它能做到开箱即用，不再需要我们手动使用 @EnableXXX 等注解来开启？这一切的答案就在 @SpringBootApplication 注解中：

这里重要的注解有三个： @SpringBootConfiguration 、 @EnableAutoConfiguration 、 @ComponentScan 。 @ComponentScan 就不用再说了， @SpringBootConfiguration 等同于 @Configuration ，而 @EnableAutoConfiguration 就是开启自动配置：

@AutoConfigurationPackage 注解的作用就是将该注解所标记类所在的包作为自动配置的包，简单看看就行，主要看 AutoConfigurationImportSelector ，这个就是实现自动配置的核心类，注意这个类是实现的 DeferredImportSelector 接口。

在这个类中有一个 selectImports 方法。这个方法在我之前的文章这一次搞懂Spring事务注解的解析也有分析过，只是实现类不同，它同样会被 ConfigurationClassPostProcessor 类调用，先来看这个方法做了些什么：

追踪源码最终可以看到也是从 META-INF/spring.factories 文件中拿到所有 EnableAutoConfiguration 对应的值（在 spring-boot-autoconfigure 中）并通过反射实例化，过滤后包装成 AutoConfigurationEntry 对象返回。

看到这里你应该会觉得自动配置的实现就是通过这个 selectImports 方法，但实际上这个方法通常并不会被调用到，而是会调用该类的内部类 AutoConfigurationGroup 的process和selectImports方法，前者同样是通过 getAutoConfigurationEntry 拿到所有的自动配置类，而后者这是过滤排序并包装后返回。

下面就来分析 ConfigurationClassPostProcessor 是怎么调用到这里的，直接进入 processConfigBeanDefinitions 方法：

前面一大段主要是拿到合格的 Configuration 配置类，主要逻辑是在 ConfigurationClassParser.parse 方法中，该方法完成了对 @Component 、 @Bean 、 @Import 、 @ComponentScans 等注解的解析，这里主要看对 @Import 的解析，其它的读者可自行分析。一步步追踪，最终会进入到 processConfigurationClass 方法：

这里需要注意 this.conditionEvaluator.shouldSkip 方法的调用，这个方法就是进行Bean加载过滤的，即根据 @Condition 注解的匹配值判断是否加载该Bean，具体实现稍后分析，继续跟踪主流程 doProcessConfigurationClass ：

这里就是完成对一系列注解的支撑，我省略掉了，主要看 processImports 方法，这个方法就是处理 @Import 注解的：

刚刚我提醒过 AutoConfigurationImportSelector 是实现 DeferredImportSelector 接口的，如果不是该接口的实现类则是直接调用 selectImports 方法，反之则是调用 DeferredImportSelectorHandler.handle 方法：

首先创建了一个 DeferredImportSelectorHolder 对象，如果是第一次执行则是添加到 deferredImportSelectors 属性中，等到 ConfigurationClassParser.parse 的最后调用process方法：

反之则是直接执行，首先通过register拿到 AutoConfigurationGroup 对象：

然后在 processGroupImports 方法中进行真正的处理：

在 getImports 方法中就完成了对process和 selectImports 方法的调用，拿到自动配置类后再递归调用调用 processImports 方法完成对自动配置类的加载。至此，自动配置的加载过程就分析完了，下面是时序图：

在自动配置类中有很多Condition相关的注解，以AOP为例：

这里就能看到 @ConditionalOnProperty 、 @ConditionalOnClass 、 @ConditionalOnMissingClass ，另外还有 @ConditionalOnBean 、 @ConditionalOnMissingBean 等等很多条件匹配注解。

这些注解表示条件匹配才会加载该Bean，以 @ConditionalOnProperty 为例，表明配置文件中符合条件才会加载对应的Bean，prefix表示在配置文件中的前缀，name表示配置的名称， havingValue 表示配置为该值时才匹配， matchIfMissing 则是表示没有该配置是否默认加载对应的Bean。其它注解可类比理解记忆，下面主要来分析该注解的实现原理。

这里注解点进去看会发现每个注解上都标注了 @Conditional 注解，并且value值都对应一个类，比如 OnBeanCondition ，而这些类都实现了 Condition 接口，看看其继承体系：

上面只展示了几个实现类，但实际上Condition的实现类是非常多的，我们还可以自己实现该接口来扩展 @Condition 注解。Condition接口中有一个matches方法，这个方法返回true则表示匹配。该方法在 ConfigurationClassParser 中多处都有调用，也就是刚刚我提醒过的shouldSkip方法，具体实现是在 ConditionEvaluator 类中：

再来看看matches的实现，但 OnBeanCondition 类中没有实现该方法，而是在其父类 SpringBootCondition 中：

getMatchOutcome 方法也是一个模板方法，具体的匹配逻辑就在这个方法中实现，该方法返回的 ConditionOutcome 对象就包含了是否匹配和日志消息两个字段。进入到 OnBeanCondition 类中：

可以看到该类支持了 @ConditionalOnBean 、 @ConditionalOnSingleCandidate 、 @ConditionalOnMissingBean 注解，主要的匹配逻辑在 getMatchingBeans 方法中：

这里逻辑看起来比较复杂，但实际上就做了两件事，首先通过 getNamesOfBeansIgnoredByType 方法调用 beanFactory.getBeanNamesForType 拿到容器中对应的Bean实例，然后根据返回的结果判断哪些Bean存在，哪些Bean不存在（Condition注解中是可以配置多个值的）并返回MatchResult对象，而MatchResult中只要有一个Bean没有匹配上就返回false，也就决定了当前Bean是否需要实例化。

本篇分析了SpringBoot核心原理的实现，通过本篇相信读者也将能更加熟练地使用和扩展SpringBoot。

另外还有一些常用的组件我没有展开分析，如事务、MVC、监听器的自动配置，这些我们有了Spring源码基础的话下来看一下就明白了，这里就不赘述了。

最后读者可以思考一下我们应该如何自定义starter启动器，相信看完本篇应该难不倒你。 关于事件驱动型流程引擎和事件驱动技术的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件驱动型流程引擎的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于事件驱动技术、事件驱动型流程引擎的信息别忘了在本站进行查找喔。