Source: http://www.manageability.org/blog/stuff /about-ebays-architecture
Yang Zheng / translation knows how the right way to do is to see how it is doing in reality. The software industry has been confused for "Many IDEAs only in theory". At the same time, software vendors continue to sell these IDEAs as best practices. Little software developers have witnessed the field of large-scale scalable architecture. Fortunately, sometimes we can see and hear about the information disclosed in this regard. I have read some good information about Google's hardware infrastructure and Yahoo's page rendering patents. Now, another interconnected giant, eBay, give us some information on its architecture (translator Note: "The one-year-old visit - the J2EE system" of the Core J2EE Pattern architecture). This article provides a lot of information. However, we will only comment on those parts that are unique to interested. Leave me a deep impression that 99.92% of the EBAY site is available and 380M Page page data. In addition, nearly 300,000 lines of code per week, clearly tell us the high scalability of eBay's Java code. Ebay uses J2EE technology how to do it. The eBay scalability is as follows: Judicious Use of Server-Side State No Server Affinity Functional Server Pools Horizontal and Vertical Database Partitioning
The linear extension of eBay acquires data access is very interesting. They mentioned the use of "custom O-R mapping" to support local cache and global Cache, Lazy Loading, Fetch Sets (Deep and Shallow), and subsets for reading and submitting updates. Moreover, they only use bean-managed transactions and the automatic submission of the database and the O-R mapping to route different data sources. There are a few things very surprising. First, don't use Entity Beans at all, just use his own O-R mapping tool (Hibernate Anyone?). Second, the application server based on Use-case is divided. Third, the division of the database is also based on Use-case. Finally, the system's stateless nature and significantly do not use cluster technology.
Here is a reference to the server status: Basically we don't really use Server-Side State. We may use it, but now we have not found the reason for using it. ..... If you need a status, let's put the status into the database; we need it from the database when you need it. We don't have to use clusters. None need to do anything for the cluster.
In short, you don't have to have a stateful server, further, forget the cluster, you don't need it. Now look at the functional division: We have a group or a batch of machines, the above-mentioned application is a specific USE CASE, such as the search function has their own server group, we can use different tuning strategies because browsing the product this Basically, only read-only use cases and the use case of this reading and writing are different during execution. In the past four five years we have been dividing the level database to achieve usability and linear scalability we need.
In short, don't put your app and database in a giant machine, just use Servers Pools, each pools corresponds to a USE CASE. It sounds similar to Google's policy.
Here are some introductions about horizontal division: content-based routing can realize the horizontal linear expansion of the system. So, imagine that if eBay has 60 million items a certain day, we don't have to store these data on a super sun server. ..... Maybe we can put these databases to many Sun servers, but how do we get the data we need? eBay proposes a method based on content routing. This method finds the data I need from 20 physical servers through a certain rule. What Cool's thing is to define the Failover policy here. Finally, the following sentence describes the future architecture that uses a more loose coupling: using a message system to coupling different USE CASE is our research.
Is it very strange, the initial article introduces J2EE design mode? The key linear extension is almost independent of Patterns. Yes, eBay uses design patterns to organize their code. However, excessively emphasizing the design pattern will lose the grasp of the whole. The key idea of eBay architecture is stateless, using flexible, highly optimized OR-MAPPING and servers based on USE Cases. The design pattern is good, but it does not expect it to make the application linear scalability.
In summary, eBay and Google examples show that the architecture of server Pools based on use-case is proved to be better linear scalability than several large computers. Of course, manufacturers are afraid to hear such conclusions. However, the biggest trouble for deploying so many servers is how to manage them. -)
My summary: eBay uses the layers of the eBay architecture in design mode, loose coupling between the layers (indicating layers, business logic, data access layers), clear responsibilities, and hierarchical improvement of code scalability and program development efficiency . EBay uses stateless design, flexible, highly optimized OR-MAPPING layer, and server based on Uses Cases, to achieve loose coupling between applications, and improve the linear scalability of the system. Why is the system that requires a linear extension, and the purpose is when the number of visits of the site rises, we can improve any code of the system, only by increasing the server, can improve the support of the entire website.
