我们用什么样的观点来认识世界?就决定了我们系统的架构是什么样子的。
过程 时间轴 对象 属性 方法 ,多个对象协同工作,事件消息。
1、举个例子
(1)去银行办事
1.0时代,大家直接在柜台前排队
2.0时代,进门先拿号,通知你,你在去具体的柜台
有什么不一样
拿号,是拿什么?
谁安排你的?怎么去安排你的?是不是整体系统视角发生了变化
想办两件事,怎么处理?
ps:医院分诊是一个例子
2、举个代码的例子
资产审核功能,审核通过后需要做2件事,1.生成合同 ,2.给客户发送短信
程序 1.0 版本
//程序1.0版本:
//代码
function AssetCheck(){
if(isChecked){
//1.生成合同
//2.给客户发短信
或
//1.生成合同安排api
//2.给客户发短信api
}
}
程序 2.0 的版本
//程序2.0的版本
//代码
function AssetCheck(){
if(isCheck){
//写入记录到资产审核后处理表
}
}
//资产审核处理,后台作业 job
function AssetJob(){
//1.生成合同
//2.给客户发短信
}
程序3.0版本:
//程序3.0的版本
//代码
funtion AssetCheck(){
if(isChecked){
//写一条资产审核已经通过的事件
}
}
//配置一个分发规则,经过事件分发处理,事件得到了两个handler 处理器中
function Event_Transport(){}
//后台作业 job 生成合同
function CrrateContractJob(){
//生成合同
//生成借款合同
//合同全在这里生成
}
//后台作业 job 发短信
function SentMessageJob(){
//给客户发短信
//放款短信
//短信全在这里发
}
3、简单介绍:
在一个事件驱动的架构中,如果一个值得注意的事情发生在你的业务之内或之外,它将直接传播到所有感兴趣的一方,感兴趣的一方将评估该事件并有选择的采取行动
4、比较全面的的说法:
Event_Driven_Architecture(事件驱动架构),定义如下:
事件代表过去发生的事件,事件即是技术架构概念,也是业务概念,以事件为驱动的编程模型称为事件驱动架构EDA
两个方面理解EDA:
(1)EDA是一种侧重于以生成消费为基础的异步通信的架构模型。这主要对照于传统的基于线程的同步系统
(2)EDA是一种以事件为核心,提供事件产生,路由,消费以及结果回调等机制的架构模式
两个特性:
①.异步
②.彻底解耦
EDA架构的核心是基于消息的发布订阅模式,通过发布订阅模式实现事件的一对多灵活分发。消息消费方对发送方而言完全透明,消息发送方只管把消息发送到消息中间件,其它事情全部不用关心,由于消息中间件中的MQ等技术,即使发送消息时候,消息接收方不可用,但任然可以正常发送,这才叫彻底的解耦。其次一对多的发布订阅模式也是一个核心重点,对于消息的订阅方和订阅机制,可以在消息中间件灵活的进行配置和管理,而对于消息发送方和发送逻辑基本没有任何影响。
EDA要求我们的是通过业务流程,首先要识别出有价值的业务事件,这些事件符合异步、实时和发布订阅等基本的事件特征;其次是对事件进行详细的分析和定义,对事件件对应的消息格式进行定义,对事件的发布订阅机制进行定义等,最后才是基于消息事件模式的开发和测试等工作。而对于EDA架构来说,订阅者向Event Bus 订阅事件,告诉事件总线我要这个,而Event Bus接收订阅后,并不会立即进行处理,而是想什么时候处理就什么时候处理,主动权在Event Bus 手中,当Event Bus想进行处理的时候,一般是接受来自Command Handler的请求,然后就分别向指定订阅者发布通知,告诉它们我已经处理了,你们可以接着做下面的事情了。
架构特点:解耦和 无状态 去中心 自组织
使用场景:
实现组件的解耦
执行异步任务,无需同步等待调用的组件或服务返回处理结果
跟踪状态的变化
事件驱动架构优点:
1.实现系统组件的送耦合,简化系统前端应用的代码,减少新增逻辑对系统原有逻辑的侵入和干扰;
2.通过将复杂、高开销的业务处理或计算剥离到事件响应单元,实现分布、并行计算,提升系统整体性能和用户体验;
3.具有良好的可复用、扩展和可维护性,通过订阅引入新的消费者(处理器),而不影响现有处理;同时便于应用部署的横向扩展;
事件驱动架构缺点:
1.削弱了事件生产者对系统的控制力。一个组件触发事件时,并不能确实响应该事件的订阅者及订阅者执行顺序;要求事件订阅者必须按事件发生去执行,并尽可能保证处理的幂等性;
2.使系统中各组件、服务间的依赖、调用关系隐藏的更深;需要维护清晰的文档,描述各事件消费者的职责,及其数据处理的逻辑和流向;
5、相关知识点
ACID:一个事务本质上有四个特点ACID
- Atomicity(原子性):一个事务中的操作是原子的,其中任何一步失败,系统都能够完全回到事务的状态。
- Consistency(一致性):数据库的状态始终是保持一致的;
- Isolation(隔离性):多个并发执行的事务不会互相影响;
- Durability(持久性):事务处理结束后,对数据的修改是永久的;
CAP:
CAP原则,指的是在一个分布式系统中,Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。
- Consistency(一致性):是指数据在多个副本之间保持一致;
- Availability (可用性) :服务一直处于可用的状态,用户的每个操作,总是在时间内返回预期的结果;
- Partition tolerance(分区容错性):分布式系统在遇到任何网络分区故障的时候,任然能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障;
BASE模型:
BASE模型是CAP牺牲强一致性、保证可用性的拆中方案;
- Basicaily Available (基本可用):系统在出现不可预知的故障的时候,允许损失部分可用性,但不等于系统不可用。
- Soft State(软状态):允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性。
- Eventually Consistent (最终一致性):系统保证最终数据能够达到一致。
我们通常接触的常见的中间件,如mysql 、zookeeper、resis、elasticsearch等都是基于BASE理论建立的,当然事件驱动架构也是。