Micro-services-decompose applications for scalability and scalability

This article describes the increasingly popular micro-service architecture patterns. The big idea behind micro-service is that large, complex and long-lasting applications are designed to be cohesive services that evolve over time. The term micro- service strongly suggests that the service should be very small.

Some people in the community even suggest building 10-100 lines of code (LOC) services. But while small services are what we want, this should not be the main goal. You should be committed to breaking down the system into services to address the development and deployment issues discussed below. Some services may indeed be very small, but some may be very large.

The nature of the micro-service architecture is not new. The concept of distributed systems has a long history. The micro-service architecture is also similar to SOA.

It was even referred to as a lightweight or fine-grained SOA. Indeed, one way to think about the microarchitecture is to see it as an SOA without commercial and heavy ws* and ESB. Although this is not a new concept, the microarchitecture is worth discussing because it is different from the traditional SOA and, more importantly, it solves the problems that many organizations are experiencing today.

In this article, you will learn about the drivers of the micro-service architecture and how to compare it to a more traditional, holistic (monolithic) architecture. We will discuss the benefits and drawbacks of the micro-service architecture. You can learn how to address the key technical challenges of using a micro-service architecture, including inter-service communication and distributed data management.

Overall architecture (sometimes harmful)

From the earliest development and application of Web systems, the most widely used enterprise application architecture is to package all service-side components into one unit. Many enterprise-class Java applications consist of a war or an ear file. Other languages, such as Ruby or even C + +, are written in the same way.

For example, let's assume that you're building an online store that accepts customer orders, checks inventory, and the amount available, and then completes the shipment. The application is likely to be constructed as shown in Figure 1.

Figure 1--The overall architecture

The application consists of several components, including the storefront UI, which implements the user interface and services for managing the product catalog, processing orders, and managing user accounts. These services share a domain model that contains entities such as product, order, and customer.

Although there is a logical modular design, the application will be deployed as a whole. For example, if you use Java, the application will consist of a war file that will run in a Web container, such as Tomcat. If the application is a rails version, it will consist of a directory structure, which can be deployed using phusion passenger if you use Apache/nginx, or when using Tomcat, using JRuby.

This so-called overall structure will have many advantages. The overall architecture is easier to develop because the IDE and other development tools are geared toward developing a single application. They are easy to test because you only need to start an application. The application of the overall architecture is also easy to deploy because you only need to copy the deployment unit-a file or directory-to the machine running the corresponding kind of server.

This is a good way for a relatively small application to work. However, for complex applications, the overall architecture becomes unwieldy. For developers, large, monolithic architecture applications can be difficult to understand and maintain. This is also an impediment to frequent deployments. To deploy a change to an application component, you have to build and deploy an entire large application that is complex, risky, time-consuming, and requires coordination with a large number of developers, leading to a long test cycle.

The overall architecture makes it difficult to test and adopt new technologies. For example, if you do not rewrite the entire application, it is difficult to try to use the new infrastructure framework, and rewriting the entire application is risky and impractical. The result is that you have to stick to the technology you chose at the beginning of the project. In other words, the overall architecture cannot be extended to support large, long-lived applications.

Decompose an application into a service

Fortunately, there are many other architectural styles to support scalability. A useful three-dimensional extensibility model is described in the art of scalability , a scalable cube, as shown in Fig. 2.

Figure 2--Extensibility Cube