JBoss Cluster Policy Analysis (Source: http://www.yesky.com) Preface Before reading this article, please make sure you have the following foundation, otherwise you may be wasting your time: 1. Learn some of J2EE's basic concepts 2. Understand the basic concepts of the cluster 3. There are some roughly understandings for JBoss, and you can download it on http://www.jboss.org. JBoss is an open source, a J2EE-based application server, which implements most J2EE specifications, in addition to this, have provided enterprise-level features that are not involved in J2EE, such as clusters. This article mainly describes the cluster strategy taken by JBoss and focuses on its load balancing and failure forwarding mechanism. Since JBoss is an application server built on the J2EE specification, we still briefly introduce J2EE specification before starting: J2EE is a set of computing environments for enterprise-class distributed applications, which defines dynamic web page features ( Servlet and JSP), Business Components (EJB), Asynchronous Message Transport Mechanism (JMS), Name, Directory Location Service (JNDI), Database Access (JDBC), with Subsystem Connectors (JCAs), security services, and more. However, it is not enough in the US, J2EE does not define the specifications necessary for enterprise applications, such as clusters, so the cluster implementation can only be designed by each manufacturer. To achieve a cluster based on J2EE specification, we usually do follows: cluster management, load balancing, fail forwarding, replication of server status (such as session in JSP), and considering synchronous and asynchronous issues (such as JMS services It is asynchronous. If you want to make a comprehensive explanation of these content, it is estimated that it can be written into a book. Therefore, this paper mainly discusses: how to achieve the load balance and failure transfer mechanism of stateless EJB? In 1999, Marc Fleury has established JBoss open source projects. Now it has almost 100 active developers, 30 core developers, up to 350,000 downloads per month, its current highest stability is 3.2, version 4.0 In stabilization, cluster management is entered since JBoss3.0, which is almost almost any J2EE specification, such as session, EJB, etc. in JNDI, JSP. More exciting is that the upcoming JBoss4.0 will join JMS to cluster management feature.
The EJB cluster is implemented in JBoss, and the above figure roughly describes a process of calling EJB in JBoss. In JBOSS, the client does not call EJB object directly, and uses a roundabout method, more professionalism is a design mode - proxy model, truly interacting with the client is a proxy object 1, this The proxy object is generally obtained by the client through JNDI technology. The implementation of specific proxy objects is completed by various vendors. In JBoss, a proxy object is a well-designed complex code. But in the client, call a proxy right like that is called that actual EJB object, although it is not the case. Here, JBoss played a small trick, although the proxy object achieved the same interface as the EJB passion, but it actually forwarded the client to another partner it was on the server 2, at the same time, this partner Some of the EJB interfaces required by the client are also defined. When these interfaces are called 3, the wonderful part started, JBoss convers all the various different calls to the client to become a unified format interface 4 ( In this article we are temporarily called the call to the client, and the interface of the JBoss generated unified format is called a system-level interface). When the conversion is completed, all the application level interfaces become system-level interfaces 5. In order to clearly explain this problem, we assume that the client will send the EJB to the following calls: MyRemoteComponent.IncreaseSalary (// myRemoteComponent is actually converted to the JBoss to the following system level call: ProxyClientContainer.invoke (Invocation); // proxyclientContainer is another partner like the agent but what is this invocation? In fact, it is an instance of class invocation, here there is a simple explanation: public class infoccuation {object [] args; // Apply some parameters in the application level interface Method method; // called the application level interface Map paypyload // jboss is the load balancing strategy taken here ...} It will pass a series of interceptors (6 to 7) when the application level interface is converted into a system-level interface. Here, I first want to explain what is a interceptor. In fact, it is a unique design idea in jboss, an interceptor is like a filter, which is used to intercept the client's call, and It performs some processing, such as checking the legitimacy of the client call, achieving security policies, supporting transactions, etc. It is worth mentioning that JBoss's cluster management is also implemented by interceptors, more gratifying, JBoss designers do not cure this interceptor in their core, but use a plug-in (Plug) -in) The method is designed, so you only need to implement its plug-in interface, you can even write your own interceptor, of course, this is not within the discussion of this article. Each of which (6 to 7) will sequentially intercept the Invocation, and they have the following cluster management capabilities: 1. Analyze the contents and tasks of the Invocation. 2, add some information to payload in Invoc to optimize the cluster policy. 3. Read any available information placed in payload. 4. Forward Invocation to the next interceptor. 5. If an error occurs, you can report the error to the caller and return to the correct place.
It is worth noting that the last interceptor, it has some special because it really performs call 8 of the actual EJB 8, which detects whether the client is in the same Java virtual machine, if yes It simply transmits this call directly to EJB objects, which can avoid unnecessary overhead brought about by network transmission, and use the call speed. On the other hand, if the client and EJB are not in the same virtual machine, then they are transmitted over the network, where JBoss provides another interesting strategy, that is, the agent object does not know what is the transfer protocol, Only the last interceptor knows what is the truly transport protocol. In fact, it provides RMI / JRMP, IIOP, HTTP, SOAP and other protocols to transmit. When we design JBoss cluster strategy, we must also decide where to activate load balancing and failure transfer. To do this, please look at the picture below: 1. In a server node, 2, in a mediation The server is 3, and the three programs in the app on the client have their pros and cons, but we feel that the last method is better than the top 2, the reasons are as follows: 1, compared with the second solution, It avoids the whole line crashes due to the failure of the intermediary server. 2, unless the client crashes, load balancing and failure forwarding strategies will fail. And I think there should be no one will have a complaint about it. There is no good complaint, isn't it? 3, from performance, this program is also optimal, because all strategies are happening at the client, province the first, 2 programs by the bottlenecks brought by the server. Therefore, we have chosen the last program to do a cluster strategy for JBoss. In fact, as long as everyone reviews the front part, I will find that the plan we previously described is not a third plan? But we must now do some more in-depth analysis of this strategy in the following aspects: 1. We must join the logic that truly load balance. 2. When the client is invoked, we should be able to decide on which server node will be sent to it. 3. We hope to design a topology map of the client agent to design a relatively appropriate server node so that we can make a good cluster strategy. The design strategy of load balancing has said that JBoss's load balancing and failure forwarding strategy is implemented by the last interceptor (1 in the above picture), however, we have to consider that although the client only issues a call, but targeting The call to the proxy object may contain multiple available server nodes, which is equal to all the sum of all valid nodes in the cluster (see 2 above the above figure), then who will determine this strategy? This work is implemented by a plug-in load balancing strategy (referred to as a referred to as a strategy 1 in the next paragraph, as shown below). When the client calls to the last interceptor, the interceptor will request a policy 1 to select a server node. If this node is valid and called success, the result will return to the proxy object. If it fails, the interceptor does not return the error to the proxy object, but reports this error message to the policy 1, and request it again Select a new node for the client. But there is still a problem worth considering, it is to process some fatal errors. For example, a database server suddenly crashes, then the last interceptor will not be invalid to this, because no matter which server node can solve this problem, the interceptor will report the error to the client, and It is made by its own decision. It seems that there is such a principle in the IT ribbon, it is "the more scalable, the more complex things". "
It is no exception in JBoss, but fortunate is that these work does not bring additional programming to the client, because all policies are completed at the server. JBoss cluster configuration follows the XML specification, the following is a typical cluster configuration of a normal EJB object:
