Reference book: "Go language high concurrency and microservices combat"
Reference book: "Go microservices combat"
The microservice architecture design was proposed as early as 2014. The idea is to transform a single application into a collection of multiple services or applications that can be independently developed, deployed, operated and maintained independently, so as to meet the needs of rapid business changes and multiple teams. The need for parallel development.
In web applications, the earliest architecture was monolithic, which packaged all server-side modules into a single monolithic application. The advantage of this is that it is easy to set up a development environment, test and deploy, but when we make even a small change to a part, the entire project needs to be redeployed and the compilation time is too long. In addition, because the server needs to be packaged uniformly, this architecture is also difficult to support multi-language technology stacks.
The development of business and the innovation of scenarios will gradually increase the number of visits to the system. The performance optimization effect brought by the method of adding machines in a single architecture will become smaller and smaller, and the number of machines and performance differences required by different business parts will increase. come bigger. In order to improve the utilization of the machine, the vertical layered architecture came into being. It vertically divides projects with a single architecture scale as a unit, and splits large applications into applications with a single structure. The most common vertical layered architecture is MVC, which divides the application into a data access layer, a service layer, and a Web layer. Of course, this architecture also has the problem of inheriting all functions in one project, which is not easy to develop, expand and maintain for large-scale projects; system performance expansion can only be achieved by expanding cluster nodes, which is costly and has bottlenecks.
When more and more applications are split by the vertical architecture, there will be business logic components that multiple applications depend on, and there will be more and more demands for each application to interact. At this time, it is necessary to separate some common business components, and define the interface for interaction between services to be provided to the outside world, so that other services can be called. This is the service-oriented structure of SOA. It is a component model that connects the different services of an application through well-defined interfaces and contracts between those services. These interfaces are defined in an independent manner independent of the hardware platform, operating system, and programming language on which the service is implemented. This enables services built in a wide variety of systems to interact in a unified and common way. However, the SOA architecture is more suitable for large-scale software service enterprises to provide external services. It is not commonly used in general business scenarios. The definition, registration and invocation of services require more complicated coding or configuration to achieve, and the business bus is also easy to cause. A single point of risk to the system drags down overall performance.
With the advent of the Internet wave, more and more small and medium-sized enterprises have launched public-oriented websites or applications. These enterprises, unlike large software services enterprises, do not have the ability or need to build the ESB enterprise service bus that SOA relies on. Finally in 2014, the microservice architecture that inherited many advantages and concepts of SOA was born. It completely componentized and serviced business systems, forming a collection of services or applications that can be independently developed, deployed and maintained independently. Respond to faster requirements changes and shorter development iterations.
The earliest definition of microservices is: "The architectural style of microservices is to develop a single application as a set of small services, each running in its own process environment and communicating through a lightweight mechanism such as the HTTP protocol. These services are built tightly around business functions and can be deployed in an automated fashion. Different programming languages can be used between different services, and management is as less centralized as possible.”
Microservices have many characteristics: unique responsibility, each service in microservices is single, or unique in the entire architecture; communication is lightweight, and each service is designed with high cohesion and low coupling. The communication between services adopts lightweight implementation, which means that the implementation of communication has nothing to do with the specific language and platform; independence means that each single service is independent in the process of development, testing and deployment, and is not affected by other services. It will not affect other services; process isolation, each microservice runs in its own independent process, has an independent runtime environment, and can be easily deployed on different machines.
The reason why the microservice architecture can become the most advanced framework at present is that it must have many advantages: high development efficiency, microservices splitting huge and complex systems, each microservice becomes a single function, easy to understand and convenient Development to ensure that the development of each microservice is very efficient; the response to new demands is fast, because for the full split of services, the development and deployment of each new service is very efficient, and the response to new requirements is very fast, which is very suitable for agile development; deployment; More convenient, the deployment of a single microservice does not affect the overall situation, especially if a microservice runs on multiple instances, it can be deployed to provide services to customers at the same time. While there are many advantages, the microservice architecture also has disadvantages: it is difficult to operate and maintain, and there are generally many service interfaces of microservices. Because there are too many, when there is a problem with the entire service, it is necessary to find out which one is the specific one. Problems with microservices are difficult. It is impossible to trace the cause through single-step debug as in the monolithic architecture application; distributed deployment is difficult, because microservices are naturally distributed, so the difficulty of deployment and scheduling management increases; the cost of interface modification High, because many microservices call each other, so when a microservice interface needs to be modified and adjusted, other medium interfaces that depend on this interface must be checked or modified; part of the code is repeated, because the development of each microservice , testing, and deployment are all independent, so many repetitive functions have to be developed repeatedly in each microservice.
Microservices architecture is a popular trend that brings not only innovations in software infrastructure, but also a set of good design concepts and principles. One, high cohesion, low coupling. Closely related transactions should be put together. Each service is an encapsulation of business capabilities for a single responsibility, focusing on one responsibility, and will only be modified due to changes in that responsibility. The services communicate through lightweight communication methods, so that the services are relatively independent and in a low-coupling state. Second, a high degree of autonomy. Services are deployed, run and expanded independently, and each service can be deployed independently and run in an independent process. This operation and deployment method can give the system flexible code organization and release rhythm, making it possible to quickly deliver and respond to changes. Independent development and evolution, flexible technology selection, not constrained by legacy system technology stacks, suitable technology stacks can be selected for appropriate business problems, independent evolution, and language-independent network communication between services. . Independent team and autonomy, the team is responsible for the entire life cycle of the service, working in an independent context, the engineers are responsible for the entire life cycle of the project and do not need to know each other. Third, focus on business. Each service represents specific business logic and has a clear bounded context. The team is organized around the business and can quickly respond to business changes. Isolate implementation details so that business domains can be reused. Fourth, flexible design. Design fault-tolerant systems, prevent exceptions, and design for known errors. Design systems that protect themselves. Services are isolated from each other, limiting the use of resources and preventing cascading service avalanche errors. Fifth, logs and monitoring. When there is an error in the online environment service, it is necessary to quickly and quickly locate the problem and detect possible anomalies and faults. Logging and monitoring are the best choice for quick location and prevention, and are a vital part of the microservice architecture. Monitoring mainly includes service availability status, request traffic, call chain, error count, structured logs, and visualization of service dependencies, so that problems can be found and repaired in time. Comprehensive monitoring can also adjust the system load in real time, perform service degradation when necessary, overload protection, etc., so that the system and environment can provide efficient and stable services. Sixth, automation. The traditional manual operation and maintenance method is bound to be eliminated, and the implementation of microservices has certain prerequisites: automation. As services scale, more automation and standardization are needed to improve performance and reduce costs. Automating operations is essential because ensuring the normal operation of a large number of microservices is a more complex process than a monolithic architecture.
The goal of microservices is to provide rapid business change responsiveness, and it is built around business capabilities. The highest purpose of microservices is to decentralize everything. It has two very important styles: one is that each service has an independent database; the other is the modularization of the system based on API. Different from monolithic applications, in order to meet the simplicity of development and deployment, each microservice corresponds to a database table, which allows the entire system to be integrated in a loosely coupled manner. In a large-scale project, in order to facilitate maintenance and development collaboration, modular segmentation will be performed. The modularization of microservices is different from the modularization of traditional applications. It is carried out through APIs. Other services cannot directly call the encapsulated methods, but can only be accessed through APIs. Modularization through API can avoid complicated internal relationships as the application grows, which makes the operation and maintenance of microservices and new functions easier.
Of course, the microservice architecture is not omnipotent. The choice of the architecture depends on the independence of the business function itself. If the business provided by the system is very low-level, such as the operating system, there is a close cooperation between functions and functions. Splitting into smaller service units will dramatically increase the workload of integration, and the artificial division cannot bring true business isolation, so it cannot be deployed and run independently, so it is not suitable to use the microservice architecture. .