基于SEDA的异步框架设计与实现
四、异步框架总体设计与实现
1、框架中的stage理想结构
前文提到,基于SEDA的异步框架,一个stage的理想结构描述如下:
在这个框架的设想中,一个stage一般需要有如下几个组件:
1、D-MQ:分布式消息中间件。用做事件队列,以进行消息的传递。
2、Local-Queue:本地队列。一般是blockingQueue,用以辅助实现stage内的动态线程池。采用Local-Queue的目的在于避免数据在mq中的堆积导致mq性能下降。
3、Thread Pool:动态线程池。进行事件的并发处理。
4、Worker:事件的具体处理器
5、Stage Controller:stage的性能控制器。用以对stage的队列、资源、调度策略进行控制。
引此为框架的设计理念,于是有了如下基于SEDA的异步框架的架构设计。
2、SEDA异步框架的使用场景
该异步框架可以用来处理如下几个场景的问题:
1、系统资源监控(CPU、内存、线程池、队列)
2、外围服务交互情况(API被调用、上游服务交互、请求方等)监控
3、系统报警(服务异常、接口压力过大等)
4、基于日志和事件的数据挖掘(规则挖掘等)
5、重要业务数据切片转储(里程碑消息、核心服务交互数据等)
6、异步触发的操作(表A写完后异步写表B等)
其使用场景大致可如下图所示:
3、SEDA异步框架系统总体架构
因而,基于以上所述适用范围的框架实现之后的系统架构,一般可如下所示:
当然,以上结构并非绝对的,如有需要,你完全可以通过自己定制bundle和bundle之间的拓扑关系,来实现各种复杂的事件处理过程。你只需要简单通 过声明bundle相关配置,即可实现任何按照你所希望的有向图去关联的bundle。框架提供给了你一个经过轻量级封装后的平台,后面的业务逻辑,就靠 开发者自己了。
4、异步框架原生态架构(Virtual Bundle)
基于上述的设计理念,最终实现的异步框架的原生态架构如下所示:
异步框架在无任何扩展的时候,其主要组件如下:
1、bundle:消息中心的核心组件。由读、处理、写三部分功能组成。同时整合开关、定时器、动态线程池等元素来支持多样化的输入和需求。bundle可以从多种数据源获取数据,并进行数据的处理。
1)开关:用以决定该bundle是否被激活。如未被激活,则该bundle将停止读取数据,同时不会在其他服务上产生该bundle对应的数据(比如在mq上生成该bundle的队列、连接、交换机等。)
2)定时器:用以指定该bundle是否定时运行。如未指定,则实时运行。
3)动态线程池:用以支持bundle以同步/异步方式调用。如未指定,则同步运行。
2、bundle decider:用以对bundle的关键指标进行决策(是否激活、时效性、同步类型等)。并同时提供健康检查。
3、Work carrier:处理数据的最小单元。
5、异步框架的AMQP实现(AMQP Bundle)
异步框架扩展的AMQP实现,其架构图如下所示:
其主要组件说明如下:
1、amqp bundle:消息中心的核心组件。由读、处理、写三部分功能组成。在整合开关、定时器、动态线程池之余,提供了配置化的订阅订阅管理以及关键行为的声明。
要声明一个bundle仅需声明对应的bean,示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
</bean>
1)开关:用以决定该bundle是否被激活。如未被激活,则该bundle将停止读取数据,同时不会在其他服务上产生该bundle对应的数据(比如在 mq上生成该bundle的队列、连接、交换机等)。加上开关之后,最大的优势在于其可以更方便的支持分布式部署。对不同的部署实例设置不一样的 active设置可以完成不同stage在不同机器的启停。默认激活。我们为bundle加上开关,示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="active" value="true" />
</bean>
2)定时器:用以指定该bundle是否定时运行。默认实时运行。我们为bundle加上定时器,示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="timer" value="0/30 * * * * ?"/>
</bean>
3)动态线程池:用以支持bundle内部的实际数据流处理过程以同步/异步方式调用。默认同步运行。我们为bundle加上动态线程池,示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="taskExecutor" ref="alarmCollectBundleExecutor"/>
</bean>
<!-- 报警信息收集器对应的动态线程池 -->
<bean id="alarmCollectBundleExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="corePoolSize" value="2" />
<property name="maxPoolSize" value="30" />
<property name="queueCapacity" value="200" />
</bean>
4)订阅发布:用以声明收集和推送信息时所需的交换机和密钥。通过支持逗号分隔的多key组合来支持多对多的上下游bundle关系。每个key的配置语 法符合rabbitmq中topic类型的exchange使用规范即可。默认采用“deimos-common”交换机。以下给出几种声明的配置:
其一:最简易配置。配置要订阅和发布的消息key即可。交换机采用默认配置。
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
</bean>
其二:声明特殊的来源和目的地的交换机:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
<property name="pubDest" value="spec1" />
<property name="subDest" value="spec2" />
</bean>
5)事件队列:每个bundle默认实现一个固定格式的独立队列。可通过配置另外指定。可支持bundle监听多队列的需求。如需要特别指定一个或多个事件队列,则示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
<property name="subQueues">
<list>
<ref bean="queueForLogError" />
</list>
</property>
</bean>
<!-- error日志消息的订阅 -->
<!--
如队列的声明不采用默认配置,完整声明如下:
<property name="exchangeName" value="deimos-common" />
<property name="queue" value="logQueue" />
<property name="bindingKey" value="collect.log.*" />
-->
<bean id="queueForLogError" class="com.cc.deimos.satellite.bo.AmqpQueueConfig">
<property name="bindingKey" value="collect.log.error" />
</bean>
6)监听容器:按照默认配置实现,并发数可通过配置指定。bundle如需额外设定channel数量,则示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
<property name="concurrency" value="20" />
</bean>
7)关键行为。用以给发布的消息打上bundle的标签。以辅助其他bundle进行数据筛选和处理。默认以发布的key为关键行为。如需额外声明,则示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
<property name="keyAction" value="ALARM_KEY_INFO" />
</bean>
2、bundle decider:用以对bundle的关键指标进行决策(是否激活、时效性、同步类型等)。并同时提供健康检查。默认采用fix strategy decider(定参策略决策器)。可进行配置来指定所需决策器类型,示例如下:
<!-- 报警消息收集器 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
<property name="strategyDecider" value="FIXED_STRATEGY"/>
</bean>
3、work carrier:处理数据的最小单元。Bundle依据决策器指示的状态同步/异步、实时/定时调用work carrier进行处理。完全对开发者透明。用户者无需关心该组件。bundle将结合decider进行调度。同时work carrier处理后的数据推送过程也对开发者透明。开发者所需要做的就是实现bundle的doWork方法,并将处理之后的数据直接return即 可。doWork方法如下所示:
@Override
public Object doWork(List<DeimosSatelliteRequest> message) throws Exception{
// do somethoing with message then retrun the result;
}
4、exchange:rabbitmq交换机。默认所有bundle都请求“deimos-common”。可集群化。配置见上。
5、amq:采用支持amqp协议的rabbitmq。默认单机内存节点。可采用镜像队列或其他方案来进行broker、queue的集群化。
6、channel:amq信道。可启动多信道并发监听amq队列消息。支持配置化设定。配置见上。
在web/servlet容器启动之后,框架中的各个组件将被依次加载,以下给出了bundle的大致启动流程,也正是因为这个启动流程,将上述的各个组件进行串联,并开始执行各自负责的工作:
以上详细介绍了SEDA框架的AMQP实现中主要组件的作用、声明方式以及实现原理。总结一下,异步框架的AMQP实现中,bundle与bundle之间通过分布式 队列rabbitmq进行数据传递,bundle内部提供包含阻塞队列的动态线程池taskExecutor来进行数据处理,同时提供了定时器timer 来控制bundle的定时/实时调用。workcarrier作为消息处理的最小单元,其调用机制完全对用户透明。消息在bundle中的接收、处理和推 送由bundle decider组件进行管理。用户只需要简单实现doWork方法和声明bundle配置即可实现消息的处理和传递。
6、一个简单的bundle安装示例
你完全可以只按照如下几步,就可以轻松实现你每个stage:
1、继承AmqpBundle类,实现doWork方法,完成你的业务逻辑。示例如下(通用收集器demo):
public class CommonAmqpCollectBundle extends SatAmqpBundle {
/**
* 采用并发队列。性能比阻塞队列高
*/
public final ConcurrentLinkedQueue<DeimosSatelliteRequest> cacheQueue = new ConcurrentLinkedQueue<DeimosSatelliteRequest>();
@Override
public Object doWork(List<DeimosSatelliteRequest> message) throws Exception {
logger.info("i am now in LogWorker:" + Thread.currentThread().getName() + "message is : " + message
+ ". now begin to collect!");
// 此处不采用锁,因为其带来的影响很有限
cacheQueue.addAll(message);
if (cacheQueue.size() < SatConstant.LOG_BATCH_SIZE) {
return null;
}
// 进行遍历导数据
List<DeimosSatelliteRequest> list = new ArrayList<DeimosSatelliteRequest>();
for (int i = 0; i < SatConstant.LOG_BATCH_SIZE && !cacheQueue.isEmpty(); i++) {
DeimosSatelliteRequest meta = cacheQueue.poll();
// 此时队列也已经为空了
if(meta == null){
break;
}
// 校验
if(meta.getTimestamp() == null || meta.getRealData() == null || meta.getData() == null){
logger.error("[deimos-satellite]meta param is error! meta request: " + meta);
continue;
}
// 记录关键行为
if(meta.getData().get(SatApiConstant.KEY_ACTION) == null){
meta.getData().put(SatApiConstant.KEY_ACTION, keyAction);
}
list.add(meta);
}
// 排序 ,以时间戳为key。考虑到可能出现时间戳一致的情况,所以不能用map。考虑到如果log要push到其他平台或者服务上,
// 该切片应该先保证自身有序而不能完全依赖于下一个bundle来处理
Collections.sort(list, new Comparator<DeimosSatelliteRequest>() {
@Override
public int compare(DeimosSatelliteRequest o1, DeimosSatelliteRequest o2) {
if (o1.getTimestamp().longValue() >= o2.getTimestamp()) {
return -1;
} else {
return 1;
}
}
});
logger.info("[deimos-satellite]common amqp collctor prepare to push to next bundle............ key action: " + keyAction);
return list;
}
}
2、对新写的bundle类加上配置声明。以下为最轻便的写法。如果需要额外定制其他bundle参数,参照上面的相关说明,进行定制即可。
<!-- 报警消息收集器,最简易参数声明。在切分成不同stage之后没有什么需要特别关注的潜在性能瓶颈时使用 -->
<bean id="alarmCollector" class="com.cc.deimos.satellite.core.collector.CommonAmqpCollectBundle">
<property name="pubKeys" value="process.alarm.*" />
<property name="subKeys" value="collect.alarm.*, collect.log.error" />
</bean>
3、启动服务。至此,你的bundle也就随着服务的启动就自动启动并开始工作了。
以上描述的一个bundle启动的过程,当所需要处理的业务被合理拆解成数个bundle(也就是所谓的stage)之后,就可以形成一个完整的基于工作流的系统实现。以下为基于对来源A进行事件收集的简易报警系统,在被拆解为三个bundle之后的数据流:
6、框架改进空间
目前框架仅仅提供了一个非常轻量的解决方案,并仅对AMQP进行了实现。后续可有如下几个改进升级的空间:
1)构成bundle strategy center。各个bundle的decider(决策器)在决策过程中,可以依赖strategy center进行bundle的相关决策。
2)支持bundle集群化、broker集群化,并引入相关策略(比如一致性哈希)来保证基于该框架的系统的高可用。可纳入bundle strategy center。
3)框架进一步基于IOC思想,进行面向接口编程的改造和升级。
(暂时整理到这,具体的uml图以及代码后续提供。)
- 大小: 37.9 KB
- 大小: 34.5 KB
分享到:
相关推荐
**基于SEDA的异步框架设计与实现** SEDA(Staged Event-Driven Architecture)是一种软件架构模式,常用于高性能、高并发的应用程序设计。它将系统分解为多个独立的阶段,每个阶段处理特定类型的事件,并通过队列...
### SEDA的企业服务总线的设计与实现 #### 一、引言 随着信息技术的发展,企业对软件系统的灵活性、可扩展性和高效性提出了更高的要求。面向服务架构(Service Oriented Architecture, SOA)作为一种业务驱动的IT...
### 基于SEDA的企业服务总线的设计与实现 #### 概述 本文主要探讨了如何通过采用阶段事件驱动架构(SEDA)来优化企业服务总线(ESB)的性能,特别是在高并发请求场景下。随着面向服务架构(SOA)在企业级软件开发...
SEDA的架构设计将服务容器分解为多个阶段,每个阶段处理不同的事件,并通过异步通信机制实现非阻塞I/O操作,这有助于系统性能的提升和可伸缩性的增加。 网格服务容器是服务网格中的一个基础组件,负责屏蔽资源异构...
而Twitter的Finagle框架进一步发展了这一概念,通过提供灵活的、可扩展的服务架构,实现了更高效的并发处理。 SEDA的核心思想是将服务分解为多个独立的阶段,并在这些阶段之间使用队列作为缓冲。这样做的好处包括:...
**SEDA架构详解** SEDA(Staged Event-Driven Architecture),即分阶段事件驱动架构,是一种面向服务的...在实际开发中,结合源码学习和工具辅助,可以更好地理解和实现SEDA架构,从而提高系统的整体性能和稳定性。
- **非阻塞I/O**:SEDA常与非阻塞I/O模型结合,减少等待时间,提升系统响应速度。 - **控制灵活性**:通过控制接口,可以在运行时动态调整系统参数,适应不断变化的环境。 **3. Eclipse工程与SEDA的关系:** `seda ...
通过这个包,开发者可以了解SEDA的早期实现,研究其设计原理,并基于此开发自己的高性能应用。 综上所述,SEDA架构提供了一种有效处理高并发问题的方法,通过分解复杂任务、利用非阻塞I/O和事件队列,实现了系统的...
6.与Spring 框架集成:可用作ESB 容器,也可以很容易的嵌入到Spring应用中. 7.使用基于SEDA处理模型的高度可伸缩的企业服务器. 8.强大的基于EIP模式的事件路由机制等. Mule发布最新版本1.1,这个发布包括集成了JBI,...
Netty是一个高性能、异步事件驱动的网络应用程序框架,适用于快速开发可维护的高性能协议服务器与客户端。该框架利用Java NIO来实现Reactor模式,这种模式通过同步等待多个I/O事件的发生,然后通过多路复用机制将...
6. **高度可伸缩性**:基于SEDA(Staged Event-Driven Architecture)模型,实现高性能和高可扩展性。 7. **基于EIP的路由机制**:采用企业集成模式(EIP),实现复杂的消息路由和处理。 #### 二、Mule ESB的整体...
6. 与 Spring 框架集成:可以用作 ESB 容器,也可以很容易地嵌入到 Spring 应用中。 7. 使用基于 SEDA 处理模型的高度可伸缩的企业服务器。 8. 强大的基于 EIP 模式的事件路由机制等。 Mule ESB 的整体结构图: ...
SEDA(Staged Event-Driven Architecture)是一种针对高性能服务器设计的体系结构,它借鉴了流水线的概念,将处理过程分解为一系列独立的阶段,每个阶段由一组专门的线程处理,通过事件驱动来协调各个阶段的工作。...
根据给定文件信息,我们可以总结出关于“seda过载保护”(即软件定义过载管理)的知识点,这些知识点涵盖分布式系统、互联网服务的过载管理、资源管理接口以及系统设计的重要性等方面。 首先,文章指出过载预防是...
唤醒Wake是一个事件驱动的框架,基于SEDA,Click,Akka和Rx的思想。 从某种意义上说,它是通用的,旨在支持计算密集型应用程序以及高性能网络,存储和旧版I / O系统。 我们实现了Wake以支持高性能,可扩展的分析处理...
【标题】:“2017-11-07 Seda 安装配置笔记1”描述了一次在Ubuntu 14.04环境下对Seda软件的安装与配置过程,涉及了VMware虚拟机、依赖软件的安装、LLVM与Clang的编译以及Seda的编译和配置。 【描述】:首先,安装...