Which application architectures are suitable for deployment in the cloud

The biggest difference between cloud-based applications and applications running in private data centers is scalability. The cloud provides the ability to scale on demand, extending and shrinking applications based on fluctuations in load. But the traditional application to give full play to the advantages of the cloud, not simply to deploy the application to the cloud is all right, but need to be based on the characteristics of the cloud around scalability to redesign the architecture, Recently AppDynamics's development preacher Dustin.whittle wrote about the application architecture suitable for cloud deployment, which has great inspiration and reference for our traditional application to cloud deployment.

Applied schemas

Dustin.whittle gives a sample architecture for cloud applications that is highly scalable, as shown in the following illustration:

In this diagram, the application is split according to the idea of layering, which is described as follows:

Client layer: The client layer contains a user interface for the target platform and may include web-based, mobile, or even fat-client user interfaces. In general, this may be a Web application that includes features such as user management, session management, and page building, but the interaction initiated by other clients requires calling the server in the form of a restful service.

Services: The server contains the caching service and the aggregation (aggregate) service, where the cache service holds the latest known state in the recording system (System of record), while the aggregation service interacts directly with the recording system and performs some destructive actions (changing the state in the recording system) )。

Recording system: The recording system is a domain-specific server that drives business functions, may include customer management systems, procurement systems, booking systems, and so on, which is likely to be legacy systems where your application needs to interact with. The aggregation service is responsible for abstracting your application from these unique recording systems and providing a consistent front-end interface for your application.

ESB: When recording system data changes, it needs to trigger events to the specified topic (topic), which is the event-driven architecture (Event-driven Architecture,eda) Where it can affect applications: When a recording system makes a change that other system might be interested in, it triggers an event, and any other system that pays attention to the recording system will monitor the event and respond accordingly. This is also the reason for using theme (topic) instead of queues (queue): Queues support Point-to-Point (point-to-point) messages, while topics support messages or events that publish-subscribe (publish-subscribe). When integrating with legacy systems, we expect these legacy systems to be protected from load. Therefore, we implemented a caching system that maintains all the most up-to-date known states in the recording system. The caching system uses EDA rules to listen for changes to the system, updating its own version of the saved data to ensure that it matches the data in the recording system. This is a very powerful strategy, however, the consistency model is ultimately consistent, which means that if you post a status on social media, your friends may be able to see it in seconds or even minutes, and the data will eventually be the same, but sometimes what you see is not the same as what your friends see. If this consistency is accepted, scalability gains can be achieved to a large extent.

NoSQL: There are many alternatives to data storage, but if you want to store large amounts of data, it's easier to scale with NoSQL storage. There are a variety of nosql stores to choose from, but this matches the characteristics of the stored data, such as MongoDB suitable for storing searchable data, neo4j suitable for storing highly correlated data, and Cassandra for storing key/value pairs. Search indexes such as SOLR are useful for speeding up queries that frequently access data.

When splitting an application into multiple tiers, the best model is to use a service-oriented architecture (service-oriented Architecture,soa). To do this, you can use soap or rest, but rest is more appropriate because it is more scalable. The author then makes a deep exposition of rest, and there are many related articles in Infoq about rest, such as here and here, and even the Chinese version of Roy Fielding's classic Ph. D. thesis. However, the author emphasizes here that the RESTful Web service can remain stateless (stateless). Stateless is a key requirement for scalability, because there is no state, so the request can be answered by any one of the servers. If you need more capacity on the service layer, simply add a virtual machine to the layer without paying attention to the client state, and the load can be redistributed easily.

Deploy to the Cloud

The Cloud based application architecture is described earlier, and the authors explain how such applications can be deployed to the cloud.

The RESTful Web service is deployed to the Web container and is before the data store. These web services are stateless and reflect only the state of the underlying data they expose, so you can deploy as many servers as you need. In cloud-based deployments, you can start by opening enough instances to respond to day-to-day requirements, and then configure the flex strategy to increase or decrease the number of servers based on the load. The best measure of saturation is the response time of the service. You also need to consider the performance of the underlying data stores that these services use. The deployment diagram for the example looks like this:

If there is an EDA requirement for cloud deployment, the ESB is deployed, and the author's advice is to partition the ESB based on functionality (partitioning), so that a segment overload does not affect other segment. As shown in the following illustration:

This separation isolates the system 1 load from the System 2 load. If the load generated by System 1 slows the ESB, it will only affect its own segment and will not affect the segment of System 2 because it is deployed on other hardware. If the ESB product is supported, we can also add servers to the specified segment to implement the extension.

Cloud based applications differ greatly from traditional applications because of their different extensibility requirements. Cloud based applications must be resilient enough to add and remove servers, must be loosely coupled, have to be as stateless as possible, have to plan for failures in advance, and must be able to scale from several servers to thousands of servers.

There is no single correct architecture for cloud applications, but the RESTful services and event-driven architecture described in this article are validated by a proven architecture. The author believes that rest and EDA are the basic tools to implement cloud scalable applications.

At present, many traditional software vendors in China are migrating to the cloud gradually, hoping that this article can provide some reference for the readers.