Discussion on server selection of large-scale Java Web system

A netizen in Javaeye asked about the architecture and deployment selection of a large web system, hoping to improve the service capabilities of existing java-based Web applications. Because architectural patterns and deployment tuning have been a hot topic in the Java community, this issue has sparked a lot of enthusiastic discussion among netizens, some of which have been instructive to other large Web projects as well. At the beginning of the discussion jackson1225 this describes the current application architecture and Deployment scenarios:

The current system architecture is as follows:

The Web layer is implemented by STRUTS+TOMCAT, the whole system adopts more than 20 Web servers, and its load balance is realized by hardware F5.

The middle layer adopts stateless session Bean+dao+helper class to realize, a total of 3 WebLogic servers, the deployment of multiple ejbs, the load balance is also used F5 to achieve;

The operation of the database layer is realized by the common class, two Oracle database servers, which hold the user information and business data respectively, and a SQL Server database is the third party's business data information;

The web layer invokes the EJB remote interface to access the middleware layer. The web layer first invokes the corresponding EJB remote interface through the EJB interface information configured in an XML configuration file.

One operation in the system involved two Oracle libraries and one SQL Server library access and operation, that is, three database connections, completed in a single transaction.

This architecture is actually used by many companies, because struts and Tomcat are the most popular Java WEB MVC frameworks and servlet containers, and F5 's load balancing is a common solution for scaling across (for example, configuring the session sticky scenario). Since there are transactions across the data source in this system, it is possible to use the WebLogic Server EJB container and support two-phase commit database drivers to guarantee the integrity of things across the data source (of course, container-managed distributed transactions are not the only and optimal solution).

But with the popularity of Rod Johnson's heavyweight book, "Java Development without EJB" and the spring framework, the concept of lightweight frameworks and lightweight containers has been pervasive. So for the jackson1225 proposed this scene, most netizens have questioned, that the system misuse of technology, is a waste of money. Most users think that SLSB (stateless session bean) is completely unnecessary to appear in this scenario, that SLSB access to local resources through the remote interface will have a significant performance overhead, this view is also Rod Johnson in without EJB critical EJB 2.x in a large reverse mode.

Because Java EE is a model-aware solution, schemas and architectures play an important role in Java EE, so many industry experts are wary of the emergence of Anti-patterns ("anti-mode"). As to whether the scheme described above is an inverse model, jackson1225 immediately stands up to plead:

Our project is to use the EJB as a façade, only the remote interface provided to the Web layer call, and only the stateless session bean, so the performance is OK.

The explanation was quickly recognized by some netizens, but it quickly became clear that the architecture was determined to meet the needs of the user, and Davexin (probably jackson1225 's colleague) described the system's users and Concurrency:

Now there is a user 40 million, immediately and another company's membership system merged, add up a total of 90 million users. There are more than 100 million data in the data sheet. This is the basic situation, in fact, I think the current architecture is still possible, now supported by about 5000 concurrent users around, the next will be a system transformation, target support 10,000 concurrent users.

After the specific amount of concurrency was published, some netizens questioned the data, thinking that the system's servlet container supports too small a number of concurrent numbers, wondering if the configuration is not optimized. Davexin also complements the server configuration for this project:

System front-end tomcat is used in the blade, configured in 2G memory, the CPU is probably in 2.0G, each machine also support 250-400 concurrent, and more words, will be corresponding time very often, more than 20 seconds, lost significance, so we came to this conclusion.