WO2018188381A1 - 一种软件模块间的事件路由框架及方法 - Google Patents

一种软件模块间的事件路由框架及方法 Download PDF

Info

Publication number
WO2018188381A1
WO2018188381A1 PCT/CN2017/120184 CN2017120184W WO2018188381A1 WO 2018188381 A1 WO2018188381 A1 WO 2018188381A1 CN 2017120184 W CN2017120184 W CN 2017120184W WO 2018188381 A1 WO2018188381 A1 WO 2018188381A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
framework
module
queue
request
Prior art date
Application number
PCT/CN2017/120184
Other languages
English (en)
French (fr)
Inventor
张磊
张文明
陈少杰
Original Assignee
武汉斗鱼网络科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 武汉斗鱼网络科技有限公司 filed Critical 武汉斗鱼网络科技有限公司
Publication of WO2018188381A1 publication Critical patent/WO2018188381A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Definitions

  • the present invention relates to the field of software event management technologies, and in particular, to an event routing framework and method between software modules.
  • Coupling referred to in software engineering refers to the phenomenon of tight coordination and interaction between the input and output of two or more software modules or threads, and the transfer of energy from one side to the other through interaction.
  • the present invention provides an event routing framework and method between software modules in order to overcome the above problems or at least partially solve the above problems.
  • the interface layer is connected to provide an event routing framework between software modules, including an event subscription layer, an event processing layer, and an interface layer:
  • the event subscription layer is respectively connected to the event subscription layer and the event processing layer, and is configured to store an event corresponding to the identifier information in each module in the event by identifying each module identification information in the software.
  • the subscriber layer of the subscription layer In the subscriber layer of the subscription layer;
  • the interface layer is connected to the interface layer, and is configured to receive an event request sent by the first module, and send the event request to the second module for processing according to the target address information in the event request;
  • the event processing layer is configured to confirm that an event pointed to by the target address information in the event request exists in a subscriber set of the routing framework.
  • the event processing layer further includes: a routing mechanism unit, configured to perform processing of the event request by using at least one of an event request processing priority mechanism, an event request concurrent processing mechanism, and an event request caching mechanism.
  • event processing layer further includes:
  • a deleting unit configured to monitor, in real time, whether the first module issues a request to exit the routing framework; when detecting that the first module issues a request to exit the routing framework, establishing at least one new thread for deleting the first module Related event request information in the framework.
  • the event subscription layer further includes a storage unit, configured to store the event corresponding to the identifier information in each module in a form of a static variable in a subscriber set.
  • routing mechanism unit is further configured to: perform high-to-low ordering on all event requests in the to-be-processed queue according to the priority level of the event request, and process the event request according to the sorting.
  • routing mechanism unit further includes:
  • the event request is re-entered into the synchronization queue to perform the s2 by continuously triggering a preset event, until the event request successfully acquires a key of the synchronization queue.
  • routing mechanism unit is further configured to: add all target events to be processed by the event processing layer to the same cache queue; confirm that a new event request exists in the cache queue, and the cache queue is The new event request is again delivered to the message queue; the upper limit of the target event that the cache queue can store is n, where n>0.
  • the deleting unit is further configured to: delete at least one of the following requests: all event requests sent by the first module in the to-be-processed queue, and all event requests sent by the first module in the synchronization queue And all event requests sent by the first module in the cache team.
  • a method for performing event routing between software modules by using the above event routing framework including:
  • Step 1 receiving an event request sent by the first module
  • Step 2 confirming that the event pointed to by the target address information in the event request exists in a subscriber set of the routing framework
  • Step 3 Send the event request to the second module processing based on the target address information.
  • the method further includes:
  • Step 1 ′ by identifying a method for identifying each module in the software, storing an event corresponding to the identifier information in each module in a subscriber set of an event subscription layer in the framework.
  • the present application proposes an event routing framework and method between software modules.
  • the solution of the present invention has the following beneficial effects: 1. Effectively reducing memory leakage caused by coupling between software modules; 2. Improving software modules and software The maintainability of code between modules; 3, a variety of message routing mechanisms greatly improve the stability and efficiency of the routing method.
  • FIG. 1 is a schematic diagram of an overall structure of an event routing framework between software modules according to an embodiment of the present invention
  • FIG. 2 is a schematic overall flow chart of an event routing method between software modules according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of an apparatus for an event routing method between software modules according to an embodiment of the present invention.
  • FIG. 1 is a schematic diagram showing an overall framework of an event routing framework between software modules in an embodiment of the present invention. In general, including:
  • the event subscription layer L1 is connected to the interface layer, and is configured to store an event corresponding to the identifier information in each module in a subscription of the event subscription layer L1 by identifying each module identification information in the software.
  • the interface layer L2 is connected to the event subscription layer and the event processing layer, and is configured to receive an event request sent by the first module, and send the event request to the second module according to the target address information in the event request. ;
  • the event processing layer L3 is connected to the interface layer, and is configured to confirm that an event pointed to by the target address information in the event request exists in a subscriber set of the routing framework.
  • an event routing framework between software modules is provided.
  • the framework can effectively exchange information between software modules that are isolated from each other, thereby reducing the beneficial effect of coupling between modules.
  • an event routing framework between software modules is provided. Instead of using the add method in the traditional call set to perform event registration, an annotation method is used to implement message registration of the message recipient.
  • the technical problem that the add method in the prior art generates a large amount of similar code and the increase in the number of codes leads to an increase in the maintenance cost in the later stage is solved.
  • an event routing framework between software modules the event processing layer further includes: a routing mechanism unit for utilizing an event request processing priority mechanism, an event request concurrent processing mechanism, and an event request At least one of the caching mechanisms performs processing of the event request.
  • an event routing framework between software modules is provided, and each step performed by the processing module is a normal information delivery process.
  • the entire routing framework is optimized according to at least one of the foregoing mechanisms.
  • an event routing framework between software modules, the event processing layer further includes:
  • a deleting unit configured to monitor, in real time, whether the first module issues a request to exit the routing framework; when detecting that the first module issues a request to exit the routing framework, establishing at least one new thread for deleting the first module Related event request information in the framework.
  • an event routing framework between software modules is provided, and the deleting unit can ensure that the memory of the first module history application can be recovered by the framework in time, thereby effectively avoiding the foregoing A module creates a risk of memory leaks.
  • an event routing framework between software modules the event subscription layer further includes a storage unit, configured to store an event corresponding to the identifier information in each module as a static variable. The form is stored in the subscriber collection.
  • an event routing framework between software modules is provided, and an event corresponding to the identifier information in each module is stored in a static manner, and the stored message is in a static area of the memory.
  • the content stored in the static zone has one and only one copy in the entire frame, which ensures that the stored event information is globally unique.
  • an event routing framework between software modules the routing mechanism unit is further configured to: according to the priority level of the event request, all event requests in the queue to be processed are high to Low sorting, processing the event request according to sorting.
  • the event request processing priority mechanism enables the routing framework to determine the priority of the current message and insert the message into a corresponding location in the message queue.
  • an event routing framework between software modules, the routing mechanism unit further includes:
  • the event request is re-entered into the synchronization queue to perform the s2 by continuously triggering a preset event, until the event request successfully acquires a key of the synchronization queue.
  • This embodiment can solve the possibility that the message is lost probabilistically when a concurrent message occurs.
  • an event routing framework between software modules is further configured to: add all target events to be processed by the event processing layer to the same cache queue; confirm new The event request exists in the cache queue, and the new event request in the cache queue is again delivered to the message queue; the upper limit of the target event that the cache queue can store is n, where n>0.
  • This embodiment can greatly improve the capabilities and processing efficiency of the framework.
  • an event routing framework between software modules the deleting unit is further configured to delete at least one of the following requests: all sent by the first module in the to-be-processed queue An event request, all event requests sent by the first module in the synchronization queue, and all event requests sent by the first module in the cached queue.
  • the specific embodiment can delete all the messages in the routing framework, thereby effectively preventing the memory leakage caused by the residual information of the first module.
  • an event routing framework between software modules includes: address information of an event receiving module and data information of the event request; and the data information of the event request is JSON format.
  • an event routing framework between software modules is further described below in conjunction with specific examples.
  • the embodiment of the present invention provides an event routing framework, and the association between the module and the module can be established through the event routing framework.
  • the solution of the specific embodiment can achieve the requirement of low coupling and high cohesion between the modules.
  • Message communication between free and other modules, the framework can effectively exchange information between isolated components.
  • Subscription layer of routing events This layer is mainly used to register messages into the routing framework.
  • Routing mechanism layer of the message This layer is mainly used to describe the routing framework's strategy and implementation method for message routing.
  • Release layer of the message This layer describes the mechanism by which the routing framework can demonstrate the message to reclaim memory.
  • the core task of the routed event subscription layer is to register the message acceptor in the routing framework and let the routing framework layer know which messages were received by which processing class.
  • the add method in the traditional call set is not used for event registration, but the annotation is used to implement the message recipient's information registration.
  • This embodiment effectively solves the deficiencies of the conventional scheme by using a custom annotator to implement message recipient registration into the routing framework.
  • the message registration is encapsulated into an interface, and the entity that needs to register the message needs to implement the message interface and deliver the message to the routing framework through the interface.
  • the route event is subscribed by annotation.
  • the specific implementation method is as follows:
  • Annotation to subscribe to routing By defining a custom annotation @BindRouter, you need to implement parsing of the annotation after defining a custom annotation.
  • the annotation parsing class ParseAnnotation is defined.
  • the annotation of the @BindRouter in the java source file is obtained by calling the getAnnotation method, and then the getValue method is called again to obtain the specific annotation device. Details, then subscribe to receive events into the routing framework by calling the add method.
  • annotations The advantage of using annotations is that the entire event subscription only needs to add @BindRouter's custom annotations to the event, and the annotation parser will automatically store the events that need to be subscribed to the routing framework during the compilation phase.
  • the initialization function init of the routing framework When the single frame is initialized, the initialization function init of the routing framework is called.
  • the init function automatically calls the annotation code parsed by the annotation device, so that all the subscription information is stored in the collection A of the routing framework.
  • the set A is declared by the static method, the set is stored in the static area of the memory, and the content stored in the static area has one and only one copy in the entire frame, so that the set A can be ensured to be globally unique. existing.
  • ModelA Since each module exists independently, if the module ModelA wishes to send information to the ModelB, then ModelA needs to send an event request to the routing framework. After the event arrives at the routing framework, it is distributed to the corresponding subscribers through the routing framework.
  • ModelA wants to send information to ModelB, it needs to pass the following information to the router:
  • the destination of the message that is, the recipient information of the message.
  • the purpose of the message in this scenario is to calibrate through a string of unique RULs (addresses similar to the design of the website address of the URL).
  • Message information delivered In order to facilitate the exchange of information between the two parties, the message mechanism in this solution uses a common JSON format data for the medium of message communication.
  • the message sender ModelA can send a message event to the routing framework by calling the post(url, jsonParam) method.
  • url represents the unique address of the subscriber of the routing framework
  • jsonParam represents the message data that needs to be passed
  • the format is the data type in json format.
  • the router After the information arrives at the routing framework, the router first obtains the destination address information by calling the getUrl method, and then obtains the destination address information to search in the subscriber set A, and determines whether there is a recipient in the subscriber set A that needs to deliver the message, if not If the message is found, the message will be delivered to the receiver ModelB, and the jsonParam parameter passed by the sender will be passed to the ModelB, thus completing the message exchange process.
  • the message is divided into three levels. The higher the level, the higher the priority, and the lower the level, the lower the priority. This way when the message is delivered to the routing framework.
  • the routing framework determines the priority of the current message and inserts the message into the appropriate location in the message queue. For example, if the rank in the message queue is 1123, then a message with level 3 needs to be inserted. At this time, the queue of the message is 11233, and the message with level 3 is inserted into the queue of level 3 in the original queue. . When all messages are reached, the message is inserted in a similar manner, so that the message can be processed with priority.
  • the message queue is designed as a synchronous queue. There is a lock inside the synchronization queue.
  • a message arrives at the synchronization queue, it will first find the synchronization queue to obtain the key of the lock. If the key is obtained, the synchronization queue will add the message to the queue. If the key is not obtained, a cache queue will be built. The message that does not acquire the lock will be in the cache queue and then the timer will be triggered by the timing of the call to retrieve the message in the cache queue. Then the view will let the message get the synchronization queue again. Lock. If the key of the synchronization queue is obtained, the synchronization queue will process the message, otherwise the above process will be repeated, which can solve the possibility that the message is lost probabilistically when the concurrent message occurs.
  • the message is cached as long as it enters the message queue.
  • the method of caching is to add the message to a normal collection each time the message is delivered to the subscriber. In this solution, the size of the cache set is located 30, so that the last 30 pieces of message information can be cached.
  • routing framework Since the routing framework has a coupling relationship with ModelA and ModelB, and the routing framework is resident memory, if the function of ModelA has been used and will not be used later, the resources of ModelA should be released.
  • the routing framework does not reference any of ModelA's messages and events, so ModelA can be released normally, but if there is some information in ModelA that has not been processed in the routing framework, ModelA will not be released for a long time, so This can cause the frame's memory to be stored in memory for a long time, causing a memory leak.
  • a green channel is set in the routing framework, and the green channel does nothing to receive the release message. If ModelA needs to exit, it is not expected that the following message will continue to be processed. At this time, ModelA can send a message to the green channel that it wants to exit. At this point, the routing framework will open a new thread to the Model Synchronization queue. All messages sent are deleted by the remove method. And all the messages in the cache queue and related to ModelA in the waiting queue are cleared. This removes all messages from the routing framework.
  • ModelA This will ensure that the memory requested by ModelA can be recycled by the framework in time, thus effectively avoiding the danger of ModelA generating memory leaks.
  • This scheme has designed an efficient event routing framework.
  • the subscription of events uses a custom annotation method to greatly improve the maintainability of the code.
  • the message routing mechanism increases the message priority, and special processing such as concurrency and caching greatly improves the stability and efficiency of the routing framework.
  • the release of the message opens up a green channel to effectively reduce the memory leak caused by the coupling.
  • an event routing method between software modules is illustrated by using the event routing framework described in all of the above embodiments. Overall, including:
  • Step 1 receiving an event request sent by the first module
  • Step 2 confirming that the event pointed to by the target address information in the event request exists in a subscriber set of the routing framework
  • Step 3 Send the event request to the second module processing based on the target address information.
  • an event routing method between software modules is implemented by using the event routing framework described in all the foregoing embodiments, and the step 2 includes:
  • Step 1 ′ by identifying a method for identifying each module in the software, storing an event corresponding to the identifier information in each module in a subscriber set of an event subscription layer in the framework.
  • an event routing method between software modules is performed by using the event routing framework described in all the foregoing embodiments, where the step 2 further includes:
  • the processing of the event request is performed by using at least one of an event request processing priority mechanism, an event request concurrency processing mechanism, and an event request caching mechanism.
  • an event routing method between software modules is implemented by using the event routing framework described in all the foregoing embodiments, and further includes:
  • Step 4 Real-time monitoring whether the first module issues an exit routing framework request; when detecting that the first module issues an exit routing framework request, establishing at least one new thread for deleting the related event request of the first module information.
  • an event routing method between software modules the step 0 further includes: storing an event corresponding to the identifier information in each module as a static variable.
  • an event routing method between software modules includes: according to the priority level of the event request, all event requests are performed in the pending queue. High to low sorting, the event request is processed according to the sort.
  • an event routing method between software modules, the target event concurrent processing mechanism further includes:
  • the event request is re-entered into the synchronization queue to perform the s2 by continuously triggering a preset event, until the event request successfully acquires a key of the synchronization queue.
  • an event routing method between software modules is implemented by using the event routing framework described in all the foregoing embodiments, where the target event caching mechanism further includes: processing the event processing layer to be processed. All target events are added to the same cache queue; confirm that a new event request exists in the cache queue, and the new event request in the cache queue is re-delivered to the message queue; the cache queue can be stored
  • the upper limit of the target event is n, where n>0.
  • an event routing method between software modules is performed by using the event routing framework described in all the foregoing embodiments, and the step 4 further includes deleting at least one of the following: the to-be-processed queue All event requests sent by the first module, all event requests sent by the first module in the synchronization queue, and all event requests sent by the first module in the cached queue.
  • an event routing method between software modules is implemented by using the event routing framework described in all of the foregoing embodiments, where the event request includes: address information of the event receiving module and the event request. Data information; the data information of the event request is in JSON format.
  • FIG. 3 is a structural block diagram of an apparatus for performing an event routing method between software modules by using the event routing framework described in all the embodiments of the present application.
  • the test device of the WDM-FSO network node resource sharing method includes: a processor 301, a memory 302, a communication interface 303, and a bus 304;
  • the processor 301, the memory 302, and the communication interface 303 complete communication with each other through the bus 304;
  • the communication interface 303 is used for information transmission between the communication device of the event routing between the test device and the software module;
  • the processor 301 is configured to invoke the program instructions in the memory 302 to perform the method provided by the foregoing method embodiments, for example, including: Step 1: receiving an event request sent by the first module; Step 2, confirming the The event pointed to by the target address information in the event request exists in the subscriber set of the routing framework; in step 3, the event request is sent to the second module for processing based on the target address information.
  • the embodiment discloses a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions, when the program instructions are executed by a computer, the computer
  • the method provided in each of the foregoing method embodiments is performed, for example, comprising: step 1: receiving an event request sent by the first module; and step 2, confirming that an event pointed to by the target address information in the event request exists in the routing frame In the subscriber set; step 3, sending the event request to the second module processing based on the target address information.
  • the embodiment provides a non-transitory computer readable storage medium, the non-transitory computer readable storage medium storing computer instructions, the computer instructions causing the computer to perform the methods provided by the foregoing method embodiments, including, for example, Step 1: receiving an event request sent by the first module; step 2, confirming that an event pointed to by the target address information in the event request exists in a subscriber set of the routing framework; step 3, based on the target address The information sends the event request to the second module for processing.
  • the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed.
  • the foregoing steps include the steps of the foregoing method embodiments; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.
  • the apparatus and the like of the event routing method between the software modules described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as the unit may be or It may not be a physical unit, that is, it may be located in one place, or it may be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without deliberate labor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种软件模块间的事件路由框架及方法，所示框架包括：事件订阅层（L1），用于通过识别软件中各模块标识信息的方式，将所述各模块中与所述标识信息对应的事件存储在所述事件订阅层的订阅者集合中；接口层（L2），用于接收第一模块发送的事件请求，基于所述事件请求中的目标地址信息将所述事件请求发送给第二模块处理；事件处理层（L3），用于确认事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中。所述框架和方法有效的降低了软件模块间耦合所引起的内存泄漏问题，提高了软件模块及软件模块间代码的可维护性，并且多种消息路由机制提高了路由方法的稳定性和高效性。

Description

一种软件模块间的事件路由框架及方法
交叉引用
本申请引用于2017年04月12日提交的专利名称为“一种软件模块间的事件路由框架及方法”的第201710237608X号中国专利申请，其通过引用被全部并入本申请。
技术领域
本发明涉及软件事件管理技术领域，更具体地，涉及一种软件模块间的事件路由框架及方法。
背景技术
软件工程中所指的耦合是指两个或两个以上的软件模块或线程的输入与输出之间存在紧密配合与相互影响，并通过相互作用从一侧向另一侧传输能量的现象。
现有技术中，软件架构设计中通常为了提高软件的可扩展性往往架构设计人员会尽可能的将软件框架中的模块与外界尽可能少的产生耦合关系，最理想的情况下是模块能够做到其他模块无耦合关联性。这样软件框架中的模块才能够实现低耦合高内聚的设计原则，但是一个模块如果尽可能少的对外暴露接口那么带来的结果就是其他模块如果想和该模块进行通信就变得异常复杂或者几乎没有通信的可能性。
所以，现有技术中亟需实现软件中各功能模块低耦合高内聚的技术方案。
发明内容
本发明为克服上述问题或者至少部分地解决上述问题，提供一种软件模块间的事件路由框架及方法。
根据本发明的一个方面与所述接口层相连，提供一种软件模块间的事件路由框架，包括事件订阅层、事件处理层和接口层：
所述事件订阅层分别与所述事件订阅层和事件处理层相连，用于通过识别软件中各模块标识信息的方式，将所述各模块中与所述标识信息对应的事件存储在所述事件订阅层的订阅者集合中；
所述接口层与所述接口层相连，用于接收第一模块发送的事件请求，基于所述事件请求中的目标地址信息将所述事件请求发送给第二模块处理；
所述事件处理层，用于确认事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中。
进一步，所述事件处理层还包括：路由机制单元，用于利用事件请求处理优先级机制、事件请求并发处理机制和事件请求缓存机制中的至少一种，进行所述事件请求的处理。
进一步，所述事件处理层还包括：
删除单元，用于实时监控所述第一模块是否发出退出路由框架的请求；当检测到所述第一模块发出退出路由框架的请求时，建立至少一个新的线程用于删除所述第一模块在所述框架中的相关事件请求信息。
进一步，所述事件订阅层还包括存储单元，用于将所述各模块中与所述标识信息对应的事件存储以静态变量的形式存储在订阅者集合中。
进一步，所述路由机制单元进一步用于：根据事件请求的优先级高低，在待处理队列中对所有事件请求进行由高到低的排序，根据排序对所述事件请求进行处理。
进一步，所述路由机制单元进一步包括用于：
S1，将多个事件请求设计为一个同步队列，在所述同步队列内设置一个锁钥对；
S2，当事件请求到达所述同步队列后，首先搜寻所述同步队列的钥匙：当成功获取钥匙时，所述同步队列将所述事件请求添加到待处理队列中，当获取钥匙失败时，将所述事件请求加入缓存队列中；
S3，通过不断触发预设事件的方式使得所述事件请求再次进入所述同步队列执行所述s2，直至该事件请求成功获取所述同步队列的钥匙。
进一步，所述路由机制单元进一步用于：将所述事件处理层待处理的所有目标事件添加至同一个缓存队列；确认新的事件请求存在于所述缓存队列中，将所述缓存队列中的所述新的事件请求再次投递到消息队列中；所述缓存队列能够存储的目标事件的上限为n，其中n＞0。
进一步，所述删除单元进一步用于删除以下请求中的至少一种：所述待处理队列中所述第一模块发送的所有事件请求、所述同步队列中所述第一模块发送的所有事件请求和所述缓存队中所述第一模块发送的所有事件请求。
根据本发明的一个方面，提供一种利用上述事件路由框架进行软件模块间事件路由的方法，包括：
步骤1，接收第一模块发送的事件请求；
步骤2，确认所述事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中；
步骤3，基于所述目标地址信息将所述事件请求发送给第二模块处理。
进一步，所述步骤2前还包括：
步骤1’，通过识别所述软件中各模块标识信息的方法，将所述各模块中与所述标识信息对应的事件存储在所述框架中事件订阅层的订阅者集合中。
本申请提出一种软件模块间的事件路由框架及方法，本发明所述方案具有如下有益效果：1、有效的降低了软件模块间耦合所引起的内存泄漏问题；2、提高了软件模块及软件模块间代码的可维护性；3、多种消息路由机制极大的提高了路由方法的稳定性和高效性。
附图说明
图1为根据本发明实施例一种软件模块间的事件路由框架的整体结构示意图；
图2为根据本发明实施例一种软件模块间的事件路由方法的整体流程示意图；
图3为根据本发明实施例一种软件模块间的事件路由方法的装置的结构示意图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。
如图1，示出本发明一个具体实施例中一种软件模块间的事件路由框架整体框架示意图。总体上，包括：
包括事件订阅层L1、事件处理层L2和接口层L3：
所述事件订阅层L1与所述接口层相连，用于通过识别软件中各模块标识信息的方式，将所述各模块中与所述标识信息对应的事件存储在所述事件订阅层L1的订阅者集合中；
所述接口层L2分别与所述事件订阅层和事件处理层相连，用于接 收第一模块发送的事件请求，基于所述事件请求中的目标地址信息将所述事件请求发送给第二模块处理；
所述事件处理层L3与所述接口层相连，用于确认事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中。
在本发明具体实施例中，提供了一种软件模块间的事件路由框架，框架能够起到有效使得相互隔离的软件模块之间进行信息交换，从而降低各模块间耦合的有益效果。
在本发明具体实施例中，提供了一种软件模块间的事件路由框架，没有使用传统的调用集合中的add方法来进行事件注册，而是使用的注解方式来实现消息接受者的信息注册，解决了现有技术中add方法会产生大量的雷同代码，并且代码数量的剧增导致后期的维护成本会增加的技术问题。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述事件处理层还包括：路由机制单元，用于利用事件请求处理优先级机制、事件请求并发处理机制和事件请求缓存机制中的至少一种，进行所述事件请求的处理。
在本发明具体实施例中，提供了一种软件模块间的事件路由框架，所述处理模块执行的各个步骤是一个正常的信息交过过程，为了提高整个路由框架的稳健性和并发性，本具体实施例中利用上述机制中的至少一种对整个路由框架做了相应的优化处理。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述事件处理层还包括：
删除单元，用于实时监控所述第一模块是否发出退出路由框架的请求；当检测到所述第一模块发出退出路由框架的请求时，建立至少一个新的线程用于删除所述第一模块在所述框架中的相关事件请求信 息。
在本发明具体实施例中，提供了一种软件模块间的事件路由框架，所述删除单元能够保证所述第一模块历史申请的内存能够及时被框架回收，从而就有效的避免了所述第一模块产生内存泄漏的风险。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述事件订阅层还包括存储单元，用于将所述各模块中与所述标识信息对应的事件存储以静态变量的形式存储在订阅者集合中。
在本发明具体实施例中，提供了一种软件模块间的事件路由框架，通过static方式将所述各模块中与所述标识信息对应的事件存储，所述存放的消息会在内存的静态区中，存放在静态区的内容在整个框架中有且仅有一份拷贝，这样就能够确保存储的各事件信息是全局唯一存在的。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述路由机制单元进一步用于：根据事件请求的优先级高低，在待处理队列中对所有事件请求进行由高到低的排序，根据排序对所述事件请求进行处理。
在本具体实施例中，上述事件请求处理优先级机制，能够使得路由框架判定当前消息的优先级并将该消息插入到消息队列中相应的位置。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述路由机制单元进一步包括用于：
S1，将多个事件请求设计为一个同步队列，在所述同步队列内设置一个锁钥对；
S2，当事件请求到达所述同步队列后，首先搜寻所述同步队列的钥匙：当成功获取钥匙时，所述同步队列将所述事件请求添加到待处 理队列中，当获取钥匙失败时，将所述事件请求加入缓存队列中；
S3，通过不断触发预设事件的方式使得所述事件请求再次进入所述同步队列执行所述s2，直至该事件请求成功获取所述同步队列的钥匙。
本具体实施例能够解决并发消息发生的时候概率性导致消息丢失的可能性。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述路由机制单元进一步用于：将所述事件处理层待处理的所有目标事件添加至同一个缓存队列；确认新的事件请求存在于所述缓存队列中，将所述缓存队列中的所述新的事件请求再次投递到消息队列中；所述缓存队列能够存储的目标事件的上限为n，其中n＞0。
本具体实施例可以极大的提升框架的能力和处理效率。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述删除单元进一步用于删除以下请求中的至少一种：所述待处理队列中所述第一模块发送的所有事件请求、所述同步队列中所述第一模块发送的所有事件请求和所述缓存队中所述第一模块发送的所有事件请求。
本具体实施例能够将路由框架中的所有消息全部进行删除，从而有效的起到了防止因第一模块残留信息而导致的内存泄漏的问题。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，所述事件请求包括：事件接收模块的地址信息和所述事件请求的数据信息；所述事件请求的数据信息为JSON格式。
在本发明另一个具体实施例中，一种软件模块间的事件路由框架，下面结合具体实例对所述方法展开进一步的说明。
本具体实施例设计了一个事件路由框架，通过所述事件路由框架 可以建立起模块与模块之间的关联，本具体实施例方案能够达到模块之间的低耦合高内聚的要求的同时又能自由的和其他模块之间进行消息通信，该框架能够有效的使得相互隔离的组件之间进行信息交换。
首先，事件路由框架的层级划分，整个路由框架的设计分为如下几层：
路由事件的订阅层：该层主要用于将消息注册到路由框架中的。
消息的路由机制层：该层主要用于描述路由框架对消息路由的策略和实现方法。
消息的释放层：该层描述的是路由框架如何将消息进行示范回收内存的机制。
其次，详细描述具体每个层级具体实施时的实现手段和实现细节。
1、路由事件订阅层
路由事件订阅层的核心任务是将消息接受者注册到路由框架中，让路由框架层知道哪些消息是被哪些处理类所接收的。本具体实施例中没有使用传统的调用集合中的add方法来进行事件注册，而是使用注解的方式来实现消息接受者的信息注册。
如果通过传统的方案使用集合并调用集合中的add方法来将信息传递到路由框架中，这样会产生大量的雷同代码，并且由于代码数量的剧增导致后期的维护成本会增加。本具体实施例通过利用自定义的注解器来实现消息接受者注册到路由框架中，有效的解决了传统方案的不足之处。
为了统一消息注册的规范，将消息注册封装成一个接口，需要注册消息的实体需要实现该消息接口并通过接口将消息传递给路由框架。
定义好消息注册接口后，通过注解的方式来实现路由事件的订阅，具体的实现方法如下所述：
注解方式来订阅路由：通过定义自定义的注解@BindRouter，当定义了自定义的注解之后需要实现该注解的解析。为了解析@BindRouter自定义的注解，定义了注解的解析类ParseAnnotation，在ParseAnnotation类中通过调用getAnnotation方法获取到解析java源文件中的@BindRouter开头的注解，然后再次调用getValue方法获取到具体注解器的详细信息，然后在通过调用add方法将接收事件订阅到路由框架中。
使用注解方式的好处是整个事件的订阅仅仅需要在事件上增加@BindRouter的自定义注解，注解解析器就会在编译阶段自动将需要订阅的事件存放到路由框架中。
单框架初始化的时候会去调用路由框架的初始化函数init，init函数会自动调用注解器解析好的订阅代码，使得所有的订阅信息全部存放在路由框架的集合A中。并且集合A是通过static方式来进行申明的，该集合会存放在内存的静态区中，存放在静态区的内容在整个框架中有且仅有一份拷贝，这样就能够确保的集合A是全局唯一存在的。
2、消息的路由机制
本段主要讲解消息路由的相关原理和实现手段。由于每个模块是独立存在的，所以如果模块ModelA希望发送信息到ModelB中，此时ModelA就需要向路由框架中发送事件请求。通过事件到达路由框架后，经过路由框架处理分发到对应的订阅者中。
接下来对于消息的分发详细来进行分析和解释，ModelA如果希望发送信息到ModelB需要传递给路由器如下信息：
消息的目的地：也即是消息的接受者信息，本方案中消息的目的 地是通过一串唯一的RUL(地址)来进行标定的(类似于网址的网站地址的设计思路)。
传递的消息信息：为了方便双方进行信息交换，本方案中消息机制使用的是通用个JSON格式数据来进行消息通信的媒介。
发送一条信息过程中，信息发送者ModelA通过调用post(url，jsonParam)方法可以向路由框架中投放一个消息事件。其中url表示的是路由框架的订阅者的唯一地址，jsonParam表示需要传递的消息数据，其格式是json格式的数据类型。
信息到达路由框架后路由器首先会通过调用getUrl方法获取到目的地址信息，然后拿到目的地址信息在订阅者集合A中进行寻找，判定订阅者集合A中是否存在需要投放消息的接受者，如果没有找到就不进行消息投放，如果找到了就会将消息投递到接收者ModelB中，同时将发送者传递的jsonParam参数传递到ModelB中，这样就完成了一次消息的交换过程。
上述过程是一个正常的信息交过过程，为了提高整个路由机制的稳健性和并发性对整个消息路由做了如下优化处理：
消息优先级划分：
为了提高消息处理的及时性，将消息划分为3个等级，等级越高表明优先级越高，等级越低表明优先级越低。这样当消息投递到路由框架中的时候。路由框架会判定当前消息的优先级并将该消息插入到消息队列中相应的位置。例如，如果消息队列中的等级排列为1123接下来需要插入一条等级为3的消息，此时消息对列的排列为11233，会讲等级为3的消息插入到原来队列中等级为3的队列后面。所有消息达到后都会按照类似的方式来对消息进行插入，这样就能够对消息进行有优先级的处理。
消息队列并发的处理：
为了解决多个消息同时到达路由框架的时候概率性导致消息丢失的问题，将消息队列设计为一个同步队列。同步队列内部有一个锁，当有消息到达同步队列后首先会找同步队列获取该条锁的钥匙，如果获取到钥匙了，同步队列就会对该条消息添加到队列中这个过程。如果没有获取到钥匙，会构建一条缓存队列，没有获取到锁的消息会在缓存队列中然后会通过调用定时来定时触发的方式来取出缓存队列中的消息然后视图让该消息再次去获取同步队列的锁。如果获取到同步队列的钥匙，同步队列就会处理该条消息否则会重复上述过程，这样就能够解决并发消息发生的时候概率性导致消息丢失的可能性。
消息缓存机制：
对于只要是进入消息队列的消息就会对该条消息进行缓存处理，缓存的方法是每次当消息投递到订阅者的时候就会将消息添加到一个普通的集合中。本方案中将缓存集合的大小定位30条，这样可以缓存最近处理的30条消息信息。缓存消息的目的有2个，其一是可以随时查看和调试当前路由框架已经处理成功的最近30条消息有哪一些。其二是如果需要投递重复消息的时候不用再去实例化消息了，因为实例化消息对框架的开销是非常大的，可以直接从缓存对内中拿到曾经投递过的消息然后再次投递到消息队列中，这样可以极大的提升框架的能力和处理效率。
3、消息的释放
由于路由框架会和ModelA与ModelB都有耦合关系，并且路由框架是常驻内存的，如果ModelA的功能已经使用完成了并且后续也不会在使用了，此时要对ModelA的资源进行释放，如果路由框架没有对ModelA的任何消息和事件进行引用，那么ModelA是能够正常被释放的，但是如果ModelA中的有一些信息一直在路由框架中没有被处理这 样就会导致ModelA长期不能够释放，这样就会导致框架的内存长时间存放在内存中，从而产生内存泄漏的问题。
为了解决该问题在路由框架中设置了一条绿色通道，该条绿色通道什么都不做主要是用来接收释放消息的。如果ModelA需要退出的时候，也不期望后面的消息被继续处理了，此时ModelA可以向绿色通道发送一条自己要退出的信息，此时路由框架会开启一个新的线程去消息同步队列中将ModelA发送的所有消息通过remove方法全部删除掉。并且将缓存队列中的和等待队列中的和ModelA相关的所有消息全部清除。这样就将路由框架中的所有消息全部都删除掉了。
这样就能够保证ModelA之前申请的内存能够及时被框架回收，从而就有效的避免了ModelA产生内存泄漏的危险。
本方案设计了一套高效的事件路由框架，事件的订阅使用了自定义注解的方式来实现可以极大的提高代码的可维护性。消息路由机制增加了消息优先级，并发，缓存等特殊处理极大的提高了路由框架的稳定性和高效性。对消息的释放开辟了一条绿色通道有效的降低了耦合所引起的内存泄漏等问题。
如图2，示出本发明一个具体实施例中，示出本一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法。整体上，包括：
步骤1，接收第一模块发送的事件请求；
步骤2，确认所述事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中；
步骤3，基于所述目标地址信息将所述事件请求发送给第二模块处理。
在本发明另一个具体实施例中，一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法，所述步骤2前还包 括：
步骤1’，通过识别所述软件中各模块标识信息的方法，将所述各模块中与所述标识信息对应的事件存储在所述框架中事件订阅层的订阅者集合中。
在本发明另一个具体实施例中，一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法，所述步骤2还包括：
利用事件请求处理优先级机制、事件请求并发处理机制和事件请求缓存机制中的至少一种，进行所述事件请求的处理。
在本发明另一个具体实施例中，一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法，还包括：
步骤4，实时监控所述第一模块是否发出退出路由框架请求；当检测到所述第一模块发出退出路由框架请求时，建立至少一个新的线程用于删除所述第一模块的相关事件请求信息。
在本发明另一个具体实施例中，一种软件模块间的事件路由方法，所述步骤0还包括：将所述各模块中与所述标识信息对应的事件存储以静态变量的形式进行保存。
在本发明另一个具体实施例中，一种软件模块间的事件路由方法，所述事件请求处理优先级机制一步包括：根据事件请求的优先级高低，在待处理队列中对所有事件请求进行由高到低的排序，根据排序对所述事件请求进行处理。
在本发明另一个具体实施例中，一种软件模块间的事件路由方法，所述目标事件并发处理机制进一步包括：
S1，将多个事件请求设计为一个同步队列，在所述同步队列内设置一个锁钥对；
S2，当事件请求到达所述同步队列后，首先搜寻所述同步队列的钥匙：当成功获取钥匙时，所述同步队列将所述事件请求添加到待处理队列中，当获取钥匙失败时，将所述事件请求加入缓存队列中；
S3，通过不断触发预设事件的方式使得所述事件请求再次进入所述同步队列执行所述s2，直至该事件请求成功获取所述同步队列的钥匙。
在本发明另一个具体实施例中，一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法，所述目标事件缓存机制进一步包括：将所述事件处理层待处理的所有目标事件添加至同一个缓存队列；确认新的事件请求存在于所述缓存队列中，将所述缓存队列中的所述新的事件请求再次投递到消息队列中；所述缓存队列能够存储的目标事件的上限为n，其中n＞0。
在本发明另一个具体实施例中，一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法，所述步骤4进一步包括删除以下至少一种：所述待处理队列中所述第一模块发送的所有事件请求、所述同步队列中所述第一模块发送的所有事件请求和所述缓存队中所述第一模块发送的所有事件请求。
在本发明另一个具体实施例中，一种利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法，所述事件请求包括：事件接收模块的地址信息和所述事件请求的数据信息；所述事件请求的数据信息为JSON格式。
图3是示出本申请实施例的利用上述所有实施例中所述的事件路由框架进行软件模块间的事件路由方法的设备的结构框图。
参照图3，所述WDM-FSO网络节点资源共享方法的测试设备，包括：处理器(processor)301、存储器(memory)302、通信接口(Communications Interface)303和总线304；
其中，
所述处理器301、存储器302、通信接口303通过所述总线304完成相互间的通信；
所述通信接口303用于该测试设备与软件模块间的事件路由的通信设备之间的信息传输；
所述处理器301用于调用所述存储器302中的程序指令，以执行上述各方法实施例所提供的方法，例如包括：步骤1，接收第一模块发送的事件请求；步骤2，确认所述事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中；步骤3，基于所述目标地址信息将所述事件请求发送给第二模块处理。
本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：步骤1，接收第一模块发送的事件请求；步骤2，确认所述事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中；步骤3，基于所述目标地址信息将所述事件请求发送给第二模块处理。
本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法，例如包括：步骤1，接收第一模块发送的事件请求；步骤2，确认所述事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中；步骤3，基于所述目标地址信息将所述事件请求发送给第二模块处理。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等 各种可以存储程序代码的介质。
以上所描述的软件模块间的事件路由方法的设备等实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后，本申请的方法仅为较佳的实施方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

  1. 一种事件路由框架，其特征在于，包括事件订阅层、事件处理层和接口层：
    所述事件订阅层与所述接口层相连，用于通过识别软件中各模块标识信息的方式，将所述各模块中与所述标识信息对应的事件存储在所述事件订阅层的订阅者集合中；
    所述接口层分别与所述事件订阅层和事件处理层相连，用于接收第一模块发送的事件请求，基于所述事件请求中的目标地址信息将所述事件请求发送给第二模块处理；
    所述事件处理层与所述接口层相连，用于确认事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中。
  2. 如权利要求1所述的框架，其特征在于，所述事件处理层还包括：路由机制单元，用于利用事件请求处理优先级机制、事件请求并发处理机制和事件请求缓存机制中的至少一种，进行所述事件请求的处理。
  3. 如权利要求1所述的框架，其特征在于，所述事件处理层还包括：
    删除单元，用于实时监控所述第一模块是否发出退出路由框架的请求；当检测到所述第一模块发出退出路由框架的请求时，建立至少一个新的线程用于删除所述第一模块在所述框架中的相关事件请求信息。
  4. 如权利要求1所述的框架，其特征在于，所述事件订阅层还包 括存储单元，用于将所述各模块中与所述标识信息对应的事件存储以静态变量的形式存储在订阅者集合中。
  5. 如权利要求3所述的框架，其特征在于，所述路由机制单元进一步用于：根据事件请求的优先级高低，在待处理队列中对所有事件请求进行由高到低的排序，根据排序对所述事件请求进行处理。
  6. 如权利要求3所述的框架，其特征在于，所述路由机制单元进一步包括用于：
    S1，将多个事件请求设计为一个同步队列，在所述同步队列内设置一个锁钥对；
    S2，当事件请求到达所述同步队列后，首先搜寻所述同步队列的钥匙：当成功获取钥匙时，所述同步队列将所述事件请求添加到待处理队列中，当获取钥匙失败时，将所述事件请求加入缓存队列中；
    S3，通过不断触发预设事件的方式使得所述事件请求再次进入所述同步队列执行所述s2，直至该事件请求成功获取所述同步队列的钥匙。
  7. 如权利要求3所述的框架，其特征在于，所述路由机制单元进一步用于：将所述事件处理层待处理的所有目标事件添加至同一个缓存队列；确认新的事件请求存在于所述缓存队列中，将所述缓存队列中的所述新的事件请求再次投递到消息队列中；所述缓存队列能够存储的目标事件的上限为n，其中n＞0。
  8. 如权利要求5至7任一所述的框架，其特征在于，所述删除单 元进一步用于删除以下请求中的至少一种：所述待处理队列中所述第一模块发送的所有事件请求、所述同步队列中所述第一模块发送的所有事件请求和所述缓存队中所述第一模块发送的所有事件请求。
  9. 一种利用权利要求1-7所述的框架进行事件路由的方法，其特征在于，包括：
    步骤1，接收第一模块发送的事件请求；
    步骤2，确认所述事件请求中的目标地址信息所指向的事件存在于所述路由框架的订阅者集合中；
    步骤3，基于所述目标地址信息将所述事件请求发送给第二模块处理。
  10. 如权利要求9所述的方法，其特征在于，所述步骤2前还包括：
    步骤1’，通过识别所述软件中各模块标识信息的方法，将所述各模块中与所述标识信息对应的事件存储在所述框架中事件订阅层的订阅者集合中。
  11. 一种事件路由导出方法的设备，其特征在于，包括：
    至少一个处理器；以及
    与所述处理器通信连接的至少一个存储器，其中：
    所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求9至10任一所述的方法。
  12. 一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如权利要求9至10任一所述的方法。
  13. 一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行如权利要求9至10任一所述的方法。
PCT/CN2017/120184 2017-04-12 2017-12-29 一种软件模块间的事件路由框架及方法 WO2018188381A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710237608.X 2017-04-12
CN201710237608.XA CN107066341B (zh) 2017-04-12 2017-04-12 一种软件模块间的事件路由框架及方法

Publications (1)

Publication Number Publication Date
WO2018188381A1 true WO2018188381A1 (zh) 2018-10-18

Family

ID=59602713

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/120184 WO2018188381A1 (zh) 2017-04-12 2017-12-29 一种软件模块间的事件路由框架及方法

Country Status (2)

Country Link
CN (1) CN107066341B (zh)
WO (1) WO2018188381A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107066341B (zh) * 2017-04-12 2020-08-04 武汉斗鱼网络科技有限公司 一种软件模块间的事件路由框架及方法
CN110347371A (zh) * 2018-04-03 2019-10-18 北京京东尚科信息技术有限公司 一种模块间通信的方法和装置
CN111352742B (zh) * 2018-12-21 2024-02-09 三六零科技集团有限公司 一种基于app组件化的信息传递方法及装置
CN111338659B (zh) * 2020-02-28 2023-06-02 广州市百果园信息技术有限公司 安装包生成方法、消息管理方法、装置、设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1056007A2 (en) * 1999-05-28 2000-11-29 Lucent Technologies Inc. System and method of exchanging information between software modules
CN101315609A (zh) * 2007-05-31 2008-12-03 华为技术有限公司 实现单进程中组件间进行通信的装置和方法
CN101458637A (zh) * 2007-12-13 2009-06-17 华为技术有限公司 一种实现进程通信的方法、装置及系统
CN103458033A (zh) * 2013-09-04 2013-12-18 北京邮电大学 事件驱动、面向服务的物联网服务提供系统及其工作方法
CN104239037A (zh) * 2014-08-25 2014-12-24 中国电子科技集团公司第二十九研究所 一种业务功能可重构的软件框架
CN107066341A (zh) * 2017-04-12 2017-08-18 武汉斗鱼网络科技有限公司 一种软件模块间的事件路由框架及方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1056007A2 (en) * 1999-05-28 2000-11-29 Lucent Technologies Inc. System and method of exchanging information between software modules
CN101315609A (zh) * 2007-05-31 2008-12-03 华为技术有限公司 实现单进程中组件间进行通信的装置和方法
CN101458637A (zh) * 2007-12-13 2009-06-17 华为技术有限公司 一种实现进程通信的方法、装置及系统
CN103458033A (zh) * 2013-09-04 2013-12-18 北京邮电大学 事件驱动、面向服务的物联网服务提供系统及其工作方法
CN104239037A (zh) * 2014-08-25 2014-12-24 中国电子科技集团公司第二十九研究所 一种业务功能可重构的软件框架
CN107066341A (zh) * 2017-04-12 2017-08-18 武汉斗鱼网络科技有限公司 一种软件模块间的事件路由框架及方法

Also Published As

Publication number Publication date
CN107066341A (zh) 2017-08-18
CN107066341B (zh) 2020-08-04

Similar Documents

Publication Publication Date Title
WO2018188381A1 (zh) 一种软件模块间的事件路由框架及方法
US11411897B2 (en) Communication method and communication apparatus for message queue telemetry transport
US9020885B2 (en) Systems and methods for collaboration shared state management
CN102197627B (zh) 组播流量收敛的改善
CN104754065B (zh) 基于内容中心网络的动态分布Web资源管理方法及系统
US8719780B2 (en) Application server with a protocol-neutral programming model for developing telecommunications-based applications
US8364124B2 (en) Methods, systems, and computer readable media for tokenization of multimedia messages
KR102136945B1 (ko) Fix 프로토콜에 기반한 서비스 구현 방법, 장치 및 시스템
CN106453625B (zh) 信息同步方法及高可用性集群系统
CN105187372A (zh) 一种基于移动应用入口的数据处理方法、装置和系统
US20050278294A1 (en) Systems and methods for a collaboration presence framework
CN110162559B (zh) 一种基于通用json同步和异步数据api接口调用的区块链处理方法
CN110297620A (zh) 一种基于Drools的动态规则维护和生成的方法
CN1761244A (zh) 设置边界网关协议路由选择通知功能的方法
WO2023011274A1 (zh) 一种通讯协议转换方法、设备、系统及网关设备
CN111935017B (zh) 跨网络的应用调用方法、装置及路由设备
CN113326272A (zh) 分布式事务的处理方法、装置及系统
US20220100644A1 (en) METHOD AND SYSTEM FOR AUTOMATED TESTING OF WEB SERVICE APIs
EP2224381A1 (en) Method and apparatus for case-based service composition
CN103957173B (zh) 语义交换机
WO2021093671A1 (zh) 任务处理方法、系统、装置、设备及计算机可读存储介质
CN107347100A (zh) 一种内容分发网络的透明代理转发方法
WO2023142605A1 (zh) 一种基于区块链的数据处理方法和相关装置
CN105812178A (zh) 一种终端升级方法及终端
CN110287045A (zh) 一种基于solaris操作系统的存储服务接口管理框架

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17905230

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17905230

Country of ref document: EP

Kind code of ref document: A1