Article Directory
(1) Development history
(1 Introduction
Any architecture that now looks very complex and huge must have evolved as the number of users and data in business products grows. The development of architecture may experience monolithic architecture, verticalization and clustering, SOA (service-oriented architecture), microservice architecture, etc. Of course, not all companies will strictly follow the order of this architecture to evolve. Each company encounters different problems, and the development process of the architecture is also different. Especially in the architecture of Internet companies, the number of users is explosive growth in most cases, so the back-end architecture will face greater challenges. The processing method must be to first carry the traffic and then optimize the architecture after the traffic is stable.
(2) Monolithic architecture
[Features]
Generally speaking, if a war package or jar package contains all the functions of an application, we call this architecture a monolithic architecture.
Many traditional Internet companies or startup companies will basically adopt such a structure in the early stage, because such a structure is simple enough to be quickly developed and launched. And for the small number of users at the beginning of the project, such an architecture is sufficient to support the normal operation of the business.
[Problems]
1. The number of users is increasing, and the number of visits to the website continues to increase, resulting in an increasing load on the back-end server.
2. With a large number of users, products need to meet the needs of different users to retain users, making business scenarios more and more complex.
3. The business scenario is becoming more and more complex, which means that it is more difficult to deploy and upgrade a single package. When you only need to update one method, the impact is that the entire package needs to be retested and deployed, and when a package has If the size is hundreds of M or GB, the deployment process is also very painful
(3) Clustering and verticalization
(1) By adding servers horizontally, a single machine becomes a cluster of multiple machines.
(2) Split according to the vertical field of the business, reduce the coupling degree of the business, and reduce the difficulty of scalability caused by a single war package.
（4） SOA
[SOA scenario description]
Assuming that a user performs an order operation, the processing logic of the system is to first check the inventory of the product in the inventory subsystem, and only submit the order when the inventory is sufficient. Then the logic of this inventory check is placed in the order subsystem or inventory What about the subsystem? In the entire system, there must be a lot of similar shared business scenarios, and the logic of these business scenarios will definitely be created repeatedly, resulting in a lot of redundant business codes, and the maintenance cost of these redundant codes It will get higher and higher as time goes by, can we extract these shared business logic to form reusable services?
There are many subsidiaries under a group company, and each subsidiary has its own business model and information Precipitation, no interaction and sharing between various subsidiaries. Although each subsidiary can create a certain value at this time, because the information between the various subsidiaries is not interconnected, information islands are formed between each other, making the value unable to be maximized.
【application】
Based on these problems, SOA (Service-Oriented Architecture) was introduced, which is a service-oriented architecture. Semantically speaking, it is the same as process-oriented, object-oriented, and component-oriented thinking. It is a kind of software composition and Way of development. The core goal is to extract some common shared services that will be called by multiple upper-layer services into independent basic services. These extracted shared services are relatively independent and can be reused. Therefore, in SOA, service is the core abstract means, and business is divided into some coarse-grained business services and business processes.
The main problem SOA solves
1. Information islands.
2. Reuse of shared services.
(5) Microservice architecture
【basic introduction】
From the name point of view, both service-oriented (SOA) and microservices are essentially a manifestation of service-oriented thinking. If SOA is the embryonic form of service-oriented development, then microservices are further optimized for reusable business services. We can regard SOA as a superset of microservices, that is, multiple microservices can form one SOA service. With the refinement of service granularity, the original 10 services may be split into 100 microservices. Once the service scale expands, the complexity of service construction, release, operation and maintenance will also increase exponentially, so the implementation of microservices The premise of the service is the maturation of the software delivery link and infrastructure. Therefore, microservices is not a new concept in my opinion, it is essentially the best practice direction of service-oriented thinking.
[The difference between
SOA and microservices] Because SOA and microservices have different concerns, there is a very big difference between the two;
SOA focuses on the reusability of services and solving the problem of information islands.
Microservices focus on decoupling. Although decoupling and reusability are the same from a specific point of view, they are essentially different. Decoupling is to reduce the degree of coupling between businesses, while reusability is concerned with Service reuse
Microservices will pay more attention to the continuous delivery of DevOps, because after the service granularity is refined, development and operation and maintenance become more important, so the integration of microservices and containerization technology is closer.
(2) Challenges brought by the microservice architecture
(1) Advantages
Controllable complexity: Through more fine-grained splitting of shared business services, a service only needs to focus on a specific business area, and clearly express the service boundary through a well-defined interface. Due to its small size and low complexity, development and maintenance will be simpler.
Technology selection is more flexible: Each microservice is maintained by a different team, so you can freely choose a technology stack based on business characteristics.
Stronger scalability: The service can be flexibly expanded according to the performance requirements and business characteristics of each microservice. For example, by increasing the cluster size of a single service, the hardware configuration of the node where the service is deployed is improved.
Independent deployment: Since each microservice is an independently running process, independent deployment can be achieved. When a microservice changes, there is no need to recompile and deploy the entire application, and the code size of a single microservice is relatively small, making the release more efficient.
Fault tolerance: In the microservice architecture, if a service fails, we can isolate the fault in a single service, and other services can achieve application-level fault tolerance through mechanisms such as retry and degradation
(2) Challenge
Troubleshooting: A request may experience multiple interactions of multiple different microservices, the interaction link may be relatively long, and each microservice will generate its own log. In this case, if a failure occurs, the developer It can be difficult to locate the source of the problem.
Service monitoring: It is easy to monitor services in a monolithic architecture, because all functions are in one service. In the microservice architecture, the service monitoring overhead will be very large. It can be imagined that in an architecture composed of hundreds of microservices, we not only need to monitor the entire link, but also need to implement a similar set of similar services for each microservice. Monitoring of monolithic architecture.
Complexity of the distributed architecture: The microservice itself is built as a distributed system. The distributed system involves remote communication between services. However, network delays and network failures in network communication are unavoidable, thus increasing the number of applications. the complexity.
Service dependency: After the number of microservices increases, there will be more dependencies between each service, making the overall system more complex. Suppose you are completing a case and need to modify services A, B, and C, and A depends on B, and B depends on C. In a monolithic application, you only need to change the relevant modules, integrate the changes, and deploy again. In contrast, the microservice architecture model needs to consider the impact of related changes on different services. For example, you need to update service C, then B, and finally A. Fortunately, many changes generally affect only one service, and there are very few changes that need to coordinate multiple services.
Operation and maintenance costs: In microservices, it is necessary to ensure the normal operation of hundreds of microservices, which poses a huge challenge to operation and maintenance. For example, how to quickly expand capacity when a single service traffic increases, how to deal with the increase of failure points after service splitting, how to quickly deploy and manage a large number of services in a unified manner.
(3) Basic structure of microservices
