CN100394726C - A Method of Improving the Reliability of Component-Based Software System - Google Patents

Abstract

A method for improving the reliability of a component-based software system. This method adopts a distributed load distribution strategy, which can dynamically load and delete nodes in the cluster without stopping the service of a JToneFrame application server cluster with multiple nodes; support level and vertical segmentation; object-level and method-level EJB container load balancing; support for stateless session bean, state session bean and entity bean cluster. There is no possibility of a single point of failure, and the load distributor is not independent, but the load distributor is used as a component of each node, which solves the centralized problem and distributes the distribution of requests to each node superior.

Description

A Method of Improving the Reliability of Component-Based Software System

technical field

The invention relates to an application server cluster and a fault-tolerant method, in particular to a method for improving the reliability of a component-based software system.

Background technique

The server-side Java platform (J2EE standard) has become the best way to provide Web information services. For mission-critical systems, reliability has become a major challenge for the Internet. Failures that directly impact critical business users or business partners are unacceptable. The infrastructure must be highly available to provide uninterrupted service to the business.

In today's dynamic business environment, in order to meet demand, enterprises must have the ability to dynamically increase capacity. The infrastructure supporting such applications must be sufficiently scalable to allow near-linear expansion without changing software and hardware. Therefore, supporting clustering, load balancing and error recovery for the J2EE platform is a feature that must be supported by an application server with excellent performance, scalability and stability. A cluster is a group of mutually independent servers that behave as a single system in the network and are managed in a single system mode. This single system provides highly reliable services to client workstations. In most cases, all computers in the cluster have a common name, and services running on any system in the cluster can be used by all network clients. The cluster must coordinate the management of errors and failures of separate components, and transparently join components to the cluster. A cluster consists of multiple (at least two) servers with shared data storage space. When any server runs an application, the application data is stored in the shared data space. Each server's operating system and application files are stored on its own local storage. Each node server in the cluster communicates with each other through the internal LAN. When a node server fails, the applications running on this server will be automatically taken over on another node server. When an application service fails, the application service will be restarted or taken over by another server. When any of the above failures occurs, customers will be able to quickly connect to new application services. Clustering services are necessary for J2EE servers used in large enterprise applications. However, the J2EE specification does not specify the content of the cluster, so the implementation of the cluster is determined by the specific server. As an enterprise-level application server, an application server needs to process a large number of concurrent requests, and the data in these processes are important and cannot be mistaken. In order to improve the performance of a large number of visits and meet the requirements of reliability, the application server needs the ability of load balancing and fault tolerance, and the following new features of the application server are provided: Scalability: refers to the ability of an application to support a growing number of users ability. When servers are dynamically added or reduced due to certain needs, there will be no impact on the system. Usually due to the increase of system load, new servers need to be added dynamically, so this call should be transparent to customers, without interrupting the work of other servers; Reliability: Reliability means that the system has a certain degree of redundancy. In the cluster system, the crash of a certain node will not affect the service of the system, the system can automatically migrate the task, and the server that can handle this task will automatically process the client's request.

As can be seen from the above features that the cluster needs to support, the cluster includes two aspects of load balancing and fault tolerance. Load balancing enables the server group to share the workload, and it adopts a certain load distribution strategy to optimize the performance of the server. And all these jobs are transparent to the client's access without the client's intervention. Ideally, if each server in the cluster has the same processing power, it will carry the same amount of load. Therefore, each load distribution algorithm is related to the performance of the server itself, how to collect and process this information, and what algorithm is used to distribute the load. Fault tolerance employs multiple replicas of data, allowing some degree of error and failure. Ideally, error recovery should be completely transparent to clients. When a server fails, clients that are interacting with this server can be automatically transferred to other servers. The key point of error recovery is that customers can continue to use server services, even if some application servers fail, and after the server is repaired, they can provide services with other servers immediately, all of which are only related to the server group, and the client does not need it at all Know. As we have analyzed above, cluster services are necessary for J2EE servers used in large-scale enterprise applications. Most of the current application servers do not support fine-grained clusters, and do not support method-level request redirection and state replication technology for object groups. The J2EE specification does not specify the content of clusters, so the implementation of clusters is It depends on the specific server.

Contents of the invention

The purpose of the present invention is to overcome the shortcoming of above-mentioned prior art, a kind of method that improves the reliability based on component software system is provided, this method can realize the JToneFrame application server cluster of a plurality of nodes under the situation of not stopping service, dynamic loading, Delete nodes in the cluster; support horizontal and vertical segmentation; object-level and method-level EJB container load balancing; support for stateless session beans, state session beans and entity bean clusters.

In order to achieve the above object, the technical scheme adopted in the present invention is:

1) First, the client sends a server call request through its client component interface agent;

2) For EJB components that comply with the EJB2.1 specification, add load balancing and fault-tolerant function tags in their extended deployment descriptors, instruct the EJB components to support cluster functions and use the random allocation load balancing algorithm by default, and compile the EJB components through the precompiler , generate the corresponding implementation classes of the EJBHome and EJBObject interfaces, and generate the Stub of the implementation class, use the precompilation tool to change the execution logic of the original remote call of the Stub class, and request the EJB component on the server side before each business method call The reference list of each server realizes the redistribution of requests;

3) The customer's request is randomly received by any server in the server group. This server uses the underlying server group communication protocol to communicate with other servers. According to the extended deployment descriptor of the EJB component, the customer selects the load parameters according to his own needs. If the customer If you have your own customized load parameters and distribution strategies, load the parameters and strategies customized by the customer, and then call the load collection command on other servers to collect load information on each node according to the loaded customized parameters and policy modules; if the customer does not customize this item, the server can load default parameters and allocation strategies;

4) Define load parameters

Basic operating environment parameters of the system: In the J2EE-based application server middleware system, the basic operating environment parameters of the system are defined as the heap size of the JVM and the memory used;

Component container: The component container includes the Servlet container and the EJB container. The Servlet container parameters include: the number of Servlet running and the number of user unit event requests. The EJB container parameters include the number of created components, the running Number of components, number of pooled components;

Other referenced resources are divided according to their categories: data source resources, JCA resources, JMS resources, define their connection quantity parameters, available connection quantity resources and waiting reference resource quantities;

5) According to the above definition of load parameters, each node regularly starts load information collection, collects data from the Java virtual machine, and dynamically calculates the server load at the current moment: L _i (t)=αB(t)+βC(t)+ λR(t), B(t) represents the load of the basic operating environment of the system at time t, C(t) represents the load of the component container at time t, R(t) represents the amount of resource references at time t, α, β, λ Indicates the weight, each node returns its current load condition L _i (t) to the requesting node, and the node receiving the client request calculates the total load of the server group at time t as $L\left(t\right)=\underset{i=1}{\overset{\mathrm{no}}{\mathrm{\Σ}}}{L}_i\left(t\right)$ and the threshold at the current moment is $T\left(t\right)=\frac{L\left(t\right)}{\mathrm{no}},$ where n is the number of servers;

6) The Stubs of each node of the server are sorted according to the load, and the list of all available servers is returned to the client interface agent;

7) When L _i (t)>T(t), the client selects nodes according to the order of the returned list, removes the reference from the node with the lightest load, and sends a request based on the server reference. At this time, the request will be in the light-loaded node execute on

8) If this node can process the request correctly and no exception is thrown, then synchronize the state information of other nodes to ensure the correctness of the next request call and allocation. If the call is unsuccessful, the client's request will return the list of client nodes, according to The server's node list selects the next light-loaded server node to call the business method of the EJB component. When all nodes in the node list fail, the client call will not be processed correctly.

Since the present invention adopts a distributed load distribution strategy, there is no centralized load distributor, there is no possibility of a single point of failure, and the load distributor is not independent, but the load distributor is used as a component of each node , which solves the centralized problem and distributes the distribution of requests to each node.

Description of drawings

Figure 1 is a call form diagram of the client;

Figure 2 is a cluster system composed of two server replica nodes.

Detailed ways

The present invention will be described in further detail below in conjunction with the accompanying drawings.

In order to realize the above-mentioned application server cluster and fault-tolerant technical content, the present invention divides the implementation into two parts, the EJB component client and the server-side implementation,

client:

First, the client sends a server call request through the client component interface agent; the client is responsible for the work of request forwarding. These tasks are specifically performed by the client agent (Stub) in the RMI system. The client Stub sends the business method call request from the client to any server replica node, and realizes fault tolerance by moving the actual call action up to its superclass. Then the request is forwarded by the client stub. The client stub must hold the server-side information, so the list view of the entire server group is synchronously maintained on each server node, and this information is stored in the member domain server. The specific content in the server is the client stub (including home stub and remote stub) generated by this EJB on each server replica node. The client stub only needs to take out the stub of any server node, obtain its remote reference, use it to replace its own remote reference, and then let the business method call happen on the current remote reference, and the business method can be called smoothly Send to the server replica node corresponding to the stub.

See Figure 1, 1. After the client Stub has added the getServerList() method, the client does not call any method at first, and there is only one content in the server, which is the client stub itself that holds it.

2. Before each client calls a business method, the client stub will call the getServerList() method to obtain the server list, update the local server content with the current server replica list of the cluster system, and then return the server list to the client End Stub. The getServerList() method is implemented in the implementation class of the Home/Remote interface on the server side, so the getServerList() method call made by the client stub is actually a remote method call.

3. When the client obtains the server list, the client stub selects a node from the list and calls the business method again. After receiving the business method call, the server calls the method of actually deploying the Bean instance of the EJB, and then sends the client Return the call result.

In order to achieve the above functions, you can use code automatic generation technology, and define extended deployment descriptors, extended deployment descriptors comply with the EJB2. It supports cluster function and adopts random distribution load balancing algorithm by default, compiles EJB components through pre-compiler, generates corresponding implementation classes of EJBHome and EJBObject interfaces, and modifies the Stub of the generated implementation classes to change the original remote call Execute the logic, before each business method call, request the reference list of each server of the EJB component on the server side, so as to realize the redistribution of the request;

The precompilation process goes through the following steps:

1. Obtain the meta-information of the input jar file through the deployment descriptor and reflection mechanism, and combine it with the template file to generate the source file of the EJB implementation class.

2. Call javac to compile the generated source file to obtain the class file.

3. Call rmic to generate corresponding stub and skeleton files. The source files of the generated stub and skeleton are kept here.

4. Modify stub and skeleton source files to add support for transactions and security.

5. Recompile the modified stub and skeleton files to obtain new class files.

6. Finally, update the input jar file with these generated class files.

7. The final output content includes new jar (ear) files of implementation classes, stub and skeleton classes, and class files defined by the original client.

The underlying server group communication protocol communicates with other servers to ensure a unified view of the server, and it is the bus used by servers.

1. The client's request is initiated by the precompiled production stub agent;

2. The client's request is randomly received by a server in the server group, and this server uses the underlying server group communication protocol to communicate with other servers;

3. The server node receiving the request sends a load collection command to other servers, and the load balancer of each node sends to collect load information. The underlying collector collects the basic system operating environment parameters of each node; component containers, and other load parameters of reference resources, and dynamically calculates the server load at the current moment: L _i (t) = αB(t) + βC(t) +λR(t), B(t) represents the load of the basic operating environment of the system at time t, C(t) represents the load of the component container at time t, R(t) represents the amount of resource references at time t, α, β, λ represents the weight respectively, and each node returns its current load situation L _i (t) to the requesting node.

4. The node receiving the call from the client calculates the total load of the server group at time t as $L\left(t\right)=\underset{i=1}{\overset{\mathrm{no}}{\mathrm{\Σ}}}{L}_i\left(t\right),$ Get the threshold at the current moment as $T\left(t\right)=\frac{L\left(t\right)}{\mathrm{no}},$ After node information collection and load calculation, the stubs of each node in the serverList are sorted according to the load priority, and the sorted serverList is sent to the client stub through the getServerList() method. When the number of servers of the current node L _i (t)>T(t), the client stub is invoked in order of serverList.

Service-Terminal

The main requirement of the server side of the cluster system is to make each server replica node identical to a specific client at any time, that is, the state is consistent. According to the EJB life cycle, for an EJB, its cluster system server has three stages:

1. Creation: EJB calls the creation method on a certain node, so that this node can receive the method call of this EJB. Then, at this time, other nodes in the cluster system also need to perform some creation work, so that any one of them can receive the method call of this EJB.

2. Method call (that is, the use process of an EJB): For stateless session beans, because the beans do not save the state, there is no need to do anything; for stateful session beans and entity beans, because the beans save the state, so in each method State replication is also required when calling, so that all nodes have the same state for this EJB, so that transparent migration can be realized.

3. Removal: If the EJB invokes the removal method on a certain node, the node will not be able to receive the EJB's method invocation request thereafter. Other nodes in the cluster system also need to be removed, so that each node cannot receive the method call request of this EJB.

Each type of EJB is different. There are different processing methods for the above processing. The specific design of the server will be divided into stateful session beans, entity beans and stateless session beans. The server-side implementations of the three types of beans are basically compared. Therefore, first Describe the implementation of stateful session beans in detail, and then supplement the special parts of entity beans and stateless session beans.

4. Stateful Session Bean (Stateful Session Bean)

There are several specific issues to consider when implementing a stateful session bean cluster: first, you need to consider replicating those states; second, you must have the correct correspondence between different nodes when performing state replication; at the same time, you must also consider passivation and activation The effect of the operation on state replication. The container is the running environment of the EJB component. Although the container initialization is not a part of the EJB life cycle, it also plays an important role in the cluster, that is, registering the EnterpriseContextRequestMessage and EnterpriseContextReplicationWrap class instances with the state manager, and registering the home implementation class instance with the The replication manager adds this node to the serverList for the home stub.

The container creation process

1. The creation process is started by the client calling the create() method in the home interface;

2. When passing through the instance interceptor, a new context instance will be associated with this creation operation;

3. In the container class, first call the ejbCreate() method of the Bean implementation class instance. Then assign an id to the context instance. In order to have a unique name in the entire cluster system, the id is changed to a node name and a long integer value that only increases. Such an id is unique in the cluster system. The next step is to start the ejbObject instance, publish it to the rmi port to make it available to the client, and register the ejbObject to the replication manager to add this node to the serverList.

4. When the method call returns to the instance interceptor, if the creation is successful, the context will be inserted into the cache, and the creation request will be sent to other nodes, and the result will be returned to the client.

Business method call process

1. The calling process of the business method starts from the client calling the business method in the Remote interface;

2. When passing through the instance interceptor, take out the context instance corresponding to the id from the cache, and send a retained message first before entering the next interceptor. Other nodes receiving this message will lock the context instance with the same id value on it. Because this method call should have the same impact on all nodes, it is necessary to prevent context instances of the same value on other nodes from being passivated or even deleted during the method call on this node.

3. When the method call returns to the instance interceptor, no matter whether the call is successful or not, the work of state synchronization must be carried out, that is, the context instance will be packaged and sent to all other nodes.

4. The response work of other nodes after receiving the state synchronization request mainly includes two aspects: one is that the instance reference of the context instance on this node will point to the received instance instance to synchronize the state changes of the instance instance; the other is that the instance reference on this node The locked value is set to the received locked value to synchronize the calling state of the context instance.

5. The post-creation process is a special creation process. After a new node joins the cluster system, if it receives an EJB business method state synchronization request, then because the EJB has not been created on this new node, the post-creation process must first be performed.

removal process

1. The removal process starts when the client calls the remove() method in the Remote interface.

2. When passing through the instance interceptor, it is the same as the general business method call.

3. In the container class, first stop the ejbObject instance to make it unavailable to the client; then call the ejbRemove() method; finally set the id of the context instance to null.

4. When the end method calls the instance interceptor, because the id of the context instance is set to null, the context instance will be removed from the cache.

Server-side state synchronization

Referring to Figure 2, Figure 2 is a cluster system composed of two server replica nodes, showing the complete process of method invocation and state replication on node1. Figure 2 shows the previous creation process, business method invocation process, response creation process and response business method state synchronization process.

1. The client's method call is received by node 1, and the method is divided into two types: the creation method of the Home interface and the business method call.

2. If it is the creation method of the Home interface, first create the component object on node 1, and then perform the state synchronization method. Node 2 receives the state synchronization method and judges the type of the synchronization method. If it is a Home creation method, it creates the same object instance on Node 2. After the synchronization process is completed, Node 1 returns the call result to the client.

3. If it is a business method call, first take out the corresponding object context (EnterpriseContext) from the Cache according to the Id of the method being called by the client, and at the same time issue a context lock request (LockingRequest), node 2 takes out the object context from the Cache, and performs the locking operation (setLock ) to make it in the waiting state (Wait). Then node 1 processes the business method call, and after completion, performs state synchronization. Node 2 receives the synchronization method call, performs the synchronization operation of the business method, and synchronizes the state attributes of the object instance. After the synchronization operation is completed, node 1 returns the call result to the client.

4. If node 2 has already created an EJB object instance, just synchronize the state of this business method call, otherwise firstly create an EJB object instance at node 2, and then synchronize with the state of node 1.

fault-tolerant process

1. If the client call returns a correct result, the call is complete.

2. If the client's call catches IOException or RunTimeException, select the second light load node from the ServerList, and continue to make business method calls to other servers.

3. If the available nodes in the ServerList are empty and no correct result is returned, the call fails.

Entity Bean (Entity Bean)

The process is basically the same as that of a stateful session bean, except that the life cycle of a stateful session bean is started by calling the create method, while the life cycle of an entity bean can be started by calling the create method or by calling the finder method.

The finder method is divided into singular search and plural search processes: singular search returns only one ejbObject instance, while plural search returns a batch of ejbObject instances. The singular search process is very similar to the creation process, while the plural search process just creates and starts a batch of ejbObject instances, and other work is performed when a specific ejbObject instance is used to call a method. Therefore, the create process and the singular finder process are referred to as singular processes here, and the plural finder processes are referred to as plural processes.

The synchronous response to the singular process and the plural process is also different: the response creation of the singular process and the stateful session bean are basically the same, but the instance instance is not copied, and only valid is set to false; the plural process obtains the id list from ejbObjectIdList, These ejbObject instances are created and started locally, and other work is performed when a method call is made through an ejbObject instance.

Business method call process

It can be said that it is the same as the business method invocation process of a stateful session bean. The only difference is that the instance instance is not copied, but the valid of the local context instance is set to false, forcing it to obtain synchronization from the database before making a method call

Stateless Session Bean (Stateless Session Bean)

Stateless session beans are quite different from the first two types of beans because they do not hold state. But there is no big difference in the basic design, and only the parts different from stateful session beans are described below.

container initialization

The container of the stateless session bean will mount its own instance to a global access point after it starts. This global access point is the static member variable containerList, which holds all the started stateless session bean container class instances on a node.

Business Method Invocation and Post-Creation

For a stateless session bean without state, there is no need for state synchronization, so when calling a business method, it will not make any state synchronization requirements for other nodes. For this reason, the post-creation work of a stateless session bean cannot be initiated by the bean itself, because the bean has no way of knowing whether a new node has joined.

Therefore, the post-creation work of the stateless session bean can adopt a more tortuous way: when a node in the cluster senses that a new node has joined, it will notify all the stateless session bean containers that have been started on this node , and the Bean relative to these containers will issue a creation request to other nodes when the next business method call (except the remove() method). The node that receives the creation request checks itself, and ignores it if it has already been created, otherwise it performs post-creation work.

Several key implementation technologies of application server clusters have been described in detail above, and these implementation processes have been verified in JToneCluster cluster servers. As long as application servers follow the above technical implementation solutions, they can achieve highly reliable and high-performance server clusters .

Claims (1)

1. A method for improving the reliability of component software systems, characterized in that: 1) First, the client sends a server call request through its client component interface agent; 2) For EJB components that comply with the EJB2.1 specification, add load balancing and fault-tolerant function tags in their extended deployment descriptors, instruct the EJB components to support cluster functions and use the random allocation load balancing algorithm by default, and compile the EJB components through the precompiler , generate the corresponding implementation classes of the EJBHome and EJBObject interfaces, and generate the Stub of the implementation class, use the precompilation tool to change the execution logic of the original remote call of the Stub class, and request the EJB component on the server side before each business method call The reference list of each server realizes the redistribution of requests; 3) The customer's request is randomly received by any server in the server group. This server uses the underlying server group communication protocol to communicate with other servers. According to the extended deployment descriptor of the EJB component, the customer selects the load parameters according to his own needs. If the customer If you have your own customized load parameters and distribution strategies, load the parameters and strategies customized by the customer, and then call the load collection command on other servers to collect load information on each node according to the loaded customized parameters and policy modules; if the customer does not customize this item, the server can load default parameters and allocation strategies; 4) Define load parameters Basic operating environment parameters of the system: In the J2EE-based application server middleware system, the basic operating environment parameters of the system are defined as the heap size of the JVM and the memory used; Component container: The component container includes the Servlet container and the EJB container. The Servlet container parameters include: the number of Servlet running and the number of user unit event requests. The EJB container parameters include the number of created components, the running Number of components, number of pooled components; Other referenced resources are divided according to their categories: data source resources, JCA resources, JMS resources, define their connection quantity parameters, available connection quantity resources and waiting reference resource quantities; 5) According to the above definition of load parameters, each node regularly starts load information collection, collects data from the Java virtual machine, and dynamically calculates the server load at the current moment: L _i (t)=αB(t)+βC(t)+ λR(t), B(t) represents the load of the basic operating environment of the system at time t, C(t) represents the load of the component container at time t, R(t) represents the amount of resource references at time t, α, β, λ Indicates the weight, each node returns its current load condition L _i (t) to the requesting node, and the node receiving the client request calculates the total load of the server group at time t as $L\left(t\right)=\underset{i=1}{\overset{\mathrm{no}}{\mathrm{\Σ}}}{L}_i\left(t\right)$ and the threshold at the current moment is $T\left(t\right)=\frac{L\left(t\right)}{\mathrm{no}},$ where n is the number of servers; 6) The Stubs of each node of the server are sorted according to the load, and the list of all available servers is returned to the client interface agent; 7) When L _i (t)>T(t), the client selects nodes according to the order of the returned list, removes the reference from the node with the lightest load, and sends a request based on the server reference. At this time, the request will be in the light-loaded node execute on 8) If this node can process the request correctly and no exception is thrown, then synchronize the state information of other nodes to ensure the correctness of the next request call and allocation. If the call is unsuccessful, the client's request will return the list of client nodes, according to The server's node list selects the next light-loaded server node to call the business method of the EJB component. When all nodes in the node list fail, the client call will not be processed correctly.

Images