Microprocessing architecture — Handling complex things
Many companies, such as Amazon, eBay, and NetFlix, have solved this problem by adopting a microprocessing-structured model. The idea is not to develop a single, monolithic application, but to break it up into small, interconnected microservices.
A microservice typically performs a specific function, such as order management, customer management, and so on. Each microservice is a miniature hexagonal application with its own business logic and adapter. Some microservices also publish apis for other microservices and application clients to use. Other microservices complete a Web UI, and at runtime, each instance may be a cloud VM or Docker container.
For example, a system described above might be decomposed as follows:
Each application area is done using microservices, and the Web application is broken down into a series of simple Web applications (one for passengers, one for taxi drivers, for example). This split is easier to deploy for different users, devices, and specific application scenarios.
Each backend service exposes a REST API, and many services themselves use apis provided by other services. For example, driver management uses notification services that inform drivers of a potential need. UI services activate other services to update Web pages. All services employ asynchronous, message-based communication. The internal mechanics of microservices will be discussed in a future series.
Some REST apis are also open to mobile applications used by passengers and drivers. Instead of directly accessing backend services, these applications pass intermediate messages through the API Gateway. The API Gateway is responsible for load balancing, caching, access control, API billing monitoring, and other tasks. It can be easily implemented through NGINX, and will be covered in subsequent articles.
The microservices architecture pattern in The figure above corresponds to The Y-axis representing The Scaleable Cube, a three-dimensional scaleable model described in The Art of Scalability. The other two scalable axes are the X-axis, which consists of multiple copies of applications running on the back end of the load balancer, and the Z-axis, which routes requirements to related services.
Applications can be basically represented by the above three dimensions, with the Y-axis representing the decomposition of applications into microservices. At runtime, the X-axis represents running multiple instances hidden behind the load balancer, providing throughput capability. Some applications may still partition services along the Z-axis. The figure below illustrates how the trip management service is deployed on a Docker running on AWS EC2.
At run time, the trip management service consists of multiple service instances. Each service instance is a Docker container. To ensure high availability, these containers typically run on multiple cloud VMS. Service instances are preceded by a layer of load balancers such as NGINX, which distribute requests between instances. The load balancer also handles other requests, such as caching, permission control, API statistics, and monitoring.
This microservice architecture pattern has a profound impact on the relationship between applications and databases. Unlike traditional services that share a single database, each microservice architecture has its own database. In addition, this thinking also affects enterprise data patterns. At the same time, this pattern implies multiple pieces of data, but one database per service is necessary if you want to reap the benefits of microservices because the architecture requires this kind of loose coupling. The figure below illustrates the sample application database architecture.
Each service has its own database, and each service can use a database type that is more appropriate for it, also known as multilingual consistency architecture. For example, driver management (discovering which driver is closer to the passenger) must use a database that supports geographic information queries.
On the surface, microservices architecture patterns are a bit like SOA in that they are composed of multiple services. Another way to look at this, however, is that the microservices architecture pattern is an SOA without Web services (WS-) and ESB services. Microservice applications prefer simple lightweight protocols, such as REST, rather than WS-, and avoid using ESB and ESB-like capabilities within microservices. The micro architecture pattern also rejects SOA concepts such as Canonical Schema.