Translation of the App Engine Architecture

From programming. Google. App. Engine

Chapter 3

3.1 The App Engine Architecture

 

 

 

An incoming request is first sent to the App Engine frontend ). This process is implemented by the Load balancer (
Balancer), which is used to distribute a large number of requests to different front-end servers (frontend)
Servers. After a request is forwarded by the Load balancer to one of the many front-end servers, the front-end will be based on the Request Path domain name (may be a Google Apps
Domain and subdomain or an appspot.com
Subdomain) determine the application requested by the request, and then query the configuration of the application to determine the next step.

The application configuration tells the front-end how to process these requests according to the request URL. A URL path can be mapped to a static file, which is directly delivered to the client, such
JavaScript code file. Alternatively, a URL path can be mapped to a request processing program, which is some application code used to generate a response. The configuration of the application is the same as that developed by the user.
Uploaded together with a program.

If the URL path of a request cannot be matched in the application configuration, the front-end will return an HTTP 404 "not found"
The error is returned to the client. If you want the client to obtain a customized response, for example, a response that reflects HTTP 404 "not found"
Error-friendly HTML code. You can define a URL ing in the configuration to map all URL requests to a program that can return custom responses.

If a URL path is mapped to a static file, the front-end server forwards the request to the static file server (static file
Servers. These servers provide static files for requests. Because static files do not change frequently, these servers have been optimized in terms of network topology and cache for static resources.
Fast transfer of the source. In the application configuration, the user needs to tell the app
Which are static files required by the application. When you upload an application, these static files are placed on the static file server.

If the request URL matches a request processing program, the front-end server forwards the request to the Application Server (APP servers. Application Server pool

Starts an application instance. If a corresponding instance already exists, the existing instance is reused. The application server also finds the corresponding request processing program based on the ing between the URL path and the request processing program in the configuration.

You can configure the frontend and use a Google account to verify the user. The front-end can use several levels of authorization to limit the access permissions of some URL paths: all users,

You have logged on to a user or an application administrator. If you use the Google Apps domain, you can also set your apps to only allow users in this domain to access the applications. The front-end checks whether the user has logged on. If not, It redirects to the Google account logon interface.

Application Server (app
Servers) use several policies to distribute requests and start the handler instance, depending on the network traffic and resource usage of the application. One goal of the application server is to maximize the throughput of the application instance.
So that as many instances as possible need to run to process requests, as few instances as possible are idle. Another design goal of the application server is that a request handler cannot interfere with other requests on the same server.
The behavior and performance of the processing program.

When an application server receives a request, the server checks the configuration to determine which request handlers are used to process the request and call them. The server manages local resources, including CPU, memory, and execution time, to ensure that the application does not interfere with the resource usage of other applications.

Your application code runs in the runtime environment (Runtime Environment). It is an abstraction layer on the server hardware and operating system. The runtime environment is a "sandbox" that only allows applications to use server resources without interfering with the functions of other applications. For example, the sandbox does not allow

The write operation in the file system of the server is not allowed to open the network and connect to other hosts at will.

However, applications can access services other than the runtime environment. For example, URL fetch Service
The service allows an application to connect to a remote machine over HTTP, or use Google's infrastructure to retrieve webpages. These services and Google's own applications such as Gmail, Google
Reader and Picasa use the same service. These services provide a scalable alternative, so that you do not have to develop and execute similar tasks on your own. At the same time, all application servers enable
With the same service, data stored in datastore by a processing program can be directly used by another processing program.

The request handler prepares the response, returns the response, and terminates the process. The application server does not send any data to the client until the request processing program has been terminated, so it cannot keep the data stream or keep the connection for a long time. When the processing program ends, the application server returns a response, and the request is complete.

The frontend can customize the client response. For example, if the client supports compressed responses, the front-end can use the "gzip compression" format to compress the response data. This applies to responses to applications and static files and is automatically completed. The front end uses several techniques to determine when appropriate response compression is used, such as web-based standards or known browser behavior.

The front-end, application server, and static file server are all managed by the Application Manager (APP master.