CN110543315A

CN110543315A - distributed operating system of kbroker, storage medium and electronic equipment

Info

Publication number: CN110543315A
Application number: CN201910843920.2A
Authority: CN
Inventors: 程延辉; 程耀辉
Original assignee: Individual
Current assignee: Individual
Priority date: 2019-09-06
Filing date: 2019-09-06
Publication date: 2019-12-06
Anticipated expiration: 2039-09-06
Also published as: CN110543315B; WO2021043124A1

Abstract

the invention discloses a kbroker distributed operating system, a storage medium and electronic equipment, which are applied to a plurality of servers and comprise a plurality of app _ service modules and a plurality of app _ allocator modules, wherein the app _ service modules are used for operating business logic, and the app _ allocator modules are used for managing operating resources of an application program and allocating the app _ service modules for operating the application program according to the required quantity of the operating resources; the distributed operating system comprises a plurality of kbroker _ server modules, a server management module, an app _ service module and an app _ allocator module, wherein the plurality of kbroker _ server modules are used for managing corresponding servers in the distributed operating system and starting and closing the app _ service modules and the app _ allocator modules on the corresponding servers; the kbroker _ super module is included to manage all program processes within the overall system. With the support of the invention, developers only pay attention to the self service, develop large-scale server end programs like the simplest single-thread program, do not need to pay attention to a series of problems caused by the increase of access, improve the efficiency of server clustering, and the system provides a disaster recovery mechanism aiming at software and hardware faults so as to realize high availability.

Description

Distributed operating system of kbroker, storage medium and electronic equipment

Technical Field

the invention relates to the field of software development and operation and maintenance systems of a server side, in particular to a kbroker distributed operating system, a storage medium and electronic equipment.

Background

The load supported by the server program is increasingly large at present, the high-volume concurrent demand of a large number of users is increasingly common, so that a lot of internet initiative enterprises can meet the technical bottleneck problem, the faster and faster the business development is, the greater the technical challenge is, and how to provide a set of simple and feasible scheme to help the internet initiative enterprises to solve the technical bottleneck, so that the business development of the internet initiative enterprises is not restricted by self technology and becomes a very common and urgent demand.

at present, for the development of large-scale server-side programs, the main technical solutions include micro-services, message queues and timing programs, and usually, the three solutions are combined for use to obtain a better effect. More advanced in the aspect of server operation and maintenance is a docker technology based on kubernets management.

The micro-service is to split the whole large function into a plurality of relatively independent small functions, and the micro-service also needs to consider the problem of large load caused by the increase of the access amount during the program design, so that the micro-service still is a subject for dealing with the high concurrency of the large load from the viewpoint of only reducing a complicated large function to a relatively simple small function, and in addition, the complexity of calling among different micro-services and the difficulty of the operation and management of the whole system of the micro-service are increased while the function is split simply.

the message queue is used for coping with peak clipping, message processing asynchronization and decoupling between realization functions in the case of instant high load, although an open source program can be used by the message queue, the writing of a business logic code needs to divide an original logic into two logics, namely a producer of a message and an executor of the message, and the development, operation and maintenance are not easy when the large-scale use is caused by additionally deploying the program and code division.

The timing program is used for solving tasks which are executed regularly under the condition that no external access is triggered, and delay tasks which are needed by the program in a normal condition are triggered at corresponding time points in a timing task mode. The timing task needs to be configured at the server side, special codes are needed to store the task to be processed and to write the specific processing of the callback function when the task is triggered, and if a plurality of different timing tasks exist, the development, operation and maintenance are troublesome and errors are easy to make.

the docker technology based on kubernets can be simply understood as a simplified virtual machine scheme, the docker is lighter than a virtual machine, the problem in the aspect of program deployment and operation is mainly solved, particularly the problem of difference of program operation environments is solved, the requirement on the capability of operation and maintenance personnel for operating the operation and maintenance system is high, certain adaptive development needs to be performed from a code level, and the set of system challenge is very large to play. Even though we consider it as simpler cloud service (such as Alice cloud) and automated deployment, it needs stronger operation and maintenance capability

In addition, in terms of operation and maintenance, it is troublesome to guarantee high availability in response to hardware and software failures of the server, which requires making feasible solutions from the server operation and development level. The difficulty in implementing and completing these three schemes from development and operation and maintenance is relatively high, and in addition, the problem of software and hardware failures of the server cluster needs to be solved, which is why most small companies have problems in server-side programs when facing large concurrent accesses.

Disclosure of Invention

In view of the above-mentioned shortcomings of the prior art, it is an object of the present invention to provide a kbroker distributed operating system and storage medium for solving the problems in the prior art:

Firstly, in the code development aspect, micro-services are used for function splitting, a message queue is used for function decoupling, and a timing delay program is added to complete development, so that the development mode has more frame components, a complex system and high requirements on developers;

Secondly, in the operation and maintenance aspect, the docker technology based on kubernets is utilized to meet the technical requirements of increasing loads and building a high-availability disaster tolerance architecture.

In order to solve the technical problem, the invention is realized as follows: a kbroker distributed operating system comprising:

the system comprises a distributed operating system, a Kbrooker _ server module, a storage type resource and a server, wherein the distributed operating system is used for storing an application _ service module and an application _ allocator module; data communication connection is carried out among the plurality of kbroker _ server modules;

The service layer module is used for realizing the service logic of the whole distributed operating system; the business logic is split into a plurality of application programs; each application program comprises a group of app _ allocator modules and at least one group of app _ service modules corresponding to the application program, wherein the app _ service modules are used for operating the business logic, the app _ allocator modules are used for managing the operating resources of the application program, and the operating resources are server resources required by the application program to execute the business logic; the app _ allocator module allocates an app _ service module for running the application program according to the demand of the running resource; the business logic is realized by logic processing of the business layer app _ object running on the app _ service module and mutual calling between the app _ object objects;

The system comprises a kbroker _ super module, a server and a server management module, wherein the kbroker _ super module is used for managing a server where the kbroker _ server module is located through the kbroker _ server module; managing all program processes in the distributed operating system through a kbroker _ server module, and setting a program _ id for each program process; managing all allocated used and available storage type resources on the distributed system through the kbroker _ server module, and setting a resource number resource _ id and storing a corresponding relation between the resource number resource _ id and the affiliated kbroker _ server module for each allocated used storage type resource; managing service layer application programs and setting an application program number app _ id for each service layer application program;

and the gateway module is a special service layer module and is used for receiving and responding to the external request.

further, the application program in the distributed operating system includes:

a computing application, the business logic of which only involves operations and temporarily saves data in memory;

storage-type applications, the business logic of which involves the use of storage-type resources to store data.

further, the storage type resource is a storage medium used for storing data and preventing the data from being lost after the distributed operating system of the kbroker is restarted;

the method comprises the following steps that a kbroker _ server module manages specific generation work of a storage type resource, and comprises a connection access mode of a local file used for saving the storage type resource after generation, when a program process is used for the storage type resource, the kbroker _ server module transmits the connection access mode of the storage type resource when starting the program process, so that the program process is connected and accesses the storage type resource required by the program process; the kbroker _ server module is also used for managing the destruction and deletion work of the storage type resource.

Further, the kbroker _ super module includes a storage resource for storing the server information, the corresponding relationship between the resource number resource _ id and the kbroker _ server module, the information of the application program, and the storage resource used by the kbroker _ super module.

further, the kbroker _ super module maintains and records the available conditions of the CPUs, the memories, the disks and the networks of the servers where all the kbroker _ server modules are located, and selects the kbroker _ server module for the newly allocated storage type resources and the newly started program process according to the available conditions.

further, program processes in the distributed operating system of the kbroker are communicated through a program _ id of a process number; the kbroker _ server module stores the association relationship between the program _ id of the process number and the kbroker _ server module on the server where the program _ id is located, and message transmission in the system is forwarded by the kbroker _ server module.

further, the kbroker _ super module manages the server in which it is located through the kbroker _ server module:

the method comprises the following steps that a kbroker _ super module adds and deletes a server where the kbroker _ server module is located into a kbroker distributed operating system by starting and closing the kbroker _ server module on the server;

A server used in each kbroker distributed operating system comprises a unique kbroker _ server module;

the method comprises the following steps that a kbroker _ server module monitors the running state of a server where the server is located and the available conditions of a CPU, a memory, a disk and a network, and reports the running state and the available conditions to a kbroker _ super module;

The method comprises the steps that a plurality of servers are interconnected through network connection of a kbroker _ server module running on the servers, the kbroker _ server module monitors connection conditions and reports the connection conditions to a kbroker _ super module, and the kbroker _ super module obtains and processes abnormal running conditions of the kbroker _ server module.

Further, the kbroker _ super module adds and deletes the server where the kbroker _ server module is located in the kbroker distributed operating system by starting and closing the kbroker _ server module on the server, and the method specifically includes:

the kbroker _ super module stores login information of all servers, serial numbers of the servers and an execution command for starting the kbroker _ server module;

the kbroker _ super module logs in the server by using the server login information;

The kbroker _ super module executes a starting command on a logged server to start the kbroker _ server module;

the started kbroker _ server module is connected to the kbroker _ super module according to the information of the kbroker _ super module in the starting command, and requests for registration and verification to the kbroker _ super module;

The kbroker _ super module verifies the registration request, and if the verification is successful, the kbroker _ server module is started successfully;

And the kbroker _ super module deletes the server in the distributed operating system by informing the successfully verified kbroker _ server module to close by itself.

Further, the kbroker _ super module is also used for adding a new server to the distributed operating system in the running process:

Submitting login information of a new server to a kbroker _ super module and starting a corresponding kbroker _ server module command on the new server;

the kbroker _ super module numbers the new server;

And starting and checking a kbroker _ server module corresponding to the new server by the kbroker _ super module, if the verification is successful, successfully adding the new server, and simultaneously storing the information of the new server by the kbroker _ super module.

further, when the application starts:

The kbroker _ super module selects a kbroker _ server module for each app _ allocator module of the application program according to the number of the app _ allocator modules required by the application program and starts the app _ allocator module through the kbroker _ server module;

the method comprises the steps that a kbroker _ super module selects and determines a main app _ allocator module corresponding to an application program from app _ allocator modules of the started application program, other started app _ allocator modules of the application program are set to be synchronous with the main app _ allocator module from the app _ allocator modules, master-slave disaster recovery is achieved, and master-slave disaster recovery is maintained in the running process;

And the main app _ allocator module starts the app _ service module and increases or decreases the running number of the app _ service module according to the requirement of running resources in the running process.

Further, the kbroker _ super module, when launching the app _ allocator module to the storage resource:

the kbroker _ super module saves the association relationship between the resource number resource _ id of the storage type resource used by the app _ allocator module and the application program number app _ id of the application program to which the app _ allocator module belongs;

when the kbroker _ super module starts an application program of which the app _ allocator module uses the storage type resources, finding resource numbers, namely resource ids, of all the storage type resources related to the application program number, namely app _ id, of the application program, finding a corresponding kbroker _ server module according to each resource number, namely resource _ id, and starting the app _ allocator module using the storage type resources, wherein if the app _ allocator module is not started successfully, the application program is started unsuccessfully; if the app _ allocator module is successfully started, judging the number of successful starts, if the number of the app _ allocator module meets the requirements of the master and slave disaster recovery devices, finishing and maintaining the master and slave disaster recovery devices, otherwise, starting a new app _ allocator module to meet the number of the master and slave disaster recovery devices, and then finishing and maintaining the master and slave disaster recovery devices;

when the kbroker _ super module starts a new app _ allocator module, creating a storage type resource, and starting the new app _ allocator module through the storage type resource, wherein the kbroker _ super module stores the association relationship between the resource number resource _ id of the newly created storage type resource and the application program number app _ id of the application program to which the app _ allocator module belongs;

when the app _ allocator module in use is unavailable, the storage type resource used by the app _ allocator module is deleted, and the association relationship between the resource number resource _ id of the storage type resource and the application program number app _ id of the application program to which the app _ allocator module belongs is deleted, and then a new app _ allocator module is started to replace the unavailable app _ allocator module.

further, the app _ service module is managed by the app _ allocator module corresponding to the application program:

When the app _ identifier module starts the app _ service module, selecting a kbroker _ server module through the kbroker _ super module and completing specific starting work through the selected kbroker _ server module;

When the app _ service module is unavailable, the app _ allocator module deletes or modifies the routing information cache of the app _ object running on the app _ service module, and determines whether to start a new app _ service module according to needs;

When there are too many app _ service modules, the app _ allocator module will close the idle app _ service module.

further, the kbroker _ server module is responsible for managing the app _ allocator module and the app _ service module running on the server where the kbroker _ server module is located:

the app _ allcator module and the app _ service module are started by the kbroker _ server module, run on the same server as the kbroker _ server module after being started and are connected to the kbroker _ server module through communication among system processes;

The message transmission of the app _ allocator module, the app _ service module and other program processes in the kbrooker distributed operating system is forwarded by the kbrooker _ server module;

The method comprises the following steps that a kbroker _ server module monitors abnormal conditions of an app _ allocator module and an app _ service module, and reports the abnormal conditions to a kbroker _ super module for processing;

and the kbroker _ server module carries out overload setting, migration and closing management operations on the app _ allocator module and the app _ service module which run on the kbroker _ server module according to the total use condition of a CPU (central processing unit), a memory, a disk and a network of the server where the kbroker _ server module is located.

further, the app _ allocator module is also operable to create an app _ object for the management application:

the mode of the app _ object of the computing application program comprises a permanent existence mode and a temporary existence mode, and the mode of the app _ object of the storage application program is the permanent existence mode;

the app _ allocator module creates a start app _ object through the app _ service module execution;

The app _ object module stores the routing information of the app _ object, wherein the routing information is the app _ service module on which the app _ object runs and provides an interface for requesting routing information;

the app _ allocator module provides corresponding interface functions for creating and deleting the app _ object in the permanent existence mode;

the app _ object in the persistent mode starts to run when being accessed, and is closed and quitted to run under the condition of no access request for a long time;

For the app _ allocator module that manages persistent mode app _ object, a storage resource is included to store the existing app _ object;

for the app _ object in the temporary existence mode, the app _ object is automatically allocated by the app _ allocator module according to the requirement;

the app _ allocator module satisfies the application program's specific requirements for the app _ object module by adding a dedicated function.

further, the app _ allocator module of the storage type application maintains master-slave disaster recovery of the app _ service module:

The method comprises the steps that an app _ allocator module of a storage type application program compiles a plurality of corresponding app _ service modules into a group, a grouping number virtual _ id is set for each group, and master-slave disaster recovery of the app _ service modules in each group is maintained;

The app _ service module of the storage type application program is provided with a storage type resource corresponding to the app _ service module, and the app _ allocator module of the storage type application program stores the association relationship between the grouped group number virtual _ id and the resource number resource _ id of the storage type resource used by the app _ service module in the group;

The existing app _ object objects are bound with the packets in a one-to-one correspondence manner, and an app _ allocator module of the storage type application program saves the correspondence; when no available packet exists, a new packet and an app _ service module in the packet are created first, and then a packet is selected for binding;

When processing a routing information request for an app _ object, an app _ allocator module of the storage-type application program finds a packet number virtual _ id of a packet corresponding to the app _ object, and then finds a process number program _ id of a main app _ service module in the packet corresponding to the packet number virtual _ id and returns the process number program _ id to a requesting party.

further, the app _ service module runs the specific logic of the app _ object:

The app _ object is uniquely identified by an application program number app _ id of the application program and an object number object _ id of the app _ object on the application program, and the business layer accesses the app _ object through the application program number app _ id of the application program and the object number object _ id of the app _ object on the application program;

The service layer realizes service logic by rewriting an app _ object _ i virtual base class provided by the app _ service module;

the logical processing of a single app _ object can only run on a single app _ service module, and multiple app _ objects run simultaneously on the single app _ service module;

the kbroker distributed operating system provides a virtual interface for creating an app _ object through an object number object _ id, the app _ service module creates the app _ object through the virtual interface rewritten by the business layer, and initializes the app _ object through an initialization interface of the app _ object;

Business logic of the same app _ object is queued on the same thread on the app _ service module for processing, each task event of the app _ object is packaged into a coroutine for execution, and the kbroker distributed operating system provides a coroutine support for a blocking type interface;

the app _ service module caches the route information of the app _ object, the route information is acquired by the app _ allocator module corresponding to the app _ object to update the cache, and the cache of the route information of the source app _ object in the access request is updated when other app _ object objects are accessed;

the business layer external access is based on the app _ object, the system provides an interface for accessing the external app _ object, and the interface is realized by the app _ service module; the app _ service module finds the process number program _ id of the app _ service module where the app _ object operates according to the cache or the routing information obtained from the corresponding app _ identifier module, and sends a message with the process number program _ id to the message so that the message is sent to the app _ service module where the app _ object operates;

The app _ service module provides collaborative support for remote function calls that access external app _ object objects;

after receiving the message to be processed of the app _ object, the app _ service module checks the running state of the target app _ object and processes the message;

The app _ service module, in the event that it is monitored as overloaded, notifies the app _ allocator module that it is no longer allocating a new app _ object to run on it;

the app _ service module provides an interface for adding an asynchronous event and a delay event to a service layer, a coroutinized lock and a coroutinized signal;

The app _ service module supports the migration of the running app _ object to other app _ service modules of the same application program;

an app _ service module of the storage type application program provides a master-slave disaster recovery framework aiming at the app _ object, and the master-slave disaster recovery framework is matched with interfaces related to master-slave synchronization in an app _ object _ i virtual base class rewritten by a service layer to realize a master-slave disaster recovery function;

the app _ service module of the storage-type application provides an interface for passing data between master and slave app _ object objects.

further, the business layer implements the business logic by rewriting the app _ object _ i virtual base class:

the app _ object _ i virtual base class of the computing application program and the app _ object _ i virtual base class of the storage application program comprise a function _ api interface, a notify _ api interface, an initialization interface, a deletion interface, a data export interface and a data import interface; the function _ api interface is used for processing access requests needing return values, and the notify _ api interface is used for processing access requests needing no return values;

The service layer module realizes service logic processing through a rewriting function _ api interface and a notify _ api interface; the business layer module rewrites the initialization interface to be used for executing initialization after the app _ service module creates an app _ object; the business layer module rewriting deletion interface is used for releasing the data created by the business layer when the app _ service module closes the app _ object; the export data interface and the import data interface are used for migration of the app _ object, the migration of the app _ object is not supported by default, if the business layer rewrites the two interfaces, the migration of the app _ object is supported by the application program, and when the business load is high, the app _ object is migrated to the app _ service module with low load;

the app _ service module of the storage type application program realizes master-slave disaster recovery, the app _ service module realizes an integral export import interface and a master-slave switching interface aiming at data of storage type resources, and the app _ object _ i virtual base class further comprises a master-slave synchronization interface which is matched with a master-slave disaster recovery framework of the app _ service module to realize master-slave disaster recovery of service layer logic data.

further, the gateway module comprises a session _ allocator module and a kbroker _ gateway module;

the session _ allocator module is used for carrying out extension development based on the basic function of the app _ allocator module, storing socket monitoring information of the kbroker _ gateway module and realizing load balancing of the plurality of kbroker _ gateway modules;

the kbroker _ gateway module is extended and developed based on the basic function of the app _ service module, supports various external request access modes based on a network, and the app _ object running on the kbroker _ gateway module is an external request connection which is passively created and comprises an object number object _ id;

the kbroker _ gateway module is used for receiving an external request and analyzing an application program number app _ id and an object number object _ id of a target app _ object corresponding to the request from the request;

the kbroker _ gateway module supports setting of a default message processing strategy and a special processing strategy based on the application program number app _ id of the target app _ object corresponding to the request for the external request, and selects and determines the processing strategy through the application program number app _ id of the target app _ object analyzed from the external request; if the special processing strategy exists, executing the special processing strategy, otherwise, executing a default processing strategy;

the kbroker _ gateway module also comprises a notify _ api interface and a function _ api interface which are provided for other application programs in the system to access; the notify _ api interface and the function _ api interface constitute an intra-system message processing policy, and the intra-system message processing policy is a default message processing policy or a special message processing policy based on an application program number app _ id of a message source app _ object, and supports setting of a special message processing policy for an application program number app _ id.

further, the kbroker distributed operating system comprises a single application program:

the single-case application program manages single-case business logic in the kbroker distributed operating system, and the single-case business logic cannot be distributed to a plurality of places and is executed in one program process;

the single application program is a special application program in the kbroker distributed system; the application program number of the single-case application program is a single-case application program number singleton _ app _ id specially distributed by the system; the app _ service module of the single application program is a program process of single business logic with various functions;

The app _ allocator module of the singleton application program allocates a singleton object number singleton _ object _ id to each app _ service module, the singleton object number singleton _ object _ id is used for showing the app _ service module as an object of the singleton application program relative to other application programs, and the business layer accesses the app _ service module of the singleton application program through the singleton application program number singleton _ app _ id and the singleton object number singleton _ object _ id of the app _ service module;

The app _ service module of the single application program supports master and slave disaster recovery, and the app _ allocator module manages and maintains the master and slave disaster recovery of the app _ service module;

the app _ service module of the singleton application comprises a unique business layer app _ object, and all business layer requests are processed by the app _ object;

The app _ allocator module of the singleton application program is provided by a kbroker distributed operating system, and the kbroker _ super module and the kbroker _ server module provide support for starting the singleton application program.

Further, the kbroker _ super module supports master-slave disaster recovery, and when the slave kbroker _ super module is unavailable, the master kbroker _ super module starts a new slave kbroker _ super module to realize replacement; when the master kbroker _ super module is unavailable, all slave kbroker _ super modules elect to determine that one slave kbroker _ super module is switched to the master kbroker _ super module, and then a new slave kbroker _ super module is started to realize replacement.

further, the system also comprises a management background used for operating the kbroker distributed operating system:

the management background provides an access interface for the distributed operating system of the kbroker, and the distributed operating system of the kbroker obtains the access interface when being started through configuration or starting parameters; the method comprises the steps that a kbroker distributed operating system reports state information through an interface, wherein the state information comprises connection information of a management gateway, monitoring information of server operation, the operation state of each application program, alarm aiming at abnormal conditions and early warning aiming at specific conditions;

the management background acquires the running information of the distributed operating system of the kbroker through the management gateway and sends an operating instruction to manage the distributed operating system of the kbroker;

And when the management background receives the alarm or early warning information reported by the distributed operating system of the kbroker, the management background gives an alarm to notify a running and developing staff to process the alarm or early warning information.

further, when a larger server cluster is supported, the kbroker distributed operating system extracts a kbroker _ message module to forward messages:

The kbroker _ messager module forwards messages based on the process number program _ id;

Each kbroker _ server module in the system is in communication connection with one kbroker _ messager module, the kbroker _ messager module stores the process number program _ id of the kbroker _ server module connected with the kbroker _ server module and the process number program _ id of other program processes running on a server of the kbroker _ messager module, the process number program _ ids are marked to be managed by the kbroker _ server module, and the process number program _ ids and the communication connection of the process number program _ ids and the kbroker _ server module are bound;

the method comprises the following steps that communication connection is conducted among a plurality of kbroker _ message modules, the kbroker _ message modules store process numbers, program _ ids, managed on other connected kbroker _ message modules, and the process numbers, the program _ ids and the corresponding kbroker _ message modules are bound with the communication connection;

The method comprises the following steps that a kbroker _ super module manages a kbroker _ message module, and each kbroker _ server module is connected to one kbroker _ message module;

when the kbroker _ message module is used for forwarding messages, the kbroker _ server modules are not in communication connection, and the kbroker _ server modules forward the messages sent by the program processes managed by the kbroker _ server modules to the kbroker _ message module after receiving the messages.

further, the present invention also provides a storage medium having stored thereon a computer program which, when executed by a processor, implements a kbroker distributed operating system as described above.

further, the present invention also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the kbroker distributed operating system as described above.

As described above, with the support of the present invention, developers can develop large server-side programs just by focusing on their own services, as they develop the simplest single-threaded programs, without focusing on a series of problems that increase with the amount of access. The efficiency of the server cluster is improved, and a disaster recovery mechanism aiming at software and hardware faults is provided to realize high availability.

drawings

fig. 1 is a schematic system structure diagram of a kbroker distributed operating system, a storage medium, and an electronic device according to an embodiment of the present invention;

Fig. 2 is a flowchart illustrating a system boot process of a kbroker distributed operating system, a storage medium, and an electronic device according to an embodiment of the present invention;

Fig. 3 is a flowchart illustrating application startup of a kbroker distributed operating system, a storage medium, and an electronic device according to an embodiment of the present invention;

fig. 4 is a flowchart illustrating the process of starting an app _ service module in the process of starting an application program of a kbroker distributed operating system, a storage medium, and an electronic device according to an embodiment of the present invention;

fig. 5 is a schematic diagram of a system structure of a kbroker distributed operating system, a storage medium, and an electronic device according to an embodiment of the present invention.

Detailed Description

The embodiments of the present invention are described below with reference to specific embodiments, and other advantages and effects of the present invention will be easily understood by those skilled in the art from the disclosure of the present specification. The invention is capable of other and different embodiments and of being practiced or of being carried out in various ways, and its several details are capable of modification in various respects, all without departing from the spirit and scope of the present invention. It is to be noted that the features in the following embodiments and examples may be combined with each other without conflict.

it should be noted that the drawings provided in the following embodiments are only for illustrating the basic idea of the present invention, and the components related to the present invention are only shown in the drawings rather than drawn according to the number, shape and size of the components in actual implementation, and the type, quantity and proportion of the components in actual implementation may be changed freely, and the layout of the components may be more complicated.

As shown in fig. 1 to 5, the present invention provides a kbroker distributed operating system, which is a distributed operating system applied to multiple servers, and includes: a kbroker _ server module, a service layer module, a kbroker _ super module and a gateway module.

Each server is provided with and only one kbroker _ server module which is an agent of the server and manages all functions on the server, including monitoring and reporting available resources, being responsible for starting the app _ allocator module and the app _ service module on the server, realizing communication connection with the kbroker _ server module on the server through processes after starting, closing and monitoring the app _ allocator module and the app _ service module which run on the server, and creating and closing storage type resources.

the kbroker _ super module manages all servers through the kbroker _ server module. The method comprises the steps of integrating resources on each server into a large resource pool through interconnection between the kbroker _ server modules, and forwarding messages through the kbroker _ server modules according to the process number program _ id of the target program process to realize message transmission among all programs in the system. The kbroker _ super module realizes the effective utilization of resources by selecting a proper kbroker _ server module in the whole resource pool to start a new program and create a storage type resource.

the business layer logic is divided into several application programs, and each application program is composed of two modules, namely an app _ allocator module and an app _ service module, which correspond to the application program. The app _ allocator module is used for managing app _ object objects of the application program, including creation, deletion and allocation of the app _ object objects to a specific app _ service module to run; the app _ service module is an object pool of app _ object objects, responsible for the specific execution of business logic assigned to the app _ object objects running thereon. When the number of the app _ object objects or the access amount is too large, so that the object pool (app _ service module) cannot meet the operation requirement of the business logic, the app _ allocator module applies to the kbroker _ super module to start a new app _ service module. The business logic of the entire system is implemented by the logical processing of the app _ object running on the app _ service module and the mutual invocation between the app _ object objects.

The management of the whole distributed operating system is divided into two layers: integrating the resources of all servers into a resource pool through a kbroker _ super module and a kbroker _ server module to be used by an application program of a business layer; management of the app _ object of the application business layer is achieved by an app _ allocator module and an app _ service module. The former realizes that the requirement can be satisfied by directly adding a server extended resource pool when the server resource is insufficient, and the latter realizes that the business layer only needs to pay attention to the business itself and does not need to pay attention to the load problem (the number of app _ object objects).

The full utilization of the coroutine is a great characteristic of the system, and the purpose of doing so is two points: one is that the method does not block threads so that the logic processing of the app _ object can be put on one thread to be executed in queue, thereby simplifying the complexity of logic development; and secondly, realizing non-blocking calling of the remote app _ object, so that the business layer calls the interface of the remote app _ object like calling the local interface, and the whole system is like a single-thread program relative to a developer.

through two-layer management and coroutine use of the system, the whole system is similar to a single-thread program with freely expandable computing resources for a service layer, loads do not need to be concerned, only services need to be concerned, and service layer logic can be simply realized by writing class functions by using an object-oriented programming idea. And the disaster recovery mechanism of the system greatly simplifies the writing and reliable operation of a large-load server program.

the application program in the kbroker distributed operating system comprises the following steps: a computing application, the business logic of which only involves operations and temporarily saves data in memory; storage-type applications, the business logic of which involves the use of storage-type resources to store data. The storage type resource is a storage medium such as a disk or a third-party external program and the like used for storing data to prevent the data from being lost after the distributed operating system is restarted.

The storage type application program refers to an app _ service module, namely an application program used by the service layer to use storage type resources; the kbroker _ super module and some app _ allocator modules also use storage resources, which are referred to as modules relating to storage resources.

the module related to the storage resource needs to run on the same server as the storage type resource used by the module, and therefore when the kbroker _ super module selects the kbroker _ server module for the module related to the storage resource, the kbroker _ server module where the storage type resource used by the module is located is selected instead of the best kbroker _ server module in the resource.

In order to prevent data loss caused by storage type resource failure, all modules related to storage resources need to be subjected to master-slave disaster recovery. The system provides uniform frame support and message transfer support between the master and the slave for the master and the slave, so that the service layer can complete master and slave synchronization through the export and import interface of the rewritten data and the sending and processing interface of the data synchronization.

all used storage type resources are set with resource numbers, resource _ ids and stored by the kbroker _ super module, the association relation between the modules related to the storage type resources and the resource numbers, resource _ ids, of the storage type resources needs to be stored by the appropriate modules, and the master-slave disaster recovery relation among the modules is realized by storing the combination relation of the resource numbers, resource _ ids, of the related storage type resources.

the kbroker _ super module comprises a storage type resource which is used for storing server information, the corresponding relation between the resource serial number resource _ id and the kbroker _ server module, information of an application program and the storage type resource used by the kbroker _ super module. The server information includes login information of the server, the number of the server, and a command to start the kbroker _ server module. The information of the application program comprises the number of the application program, the type of the application program, the parameters of the application program and the storage type resources used by the app _ allocator module of the application program.

The kbroker _ super module maintains and records the available conditions of CPUs, memories, disks and networks on servers where all the kbroker _ server modules are located, and selects a proper kbroker _ server module for newly allocated storage type resources and newly started program processes according to the available conditions.

program processes in the distributed operating system of the kbroker are communicated through a program _ id of a process number; the kbroker _ server module stores the association relationship between the program _ id of the process number and the kbroker _ server module on the server where the program _ id is located, and message transmission in the system is forwarded by the kbroker _ server module.

the server where the kbroker _ server module is located is managed by the kbroker _ super module through the kbroker _ server module, and the addition and deletion of the server where the kbroker _ server module is located in the kbroker distributed operating system are achieved by starting and closing the kbroker _ server module on the server through the kbroker _ super module. A unique kbroker _ server module is included on a server used in each kbroker distributed operating system. The kbroker _ server module monitors the running state of the server where the server is located and the available conditions of a CPU, a memory, a disk and a network, and reports the running state and the available conditions to the kbroker _ server module. The method comprises the steps that a plurality of servers are interconnected through network connection of a kbroker _ server module running on the servers, the kbroker _ server module monitors connection conditions and reports the connection conditions to a kbroker _ super module, and the kbroker _ super module obtains and processes abnormal running conditions of the kbroker _ server module.

In the process that the kbroker _ super module starts the kbroker _ server module: after the kbroker _ server module is started, the network port monitored by the kbroker _ server module is read from the configuration for monitoring, the port monitored by the kbroker _ server module is also carried as a parameter to be uploaded in the process of registering to the kbroker _ super module, and the network address and the monitoring port of the kbroker _ server are stored by the kbroker _ super module after the successful verification.

And after the successful registration of the kbroker _ server module, requesting the network addresses and the monitoring ports of other running kbroker _ servers from the kbroker _ super module, then connecting to other kbroker _ server modules according to the information, and completing the connection after verification.

after the kbroker _ server module is connected with one other running kbroker _ server module or is connected with the other running kbroker _ server modules, the process number program _ id of all program processes running on the kbroker _ server module is requested to the kbroker _ server module, after the process number program _ id is obtained, the process number program _ id is associated with the process number program _ id of the kbroker _ server module, and the forwarding rules of the process number program _ id are associated to the network connection between the kbroker _ server module and the kbroker _ server module.

After the kbroker _ server module is started and registered, is connected with other operating other kbroker _ server modules and acquires programs operating on the kbroker _ server modules, the kbroker _ server module is notified that the kbroker _ server module is initialized successfully, and after the kbroker _ server module receives the notification that the initialization is successful, the kbroker _ server module requests the status of available resources on the kbroker _ server module and then puts the status of the available resources into an available queue.

The method includes that the kbroker _ super module adds and deletes a server where the kbroker _ server module is located in a kbroker distributed operating system by starting and closing the kbroker _ server module on the server, and specifically includes the following steps: the kbroker _ super module stores login information of all servers, serial numbers of the servers and an execution command for starting the kbroker _ server module; the kbroker _ super module logs in the server by using the server login information; the kbroker _ super module executes a starting command on a logged server to start the kbroker _ server module; the started kbroker _ server module is connected to the kbroker _ super module according to the information of the kbroker _ super module in the starting command, and requests for registration and verification to the kbroker _ super module; the kbroker _ super module verifies the registration request, and if the verification is successful, the kbroker _ server module is started successfully; and the kbroker _ super module deletes the server in the distributed operating system by informing the successfully verified kbroker _ server module to close by itself.

the kbroker _ super module is also used to add a new server to the distributed operating system during runtime: submitting login information of a new server to a kbroker _ super module and starting a corresponding kbroker _ server module command on the new server, wherein the kbroker _ super module numbers the new server; and starting and checking a kbroker _ server module corresponding to the new server by the kbroker _ super module, if the verification is successful, successfully adding the new server, and simultaneously storing the information of the new server by the kbroker _ super module.

When the application starts: the method comprises the following steps that a kbroker _ super module selects a proper kbroker _ server module for each app _ allocator module of an application program according to the number of the app _ allocator modules required by the application program, and starts the app _ allocator module through the kbroker _ server module; the method comprises the steps that a kbroker _ super module selects and determines a main app _ allocator module corresponding to an application program from app _ allocator modules of the started application program, other started app _ allocator modules of the application program are set to be synchronous with the main app _ allocator module from the app _ allocator modules, master-slave disaster recovery is achieved, and master-slave disaster recovery is maintained in the running process; and the main app _ allocator module starts the app _ service module and increases or decreases the running number of the app _ service module according to the requirement of running resources in the running process.

The specific process of the app _ allocator module starting the app _ service module is as follows: the app _ allocator module sends a request command for starting an app _ service module to the kbroker _ super module; the method comprises the steps that a kbroker _ super module generates a process number program _ id for a newly started app _ service module, selects a proper kbroker _ server module according to a starting request, and sends a starting instruction for starting the selected app _ service module to the kbroker _ server module; the selected kbroker _ server module starts a corresponding app _ service module according to the starting instruction; and after the app _ service module is started, the app _ service module is connected to the kbroker _ server module through system inter-process communication, and then verification registered in the kbroker _ server module is completed according to the started parameters. After verifying the app _ service module, the kbroker _ server module replies to the kbroker _ super module that the starting is successful, but at the moment, the app _ service module is not added into the own program process; after receiving a successful reply of the kbroker _ server module for starting the app _ service module, the kbroker _ super module stores a process number program _ id of the newly started app _ service module and a corresponding relation between the process number program _ id and the kbroker _ server module, and replies a request parameter which confirms that the app _ service module is successfully started and carries the app _ allocator module to the kbroker _ server module; after receiving the information confirming that the app _ service module is successfully started, the kbroker _ server module adds the app _ service module to the own program process, and simultaneously informs other kbroker _ server modules of newly adding the program process. Then, according to the request parameter of the app _ allocator module in the information, replying to the app _ allocator module that the app _ service module is started successfully and carrying a process number program _ id of the newly started app _ service module; after the app _ allocator module receives the reply that the kbroker _ server module successfully starts the app _ service module, the app _ service module is set with parameter configuration to complete initialization and is added into an available queue.

The kbroker _ super module, when launching the app _ allocator module to the storage resource: the kbroker _ super module saves the association relationship between the resource number resource _ id of the storage type resource used by the app _ allocator module and the application program number app _ id of the application program to which the app _ allocator module belongs; when the kbroker _ super module starts an application program of which the app _ allocator module uses the storage type resources, finding resource numbers, namely resource ids, of all the storage type resources related to the application program number, namely app _ id, of the application program, finding a corresponding kbroker _ server module according to each resource number, namely resource _ id, and starting the app _ allocator module using the storage type resources, wherein if the app _ allocator module is not started successfully, the application program is started unsuccessfully; if the app _ allocator module is successfully started, judging the number of successful starts, if the number of the app _ allocator module meets the requirements of the master and slave disaster recovery devices, finishing and maintaining the master and slave disaster recovery devices, otherwise, starting a new app _ allocator module to meet the number of the master and slave disaster recovery devices, and then finishing and maintaining the master and slave disaster recovery devices; when the kbroker _ super module starts a new app _ allocator module, creating a storage type resource, and starting the new app _ allocator module through the storage type resource, wherein the kbroker _ super module stores the association relationship between the resource number resource _ id of the newly created storage type resource and the application program number app _ id of the application program to which the app _ allocator module belongs; when the app _ allocator module in use is unavailable, the storage type resource used by the app _ allocator module is deleted, and the association relationship between the resource number resource _ id of the storage type resource and the application program number app _ id of the application program to which the app _ allocator module belongs is deleted, and then a new app _ allocator module is started to replace the unavailable app _ allocator module.

The kbroker _ server module is responsible for message forwarding in the system: all messages are forwarded through a message forwarding mechanism on the kbroker _ server module, wherein the message forwarding mechanism is carried out based on a process number program _ id of a target program process; when the kbroker _ server module receives a message to be forwarded, the program _ id of the process number of the message target program process is found out first, and then forwarding is carried out according to the condition of the program _ id of the process number. The specific situations are as follows: when the process number program _ id is owned by the current kbroker _ server module, forwarding the program through communication between the target program process and the own process; when the process number program _ id is owned by other kbroker _ server modules, the process number program _ id is forwarded through the network connection of the kbroker _ server module corresponding to the process number program _ id and the user; and when the process number program _ id does not exist, directly discarding the message. If the program _ id of the process number does not exist in a short time, the program _ id of the process number is requested to be confirmed to exist in the kbroker _ super module; if the sender of the message is owned by the sender, the sender informs that the process number program _ id does not exist, and if the sender is owned by other kbroker _ server modules, the corresponding kbroker _ server module is informed that the process number program _ id does not exist.

The app _ service module is managed by an app _ allocator module corresponding to the application program, and when the app _ allocator module starts the app _ service module, a proper kbroker _ server module is selected through the kbroker _ super module and the selected kbroker _ server module is used for completing specific starting work. When the app _ service module is unavailable, the app _ allocator module deletes or modifies the routing information cache on which the app _ object running on the app _ service module is located, and determines whether to start a new app _ service module as needed. When there are too many app _ service modules, the app _ allocator module will idle the app _ service module.

The kbroker _ server module is responsible for managing the app _ allocator module and the app _ service module which run on the server where the kbroker _ server module is located: the app _ allcator module and the app _ service module are started by the kbroker _ server module, run on the same server as the kbroker _ server module after being started and are connected to the kbroker _ server module through communication among system processes; the message transmission of the app _ allocator module, the app _ service module and other program processes in the kbrooker distributed operating system is forwarded by the kbrooker _ server module; the method comprises the following steps that a kbroker _ server module monitors abnormal conditions of an app _ allocator module and an app _ service module, and reports the abnormal conditions to a kbroker _ super module for processing; and the kbroker _ server module carries out overload setting, migration and closing management operations on the app _ allocator module and the app _ service module which run on the kbroker _ server module according to the total use condition of a CPU (central processing unit), a memory, a disk and a network of the server where the kbroker _ server module is located.

and the kbroker _ server module performs management operations such as overload setting, migration, closing and the like on the app _ allocator module and the app _ service module which run on the kbroker _ server module according to the total resource use condition of the server. When the kbroker _ server module monitors that the used resources of the server reach the set available threshold, all the app _ service modules running on the kbroker _ server module are set to be in an overload state, so that the kbroker _ server module informs the corresponding app _ allocator module that a new app _ object is no longer allocated to the corresponding app _ allocator module. And when the kbroker _ server module monitors that the used resources of the server reach a set limit threshold value, starting migration work.

The computational app _ service module is first notified to shorten the removal interval of the app _ object, change from a relatively long time without access to remove the app _ object to a short time without access to remove the app _ object and notify the app _ allocator module to remove the route of the app _ object.

if the resource usage is still too high after the operation, the computing app _ service module is then notified to migrate the app _ object, and if the app _ object supports migration (the export import interface is implemented), it is migrated to other idle app _ service modules.

And all storage type resources are related to a master-slave disaster recovery mode, and the slave app _ allocator module and the slave app _ service module in the master-slave disaster recovery mode which run on the storage type resources are directly closed under the extreme condition that the used resources are still too high after the operation.

if the resource usage is too high after the slave service is closed, the master app _ allocator module and the master app _ service module in the master-slave disaster recovery mode are switched to other slave modules to convert the master app _ allocator module and the master app _ service module into slaves, and then the closing operation is performed.

when the app _ allocator module manages app _ object objects: the main function of the app _ object module is to manage app _ object, start enough app _ service modules according to the running app _ object, allocate the app _ object objects to be run to the appropriate app _ service modules to run, and provide an interface for querying the routing information of the app _ object (specifically, on which app _ service module) in the system.

Since the app _ service module caches the route information, when the app _ object module replies to a route information request that the app _ object does not exist, it needs to record that the app _ object does not exist and returns the object to the requester for notification to the requester to update its route cache for the app _ object when the app _ object is created next.

The app _ object of the computing application is divided into two modes of permanent existence and temporary existence: permanent existence type: such objects are created and exist unless they are deleted; it does not exist without creation. Such as a common user registration function, the user exists if the user is registered, and does not exist if the user is not registered. Temporary existence type: this is the case where the outside world does not care about or confirm a particular object, and the app _ allocator module manages creation and destruction from the row as needed. Such as unlimited multi-person chunking to buy something, the user only cares about whether the chunking was successful and not about which specific chunking was, for the app _ allocator module of this application, it manages each chunking by itself and assigns the users applying for chunking to the appropriate chunking.

When one app _ service module crashes, the app _ allocator module deletes the routing information stored in all the app _ object objects running on the app _ service module, and allocates the corresponding app _ object objects to the new app _ service module to run when the routing information requests for the app _ object objects are encountered. Additionally, whether to launch a new app _ service module may be considered as needed.

The app _ allocator module is also used to create app _ object objects that manage the application: the mode of the app _ object of the computing application program comprises a permanent existence mode and a temporary existence mode, and the mode of the app _ object of the storage application program is the permanent existence mode; the app _ allocator module creates a start app _ object through the app _ service module execution; the app _ object module stores the routing information of the app _ object, wherein the routing information is the app _ service module on which the app _ object runs and provides an interface for requesting routing information; the app _ allocator module provides corresponding interface functions for creating and deleting the app _ object in the permanent existence mode; the app _ object in the persistent mode starts to run when being accessed, and is closed and quitted to run under the condition of no access request for a long time; for the app _ allocator module that manages persistent mode app _ object, a storage resource is included to store the existing app _ object; for the app _ object in the temporary existence mode, the app _ object is automatically allocated by the app _ allocator module according to the requirement; the app _ allocator module satisfies the application program's specific requirements for the app _ object module by adding a dedicated function.

the app _ allocator module of the storage type application program maintains master and slave disaster recovery of the app _ service module, the app _ allocator module of the storage type application program compiles a plurality of corresponding app _ service modules into a group, sets a grouping number virtual _ id for each group, and maintains master and slave disaster recovery of the app _ service modules in each group.

The app _ service module of the storage type application program is provided with a storage type resource corresponding to the app _ service module, and the app _ allocator module of the storage type application program stores the association relationship between the grouped group number virtual _ id and the resource number resource _ id of the storage type resource used by the app _ service module in the group.

The existing app _ object objects are bound with the packets in a one-to-one correspondence manner, and an app _ allocator module of the storage type application program saves the correspondence; and when no available packet exists, the new packet and the app _ service module in the packet are created first, and then a packet is selected for binding.

The specific logic of the app _ object: the app _ object is uniquely identified by an application program number app _ id of the application program and an object number object _ id of the app _ object on the application program, and the business layer accesses the app _ object through the application program number app _ id of the application program and the object number object _ id of the app _ object on the application program; the service layer realizes service logic by rewriting an app _ object _ i virtual base class provided by the app _ service module; logical processing of a single app _ object can only run on a single app _ service module, with multiple app _ objects running simultaneously on a single app _ service module.

the kbroker distributed operating system provides a virtual interface for creating an app _ object by an object number object _ id, the app _ service module creates the app _ object by the virtual interface rewritten by the business layer, and initializes the app _ object by an initialization interface of the app _ object.

Business logic of the same app _ object is queued on the same thread on the app _ service module for processing, each task event of the app _ object is packaged into a coroutine for execution, the kbroker distributed operating system provides a coroutine support for the blocking type interface, and the support method is to replace the blocking type interface of the operating system to a non-blocking interface of the support coroutine after rewriting through a hook mechanism.

the app _ service module caches the route information of the app _ object, the route information is acquired by the app _ allocator module corresponding to the app _ object to update the cache, and the cache of the route information of the source app _ object in the access request is updated when other app _ object objects are accessed.

The business layer external access is based on the app _ object, the system provides an interface for accessing the external app _ object, and the interface is realized by the app _ service module; the app _ service module finds the process number program _ id of the app _ service module where the app _ object runs according to the cache or the routing information obtained from the corresponding app _ identifier module, and sends a message with the process number program _ id so that the message is sent to the app _ service module where the app _ object runs.

The app _ service module provides programmatic support for remote function calls that access external app _ object objects.

after receiving the message to be processed by the app _ object, the app _ service module checks the operating status of the target app _ object and processes the message, and when monitoring that the message is overloaded, the app _ service module notifies the app _ allocator module to no longer allocate a new app _ object to operate on the object.

the app _ service module provides an interface for the business layer to add asynchronous events and delayed events, a coroutinized lock, and a coroutinized signal.

The app _ service module supports migration of running app _ object objects to other app _ service modules of the same application as it.

the app _ service module of the storage type application program provides a master-slave disaster recovery framework aiming at the app _ object, the master-slave disaster recovery function is realized by matching with a master-slave synchronization related interface in an app _ object _ i virtual base class rewritten by the service layer, and the app _ service module of the storage type application program provides an interface for transmitting data between the master-slave app _ object and the slave app _ object.

The app _ service module is a module for implementing specific business logic, and other modules of the system are all used for providing support for the app _ service module, so that the whole system can run a large number of app _ service modules of various application programs, and further, a large number of app _ object objects are supported to run simultaneously, and the whole distributed system is changed into a simple single-thread program relative to developers.

The app _ service module is an object pool of app _ object objects, creates objects through a create object interface rewritten by the business layer, and passes a message of a certain app _ object sent to the module to a corresponding app _ object running thereon for execution.

when the app _ service module receives the service layer message, it will first determine the status of the target app _ object: the target app _ object is in a normal state, and the interface execution of the app _ object is directly called; if the target app _ object is being initialized, caching the message, and executing the message in sequence after the initialization is finished; if the target app _ object is migrating, caching the message, and if the migration is successful, sequentially delivering the message to the app _ service module in which the target app _ object is migrated to execute the message; if the migration fails, the app _ object is restored to a normal state, and the cached messages are sequentially executed; if the target app _ object is not on the host, the routing information of the target app _ object is searched and the message is forwarded.

The system provides the business layer with a notify _ api _ call interface and a function _ api _ call interface for accessing the remote object, which are both parameterized by the application number app _ id and the object number object _ id of the target app _ object. The notify _ api _ call interface only needs to deliver messages without returning values; the function _ api _ call interface is a programmed remote function call, saves the stack and gives the CPU after the message is delivered, and then restores the stack to the return value after the remote app _ object returns the message to continue execution.

the whole distributed system is that developers can develop a large distributed server-side program like the simplest single-thread program, so that the conventional thinking is adapted to the large distributed server-side program in many places, and the class of the app _ object corresponds to the class in the conventional programming: the function _ api interface of the app _ object corresponds to the general entry in the class that requires a return value function; the notify _ api interface of the app _ object corresponds to the general entry in the class that does not require a return value function; the notify _ api _ call interface converts a function interface of a remote call object, which does not need a return value, into message delivery, the function _ api _ call interface serializes the function interface of the remote call object, which needs a return value, and the service layer can use remote call as local call.

the service layer application program utilizes the notify _ api _ call interface and the function _ api _ call interface to package the interface call provided by the object to the outside into a header file, and other service layers directly use the packaged function interfaces to call the function interfaces of the object. This encapsulated header file resembles the header file of a class in a conventional program. In order for the developer to use existing design patterns, we provide a singleton, object _ singleton, for the current app _ object, the developer can inherit the object _ singleton to use like the traditional singleton pattern.

When the function of adding the asynchronous event and the delayed event interface is realized, the app _ service module cannot be directly added when the service layer calls the interface, and the events should be cached, and the added events are added after the current task logic is executed, so that the problem that the added asynchronous events or delayed events are executed when the current logic is not executed is solved. The app _ service module additionally provides an interface for directly adding asynchronous events to the orchestration signal.

the collaborative lock provided by the app _ service module caches the stack under the condition that other tasks are locked, gives way to the CPU, and restores the stack to continue executing after the locks of the other tasks are released, and in addition, whether the execution is restored after the interruption can be judged through a return value, and whether the execution is overtime exit can be judged through an error parameter.

The programmer signal provided by the app _ service module mainly has two functions of monitoring and sending, and the cache stack gives way out of the CPU during monitoring, and the stack is recovered to continue executing after other tasks send corresponding signals.

The service layer realizes service logic by rewriting the app _ object _ i virtual base class, and the app _ object _ i virtual base class of the computing application program and the app _ object _ i virtual base class of the storage application program both comprise a function _ api interface, a notify _ api interface, an initialization interface, a deletion interface, a data export interface and a data import interface; the function _ api interface is used for processing access requests needing return values, and the notify _ api interface is used for processing access requests needing no return values.

the service layer module realizes service logic processing through a rewriting function _ api interface and a notify _ api interface; the business layer module rewrites the initialization interface to be used for executing initialization after the app _ service module creates an app _ object; the business layer module rewriting deletion interface is used for releasing the data created by the business layer when the app _ service module closes the app _ object; the export data interface and the import data interface are used for migration of the app _ object, the migration of the app _ object is not supported by default, the migration of the app _ object is supported by the application program if the business layer rewrites the two interfaces, and the app _ object is migrated to the app _ service module with low load when the business load is high.

the gateway module comprises a session _ allocator module and a kbroker _ gateway module; the session _ allocator module is used for carrying out extension development based on the basic function of the app _ allocator module, storing socket monitoring information of the kbroker _ gateway module and realizing load balancing of the plurality of kbroker _ gateway modules.

the kbroker _ gateway module is extended and developed based on the basic functions of the app _ service module, supports various external request access modes based on a network, and the app _ object running on the kbroker _ gateway module is an external request connection which is passively created and comprises an object number object _ id.

the kbroker _ gateway module is used for receiving an external request and analyzing an application program number app _ id and an object number object _ id of a target app _ object corresponding to the request from the request. The kbroker _ gateway module supports setting of a default message processing policy for the external request and a special processing policy based on the application program number app _ id of the target app _ object corresponding to the request, and selects and determines the processing policy through the application program number app _ id of the target app _ object analyzed from the external request. And executing the special processing strategy if the special processing strategy exists, and executing a default processing strategy if the special processing strategy does not exist.

the kbroker _ gateway module also comprises a notify _ api interface and a function _ api interface which are provided for other application programs in the system to access; the notify _ api interface and the function _ api interface constitute a message processing policy in the system, the message processing policy in the system is a default message processing policy or a special message processing policy based on an application program number app _ id of a message source app _ object, and the special message processing policy for a certain application program number app _ id is set in a supporting manner.

The gateway module mainly receives an external request, analyzes a target app _ object from the request, and then sends the request to the target app _ object for processing, and also supports special processing logic for the request in specific operation. The gateway can be classified into a long connection type and a short connection type.

Long connection type requests usually require login verification, the login verification is handled by the session _ allocator module, and after the verification is successful, the internal object _ id is obtained, so that the connection and the object _ id can be directly bound, and the subsequent operation is similar to that of a conventional app _ object. There are also long connection type requests that do not require authentication, which can be considered as combining multiple short connections into one connection, and the processing is similar to the short connection type requests below.

the http request is described as an http request, the http request is similar to a functional call, one request is returned, a target app _ object is analyzed from the request, socket connection is stored, then the target app _ object is accessed by directly utilizing a function _ api _ call interface provided by the system, and the function returns and then sends return data to the socket connection.

the gateways of the whole distributed system can be divided into service layer gateways, system management gateways and service management gateways in terms of function types.

The service layer gateway is a gateway provided by the service layer for receiving an external request, and is used for realizing an access interface provided by the service layer of the system.

The system management gateway is a gateway interface provided for system management personnel to use, the system management personnel can obtain the information of the current system such as the operation condition, the fault alarm and the like through the gateway interfaces, and can also execute some operations (including but not limited to adding and deleting servers, forcibly closing a certain application program and the like) through the interfaces to maintain the operation of the system.

The service management gateway is submitted to developers for use, and has the functions of inquiring the running state, alarm information and the like of the application program, adding and deleting the application program, issuing the application program and the like.

The kbroker distributed operating system includes a single instance of an application that manages single instance business logic within the kbroker distributed operating system that is business logic that cannot be distributed to multiple locations but is executed in only one program process.

The single-case application program is a special application program in the kbroker distributed system, the application program number of the single-case application program is a single-case application program number singleton _ app _ id specially distributed by the system, and the app _ service module of the single-case application program is a program process of single-case business logic with various inconsistent functions.

the app _ allocator module of the singleton application allocates a singleton object number singleton _ object _ id to each app _ service module, the singleton object number singleton _ object _ id is used for showing the app _ service module as an object of the singleton application relative to other applications, and the business layer accesses the app _ service module of the singleton application through the singleton application number singleton _ app _ id and the singleton object number singleton _ object _ id of the app _ service module.

the app _ service module of the single application program supports master and slave disaster recovery, and the app _ allocator module manages and maintains the master and slave disaster recovery of the app _ service module. The app _ service module of the singleton application includes a unique business layer app _ object from which all business layer requests are processed. The app _ allocator module of the singleton application program is provided by a kbroker distributed operating system, and the kbroker _ super module and the kbroker _ server module provide support for starting the singleton application program.

The single application program is used for solving the problem that only globally unique logic is provided, such as a common id generator, the id generator provides id number generation work for the whole system, the whole system only has one program to run the logic, and the implementation of the function requirement is greatly different from the operation of the execution logic of the common application program distributed to a plurality of app _ service modules, and therefore a special application program needs to be specially provided to support the function requirement.

The kbroker _ super module supports master-slave disaster recovery, and realizes a master-slave disaster recovery mechanism with multiple slaves. When the slave kbroker _ super module is unavailable, the master kbroker _ super module starts a new slave kbroker _ super module to realize replacement; when the master kbroker _ super module is unavailable, all slave kbroker _ super modules elect to determine that one slave kbroker _ super module is switched to the master kbroker _ super module, and then a new slave kbroker _ super module is started to realize replacement.

the distributed system of the kbroker starts a master kbroker _ super module, the master kbroker _ super module starts a slave kbroker _ super module, and data synchronization is completed to realize master-slave disaster recovery.

And when the master-book _ super module fails, selecting the currently available highest-priority kbroker _ super module from the rest available slave-book _ super modules as the master-book _ super module.

When a slave-book-super module is switched to a master-book-super module, firstly, the available resource status of all the book-server modules and the program number program _ id of the program processes owned by the book-server modules are obtained, the available resource queues of the book-server modules are updated, and the difference between the actual data obtained by the cached book-server module owning program and the slave-book-server module is checked and processed.

The master-slave disaster recovery of the kbroker _ super module is independently realized without depending on other existing programs or class libraries, and can also be realized by the assistance of open source software such as zookeeper.

The distributed operating system of the kbroker also comprises a management background which is used for operating the distributed operating system of the kbroker. The management background provides an access interface for the distributed operating system of the kbroker, and the distributed operating system of the kbroker obtains the access interface when being started through configuration or starting parameters; the kbroker distributed operating system reports state information through the interface, wherein the state information comprises connection information of a management gateway, monitoring information of server operation, the operation state of each application program, alarm aiming at abnormal conditions and early warning aiming at specific conditions.

and the management background acquires the running information of the distributed operating system of the kbroker through the management gateway and sends an operating instruction to manage the distributed operating system of the kbroker.

When a larger-scale server cluster is supported, the distributed operating system of the kbroker extracts a module of the kbroker _ message to forward messages, and the module of the kbroker _ message forwards messages based on the process number program _ id.

Each kbroker _ server module in the system is in communication connection with one kbroker _ message manager module, the kbroker _ message manager module stores the process number program _ id of the kbroker _ server module connected with the kbroker _ server module and the process number program _ id of other program processes running on the server of the kbroker _ message manager module, marks the process number program _ id to be managed by the kbroker _ server module, and binds the process number program _ id and the communication connection of the process number program _ id and the kbroker _ server module.

the method comprises the steps that communication connection is conducted among a plurality of the kbroker _ message modules, the kbroker _ message modules store process numbers, program _ ids, managed on other connected kbroker _ message modules, and the process numbers, the program _ ids and the communication connection between the corresponding kbroker _ message modules are bound.

the kbroker _ super module manages the kbroker _ message modules, and each kbroker _ server module is allocated to be connected to one kbroker _ message module.

considering that the complex management and maintenance can be caused by making the kbroker _ super module into an independent program, and the performance is affected by the network connection between the kbroker _ super module and each kbroker _ server module, for this reason, the kbroker _ super module and the kbroker _ server module are combined into one kbroker program, and when the kbroker _ super module exists on the server where the kbroker program is located, the kbroker _ super module in the program is started, and otherwise, the kbroker _ super module is not started. Thus, only one key kbroker program is required on the entire distributed system. For the development support aspect of the application program, the distributed system provides library files and interface files of an app _ allocator module and an app _ service module, and the application program rewrites the interfaces, compiles and links the library files to form a real app _ allocator program and an app _ service program of the application program.

The kbroker _ super module has a storage type resource for storing login information of all servers, a kbroker _ server number and a command for starting the kbroker _ server module; additionally, an application program number app _ id of the used application program is stored; and the resource serial numbers resource _ id of all the resources and the association relationship of the kbroker _ server module on the server where the resource serial numbers resource _ id are located are also stored. The kbroker _ super module is part of the kbroker program, running on a separate set of threads from the kbroker program. The main functions of the kbroker _ super module are as follows:

And starting the kbroker programs on all the servers according to the stored server information to complete verification registration of the kbroker _ server module in the kbroker programs, and storing socket monitoring information of the kbroker _ server module after verification registration.

And storing and maintaining socket monitoring information of all the kbroker _ server modules, and transmitting the information to the required kbroker _ server module to enable the required kbroker _ server module to be connected to other kbroker _ server modules, so that network connection among all the kbroker _ server modules is realized.

And saving and updating the resource condition of the server reported by all the kbroker _ server modules in time, and selecting a proper server when starting the program process of the application program and allocating resources according to the resource condition.

And distributing a process number program _ id for each running program, wherein the running program comprises a kbroker program in which a kbroker _ server module is positioned, an app _ allocator program and an app _ service program of an application program, and the kbroker _ super module. And meanwhile, the program number program _ id of the progress of the kbroker program is used as the number of the server, and the corresponding relation between all the program numbers program _ id and the numbers of the servers where the program numbers program _ id are located is saved.

and distributing and recording an application program number app _ id for each applied application program, saving the corresponding relation between the process numbers program _ id of the app _ allocator programs and the app _ service program processes and the application program number app _ id after the application programs are started, and managing and maintaining the master-slave disaster recovery of the app _ allocator programs of each application program.

The kbroker _ server module in the kbroker program is mainly connected with other servers in the system to manage programs on the server. The core functions are as follows:

one network port is monitored for accepting connections of the kbroker programs on other servers.

When the kbroker program is connected to other kbroker programs, the number and the check code of the kbroker program are sent to the other party, the other party can take the information and the network address of the source kbroker program to go to a kbroker _ super module for checking, after the check is successful, the two parties are connected successfully, and after the connection is successful, the two parties can mutually acquire the process number program _ id managed by the other party and bind the message delivery of the process number program _ id with the network connection of the two parties.

the kbroker _ server module stores all process number program _ ids and the corresponding relation between the process number program _ ids and the process number program _ ids of the processes of the kbroker program, and the kbroker _ super module is used for judging and processing when the corresponding relation between the unknown process number program _ id or the process number program _ id and the process number program _ id of the processes of the kbroker program conflicts in the running process.

The method comprises the steps that a kbroker _ server module starts a corresponding program after receiving a command of starting the program of a kbroker _ super module, and when starting the program of an app _ allocator module or an app _ service module of an application program, whether an execution file of the corresponding application program exists or not is checked, and the execution file is directly started if the execution file exists; if the software package does not exist, the software package corresponding to the application program is downloaded from the network, the software package comprises all the execution files and the configuration of the application program, the software package is decompressed after being downloaded, and then the execution files are started. After the program is started, the program is connected to a kbroker program through a local socket of an operating system, a kbroker _ server module of the kbroker program stores a program number program _ id of a new starting program process and a corresponding relation of socket connection of the program number program _ id after the kbroker _ super module confirms that the program is started successfully, and broadcasts the new program number program _ id owned by the kbroker program to the kbroker _ server modules of other kbroker programs.

the kbroker program is provided with a thread which is specially responsible for message forwarding, all messages are forwarded according to the target process number program _ id, if the process number program _ id is on other servers, the message is forwarded to a kbroker _ server module of a corresponding server through a socket, and if the process number program _ id is on the server of the program, the corresponding socket is directly found and sent to the corresponding program.

The kbroker program is responsible for monitoring the resource condition of the server where the kbroker program is located and the state of the program process on the server, and managing and maintaining the socket connection condition with other kbroker programs.

the kbroker program implements some relatively cumbersome non-core functions, such as startup of app _ allocator and app _ service programs, resource monitoring of servers, etc., in a scripting language such as python.

The app _ allocator module provides a library of app _ allocators for the business layer to use, provides interfaces to the business layer to implement its own proprietary logic, and then compiles the proprietary code and the library of app _ allocators together to produce an app _ allocator program that is application specific.

the core functions of the app _ allocator module class library are to manage and allocate app _ object objects and manage app _ service modules that specifically run the app _ object objects, which have been described above, and specifically implement the case where the same request, such as a routing request, is sent multiple times in succession, in which case a locking mechanism may be used to avoid repeated operations.

the app _ allocator module class library provides processing interfaces for core operations such as external incoming routing query requests, successful starting and closing of the app _ service module, successful starting or closing of the app _ object and the like, and the service layer can implement its own proprietary logic by rewriting the interfaces and can also specify whether to execute the conventional logic provided by the class library after executing its own proprietary logic.

the app _ allocator module is not particularly numerous in type in general, and some proprietary programs such as a special app _ allocator program for common persistent objects, mysql, file storage, scene entry, etc. can be appropriately packaged on the basis of providing a base class library to simplify development.

the app _ service module provides an app _ service class library for the business layer to use, the business layer realizes the specific functions of the business layer by rewriting the virtual base class app _ object _ i, and rewrites the virtual interface provided by the system for creating the app _ object to realize the creation of the real business layer object.

The business layer of the app _ service module does not refer to any content related to the server or process number program _ id, but only to the app _ object, which is accessed by the application number app _ id and the object number object _ id.

Parameters of both the notify _ api and the function _ api have cmd command words and msg message contents.

Considering that the notify _ api interface may send a message to the source app _ object in execution although it does not need to return a value, the parameters of the notify _ api interface need to have the application number app _ id and the object number object _ id of the source app _ object of the message as parameters.

The function _ api interface should in principle perform the same logic for all request sources, so there is no need to distinguish which specific app _ object the request source is, but there may be an application number app _ id of the source app _ object of the message in the parameter, which is for access control.

Interfaces such as a notify _ api _ call interface, a function _ api _ call interface, a coordinated lock and signal, an added asynchronous event, a delayed event and the like are unified into a header file of a user _ api, and a service layer refers to the header file as required and uses a related interface.

On the basis of providing a basic class library, the app _ service module class library can also provide a special class library for common requirements such as mysql and the like to simplify development, and all the class libraries can provide respective setting interfaces for setting the interfaces and other parameters for creating the business layer objects rewritten by the business layer.

The gateway module is used for monitoring network connection, receiving an external request, forwarding the external request to an internal corresponding app _ object for processing, and sending return content to a requester. Also by providing a library of kbroker _ gateway module classes for use by the business layer.

the kbroker _ gateway module class library provides a network monitoring interface for the service layer to set a network monitoring port. The method comprises the steps that a kbroker _ gateway module class library provides a virtual base class of a network processing strategy, and the virtual base class comprises interfaces of event processing strategies such as new connection, message receiving, disconnection and the like; and provides an interface for setting policies. The business layer rewrites the virtual base class to realize a special logic, and sets up the rewritten strategy through an interface for setting the strategy.

The kbroker _ gateway module class library provides an interface to set the client message default processing policy, and a special processing policy based on the application number app _ id of the message target app _ object.

The kbroker _ gateway module class library provides a set interface for processing the proprietary processing policy of messages from other programs in the system, the policy being based on the application number app _ id of the message source app _ object, the specific interface in the processing policy being the same as the notify _ api interface and the function _ api interface of the app _ object. The default policy is used without a proprietary processing policy, where the notify _ api interface is processed by sending it to the client over the network connection of the target app _ object, and the function _ api interface is processed by returning an error directly.

an application program finally has its dedicated app _ allocator and app _ service programs and its configuration file, and makes it into a compressed package, which includes the above-mentioned files and a total configuration file, and this total configuration file will indicate the start commands of app _ allocator and app _ service programs, and this compressed package will be uploaded to an internal server for downloading by the whole system, and the kbroker program on each server can download its corresponding package through the application program number app _ id of the application program when necessary, and then decompress to local to start the program in the application program.

The kbroker _ super module, the app _ allocator module and the app _ service module of the storage-type application program all have master-slave disaster recovery, the master module and the slave module are defaulted to be the master module of the corresponding module under the condition that the master module and the slave module are not explicitly specified in the description, only the master module is responsible for logic processing, and the slave module does not participate in the logic processing and is only responsible for synchronously saving the state of the master module.

the present invention also provides a storage medium having stored thereon a computer program which, when executed by a processor, implements a kbroker distributed operating system as described above.

The invention also provides an electronic device, which comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein the computer program realizes the kbroker distributed operating system when the processor processes the program.

In summary, according to the kbroker distributed operating system, the storage medium and the electronic device of the present invention, a developer only focuses on the own service itself, develops a large server-side program like a simplest single-threaded program, and does not need to focus on a series of problems caused by an increase in access amount. The efficiency of the server cluster is improved, and a disaster recovery mechanism aiming at software and hardware faults is provided to realize high availability. Therefore, the present invention effectively overcomes various disadvantages of the prior art and has high industrial utilization value.

The foregoing embodiments are merely illustrative of the principles and utilities of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or change the above-mentioned embodiments without departing from the spirit and scope of the present invention. Accordingly, it is intended that all equivalent modifications or changes which can be made by those skilled in the art without departing from the spirit and technical spirit of the present invention be covered by the claims of the present invention.

Claims

1. a kbroker distributed operating system, comprising:

2. the kbroker distributed operating system of claim 1 wherein the application programs in the distributed operating system comprise:

3. the kbroker distributed operating system of claim 1 wherein the storage resource is a storage medium for storing data to prevent data loss after the kbroker distributed operating system is restarted;

The method comprises the following steps that a kbroker _ server module manages specific generation work of a storage type resource, the specific generation work comprises a local file used for storing a connection access mode of the storage type resource after the storage type resource is generated, and when a program process is used for the storage type resource, the kbroker _ server module transmits the connection access mode of the storage type resource when the program process is started, so that the program process is connected and accesses the storage type resource required by the program process; the kbroker _ server module is also used for managing the destruction and deletion work of the storage type resource.

4. the kbroker distributed operating system according to claim 1, wherein the kbroker _ super module includes a storage resource for storing server information, a correspondence between a resource number resource _ id and the kbroker _ server module, information of an application program, and a storage resource used by the kbroker _ super module.

5. the kbroker distributed operating system according to claim 1, wherein the kbroker _ super module maintains and records available conditions of CPUs, memories, disks, and networks of servers where all the kbroker _ server modules are located, and selects the kbroker _ server module for the newly allocated storage type resource and the newly started program process according to the available conditions.

6. The kbroker distributed operating system according to claim 1, wherein program processes in the kbroker distributed operating system communicate with each other by a process number program _ id; the kbroker _ server module stores the association relationship between the program _ id of the process number and the kbroker _ server module on the server where the program _ id is located, and message transmission in the system is forwarded by the kbroker _ server module.

7. The kbroker distributed operating system according to claim 1, wherein the kbroker _ super module manages a server in which the kbroker _ super module is located through the kbroker _ server module:

8. the kbroker distributed operating system according to claim 7, wherein the kbroker _ super module adds and deletes a server where the kbroker _ server module is located in the kbroker distributed operating system by starting and closing the kbroker _ server module on the server, and specifically includes:

9. the kbroker distributed operating system of claim 8 wherein the kbroker _ super module is further configured to add a new server to the distributed operating system during runtime:

the kbroker _ super module numbers the new server;

10. the kbroker distributed operating system of claim 1 wherein when an application starts:

11. The kbroker distributed operating system of claim 10 wherein the kbroker _ super module, when launching the app _ allocator module to the storage resource:

12. The kbroker distributed operating system according to claim 10, wherein the app _ service module is managed by an app _ allocator module corresponding to the app _ service module:

13. The kbroker distributed operating system according to claim 1, wherein the kbroker _ server module is responsible for managing the app _ allocator module and the app _ service module running on the server where the kbroker _ server module is located:

14. The kbroker distributed operating system of claim 1 wherein the app _ allocator module is further configured to create app _ object objects for managing applications:

15. The kbroker distributed operating system of claim 14 wherein the app _ allocator module of the storage-type application maintains a master-slave disaster recovery of the app _ service module:

16. The kbroker distributed operating system according to claim 1, wherein the app _ service module runs specific logic of app _ object:

17. The kbroker distributed operating system of claim 16 wherein the business layer implements the business logic by overwriting the app _ object _ i virtual base class:

18. The kbroker distributed operating system of claim 1 wherein said gateway module comprises a session _ allocator module, a kbroker _ gateway module;

19. The kbroker distributed operating system of claim 1 wherein the kbroker distributed operating system comprises a singleton application:

20. the distributed klokker operating system according to claim 1, wherein the klokker _ super module supports master-slave disaster recovery, and when the slave klokker _ super module is unavailable, the master klokker _ super module starts a new slave klokker _ super module to realize replacement; when the master kbroker _ super module is unavailable, all slave kbroker _ super modules elect to determine that one slave kbroker _ super module is switched to the master kbroker _ super module, and then a new slave kbroker _ super module is started to realize replacement.

21. The kbroker distributed operating system of claim 1 further comprising a management back-end for operating the kbroker distributed operating system:

22. The kbroker distributed operating system of claim 1 wherein, in supporting larger server clusters, the kbroker distributed operating system abstracts a kbroker _ message module for message forwarding:

23. a storage medium having stored thereon a computer program, characterized in that the program, when executed by a processor, is adapted to implement a kbroker distributed operating system as claimed in claims 1-22.

24. an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement a kbroker distributed operating system as recited in claims 1-22.