You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, all! I am a participant in OSPP. The topic is to build a unified Sentinel event system. My proposal is as follows. If there are any unreasonable designs or optimization points, I will appreciate it if you can correct them.
Background
As a traffic governance component for distributed and multilingual heterogeneous service architecture, Sentinel's observability system will greatly affect the rationality of users' rule configuration and thus affect the actual protection effect There are many state transitions in Sentinel, such as current limiting state transitions, fuse state transitions, adaptive algorithm state transitions, rule state transitions, etc. Some of these state transitions do not have event mechanisms, while others have independent event mechanisms, resulting in users not having a suitable way to simultaneously monitor and handle these events. So it is necessary to build a unified and scalable event system to support the event requirements of these state transitions and other functional modules. On the basis of this event system, it is necessary to have the ability to connect with the open source ecosystem.
Design Overview
Design Overview
SentinelEventBus: Provides an operational entry point for using the entire event model
This type of open pure static interface, such as publishing events, registering listeners, registering event publishers, etc., is easy to operate from any location
SentinelEventMulticasterFactory: an event broadcaster factory interface responsible for maintaining the mapping relationship between events and broadcasters (event isolation implementation)
SentinelEventMulticaster: an event broadcaster interface responsible for defining how to broadcast callbacks when an event occurs
SentinelEventListenerRegistry: The storage interface for event listeners, which provides unified management and maintenance of listeners (defining how to manage and organize storage)
SentinelEvent: an event based abstract class used to pass event information
SentinelEventListener: an event listener interface responsible for listening to events and customizing logic
SentinelEventFreqLimiter: Frequency control for event dimensions to prevent event explosions
SentinelEventListener
The event listener is maintained as a collection in the SentinelEventListenerRegistry, responsible for the specific processing of events. The main operation entry is the static method addListener of SentinelEventBus.
publicabstractclassSentinelEventListener {
/** * callback * * @param event event */voidonEvent(SentinelEventevent);
/** * event types this listener are listening */List<Class<? extendsSentinelEvent>> eventType();
/** * async handle */publicExecutorexecutor() {
returnnull;
}
/** * Whether to ignore expired event */publicbooleanalwaysLast() {
returnfalse;
}
/** * Priority * The smaller the number, the higher the priority */publicintorder() {
returnInteger.MAX_VALUE;
}
}
SentinelEventListenerRegistry
Storaging event listener, defining how to maintain and organize listener logic, combined in SentinelEventBus and SentinelVentMulticaster, where a SentinelApplication only has one SentinelEventListenerRegistry 。
publicinterfaceSentinelEventListenerRegistry {
// init opsvoidinit(Propertiesproperties);
// destory opsvoiddestory();
// add mappingvoidaddSubscriber(SentinelEventListenerlistener);
// remove mappingvoidremoveSubscriber(SentinelEventListenerlistener);
// get all listeners of eventList<SentinelEventListener> getSentinelEventListener(SentinelEventevent);
}
SentinelEvent
As a carrier of event information, it supports custom inheritance and publishes events through the publishEvent static method provided by SentinelEventBus.
publicabstractclassSentinelEvent {
// used to recognize expired eventprivatestaticfinalAtomicLongSEQUENCE = newAtomicLong(0);
privatefinallongsequence = SEQUENCE.getAndIncrement();
}
SentinelEventMulticaster
As the core of the entire event driven model, the event broadcaster defines how to callback listeners and build and maintain them through the SentinelEventMulticasterFactory event broadcaster factory.
The event broadcaster factory is responsible for maintaining the mapping relationship between events and broadcasters.
The main completed tasks include:
Customize the mapping relationship between events and broadcasters, which supports isolation control of events (such as aggregating multiple event types into the same broadcaster)
Support customizing callback logic based on event granularity
This class serves as the core class, responsible for maintaining the mapping relationship between event types and broadcasters, and providing static methods for providing an entry point that can be operated from any location to the outside world.
The main static methods provided are:
Add listeners;
Remove the listener;
Increase the mapping relationship between event broadcasters and events;
Delete the mapping relationship between event broadcasters and events;
Initialization work is completed by relying on the InitFunc initialization interface
Register the SentinelEventFreqLimiter frequency controller
Register default supported listeners (write events to a file similar to 'metric. log' and support limiting the number and size of files)
Event tracking work relies on the newly added 'EventSlot' to complete
Burial points for 'block' events
Expansion
SentinelEventMulticasterFactory: Can redefine how to access broadcaster logic, supports SPI`
At present, it is only maintained based on event types and broadcasters, and if it cannot be found, it will return to the default implementation
SentinelEventListenerRegistry: can define how to access listener logic, supports SPI`
-Currently, it is only maintained with simple event types and listener lists
SentinelEventMulticaster: Redefine how to perform event broadcast/callback behavior, implemented through an interface and registered in SentinelEventBus
At present, only the production consumption mode is used to consume events placed in the broadcaster queue (implemented in two ways: real-time consumption and timed consumption)
SentinelEvent: can expand to more heterogeneous event types, completed through inheritance
SentinelEventListener: Extend listeners for more events through inheritance
Initial plan to support events
After triggering, the following events will be written in JSON format to the 'event. log' file.
The text was updated successfully, but these errors were encountered:
Hi, 社区的老师们好!我是OSPP的参与者。议题是构建统一的 Sentinel 事件体系,我的方案如下,如果有设计不合理或优化点,还望老师们批评指正!
导师:@LearningGp
背景
Sentinel
作为面向分布式、多语言异构化服务架构的流量治理组件,它的可观测体系很大程度上会影响用户对于规则的配置的合理性进而影响到实际的防护效果。Sentinel
中存在很多状态的转换,例如,限流状态的转换、熔断器状态的转换、自适应算法状态的转换、规则状态的转换等。这些状态转换中有些没有事件机制,有些有着独立的事件机制,导致用户没有合适的方式来同时监听、处理这些事件。所以需要构建一个统一的可扩展的事件体系来支撑这些状态转化以及其他功能模块的事件需求。同时在该事件体系的基础上,需要具备对接开源生态的能力。设计概述
SentinelEventBus
:提供使用整个事件模型的操作入口SentinelEventMulticasterFactory
:事件广播器工厂接口,负责维护事件以及广播器的映射关系 (事件隔离实现)SentinelEventMulticaster
:事件广播器接口,负责定义在事件发生如何广播进行回调SentinelEventListenerRegistry
:事件监听器的存储接口,统一管理和维护监听器 (定义如何管理和组织存储)SentinelEvent
:事件基础抽象类,用于传递事件信息SentinelEventListener
:事件监听器接口,负责监听事件进行自定义逻辑SentinelEventFreqLimiter
:针对事件维度进行频率控制,防止事件爆炸SentinelEventListener
事件监听器以集合的方式被维护在
SentinelEventListenerRegistry
当中,负责进行事件的具体处理,主要操作入口为SentinelEventBus
的addListener
静态方法。SentinelEventListenerRegistry
统一存储事件监听器,定义如何维护和组织监听器逻辑,被组合在
SentinelEventBus
和SentinelEventMulticaster
中,一个Sentinel
应用只会有一个SentinelEventListenerRegistry
。SentinelEvent
作为事件信息的载体,支持被自定义继承,通过
SentinelEventBus
提供的publishEvent
静态方法,进行事件发布。SentinelEventMulticaster
事件广播器作为整个事件驱动模型的核心,定义如何回调监听器,通过
SentinelEventMulticasterFactory
事件广播器工厂构建和维护。SentinelEventMulticasterFactory
事件广播器工厂,负责维护事件以及广播器的映射关系。
主要完成的内容有:
SentinelEventBus
该类作为核心类,负责维护事件类型以及广播器的映射关系,并提供静态方法,用于为外界提供任意位置都可以操作的入口。
主要提供静态方法有:
SentinelEventFreqLimiter
负责针对事件进行频率控制,防止出现事件爆炸。
InitFunc
初始化接口完成SentinelEventFreqLimiter
频率控制器metric.log
的文件,并支持限制文件数量和大小)EventSlot
完成block
事件进行埋点使用拓展
SentinelEventMulticasterFactory
:可重新定义如何存取广播器逻辑,支持SPI
SentinelEventListenerRegistry
:可定义如何存取监听器逻辑,支持SPI
SentinelEventMulticaster
:可重新定义如何进行事件广播/回调行为,通过接口实现并在SentinelEventBus
注册SentinelEvent
:可拓展更多异构的事件类型,通过继承完成SentinelEventListener
:通过继承的方式拓展更多事件的监听器初期计划支持事件
以下事件在触发后,均会以
json
格式写入event.log
文件中。Hi, all! I am a participant in OSPP. The topic is to build a unified Sentinel event system. My proposal is as follows. If there are any unreasonable designs or optimization points, I will appreciate it if you can correct them.
Background
As a traffic governance component for distributed and multilingual heterogeneous service architecture, Sentinel's observability system will greatly affect the rationality of users' rule configuration and thus affect the actual protection effect There are many state transitions in Sentinel, such as current limiting state transitions, fuse state transitions, adaptive algorithm state transitions, rule state transitions, etc. Some of these state transitions do not have event mechanisms, while others have independent event mechanisms, resulting in users not having a suitable way to simultaneously monitor and handle these events. So it is necessary to build a unified and scalable event system to support the event requirements of these state transitions and other functional modules. On the basis of this event system, it is necessary to have the ability to connect with the open source ecosystem.
Design Overview
SentinelEventBus
: Provides an operational entry point for using the entire event modelSentinelEventMulticasterFactory
: an event broadcaster factory interface responsible for maintaining the mapping relationship between events and broadcasters (event isolation implementation)SentinelEventMulticaster
: an event broadcaster interface responsible for defining how to broadcast callbacks when an event occursSentinelEventListenerRegistry
: The storage interface for event listeners, which provides unified management and maintenance of listeners (defining how to manage and organize storage)SentinelEvent
: an event based abstract class used to pass event informationSentinelEventListener
: an event listener interface responsible for listening to events and customizing logicSentinelEventFreqLimiter
: Frequency control for event dimensions to prevent event explosionsSentinelEventListener
The event listener is maintained as a collection in the SentinelEventListenerRegistry, responsible for the specific processing of events. The main operation entry is the static method
addListener
of SentinelEventBus.SentinelEventListenerRegistry
Storaging event listener, defining how to maintain and organize listener logic, combined in SentinelEventBus and SentinelVentMulticaster, where a SentinelApplication only has one
SentinelEventListenerRegistry
。SentinelEvent
As a carrier of event information, it supports custom inheritance and publishes events through the
publishEvent
static method provided bySentinelEventBus
.SentinelEventMulticaster
As the core of the entire event driven model, the event broadcaster defines how to callback listeners and build and maintain them through the SentinelEventMulticasterFactory event broadcaster factory.
SentinelEventMulticasterFactory
The event broadcaster factory is responsible for maintaining the mapping relationship between events and broadcasters.
The main completed tasks include:
SentinelEventBus
This class serves as the core class, responsible for maintaining the mapping relationship between event types and broadcasters, and providing static methods for providing an entry point that can be operated from any location to the outside world.
The main static methods provided are:
SentinelEventFreqLimiter
Responsible for frequency control of events to prevent explosions.
InitFunc
initialization interfaceExpansion
SentinelEventMulticasterFactory
: Can redefine how to access broadcaster logic, supports SPI`SentinelEventListenerRegistry
: can define how to access listener logic, supports SPI`-Currently, it is only maintained with simple event types and listener lists
SentinelEventMulticaster
: Redefine how to perform event broadcast/callback behavior, implemented through an interface and registered in SentinelEventBusSentinelEvent
: can expand to more heterogeneous event types, completed through inheritanceSentinelEventListener
: Extend listeners for more events through inheritanceInitial plan to support events
After triggering, the following events will be written in JSON format to the 'event. log' file.
The text was updated successfully, but these errors were encountered: