Thought gold mine of eBay architecture-ZT

A correct way to understand how one thing is done is to see how it is done in reality. The software industry has always been confused by "Many idea just talk about it in theory. At the same time, software vendors constantly promote these idea as best practices.
Few software developers have witnessed the field of large-scale scalable architecture. Fortunately, sometimes we can see and hear publicly posted information about this. I have read some good materials about Google's hardware infrastructure design and Yahoo's page rendering patents. Now, eBay, another Internet giant, provides us with some information about its architecture: this article refers to "one billion accesses a day-a J2EE system with core J2EE pattern architecture ).
This article provides a lot of information. However, we will only comment on those parts that are unique and of interest to me.
I was impressed by the 99.92% availability of the eBay site and 380 m page data. In addition, nearly 30 thousand lines of code changes every week clearly tell us the high scalability of eBay's Java code.
How eBay uses J2EE technology to achieve this. The extensibility of eBay is as follows:

Judicious use of server-side state
No server affinity
Functional server pools
Horizontal and vertical database partitioning

The linear expansion of eBay's access to data is very interesting. They mentioned the use of "customized O-R mapping" to support local cache and global cache, lazy loading, fetch sets (deep and shallow), and to read and submit a subset of updates. Moreover, they only use bean-managed transactions and automatic database commit and O-R mapping to route different data sources.
Several things are surprising. First, don't use entity beans at all, just use his own O-R mapping tool (hibernate anyone ?). Second, use-case-based application server division. Third, database Division is also based on use-case. Finally, it is the stateless nature of the system and obviously does not use the cluster technology.

The following is a reference to the server status:
Basically, we do not actually use server-side state. We may use it, but now we have no reason to use it ...... To be stateful, put the status in the database. If necessary, we can retrieve the status from the database. We do not need to use clusters. You do not need to do any work for the cluster.

In short, you don't have to worry about building a stateful server on your own. Further, forget about the cluster and you don't need it. Now let's look at the functional division:
 
We have a group or a batch of machines. The application running above is a specific use case. For example, if the search function has its own server group, we can adopt different tuning policies, the reason is that the read-only use case for browsing products is basically different from the read/write use case for selling a product. In the past year 45, we have been using horizontal database partitioning to achieve the availability and linear scalability we need.

In short, do not place your applications and databases on a giant machine. Use Only servers pools. Each pools corresponds to a use case. Does it sound similar to Google's policy.

Below are some introductions on horizontal division:
Content-based routing can achieve horizontal linear expansion of the system. So, imagine that if Ebay has 60 million types of products one day, we don't have to store the data on a super sun server ...... Maybe we can put these databases on many sun servers, but how can we get the data we need? Ebay proposes a content-based routing method. This method uses certain rules to find the data I need from 20 physical servers. What's more about cool is that the Failover policy is also defined here.

Finally, the following statement describes the future architecture with more loose coupling:
 
Using message systems to couple different use cases is our research.

Is it strange that this article first introduced the J2EE design mode? The key idea of linear expansion is almost irrelevant to patterns. Yes, eBay uses design patterns to organize their code. However, over-emphasizing the design model will lead to a loss of overall control. The key idea of the eBay architecture is stateless design. The flexible and highly optimized or-mapping layer and servers are divided based on use cases. The design pattern is good, but it cannot be expected to make the application linearly scalable.

In short, the eBay and Google examples show that the use-case-based server pools architecture is more linearly scalable and available than several large computers. Of course, vendors are afraid to hear such a conclusion. However, the biggest trouble for deploying so many servers is how to manage them. -)

 

My summary:
EBayUse the design model to reach eBayLayered Architecture: layers (presentation layer, business logic layer, and data access layer) are loosely coupled with clear responsibilities, which improves code scalability and program development efficiency.
EBayStateless design, flexible and highly optimized or-MappingLayer and server are based on Use CasesDivision to achieve loose coupling between applications and improve linear scalability of the system.
Why does the system require linear scalability? The purpose is to determine the Website access volume.In the rise, we can increase the support of the entire website by adding servers without modifying any code of the system.