事假驱动架构介绍

我们用什么样的观点来认识世界?就决定了我们系统的架构是什么样子的。

  过程 时间轴 对象 属性 方法 ,多个对象协同工作,事件消息。

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理论建立的,当然事件驱动架构也是。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值