WO2021120693A1 - 一种新旧代码共同运行的kbroker分布式操作系统 - Google Patents

一种新旧代码共同运行的kbroker分布式操作系统 Download PDF

Info

Publication number
WO2021120693A1
WO2021120693A1 PCT/CN2020/112829 CN2020112829W WO2021120693A1 WO 2021120693 A1 WO2021120693 A1 WO 2021120693A1 CN 2020112829 W CN2020112829 W CN 2020112829W WO 2021120693 A1 WO2021120693 A1 WO 2021120693A1
Authority
WO
WIPO (PCT)
Prior art keywords
app
kbroker
service module
module
operating system
Prior art date
Application number
PCT/CN2020/112829
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 WO2021120693A1 publication Critical patent/WO2021120693A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/76—Adapting program code to run in a different environment; Porting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level

Definitions

  • the invention relates to the field of server-side software development and operation and maintenance systems, in particular to a kbroker distributed operating system in which new and old codes run together.
  • the purpose of the present invention is to provide a kbroker distributed operating system with new and old codes running together to solve the problems in the prior art:
  • a kbroker distributed operating system with new and old codes running together which is characterized in that it includes:
  • the business layer module is used to implement the business logic of the entire system; the business logic is split into a number of applications, and each application includes a corresponding set of app_allocator modules and at least one set of app_service modules;
  • the app_service module is used to run the app_object object of the application, provides a unified interface in the kbroker distributed operating system to access the app_object object running on it, and provides an interface to the business layer to access other app_object objects in the kbroker distributed operating system;
  • the business logic is implemented by the logical processing of the app_object object of the business layer running on the app_service module and the mutual calls between the app_object objects;
  • the app_allocator module is used to manage the startup and shutdown of the app_service module required for the logical operation of the application, the creation and deletion of the app_object object, and the management and allocation of the app_object object to run in the app_service module; the app_allocator module groups the app_service modules for each group Set the group number, the group number is the virtual_id number, responsible for the master-slave disaster recovery of the app_service module in the group;
  • the kbroker_server module is used to manage the server where it is located in the kbroker distributed operating system.
  • the kbroker_server module manages the app_service module, app_allocator module and storage resources on the server where it is located; data communication connections between multiple kbroker_server modules;
  • the kbroker_super module is used to manage the server where the kbroker_server module is located through the kbroker_server module; manage all program processes in the kbroker distributed operating system through the kbroker_server module, and set the process number program_id for each program process; manage business layer applications, and Set the application number app_id for each business layer application;
  • the app_object object is identified by the app_id number of the application and the object_id number on the application; the operating mode of the app_object object includes standard mode and extended mode; the standard mode is used for writing and running new code; in the standard mode, the app_object object runs Inside the app_service module program, through the internal interface provided by the app_service module to interact with the kbroker distributed operating system; the extended mode is used to run the old code; in the extended mode, the logical processing of the app_object object runs as a business layer independent execution program Outside the app_service module, it is connected to the app_service module through an external interface to realize the data interaction of the same kbroker distributed operating system.
  • a storage resource is a storage medium used to save data to prevent data loss or temporarily save data after the kbroker distributed operating system restarts,
  • the deployment methods of storage resources include deployment in the kbroker distributed system and deployment outside the kbroker distributed system; when the storage resources are deployed in the kbroker distributed system, the kbroker_server module is responsible for creating the server where it is located The above is managed by the kbroker_super module; when the storage resource deployment method is deployed outside the kbroker distributed operating system, it provides an access interface for the applications in the kbroker distributed system to call.
  • app_allocator module is used to manage the master-slave disaster recovery of the app_service module
  • the app_service modules of all applications support master-slave disaster recovery, and treat applications that do not require master-slave disaster recovery with the app_service module as a special case where there is only a master but no slave;
  • the app_allocator module groups the app_service modules, and each group has at least one app_service module as the main app_service module of the group; each group also includes the existence of the slave app_service module mode and the nonexistence of the app_service module mode, the existence of the slave app_service module mode is The app_service module requires master-slave disaster recovery, the non-existent app_service module mode is that the app_service module does not require master-slave disaster recovery, and the app_allocator module is used to manage and maintain the master-slave disaster recovery of the app_service module in the group;
  • the app_allocator module allocates the app_object object to the main app_service module of the specific group to run, and all requests for access are sent to the corresponding main app_service module for response processing.
  • the slave app_service module that requires the master and the disaster recovery is synchronized by the main app_service module of the group;
  • the app_allocator module is used to create a new group and start a new app_service module in the new group.
  • app_allocator module manages and allocates app_object objects
  • the app_allocator module allocates an app_object object to run on a grouped main app_service module, and provides a routing information interface for requesting the app_object object in the system;
  • the relationship between the app_object object of the application and the app_service module grouping includes an association relationship and a non-association relationship
  • the app_allocator module of the application saves the association relationship between the object_id number and the virtual_id number, and the association relationship between the app_service module group and the app_service module in the group; found when the app_object object is started Its associated virtual_id number corresponds to the main app_service module of the group to start and run; when creating an app_object object, first select a group, and then save the association relationship between the object_id number and the virtual_id number;
  • the app_allocator module selects a group from all running groups when starting the app_object object, and then starts and runs the group on the main app_service module of the selected group app_object object.
  • app_service module runs the business logic of the app_object object of the application
  • An app_object object runs on the only app_service module of the application in the same time period, and an app_service module runs multiple app_object objects of the application at the same time;
  • the app_service module creates and records the app_object object running on it according to the command of the app_allocator module.
  • the logic of the app_object object is implemented by the business layer.
  • the app_service module is responsible for starting and closing the operation of the app_object object;
  • the app_service module provides a master-slave disaster recovery framework, and cooperates with the business layer to achieve master-slave disaster recovery when the app_object object needs master-slave disaster recovery.
  • app_service module provides a unified interface to access the app_object object running on it
  • the coroutine When the app_object object runs in standard mode, the coroutine is used to solve the blocking problem in the logic operation. Its business logic runs on a single thread on the app_service module, and all requests are encapsulated into a coroutine and queued for execution; by rewriting the app_object object
  • the virtual base class app_object_i implements business logic and responds to external requests;
  • the app_service module converts the functional request access and notification request access of the app_object object running on it in the system into this
  • the business layer independently executes the interface supported by the program for invocation processing.
  • the business logic runs on the independent execution program of the business layer independent of the app_service module
  • the app_object object runs in the extended mode, its business logic runs on the business layer independent execution program.
  • One or more business layer independent execution programs and their affiliated components jointly complete the business logic operation of the app_object object, and its corresponding app_service
  • the modules together form a set of running collections of app_object objects, and respond to requests for access to the app_object objects running on it in the kbroker distributed operating system;
  • the app_service module is used to receive request access to the app_object object running on it in the kbroker distributed operating system, and forward the request access to the business layer executive program where the app_object object is located to complete the response processing; the business layer executive program provides access to the app_service module Access interface of the app_object object running on.
  • request access of the kbroker distributed operating system to the app_object object includes functional request access that requires a return value and notification request access that does not require a return value.
  • the business layer independent execution program of the app_object object is used for the logical operation of the app_object object
  • the accessory component is the storage resource corresponding to the app_object object in the extended mode
  • the deployment method of the accessory component includes deployment in the kbroker distributed system and distribution in kbroker Deployment outside the system.
  • the accessory component When the deployment method of the accessory component is independent deployment, the accessory component is a storage resource that is exclusive to each group of business layer independent execution programs. It is deployed together with the business layer execution program.
  • the app_service module provides master-slave disaster recovery for the auxiliary components. All the subsidiary components corresponding to the independent execution program of the group business layer are used as a storage resource in the kbroker distributed operating system, and the kbroker_server module is selected by the kbroker_super module to create and manage;
  • the application is a storage application and is used to manage storage resources corresponding to the auxiliary component.
  • the business layer accesses the app_object of the application. Object to access subsidiary components.
  • app_service module provides an interface for the business layer to access other app_object objects in the kbroker distributed operating system
  • the business layer directly calls the internal function call interface provided by app_service, accesses the interface of other app_object object function calls to avoid blocking through coroutine processing, and provides additional asynchronous events, delayed events, and coordination.
  • Programmable lock and signal interface
  • the app_service module When the app_object object runs in the extended mode, the app_service module provides interface extensions for the business layer to use; the interface for the app_service module to access other app_object object functional calls is a blocking remote call, and the business layer handles the blocking event on the app_object object logic operation At the same time, it provides interfaces for adding asynchronous events, delayed events, and lock operations. The added asynchronous and delayed events are saved by the app_service module, and then the business layer execution program is called back for execution processing.
  • the distributed operating system of the present invention applied to multiple servers has the following beneficial effects:
  • the existing code can be migrated to run on the kbroker distributed operating system after simple interface modification
  • Fig. 1 shows a schematic diagram of the module structure of a distributed operating system applied to multiple servers in an embodiment of the present invention.
  • the present invention provides a kbroker distributed operating system with new and old codes running together.
  • the business layer module is used to implement the business logic of the entire system.
  • the business logic is split into several applications, and each application includes a set of corresponding The app_allocator module, at least one set of app_service modules.
  • the app_service module is used to run the app_object object of the application, provides a unified interface in the kbroker distributed operating system to access the app_object object running on it, and provides an interface to the business layer to access other app_object objects in the kbroker distributed operating system;
  • the business logic is implemented by the logical processing of the app_object object in the business layer running on the app_service module and the mutual calls between the app_object objects.
  • the app_allocator module is used to manage the startup and shutdown of the app_service module required for the logical operation of the application, the creation and deletion of the app_object object, and the management and allocation of the app_object object to run in the app_service module; the app_allocator module groups the app_service modules for each group Set the virtual_id number, responsible for the master-slave disaster recovery of the app_service module in the group.
  • the kbroker_server module is used to manage the server where it is located in the kbroker distributed operating system.
  • the kbroker_server module manages the app_service module, app_allocator module and storage resources on the server where it is located; data communication connections between multiple kbroker_server modules.
  • the kbroker_super module is used to manage the server where the kbroker_server module is located through the kbroker_server module; manage all program processes in the kbroker distributed operating system through the kbroker_server module, and set the process number program_id for each program process; manage business layer applications, and Set the application number app_id for each business layer application.
  • the app_object object is identified by the app_id number of the application and the object_id number on the application; the operating mode of the app_object object includes standard mode and extended mode; the standard mode is used for writing and running new code; in the standard mode, the app_object object runs Inside the app_service module program, through the internal interface provided by the app_service module to interact with the kbroker distributed operating system; the extended mode is used to run the old code; in the extended mode, the logical processing of the app_object object runs as a business layer independent execution program Outside the app_service module, it is connected to the app_service module through an external interface to realize the data interaction of the same kbroker distributed operating system.
  • Storage resources are storage media that are used to save data to prevent data loss or temporarily save data after the kbroker distributed operating system restarts. It can be a computer storage medium such as a disk or an independent third-party executable program.
  • the deployment methods of storage resources include deployment in the kbroker distributed system and deployment outside the kbroker distributed system; when the storage resources are deployed in the kbroker distributed system, the kbroker_server module is responsible for creating the server where it is located The above is managed by the kbroker_super module; when the storage resource deployment method is deployed outside the kbroker distributed operating system, it provides an access interface for the applications in the kbroker distributed system to call.
  • the whole system is to achieve the goal of business logic by the logical processing of the app_object object and the mutual call between the app_object object.
  • the app_allocator module is used to realize the management and allocation of the app_object object
  • the app_service module is used to encapsulate the app_object object. Logic processing and response processing to external requests.
  • each app_object object can only run on one app_service module at a time.
  • the app_service module is responsible for receiving all access requests to the app_object object and handing these requests to the app_object object for processing.
  • the app_service module exists to achieve the encapsulation of the app_object object, which shields the difference in the implementation of the app_object object.
  • the realization of the encapsulation of the app_object object into the app_service module is essentially to solve the impact of blocking calls on the business logic processing of the app_object object.
  • the third is to use a coroutine to solve the blocking problem.
  • the original kbroker distributed operating system used coroutines to solve the blocking problem which corresponds to the standard mode in this patent; the existing common server-side programs generally solve the blocking problem through multi-process or multi-threaded methods.
  • Asynchronous calls can also be used to solve the blocking problem, but the solution of asynchronous calls will cause the code logic to be scattered and increase the complexity of writing.
  • the encapsulation of existing programs corresponds to the expansion mode of this patent.
  • the app_allocator module is used to manage the master-slave disaster recovery of the app_service module.
  • the app_service modules of all applications support master-slave disaster recovery.
  • the app_service module does not require a master-slave disaster recovery application as a special case where there is only a master and no slave.
  • the app_allocator module groups the app_service modules, and each group has at least one app_service module as the main app_service module of the group; each group also includes the existence of the slave app_service module mode and the nonexistence of the app_service module mode, the existence of the slave app_service module mode is
  • the app_service module requires master-slave disaster recovery, the non-existent app_service module mode is that the app_service module does not require master-slave disaster recovery, and the app_allocator module is used to manage and maintain the master-slave disaster recovery of the app_service module in the group.
  • the app_allocator module allocates app_object objects to the main app_service module of the specific group to run, and all requests for access are sent to the corresponding main app_service module for response processing.
  • the slave app_service module that requires the master and the disaster recovery is synchronized by the main app_service module of the group.
  • the app_allocator module creates a new group and starts a new app_service module in the new group.
  • the app_service module supports master-slave disaster recovery by default, which enhances the robustness and reliability of the system and reduces the maintenance work during runtime. Regarding supporting master-slave disaster recovery as the normal state, and not supporting master-slave disaster recovery as a special case of only master and no slave, on the one hand, it supports the demand for master-slave disaster recovery in various situations and not only when there are storage resources. Supporting master-slave disaster recovery can better enhance the stability of the system. In addition, a unified logical system can be used to handle both supporting and not supporting master-slave disaster recovery, which greatly reduces the complexity of code maintenance.
  • the above app_allocator module implements a master-slave disaster recovery management module, which cooperates with the master-slave disaster recovery processing module implemented by the app_service module to realize the master-slave disaster recovery of the app_service module.
  • the app_allocator module manages and allocates app_object objects.
  • the app_allocator module allocates an app_object object to run on a grouped main app_service module, and provides a routing information interface requesting the app_object object in the system.
  • the routing information is which main app_service the app_object object is running on.
  • the relationship between the app_object object of the application and the grouping of the app_service module includes an association relationship and a non-association relationship.
  • the app_allocator module of the application saves the association relationship between the object_id number and the virtual_id number, and the association relationship between the app_service module group and the app_service module in the group; found when the app_object object is started Its associated virtual_id number corresponds to the main app_service module of the group to start and run; when creating an app_object object, first select a group, and then save the association relationship between the object_id number and the virtual_id number.
  • the app_allocator module selects a group from all running groups when starting the app_object object, and then starts and runs the group on the main app_service module of the selected group app_object object.
  • the above operation is based on the app_service module to support the master-slave disaster recovery, because both support the master-slave disaster recovery, the difference is only whether there is a slave app_service module, which determines that the allocation of app_object objects is based on the master of the app_service module From the disaster recovery group, the app_object object runs on the main app_service module of the corresponding master-slave disaster recovery group. Whether the app_object object is associated and bound with the app_service module group solves the problem of whether the app_object object still needs to be allocated to the last allocated app_service module group after each startup.
  • the storage application on the original kbroker distributed operating system corresponds to app_object
  • this patent uses the association binding relationship to identify whether the app_object object needs to be allocated to the original app_service module group after the startup. This is based on processing the original storage application to deal with more similar Leave room for the situation.
  • association relationship between the object_id number of the app_object object stored by the app_allocator module and the virtual_id number of the app_service module group is stored on a non-volatile storage medium; the association relationship between the app_service module group and the app_service module in the group is also stored in a non-volatile storage medium.
  • the association relationship is mainly to save the relevant information that can mark the specific kbroker_server module of the app_service module instead of the program_id number of the app_service module, such as storage Storage resources used by the app_service module of a type application.
  • the app_service module runs the business logic of the app_object object of the application.
  • An app_object object runs on the only app_service module of the application at the same time period, and an app_service module runs multiple app_object objects of the application at the same time.
  • the app_service module creates and records the app_object object running on it according to the command of the app_allocator module.
  • the logic of the app_object object is implemented by the business layer.
  • the app_service module is responsible for starting and closing the operation of the app_object object.
  • the app_service module provides a master-slave disaster recovery framework, and cooperates with the business layer to achieve master-slave disaster recovery when the app_object object needs master-slave disaster recovery.
  • the app_service module is responsible for encapsulating the app_object object, so that the difference in the implementation of the app_object object is shielded when called in the system.
  • the standard mode provided here corresponds to the logical processing solution of the app_object object in the original kbroker distributed operating system.
  • the extended mode is used to run existing codes or develop in a familiar development method.
  • the core difference is the business in the standard mode.
  • the logic and app_service module are combined into one.
  • the business logic and app_service module run in independent execution programs, and communicate with each other through the interface access between each other, so that the existing code can be realized Run in its normal operation mode, so that the original code can be migrated to the kbroker distributed system to run with as few code changes as possible, and it also allows developers to perform applications on the kbroker distributed system according to the original development method Development.
  • the app_service module provides a master-slave disaster recovery framework.
  • the master-slave disaster recovery framework is implemented by an independent master-slave disaster recovery module in each app_service module with the corresponding master-slave disaster recovery management module of the app_allocator module.
  • the master app_service module sends synchronization information to the slave app_service module through the master-slave disaster recovery module, and the slave app_service module receives and executes the synchronization information through the master-slave disaster recovery module.
  • Each logic module in the app_service module that requires master-slave synchronization is registered in its master-slave disaster recovery module.
  • the synchronization information sent by each logic module and the execution logic of the synchronization information are defined by the logic module itself, on the main app_service module
  • the synchronization information sent by each logic module is passed to the master-slave disaster recovery module of the slave app_service module through the master-slave disaster recovery module, and then passed from the master-slave disaster recovery module of the app_service module to the corresponding logic module to process the synchronization information.
  • the master-slave disaster recovery module of the app_service module provides framework support for the realization of master-slave switching in the process of master-slave disaster recovery, registration from app_service module to main app_service module, data export and import, among which data export and import, and synchronization information sending
  • the processing work after execution and switching to the master is implemented by each logic module that needs to be synchronized, and other unified logic is implemented by the master-slave disaster recovery framework.
  • the app_service module provides a unified interface to access the app_object object running on it.
  • the coroutine is used to solve the blocking problem in the logic operation. Its business logic runs on a single thread on the app_service module. Requests are encapsulated into a coroutine and executed in sequence; the virtual base class app_object_i of the app_object object is rewritten to implement business logic and respond to external requests.
  • the app_service module converts the functional request access and notification request access of the app_object object running on it in the system into this
  • the business layer independently executes the interface supported by the program for invocation processing.
  • the standard mode is the solution provided by the original kbroker distributed operating system, which is mainly to solve the blocking problem through coroutines, and then run the app_object object on the same thread to support the app_service module to directly call its interface.
  • the business logic runs on the independent execution program of the business layer independent of the app_service module.
  • the app_object object runs in the extended mode, its business logic runs on the business layer independent execution program.
  • One or more business layer independent execution programs and their affiliated components jointly complete the business logic operation of the app_object object, and its corresponding app_service
  • the modules together form a set of running collections of app_object objects, and respond to requests for access to the app_object objects running on it in the kbroker distributed operating system.
  • the app_service module is used to receive request access to the app_object object running on it in the kbroker distributed operating system, and forward the request access to the business layer executive program where the app_object object is located to complete the response processing; the business layer executive program provides access to the app_service module Access interface of the app_object object running on.
  • the kbroker distributed operating system's request access to the app_object object includes functional request access that requires a return value and notification request access that does not require a return value.
  • the expansion mode is to deploy the original code into multiple small execution groups. Each group is supported by the original business layer executive program running the original code to support all the original functions but the supported load range (the number of app_object objects) is relatively small.
  • a grouping and app_service module are combined and encapsulated together, and then the system supports all load ranges by grouping multiple app_service modules with their original business layer execution program by the system running multiple app_service modules at the same time.
  • the system is responsible for assigning the access of the app_object object to the corresponding app_service module to run, and the app_service module converts the access into an interface that can be supported by running the original business layer executive program to handle the access.
  • the original business layer executive program needs to be encapsulated with a container.
  • the app_service module is responsible for implementing the container function and the communication connection with the inside and outside of the container, the original business layer executive program and its subsidiary components It runs in the container and provides an interface to support the invocation of the app_service module.
  • the app_service module converts the access request sent by the system to the business layer execution program in the container for processing.
  • the original business layer executive program uses such a package to be externally displayed as a running collection of running a certain number of app_object objects, realizing the migration and running of the original code to the kbroker distributed operating system.
  • the app_object object in the extended mode is composed of one or more business layer independent execution programs and its subsidiary components to complete the business logic operation of the app_object object.
  • the business layer independent execution program of the app_object object is used for the logical operation of the app_object object.
  • the subsidiary components are in normal conditions.
  • the following is the data storage for the app_object object in the extended mode; the accessory component is the storage resource corresponding to the app_object object in the extended mode.
  • the deployment method of the accessory component includes deployment in the kbroker distributed system and deployment outside the kbroker distributed system. When the auxiliary component deployment method is deployed outside the kbroker distributed system, it is consistent with the traditional deployment method; when the auxiliary component deployment method is deployed in the kbroker distributed system, the deployment method includes independent deployment and application deployment.
  • the accessory component When the deployment method of the accessory component is independent deployment, the accessory component is a storage resource that is exclusive to each group of business layer independent execution programs. It is deployed together with the business layer execution program.
  • the app_service module provides master-slave disaster recovery for the auxiliary components. All auxiliary components corresponding to the independent execution program of the group business layer are used as a storage resource in the kbroker distributed operating system, and the kbroker_server module is selected by the kbroker_super module to create and manage.
  • the deployment method of the auxiliary component is application deployment, create a separate application for the auxiliary component.
  • the application is a storage application and is used to manage storage resources corresponding to the auxiliary component.
  • the business layer accesses the app_object of the application. Object to access subsidiary components.
  • connection operation part of the additional components that save the data.
  • additional components are mainly the cache and the database. Others such as message queues and delay programs are all provided by the interface provided by the system. deal with.
  • the original traditional deployment method of accessory components is to deploy them separately, and then provide an access interface for the execution program to call. When the accessory components are deployed outside the kbroker distributed system, they can be deployed like the traditional deployment method before.
  • the simplest way to deploy the cache and database is to deploy them in the same container with the original business layer execution program, and then access them through the access library provided by the system, using the system provided
  • the access class library is to synchronize the messages of the corresponding slave add-on components while performing access operations to achieve master-slave disaster recovery; another improved form of deployment is to implement it into a corresponding storage application, which is very It is convenient to realize the management and disaster recovery of add-on components.
  • the original method of directly accessing add-on components can be replaced by object access to the new storage application.
  • the app_service module provides an interface for the business layer to access other app_object objects in the kbroker distributed operating system.
  • the business layer directly calls the internal function call interface provided by app_service, and accesses other app_object object functional call interfaces through Coroutine processing to avoid blocking, while providing an interface for adding asynchronous events, delay events, coroutine locks and signals.
  • the app_service module provides interface extensions for the business layer to use; the interface for the app_service module to access other app_object object functional calls is a blocking remote call, and the business layer handles the blocking event on the app_object object logic operation At the same time, it provides interfaces for adding asynchronous events, delayed events, and lock operations. The added asynchronous and delayed events are saved by the app_service module, and then the business layer execution program is called back for execution processing.
  • the core of the whole system is to deal with the blocking problem caused by remote calls, so that the business logic of an app_object object can be run on an app_service module.
  • the original solution provided by the kbroker distributed operating system is caused by processing calls in the coroutine mode.
  • Blocking problem traditional server-side development is to deal with blocking problems caused by remote calls through a multi-process method. From the perspective of technical realization capabilities, processes, threads, and coroutines can all handle blocking problems caused by calls.
  • the system In the standard mode, the system directly provides remote or local calls based on the coroutine, and the business layer does not need to care about the blocking problem.
  • the extended mode the system provides a blocking call interface, using the multi-process or local code used in the original code.
  • the delay and asynchronous interface provided in the extended mode is to replace the message queue and timing callback used in traditional server-side development, so as to facilitate deployment and maintenance.
  • the kbroker_super module and kbroker_server module in the original kbroker distributed operating system have not changed much, mainly in the app_allocator module and app_service module.
  • the functional changes of the app_allocator module are mainly focused on treating all app_service modules as supporting master-slave disaster recovery, taking the app_service module that supports master-slave disaster recovery as the normal state, and taking the app_service module that does not support master-slave disaster recovery as a special case.
  • the business layer realizes unified processing and enhances the availability of the system in the case of various master-slave disaster recovery requirements.
  • the app_service module in the standard mode also provides a class library for the business layer to use, which is consistent with the core functions of the app_service class library provided by the original kbroker distributed operating system.
  • the main change is to add a master-slave disaster recovery management module to make various All types of app_service modules can easily implement the master-slave disaster recovery of its own logic modules and additional components with the cooperation of the app_allocator module.
  • the app_service module in the extended mode also provides a class library for the business layer to use.
  • the route cache provided by the original kbroker distributed operating system app_service class library and the currently running app_object object are also the same as before. Create, start and close app_object objects.
  • the interface is implemented by the business layer calling the interface provided by the business layer independent execution program; in addition, the business layer mainly writes the strategy for converting the access request of the app_object object in the system into the business layer independent execution program access interface.
  • the app_service module in the extended mode provides an extension library file used by the business layer for the business layer to access the app_service module.
  • the extension file is connected to the app_service module for data interaction through inter-process communication.
  • the code developed under the existing development model generally has components responsible for saving data such as cache and database.
  • the business code is responsible for logic processing and has nothing to do with the specific app_object object.
  • the corresponding app_object object is obtained from the cache or database according to the parameters when the business code is running. Rebuild the app_object object from the data, and then execute the corresponding logical processing.
  • the components that store data such as cache and database are classified as app_service module to manage and implement master-slave disaster recovery and provide access interfaces for business layer code calls.
  • Existing codes follow the original Run mode to deploy and run.
  • the kbroker distributed operating system splits the access into multiple app_service modules for processing through the app_object object mode.
  • Each app_service module uses the original code to deploy and run a small-scale original service to support access.
  • the system provides master-slave disaster recovery for data storage components, which realizes the migration of existing code to run on the kbroker distributed system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

本发明属于服务器端的软件开发和运维系统。kbroker分布式操作系统提供了一种对服务器集群的维护和开发架构，但其并没有提供针对现有代码如何迁移到其上运行的处理方案，本发明就是在kbroker分布式操作系统的基础上提供一种针对将现有代码迁移到kbroker分布式系统上与在其上开发的新代码一起运行的处理方法，使得可以在少量修改的情况下迁移原有代码到kbroker分布式系统上运行，当然也相应提供了一种在传统开发方式下开发kbroker分布式操作系统上应用程序的方法。在本发明的支持下可以极大提升kbroker分布式操作系统的适用范围和降低使用难度。

Description

一种新旧代码共同运行的kbroker分布式操作系统 技术领域
本发明涉及服务器端的软件开发和运维系统领域，特别是涉及一种新旧代码共同运行的kbroker分布式操作系统。
背景技术
鉴于kbroker分布式操作系统的开发方法虽然是最基础最传统的开发方法，但和现有服务端的开发方法并不相同，这就导致了现有大量已经开发的业务逻辑代码无法在kbroker分布式操作系统上运行，如果要将现有的业务迁移到kbroker分布式系统上运行就需要重写代码，这个迁移成本无疑是难以接受的；同时大家也一定程度上习惯了现有的开发方法，虽然改变并不是很难，但提供一种兼容现有开发方法的解决方案也是很有价值的；最后原有的开发方法下需要用到很多缓存和数据库之类的辅助组件，在运行时需要运维人员考虑这些辅助组件的灾备和监控等工作，而在kbroker分布式系统上这些工作都是由系统本身来提供的，如何在支持现有代码运行的同时对其使用到的辅助组件进行灾备支持也是需要考虑的。
发明内容
鉴于以上所述现有技术的缺点，本发明的目的在于提供一种新旧代码共同运行的kbroker分布式操作系统，用于解决现有技术中的问题：
第一，现有代码无法简单的迁移到kbroker分布式系统上运行。
第二，开发者无法按照原来开发方法开发kbroker分布式系统上的应用程序。
为解决上述技术问题，本发明是按如下方式实现的：一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，包括：
业务层模块，用于实现整个系统的业务逻辑；所述业务逻辑被拆分成若干个应用程序，每个应用程序包括与之对应的一组app_allocator模块和至少一组app_service模块；
app_service模块，用于运行应用程序的app_object对象，对kbroker分布式操作系统内提供统一的接口访问在其上运行的app_object对象，并且对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口；业务逻辑由运行在app_service模块上的业务层app_object对象的逻辑处理以及app_object对象之间的相互调用实现；
app_allocator模块，用于管理应用程序逻辑运行所需的app_service模块的启动和关闭、 app_object对象的创建和删除，并且管理和分配app_object对象在app_service模块运行；app_allocator模块将app_service模块进行分组，为每个分组设置分组编号，该分组编号为virtual_id编号，负责分组内app_service模块的主从灾备；
kbroker_server模块，用于管理kbroker分布式操作系统中其所在的服务器，kbroker_server模块管理其所在服务器上的app_service模块、app_allocator模块和存储型资源；多个kbroker_server模块之间数据通信连接；
kbroker_super模块，用于通过kbroker_server模块管理kbroker_server模块所在的服务器；通过kbroker_server模块管理kbroker分布式操作系统中的所有程序进程，并为每个程序进程设置进程编号program_id；管理业务层应用程序，并为每个业务层应用程序设置应用程序编号app_id；
app_object对象由应用程序的app_id编号和应用程序上的对象object_id编号来标识；app_object对象的运行模式包括标准模式和扩展模式；标准模式用于新代码的编写和运行；在标准模式下，app_object对象运行在app_service模块的程序内部，通过app_service模块提供的内部接口与kbroker分布式操作系统进行数据交互；扩展模式用于老代码的运行；在扩展模式下，app_object对象的逻辑处理作为业务层独立执行程序运行在app_service模块外部，通过外部接口与app_service模块连接以实现相同kbroker分布式操作系统的数据交互。
进一步地，存储型资源为用于保存数据防止kbroker分布式操作系统重启后丢失数据或临时保存数据的存储介质，
存储型资源的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署；当存储型资源的部署方式为在kbroker分布式系统内部署时，由kbroker_server模块负责创建在其所在的服务器上，由kbroker_super模块负责管理；当存储型资源部署方式为在kbroker分布式操作系统外部署时，提供访问接口给kbroker分布式系统内的应用程序进行调用。
进一步地，app_allocator模块用于管理app_service模块的主从灾备，
所有应用程序的app_service模块都支持主从灾备，将app_service模块不需要主从灾备的应用程序作为只有主没有从的特例处理；
app_allocator模块将app_service模块进行分组，每个分组至少有一个app_service模块作为该分组的主app_service模块；每个分组还包括存在从app_service模块模式和不存在从app_service模块模式，所述存在从app_service模块模式为app_service模块需要主从灾备，所述不存在从app_service模块模式为app_service模块不需要主从灾备，并且app_allocator模块用于管理维护该分组内app_service模块的主从灾备；
app_allocator模块分配app_object对象到具体分组的主app_service模块上运行，所有请求访问发送到该对应的主app_service模块上进行响应处理，需要主从灾备的从app_service模块由该分组的主app_service模块同步数据；
当现有分组无法满足该应用程序的app_object对象的运行需要时，app_allocator模块用于创建新的分组和启动新分组内新的app_service模块。
进一步地，app_allocator模块管理和分配app_object对象，
app_allocator模块分配一个app_object对象在一个分组的主app_service模块上运行，并对系统内提供请求该app_object对象的路由信息接口；
应用程序的app_object对象与app_service模块分组的关系包括关联关系和非关联关系；
当应用程序的app_object对象与app_service模块分组的关系为关联关系时，应用程序的app_allocator模块保存object_id编号和virtual_id编号的关联关系、app_service模块分组与其分组内app_service模块的关联关系；启动该app_object对象时找到其关联virtual_id编号对应分组的主app_service模块进行启动和运行；创建app_object对象时先选择一个分组，然后保存object_id编号和virtual_id编号的关联关系；
当应用程序的app_object对象与app_service模块分组的关系为非关联关系时，app_allocator模块启动该app_object对象时从所有正在运行的分组中选择一个分组，然后在被选择分组的主app_service模块上启动和运行该app_object对象。
进一步地，app_service模块运行该应用程序app_object对象的业务逻辑，
一个app_object对象在同一个时间段运行在唯一一个该应用程序的app_service模块上，一个app_service模块同时运行多个该应用程序的app_object对象；
app_service模块根据app_allocator模块的命令创建并记录在其上运行的app_object对象，app_object对象的逻辑由业务层实现，启动和关闭app_object对象的运行由app_service模块负责；
app_service模块提供主从灾备框架，在app_object对象需要主从灾备的情况下配合业务层实现主从灾备。
进一步地，app_service模块提供统一的接口访问在其上运行的app_object对象，
当app_object对象运行在标准模式下，利用协程解决逻辑运行中的阻塞问题，其业务逻辑在app_service模块上的一个单线程上运行，所有请求封装成协程排队依次执行；通过重写app_object对象的虚基类app_object_i实现业务逻辑和响应外部请求；
当app_object对象运行在扩展模式下，其业务逻辑运行在独立于app_service模块的业务 层独立执行程序上，app_service模块将系统内对其上运行app_object对象的函数型请求访问和通知型请求访问转换成该业务层独立执行程序支持的接口进行调用处理。
进一步地，当app_object对象运行在扩展模式下，业务逻辑运行在独立于app_service模块的业务层独立执行程序上，
当app_object对象运行在扩展模式下，其业务逻辑运行在业务层独立执行程序上，由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，并与其对应的app_service模块一起组成一组app_object对象的运行集合，响应处理kbroker分布式操作系统内对其上运行app_object对象的请求访问；
app_service模块用于接收kbroker分布式操作系统内对其上运行的app_object对象的请求访问，并将请求访问转发给app_object对象所在业务层执行程序以完成响应处理；业务层执行程序为app_service模块提供访问其上运行的app_object对象的访问接口。
进一步地，kbroker分布式操作系统对app_object对象的请求访问包括需要返回值的函数型请求访问和不需要返回值的通知型请求访问。
进一步地，app_object对象的业务层独立执行程序用于app_object对象的逻辑运算，附属组件为扩展模式下app_object对象对应的存储型资源；附属组件的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署。当附属组件部署方式为在kbroker分布式系统外部署时，和传统部署方式一致；当附属组件部署方式为在kbroker分布式系统内部署时，其部署方式包括独立部署和应用程序部署；
当附属组件的部署方式为独立部署时，附属组件为每组业务层独立执行程序独享的存储型资源，与业务层执行程序部署在一起，app_service模块提供对附属组件的主从灾备，每组业务层独立执行程序对应的所有附属组件作为kbroker分布式操作系统内的一个存储型资源，并且由kbroker_super模块选择kbroker_server模块进行创建和管理；
当附属组件的部署方式为应用程序部署时，为附属组件单独创建一个应用程序，该应用程序为存储型应用程序，用于管理辅助组件对应的存储型资源，业务层通过访问该应用程序的app_object对象来访问附属组件。
进一步地，app_service模块对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口，
当app_object对象运行在标准模式下，业务层直接调用app_service提供的内部函数调用接口，访问其他app_object对象函数型调用的接口通过协程化处理来避免阻塞，同时提供添加异步事件、延时事件、协程化的锁和信号的接口；
当app_object对象运行在扩展模式下，app_service模块提供接口扩展给业务层使用；app_service模块访问其他app_object对象函数型调用的接口为一个阻塞型的远程调用，由业务层处理阻塞事件对app_object对象逻辑运行的影响，同时提供添加异步事件、延时事件和锁操作的接口，添加的异步和延时事件由app_service模块进行保存，然后再回调业务层执行程序进行执行处理。
如上所述，本发明的一种应用于多台服务器的分布式操作系统，具有以下有益效果：
第一，现有代码可以经过简单的接口修改就可以迁移到kbroker分布式操作系统上运行；
第二，对现有代码用到的附属组件做灾备支持，降低现有代码迁移后在kbroker分布式系统上运行的运维难度和增加运行的安全性；
第三，提供开放者基于现有开发方法开发kbroker分布式操作系统上应用程序的能力。
附图说明
图1显示为本发明实施例中一种应用于多台服务器的分布式操作系统的模块结构示意图。
具体实施方式
以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
本发明提供一种新旧代码共同运行的kbroker分布式操作系统，业务层模块用于实现整个系统的业务逻辑，业务逻辑被拆分成若干个应用程序，每个应用程序包括与之对应的一组app_allocator模块、至少一组app_service模块。app_service模块，用于运行应用程序的app_object对象，对kbroker分布式操作系统内提供统一的接口访问在其上运行的app_object对象，并且对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口；业务逻 辑由运行在app_service模块上的业务层app_object对象的逻辑处理以及app_object对象之间的相互调用实现。app_allocator模块，用于管理应用程序逻辑运行所需的app_service模块的启动和关闭、app_object对象的创建和删除，并且管理和分配app_object对象在app_service模块运行；app_allocator模块将app_service模块进行分组，为每个分组设置virtual_id编号，负责分组内app_service模块的主从灾备。kbroker_server模块，用于管理kbroker分布式操作系统中其所在的服务器，kbroker_server模块管理其所在服务器上的app_service模块、app_allocator模块和存储型资源；多个kbroker_server模块之间数据通信连接。kbroker_super模块，用于通过kbroker_server模块管理kbroker_server模块所在的服务器；通过kbroker_server模块管理kbroker分布式操作系统中的所有程序进程，并为每个程序进程设置进程编号program_id；管理业务层应用程序，并为每个业务层应用程序设置应用程序编号app_id。app_object对象由应用程序的app_id编号和应用程序上的对象object_id编号来标识；app_object对象的运行模式包括标准模式和扩展模式；标准模式用于新代码的编写和运行；在标准模式下，app_object对象运行在app_service模块的程序内部，通过app_service模块提供的内部接口与kbroker分布式操作系统进行数据交互；扩展模式用于老代码的运行；在扩展模式下，app_object对象的逻辑处理作为业务层独立执行程序运行在app_service模块外部，通过外部接口与app_service模块连接以实现相同kbroker分布式操作系统的数据交互。
存储型资源为用于保存数据防止kbroker分布式操作系统重启后丢失数据或临时保存数据的存储介质，可以为磁盘等计算机的存储介质，也可以为独立的第三方执行程序。
存储型资源的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署；当存储型资源的部署方式为在kbroker分布式系统内部署时，由kbroker_server模块负责创建在其所在的服务器上，由kbroker_super模块负责管理；当存储型资源部署方式为在kbroker分布式操作系统外部署时，提供访问接口给kbroker分布式系统内的应用程序进行调用。
整个系统都是为了达成业务逻辑由app_object对象的逻辑处理和app_object对象之间的相互调用实现这一目标而进行的，通过app_allocator模块来实现对app_object对象的管理和分配，通过app_service模块封装app_object对象的逻辑处理以及对外部请求的响应处理。在系统的层面实现每个app_object对象一个时间只运行在一个app_service模块上，该app_service模块负责接收所有对该app_object对象的访问请求，并将这些请求交给该app_object对象进行处理。app_service模块就是为了实现对app_object对象的封装而存在的，由其屏蔽了app_object对象实现上的差异。实现对app_object对象封装到app_service模块运行本质上是解决阻塞型调用对app_object对象业务逻辑处理的影响，解决途径上主要有三种：一是用多 进程解决阻塞问题、二是用多线程解决阻塞问题、三是用协程解决阻塞问题。其中原kbroker分布式操作系统中使用的就是用协程方式来解决阻塞问题，对应于本专利中的标准模式；现有常见的服务端程序一般通过多进程或多线程的方式来解决阻塞问题，也有用异步调用方式来解决阻塞问题的，但异步调用的解决方案会导致代码逻辑分散而增加编写的复杂度，对于现有程序的封装对应于本专利的扩展模式。
app_allocator模块用于管理app_service模块的主从灾备，所有应用程序的app_service模块都支持主从灾备，将app_service模块不需要主从灾备的应用程序作为只有主没有从的特例处理。app_allocator模块将app_service模块进行分组，每个分组至少有一个app_service模块作为该分组的主app_service模块；每个分组还包括存在从app_service模块模式和不存在从app_service模块模式，所述存在从app_service模块模式为app_service模块需要主从灾备，所述不存在从app_service模块模式为app_service模块不需要主从灾备，并且app_allocator模块用于管理维护该分组内app_service模块的主从灾备。app_allocator模块分配app_object对象到具体分组的主app_service模块上运行，所有请求访问发送到该对应的主app_service模块上进行响应处理，需要主从灾备的从app_service模块由该分组的主app_service模块同步数据。当现有分组无法满足该应用程序的app_object对象的运行需要时，app_allocator模块创建新的分组和启动新分组内新的app_service模块。
app_service模块默认支持主从灾备使得系统的健壮性和可靠性得到增强，降低了运行时的维护工作。将支持主从灾备作为常态，不支持主从灾备作为只有主没有从的特例来处理，一方面支持各种情况下对主从灾备的需求而不仅仅只是在有存储型资源时才支持主从灾备可以更好的增强系统的稳定性，另外还可以用统一一套逻辑系统同时处理支持和不支持主从灾备两种情况，从而大大减少了代码维护的复杂度。上述app_allocator模块实现的是主从灾备的管理模块，其将与app_service模块实现的主从灾备的处理模块配合起来实现对app_service模块的主从灾备。
app_allocator模块管理和分配app_object对象，app_allocator模块分配一个app_object对象在一个分组的主app_service模块上运行，并对系统内提供请求该app_object对象的路由信息接口，路由信息为该app_object对象具体运行在哪个主app_service模块。应用程序的app_object对象与app_service模块分组的关系包括关联关系和非关联关系。当应用程序的app_object对象与app_service模块分组的关系为关联关系时，应用程序的app_allocator模块保存object_id编号和virtual_id编号的关联关系、app_service模块分组与其分组内app_service模块的关联关系；启动该app_object对象时找到其关联virtual_id编号对应分组的主 app_service模块进行启动和运行；创建app_object对象时先选择一个分组，然后保存object_id编号和virtual_id编号的关联关系。当应用程序的app_object对象与app_service模块分组的关系为非关联关系时，app_allocator模块启动该app_object对象时从所有正在运行的分组中选择一个分组，然后在被选择分组的主app_service模块上启动和运行该app_object对象。
上述操作是基于app_service模块都以支持主从灾备的情况下处理的，因为都支持主从灾备，区别只是有没有从app_service模块而已，这就决定了app_object对象的分配是基于app_service模块的主从灾备分组的，app_object对象是运行在其对应主从灾备分组的主app_service模块上的。app_object对象是否和app_service模块分组关联绑定解决的是每次启动后app_object对象是否还需要分配到上次分配的app_service模块分组的问题，原始kbroker分布式操作系统上的存储型应用程序对应的就是app_object对象和app_service模块绑定的情况，本专利中用关联绑定关系标识启动后app_object对象是否还需要分配到原来的app_service模块分组，在处理原本存储型应用程序的基础上为处理更多可能类似的情况留出空间。
关联情况下，app_allocator模块保存app_object对象的object_id编号和app_service模块分组的virtual_id编号的关联关系是保存到非易失性存储介质上；保存app_service模块分组与其分组内app_service模块的关联关系也是保存到非易失性存储介质上，由于app_service模块的program_id编号在重新启动后是会变化的，关联关系主要是保存那些可以标记app_service模块具体在哪个kbroker_server模块上的相关信息而非app_service模块的program_id编号，比如存储型应用程序app_service模块用到的存储型资源。
app_service模块运行该应用程序app_object对象的业务逻辑，一个app_object对象在同一个时间段运行在唯一一个该应用程序的app_service模块上，一个app_service模块同时运行多个该应用程序的app_object对象。app_service模块根据app_allocator模块的命令创建并记录在其上运行的app_object对象，app_object对象的逻辑由业务层实现，启动和关闭app_object对象的运行由app_service模块负责。app_service模块提供主从灾备框架，在app_object对象需要主从灾备的情况下配合业务层实现主从灾备。
app_service模块负责封装app_object对象，使得在系统中调用时屏蔽掉app_object对象实现的差异。这里提供的标准模式对应于原本kbroker分布式操作系统中的app_object对象的逻辑处理方案，扩展模式用于兼容运行现有代码或者以现有大家熟悉的开发方式进行开发，核心差别就是标准模式中业务逻辑和app_service模块是合二为一的，扩展模式下业务逻辑和app_service模块运行在彼此独立的执行程序，通过相互之间的接口访问来彼此之间的消息交互，这样就可以实现现有的代码以其正常运行的模式进行运行，从而尽可能少的代码改动就 可以将原有代码迁移到kbroker分布式系统上运行，同时也使得开发者可以按照原来开发方式在kbroker分布式系统上进行应用程序的开发。
app_service模块提供主从灾备框架，主从灾备框架由每一个app_service模块内独立的主从灾备模块，配合app_allocator模块对应的主从灾备管理模块实现。主app_service模块通过主从灾备模块来对从app_service模块发送同步信息，从app_service模块通过主从灾备模块接收同步信息并执行。app_service模块中每项需要主从同步的逻辑模块都注册到其主从灾备模块中，每项逻辑模块发送的同步信息和同步信息的执行逻辑都由该项逻辑模块自己定义，主app_service模块上每一项逻辑模块发送的同步信息通过主从灾备模块传递到从app_service模块的主从灾备模块，再由从app_service模块的主从灾备模块传递给对应的逻辑模块来处理同步信息。app_service模块的主从灾备模块为实现主从灾备过程中的主从切换、从app_service模块到主app_service模块的注册、数据导出导入等功能提供框架支持，其中数据导出和导入、同步信息的发送和执行、从切换到主之后的处理工作由每个需要同步的逻辑模块自己实现，其他的统一逻辑都由主从灾备框架实现。
app_service模块提供统一的接口访问在其上运行的app_object对象，当app_object对象运行在标准模式下，利用协程解决逻辑运行中的阻塞问题，其业务逻辑在app_service模块上的一个单线程上运行，所有请求封装成协程排队依次执行；通过重写app_object对象的虚基类app_object_i实现业务逻辑和响应外部请求。当app_object对象运行在扩展模式下，其业务逻辑运行在独立于app_service模块的业务层独立执行程序上，app_service模块将系统内对其上运行app_object对象的函数型请求访问和通知型请求访问转换成该业务层独立执行程序支持的接口进行调用处理。
标准模式就是原本kbroker分布式操作系统提供的解决方案，主要是通过协程来解决阻塞问题，进而将app_object对象运行在同一个线程上支持app_service模块对其接口进行直接调用。
当app_object对象运行在扩展模式下，业务逻辑运行在独立于app_service模块的业务层独立执行程序上。当app_object对象运行在扩展模式下，其业务逻辑运行在业务层独立执行程序上，由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，并与其对应的app_service模块一起组成一组app_object对象的运行集合，响应处理kbroker分布式操作系统内对其上运行app_object对象的请求访问。app_service模块用于接收kbroker分布式操作系统内对其上运行的app_object对象的请求访问，并将请求访问转发给app_object对象所在业务层执行程序以完成响应处理；业务层执行程序为app_service模块 提供访问其上运行的app_object对象的访问接口。kbroker分布式操作系统对app_object对象的请求访问包括需要返回值的函数型请求访问和不需要返回值的通知型请求访问。
扩展模式是将原来的代码部署成多个小的执行分组，每个分组都由运行原来代码的原业务层执行程序支持原来所有的功能但支持的负载范围(app_object对象数量)比较小，将每个分组和app_service模块组合封装在一起，然后通过系统同时运行多个app_service模块与其原业务层执行程序分组的方式支持所有的负载范围。系统负责将app_object对象的访问分配到对应的app_service模块上运行，app_service模块将访问转换成运行原业务层执行程序可以支持的接口以处理访问。为了实现app_service模块和原业务层执行程序的组合封装，需要用容器将原业务层执行程序进行封装，app_service模块负责实现容器功能以及实现与容器内外的通信连接，原业务层执行程序及其附属组件运行在容器内提供接口支持app_service模块的调用，app_service模块将系统发送的访问请求转换后交给容器内业务层执行程序进行处理。原业务层执行程序利用这样的封装就对外展现为运行一定数量app_object对象的运行集合，实现了迁移运行原代码到kbroker分布式操作系统。
扩展模式的app_object对象由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，app_object对象的业务层独立执行程序用于app_object对象的逻辑运算，附属组件在通常情况下是用于扩展模式下的app_object对象的数据存储；附属组件为扩展模式下app_object对象对应的存储型资源，附属组件的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署。当附属组件部署方式为在kbroker分布式系统外部署时，和传统部署方式一致；当附属组件部署方式为在kbroker分布式系统内部署时，其部署方式包括独立部署和应用程序部署。当附属组件的部署方式为独立部署时，附属组件为每组业务层独立执行程序独享的存储型资源，与业务层执行程序部署在一起，app_service模块提供对附属组件的主从灾备，每组业务层独立执行程序对应的所有附属组件作为kbroker分布式操作系统内的一个存储型资源，并且由kbroker_super模块选择kbroker_server模块进行创建和管理。当附属组件的部署方式为应用程序部署时，为附属组件单独创建一个应用程序，该应用程序为存储型应用程序，用于管理辅助组件对应的存储型资源，业务层通过访问该应用程序的app_object对象来访问附属组件。
对于原有代码的迁移，最需要修改的就是针对保存数据的附加组件的连接操作部分，这些附加组件主要是缓存和数据库，其他例如消息队列、延时程序之类的都由系统提供的接口来处理。附属组件原有的传统部署方式是将其单独部署，然后提供访问接口给执行程序调用，当附属组件在kbroker分布式系统外部署时可以像之前传统的部署方式一样进行部署。当附属 组件在kbroker分布式系统内部署时，缓存和数据库最简单的部署方式就是和原有业务层执行程序一起部署在同一个容器里，然后通过系统提供的访问类库进行访问，使用系统提供的访问类库是为了可以在进行访问操作的同时对对应的从附加组件进行消息同步从而实现主从灾备；另外一种改进形式的部署方式就是将其实现成对应的存储型应用程序，这样很方便的就实现了对附加组件的管理和灾备，原有直接访问附加组件的方式通过替换成对新的存储型应用程序的对象访问就可以了。
app_service模块对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口，当app_object对象运行在标准模式下，业务层直接调用app_service提供的内部函数调用接口，访问其他app_object对象函数型调用的接口通过协程化处理来避免阻塞，同时提供添加异步事件、延时事件、协程化的锁和信号的接口。当app_object对象运行在扩展模式下，app_service模块提供接口扩展给业务层使用；app_service模块访问其他app_object对象函数型调用的接口为一个阻塞型的远程调用，由业务层处理阻塞事件对app_object对象逻辑运行的影响，同时提供添加异步事件、延时事件和锁操作的接口，添加的异步和延时事件由app_service模块进行保存，然后再回调业务层执行程序进行执行处理。
整个系统的核心关键就是处理远程调用引起的阻塞问题，从而使得一个app_object对象的业务逻辑可以在一个app_service模块上运行，kbroker分布式操作系统原本提供的解决方案是通过协程的模式处理调用引起的阻塞问题，传统的服务端开发是通过多进程的方式来处理远程调用引起的阻塞问题，从技术的实现能力上来看无论是进程、线程、协程都可以处理调用引起的阻塞问题。标准模式下由系统直接提供基于协程的远程或者本地调用，业务层就不需要关心阻塞问题了，在扩展模式下，系统提供的是阻塞型的调用接口，利用原本代码中采用的多进程或者多线程的方式来处理阻塞问题，从而在两种模式下都能实现将一个app_object对象的全部业务逻辑放在一个app_service模块上运行的目标。扩展模式下提供的延时和异步接口是为了替换掉传统服务端开发中用到的消息队列和定时回调，从而更方便进行部署和维护。
原始kbroker分布式操作系统中kbroker_super模块和kbroker_server模块改动不大，主要是在app_allocator模块和app_service模块上的改动。
app_allocator模块功能改动主要集中于将所有的app_service模块作为支持主从灾备来处理，将支持主从灾备的app_service模块作为常态，而将不支持主从灾备的app_service模块作为特例，从而在支持业务层各种主从灾备需求的情况下实现统一处理和增强系统的可用性。
标准模式下的app_service模块也是提供一个类库给业务层使用，其和原始kbroker分布 式操作系统提供的app_service类库的核心功能一致，主要改动是增加主从灾备的管理模块，使得可以各种类型的app_service模块都可以很方便的在app_allocator模块的配合下实现对其自身各个逻辑模块和附加组件的主从灾备。
扩展模式下的app_service模块也是提供一个类库给业务层使用，原始kbroker分布式操作系统app_service类库提供的路由缓存和当前运行的app_object对象等功能也之前的一致，创建、启动和关闭app_object对象的接口由业务层调用业务层独立执行程序提供的接口实现；另外业务层主要编写将系统内对其app_object对象的访问请求转换成业务层独立执行程序访问接口的策略。扩展模式下的app_service模块提供一个给业务层使用的扩展库文件用于业务层访问app_service模块，该扩展文件通过进程间通信方式连接到app_service模块上进行数据交互。
现有开发模式下开发的代码，一般会有缓存和数据库等负责保存数据的组件，业务代码负责逻辑处理且与具体的app_object对象无关，业务代码运行时根据参数从缓存或者数据库中获取对应app_object对象的数据重建app_object对象，然后再执行对应的逻辑处理。迁移现有代码时，将缓存和数据库等保存数据的组件归为app_service模块管理和实现主从灾备并提供访问接口给业务层代码调用，现有代码在替换了数据访问接口后按照原有的运行方式进行部署和运行。总体上来看，就是kbroker分布式操作系统通过app_object对象的模式将访问拆分到多个app_service模块上进行处理，每个app_service模块使用原有代码部署运行一个小规模的原有服务来支持访问，再加上系统对数据保存组件提供主从灾备，这就实现了现有代码迁移到kbroker分布式系统上运行。

Claims (10)

  1. 一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，包括：
    业务层模块，用于实现整个系统的业务逻辑；所述业务逻辑被拆分成若干个应用程序，每个应用程序包括与之对应的一组app_allocator模块和至少一组app_service模块；
    app_service模块，用于运行应用程序的app_object对象，对kbroker分布式操作系统内提供统一的接口访问在其上运行的app_object对象，并且对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口；业务逻辑由运行在app_service模块上的业务层app_object对象的逻辑处理以及app_object对象之间的相互调用实现；
    app_allocator模块，用于管理应用程序逻辑运行所需的app_service模块的启动和关闭、app_object对象的创建和删除，并且管理和分配app_object对象在app_service模块运行；app_allocator模块将app_service模块进行分组，为每个分组设置分组编号virtual_id编号，负责分组内app_service模块的主从灾备；
    kbroker_server模块，用于管理kbroker分布式操作系统中其所在的服务器，kbroker_server模块管理其所在服务器上的app_service模块、app_allocator模块和存储型资源；多个kbroker_server模块之间数据通信连接；
    kbroker_super模块，用于通过kbroker_server模块管理kbroker_server模块所在的服务器；通过kbroker_server模块管理kbroker分布式操作系统中的所有程序进程，并为每个程序进程设置进程编号program_id；管理业务层应用程序，并为每个业务层应用程序设置应用程序编号app_id；
    app_object对象由应用程序的app_id编号和应用程序上的对象编号object_id编号来标识；app_object对象的运行模式包括标准模式和扩展模式；标准模式用于新代码的编写和运行；在标准模式下，app_object对象运行在app_service模块的程序内部，通过app_service模块提供的内部接口与kbroker分布式操作系统进行数据交互；扩展模式用于老代码的运行；在扩展模式下，app_object对象的逻辑处理作为业务层独立执行程序运行在app_service模块外部，通过外部接口与app_service模块连接以实现相同kbroker分布式操作系统的数据交互。
  2. 根据权利要求1所述的一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，存储型资源为用于保存数据防止kbroker分布式操作系统重启后丢失数据或临时保存数据的存储介质，
    存储型资源的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署；当存储型资源的部署方式为在kbroker分布式系统内部署时，由kbroker_server模块负责创建 在其所在的服务器上，由kbroker_super模块负责管理；当存储型资源部署方式为在kbroker分布式操作系统外部署时，提供访问接口给kbroker分布式系统内的应用程序进行调用。
  3. 根据权利要求1所述的一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，app_allocator模块用于管理app_service模块的主从灾备，
    所有应用程序的app_service模块都支持主从灾备，将app_service模块不需要主从灾备的应用程序作为只有主没有从的特例处理；
    app_allocator模块将app_service模块进行分组，每个分组至少有一个app_service模块作为该分组的主app_service模块；每个分组还包括存在从app_service模块模式和不存在从app_service模块模式，所述存在从app_service模块模式为app_service模块需要主从灾备，所述不存在从app_service模块模式为app_service模块不需要主从灾备，并且app_allocator模块用于管理维护该分组内app_service模块的主从灾备；
    app_allocator模块分配app_object对象到具体分组的主app_service模块上运行，所有请求访问发送到该对应的主app_service模块上进行响应处理，需要主从灾备的从app_service模块由该分组的主app_service模块同步数据；
    当现有分组无法满足该应用程序的app_object对象的运行需要时，app_allocator模块创建新的分组和启动新分组内新的app_service模块。
  4. 根据权利要求1所述的一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，app_allocator模块管理和分配app_object对象，
    app_allocator模块分配一个app_object对象在一个分组的主app_service模块上运行，并对系统内提供请求该app_object对象的路由信息接口；
    应用程序的app_object对象与app_service模块分组的关系包括关联关系和非关联关系；
    当应用程序的app_object对象与app_service模块分组的关系为关联关系时，应用程序的app_allocator模块保存object_id编号和virtual_id编号的关联关系、app_service模块分组与其分组内app_service模块的关联关系；启动该app_object对象时找到其关联virtual_id编号对应分组的主app_service模块进行启动和运行；创建app_object对象时先选择一个分组，然后保存其object_id编号和virtual_id编号的关联关系；
    当应用程序的app_object对象与app_service模块分组的关系为非关联关系时，
    app_allocator模块启动该app_object对象时从所有正在运行的分组中选择一个分组，然后在被选择分组的主app_service模块上启动和运行该app_object对象。
  5. 根据权利要求1所述的一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，app_service模块运行该应用程序app_object对象的业务逻辑，
    一个app_object对象在同一个时间段运行在唯一一个该应用程序的app_service模块上，一个app_service模块同时运行多个该应用程序的app_object对象；
    app_service模块根据app_allocator模块的命令创建并记录在其上运行的app_object对象，app_object对象的逻辑由业务层实现，启动和关闭app_object对象的运行由app_service模块负责；
    app_service模块提供主从灾备框架，在app_object对象需要主从灾备的情况下配合业务层实现主从灾备。
  6. 根据权利要求1所述的一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，app_service模块提供统一的接口访问在其上运行的app_object对象，
    当app_object对象运行在标准模式下，利用协程解决逻辑运行中的阻塞问题，其业务逻辑在app_service模块上的一个单线程上运行，所有请求封装成协程排队依次执行；通过重写app_object对象的虚基类app_object_i实现业务逻辑和响应外部请求；
    当app_object对象运行在扩展模式下，其业务逻辑运行在独立于app_service模块的业务层独立执行程序上，app_service模块将系统内对其上运行app_object对象的函数型请求访问和通知型请求访问转换成该业务层独立执行程序支持的接口进行调用处理。
  7. 根据权利要求6的所述一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，当app_object对象运行在扩展模式下，业务逻辑运行在独立于app_service模块的业务层独立执行程序上，
    当app_object对象运行在扩展模式下，其业务逻辑运行在业务层独立执行程序上，由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，并与其对应的app_service模块一起组成一组app_object对象的运行集合，响应处理kbroker分布式操作系统内对其上运行app_object对象的请求访问；
    app_service模块用于接收kbroker分布式操作系统内对其上运行的app_object对象的请求访问，并将请求访问转发给app_object对象所在业务层执行程序以完成响应处理；业务层执行程序为app_service模块提供访问其上运行的app_object对象的访问接口。
  8. 根据权利要求7的所述一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，kbroker分布式操作系统对app_object对象的请求访问包括需要返回值的函数型请求访问和不需要返回值的通知型请求访问。
  9. 根据权利要求7的所述一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，
    app_object对象的业务层独立执行程序用于app_object对象的逻辑运算，附属组件为扩展模式下app_object对象对应的存储型资源；附属组件的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署。当附属组件部署方式为在kbroker分布式系统外部署时，和传统部署方式一致；当附属组件部署方式为在kbroker分布式系统内部署时，其部署方式包括独立部署和应用程序部署；
    当附属组件的部署方式为独立部署时，附属组件为每组业务层独立执行程序独享的存储型资源，与业务层执行程序部署在一起，app_service模块提供对附属组件的主从灾备，每组业务层独立执行程序对应的所有附属组件作为kbroker分布式操作系统内的一个存储型资源，并且由kbroker_super模块选择kbroker_server模块进行创建和管理；
    当附属组件的部署方式为应用程序部署时，为附属组件单独创建一个应用程序，该应用程序为存储型应用程序，用于管理辅助组件对应的存储型资源，业务层通过访问该应用程序的app_object对象来访问附属组件。
  10. 根据权利要求1的所述一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，app_service模块对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口，
    当app_object对象运行在标准模式下，业务层直接调用app_service提供的内部函数调用接口，访问其他app_object对象函数型调用的接口通过协程化处理来避免阻塞，同时提供添加异步事件、延时事件、协程化的锁和信号的接口；
    当app_object对象运行在扩展模式下，app_service模块提供接口扩展给业务层使用；
    app_service模块访问其他app_object对象函数型调用的接口为一个阻塞型的远程调用，由业务层处理阻塞事件对app_object对象逻辑运行的影响，同时提供添加异步事件、延时事件和锁操作的接口，添加的异步和延时事件由app_service模块进行保存，然后再回调业务层执行程序进行执行处理。
PCT/CN2020/112829 2019-12-18 2020-09-01 一种新旧代码共同运行的kbroker分布式操作系统 WO2021120693A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911312495.0A CN111104162B (zh) 2019-12-18 2019-12-18 一种新旧代码共同运行的kbroker分布式操作系统
CN201911312495.0 2019-12-18

Publications (1)

Publication Number Publication Date
WO2021120693A1 true WO2021120693A1 (zh) 2021-06-24

Family

ID=70422800

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/112829 WO2021120693A1 (zh) 2019-12-18 2020-09-01 一种新旧代码共同运行的kbroker分布式操作系统

Country Status (2)

Country Link
CN (1) CN111104162B (zh)
WO (1) WO2021120693A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110543315B (zh) * 2019-09-06 2021-08-31 程延辉 一种kbroker分布式操作系统、存储介质和电子设备
CN111104162B (zh) * 2019-12-18 2023-03-24 程延辉 一种新旧代码共同运行的kbroker分布式操作系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6199202B1 (en) * 1998-01-06 2001-03-06 Hewlett-Packard Company Method and apparatus for the inter-operation of differing architectural and run time conventions
CN110532000A (zh) * 2019-09-06 2019-12-03 程延辉 一种用于运营发布的kbroker分布式操作系统和运营发布系统
CN110543315A (zh) * 2019-09-06 2019-12-06 程延辉 一种kbroker分布式操作系统、存储介质和电子设备
CN110569043A (zh) * 2019-09-06 2019-12-13 程延辉 一种多用户的kbroker分布式操作系统和多用户管理系统
CN111104162A (zh) * 2019-12-18 2020-05-05 程延辉 一种新旧代码共同运行的kbroker分布式操作系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2004206358A1 (en) * 2003-01-23 2004-08-05 Electronic Data Systems Corporation System and method for automated code generation using language neutral software code

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6199202B1 (en) * 1998-01-06 2001-03-06 Hewlett-Packard Company Method and apparatus for the inter-operation of differing architectural and run time conventions
CN110532000A (zh) * 2019-09-06 2019-12-03 程延辉 一种用于运营发布的kbroker分布式操作系统和运营发布系统
CN110543315A (zh) * 2019-09-06 2019-12-06 程延辉 一种kbroker分布式操作系统、存储介质和电子设备
CN110569043A (zh) * 2019-09-06 2019-12-13 程延辉 一种多用户的kbroker分布式操作系统和多用户管理系统
CN111104162A (zh) * 2019-12-18 2020-05-05 程延辉 一种新旧代码共同运行的kbroker分布式操作系统

Also Published As

Publication number Publication date
CN111104162A (zh) 2020-05-05
CN111104162B (zh) 2023-03-24

Similar Documents

Publication Publication Date Title
US9875122B2 (en) System and method for providing hardware virtualization in a virtual machine environment
WO2021147288A1 (zh) 一种容器集群管理方法、装置及系统
TW202021328A (zh) 統一資源調度協調器及其創建虛擬機和／或容器的方法、統一資源調度系統
EP2662771A1 (en) Scheduling method, and multi-core processor system
WO2021120693A1 (zh) 一种新旧代码共同运行的kbroker分布式操作系统
CN111857993B (zh) 一种内核态调用用户态函数的方法
CN101764703B (zh) 一种基于虚拟技术的网元管理系统的实现方法
CN111414256B (zh) 基于麒麟移动操作系统的应用程序进程派生方法、系统及介质
JPWO2012026034A1 (ja) スケジューラ、マルチコアプロセッサシステムおよびスケジューリング方法
WO2021103646A1 (zh) 一种部署pod的方法及装置
CN114756170B (zh) 一种面向容器应用的存储隔离系统及其方法
WO2021022964A1 (zh) 一种基于多核系统的任务处理方法、装置及计算机可读存储介质
EP3877853A1 (en) Computing resource allocation
WO2017181829A1 (zh) 虚拟化平台的运行方法及虚拟化平台
WO2021043124A1 (zh) 一种kbroker分布式操作系统、存储介质和电子设备
CN116680209A (zh) 基于wasm的多智能合约实例管理方法
Tsai et al. Model-driven tenant development for PaaS-based SaaS
Morisawa et al. Flexible executor allocation without latency increase for stream processing in apache spark
CN114840343A (zh) 基于分布式系统的任务调度方法及系统
CN110399206B (zh) 一种基于云计算环境下idc虚拟化调度节能系统
CN110532000B (zh) 一种用于运营发布的kbroker分布式操作系统和运营发布系统
US11762672B2 (en) Dynamic linker for loading and running an application over a plurality of nodes
WO2023116910A1 (zh) 一种计算资源和缓存资源调度方法、装置及系统
JP2001092664A (ja) オブジェクト計算機システム及びプログラムを記録したコンピュータ読み取り可能な記録媒体
CN115729721A (zh) 一种用于linux系统进程间的数据交互方法及装置

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: 20900958

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: 20900958

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20900958

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 19/01/2023)