Author:
Ikewu| Reprinted, but the original source, author information, and copyright statement of the article must be indicated in hyperlink form
Web: http://www.dbanotes.net/arch/google_app_engine-arch_intro.html
Press: This is the guest blog series. Contributed by Wu zhuhua, who has been engaged in cloud computing-related research at the IBM China Research Institute, is now working on cloud computing technology.
This article will first introduce some design concepts of APP engine, and then introduce the components of App Engine.
Design Concept
In terms of design concepts, App Engine can be summarized as follows:
- Reuse of existing Google technologies: we all know that reuse is one of the core concepts of software engineering, because reuse can not only reduce development costs, but also simplify the architecture. During App Engine Development, the idea of reuse has also been well reflected. For example, datastore is based on Google's bigtable technology and images service is based on Picasa, the User Authentication Service uses Google account, while the e-mail service is based on Gmail.
- Stateless: to better support expansion, Google does not store any important status on the application server layer, but mainly persists data on the datastore layer. In this way, when the application traffic suddenly bursts, you can add a new server to the application for expansion.
- Hard restrictions: the App Engine imposes many hard restrictions on the application code running on it, such as the inability to create socket, thread, and other limited system resources, this ensures that some vicious applications are not affected by the normal operation of their adjacent applications, but also the isolation between applications.
- The Protocol buffers technology is used to solve service heterogeneity: application servers are connected to many services, and there may be heterogeneous problems. For example, the application server is written in Java, some services are written in C ++. Google's solution to this problem is language-neutral, platform-neutral, and scalable protocol buffer, in addition, all API calls on the App Engine platform must be compiled into the binary format of protocol buffer before RPC (Remote Procedure Call.
- Distributed Database: Because App Engine will support a large number of network applications, the design of an independent database is definitely not desirable, and it is likely to face fluctuating traffic, therefore, a distributed database is required to support massive data volumes and massive queries.
Components
Figure 1. Gae architecture diagram (source self-parameter [6])
In short, the architecture can be divided into three parts: front-end, datastore, and service group:
Front end
It consists of four modules:
- Front end: either Load balancer or proxy, which is mainly responsible for load balancing and forwarding requests to the app server (Application Server) or static files.
- Static files: similar to CDN (Content Delivery Network), it is used to store and transmit static files, slice, CSS, and JS scripts attached to those applications.
- APP server: used to process user requests and call the datastore and Service Group following the request content.
- APP master: Scheduling applications between application servers and notifying the front end after scheduling.
Datastore
It is a distributed database based on bigtable technology. Although it can also be understood as a service, it is the only place where the App Engine stores persistent data, therefore, it is a very core module in App Engine. The details will be discussed in the next article.
Service Group
The entire service group includes many services for the app server to call, such as memcache, graphics, users, URL capturing, and task queue.
Differences between Python and Java App Engine
Because most services can be shared by these two versions, the differences between the two are mainly concentrated on the app server side. The Python version of APP server should be the python runtime modified by Google, the version number should be 2.5.2, while the Java version of APP server is based on Jetty 6, because it is smaller than the most commonly used tomcat, so that a server can support more applications, and it should be modified by Google.
Process
Here is an example of a common HTTP request processing process:
- The user sends an HTTP request.
- Front end accepts this request and forwards it to an idle app server.
- The app server processes the request.
- Check whether the handler used to process the request has been initialized. If not, initialize the handler.
- Call the user authentication service of the Service Group to authenticate the user. If the request fails, the entire request processing process must be terminated and information about the user being authenticated must be returned.
- Check whether the data required for this request has been cached in memcahe. If not, a query request is sent to datastore to obtain the data.
- Integrate the data obtained in the previous step to generate the relevant HTML and return it to the user.
- Because HTML contains references to some static files, such as slice and CSS, after you receive HTML, you can also use the front end interface to read static files stored in static files.
The end of this article will focus on the design of the App Engine's core datastore.
-- EOF--
