Whether you are developing or operating, you have to know about microservices!

Before opening the article, I will state a few attitudes towards microservices:

There are many architectural patterns, and microservices are not the only option nor a silver bullet. The vast majority of domestic small and medium-sized companies are blindly pursuing the introduction of microservices, and it can also be seen that the quality of the infrastructure of the engineers who do this kind of technology selection is insufficient.

"You must be tall enough to use microservices." Microservices infrastructure, especially container technology, automated deployment, and automated testing are incomplete, and microservices are in vain and will not bring any qualitative improvement.

The key to the microservice architecture is not the specific implementation, but how to reasonably divide the service boundary and whether the organizational structure matches. Blindly uploading microservices regardless of the size and composition of the R&D team is a bad technology selection.

Spring Boot is the upper encapsulation of Spring's family bucket. It is not a brand-new technology, nor is it a technology worthy of becoming its own killer.

The components of Spring Cloud Netflix in Spring Cloud are verified in the production environment, and the others are recommended to be selected carefully.

1. What is a microservice

Microservices originated from the Micro-Web-Service (Micro-Web-Service) proposed by Dr. Peter Rodgers at the Cloud Computing Expo in 2005. The fundamental idea is similar to the Unix pipeline design concept. In 2014, Martin Fowler and James Lewis jointly proposed the concept of microservices, and defined that the microservice architecture style is a method of developing a single application through a set of small services. Each service runs in its own process and passes Lightweight mechanism for communication (HTTP API). The three key points are small, automated, and lightweight.

Compared with SOA, microservices can be regarded as a subset of SOA, a lightweight SOA, with finer-grained services, independent processes, data separation, and more emphasis on agility, continuous delivery, DevOps, and decentralized practices. The common architecture principle:

• Single responsibility
• Separation of attention: separation of control and logic
• Modularity and divide and conquer

Features:

• Componentization with services
• Organize around business capabilities
• It's a product, not a project
• Endpoint intelligence and dumb pipes: The control logic is at the end point, and the pipe is just transmission
• Fully automated deployment
• Decentralized control of language and data
• Design for failure
• Progressive design

The advantages and disadvantages are as follows

advantage:

• Strong boundaries of modules
• Standalone deployment
• Diversity of technology selection

Disadvantages:

• Distributed brings programming complexity and consumption of remote calls
• Abandon strong consistency and achieve ultimate consistency
• Operational complexity requires a mature operation and maintenance team or operation and maintenance infrastructure

2. Why use microservices

Whether to choose microservices depends on the complexity of the system you want to design. Microservices are used to control complex systems, but with it comes the introduction of the complexity of microservices. The problems faced by other distributed systems, including automated deployment, monitoring, fault-tolerant processing, and eventual consistency, need to be solved. Even if there are some commonly used solutions, there are still significant costs.

The relationship between productivity and complexity is shown in the figure. It can be seen that the more complex the system, the greater the benefits brought by microservices. In addition, whether it is a monolithic application or a microservice, the skills of the team need to be able to be controlled.

One of Martin Fowler's point of view is: Unless the cost of managing a single application is already too complicated (too big to make it difficult to modify and deploy), don't consider microservices. Most applications should choose a monolithic architecture, and do a good job of modularizing monolithic applications instead of splitting them into services.

Therefore, at the beginning, the system adopts a monolithic architecture and is modularized. As the system becomes more and more complex and the boundaries between modules/services become clearer, it is a reasonable architecture to restructure into a microservice architecture. path.

Four situations can be considered for microservices:

• Many people develop a module/project, and there are a lot of conflicts frequently when submitting code.
• The modules are severely coupled and depend on each other. Each change requires multiple teams. There are too many requirements for a single online launch and the risk is high.
• The main business and the secondary business are coupled, and the horizontal expansion process is complicated.
• Fuse downgrade depends on if-else.

The three stages of microservices

• Microservice 1.0: Only use registration discovery and develop based on SpringCloud or Dubbo.
• Microservice 2.0: Uses service management strategies such as circuit breaker, current limit, and downgrade, and is equipped with complete service tools and platforms.
• Microservice 3.0: Service Mesh takes service governance as a general component and is implemented at the platform layer. The application layer only focuses on business logic. The platform layer can automatically schedule and adjust parameters according to business monitoring to achieve AIOps and intelligent scheduling.

Three, microservice architecture

prerequisites

• Rapid environment provision capabilities: rely on cloud computing and container technology to quickly deliver the environment.
• Basic monitoring capabilities: including basic technical monitoring and business monitoring.
• Rapid application deployment capabilities: deployment pipelines are required to provide rapid deployment capabilities.
• Devops culture: It needs to have good continuous delivery capabilities, including full-link tracking, rapid environment provision and deployment, etc. It also needs rapid response capabilities (quick response to problems and failures), and collaborative work of development and operation and maintenance.

In addition, according to Conway's law and inverse Conway's law (technical structure forces organizational structure improvement), organizational structure is also a very critical factor. Corresponding to the microservice architecture, the organizational structure needs to follow the following principles:

• A microservice is maintained by a team, and the team members should preferably be three.
• The tasks and development of a single team are independent and not affected by other factors.
• The team is fully functional, full stack, autonomous, flat and self-managed.

infrastructure

The implementation of microservices needs to rely on many underlying infrastructures, including the provision of microservices compilation, integration, packaging, deployment, configuration, etc., the use of PaaS platform to solve the full life cycle management of microservices from development to operation, while providing a heterogeneous environment Management, container resource isolation and intercommunication, service scaling drift, service upgrade and rollback, service fusing and downgrade, service registration and discovery.

The most basic infrastructure

• Inter-process communication mechanism: Microservices are independent processes, and the communication method between them needs to be determined.
• Service discovery + service routing: Provide a service registry, service providers and consumers obtain service information through service discovery to call services, and achieve service load balancing.
• Service fault tolerance: In the microservice architecture, because there are many services, one service is often down, and the entire request link service is affected. Therefore, service fault tolerance is required. When the service call fails, it can handle errors or fail quickly, including circuit breakers. , Fallback, retry, flow control and service isolation, etc.
• Distributed transaction support: As the business is split into services, sometimes cross-service transactions are unavoidable, that is, the problem of distributed transactions. The principle is to avoid distributed transactions as much as possible. If it is unavoidable, then you can use the message system or CQRS and Event Sourcing solutions to achieve eventual consistency. If strong consistency is required, there are distributed transaction solutions such as two-phase commit, three-phase commit, and TCC.

Improve the efficiency of external service docking and internal development efficiency

• API Gateway: Responsible for the access of external systems and the cross-sectional public level work, including security, logging, permission control, transmission encryption, request forwarding, flow control, etc. The typical gateway function is to expose a domain name xx.com to the outside, and do reverse routing xx.com/user, xx.com/trade according to the first-level directory. Each level of directory, such as user and trade corresponds to a service domain name. In addition, the API gateway can also have a service orchestration function (not recommended).
• Interface framework: Standardize the data format, parsing package, and self-explanatory document used in the communication between services, so that service users can quickly get started.

Improve the efficiency of testing and operation and maintenance

• Continuous integration: This part is not specific to microservices. For the previous monolithic applications, this part is generally necessary. Mainly refers to the continuous compilation and construction of the code process, automated testing through automated means, in order to obtain fast and effective quality feedback, thereby ensuring the smooth delivery of the code. Automated testing includes code-level unit testing, integration testing of a single system, and interface testing between systems.
• Automated deployment: Microservice architecture, the number of nodes can be hundreds or thousands, and automated deployment can increase deployment speed and deployment frequency, thereby ensuring continuous delivery. Including functions such as version management, resource management, deployment operations, and rollback operations. The deployment methods for microservices include blue-green deployment, rolling deployment, and canary deployment.
• Configuration Center: Run-time configuration management can solve the problem of dynamically modifying the configuration and taking effect in batches. Including configuration version management, configuration item management, node management, configuration synchronization, etc.
• Continuous delivery: Including continuous integration, automated deployment and other processes. The goal is to iterate in small steps and deliver quickly.

Further improve operation and maintenance efficiency

• Service monitoring: There are a large number of nodes under the microservice architecture, and the number of machines, networks, processes, interfaces, etc. that need to be monitored is greatly increased. A powerful monitoring system is required that can provide real-time collection of information for analysis and early warning on real-time analysis. Including the number of requests for monitoring services, response time distribution, maximum/minimum response value, error code distribution, etc.
• Service tracking: Tracking the complete path of a request, including request initiation time, response time, response code, request parameters, return results and other information, also called full link tracking. Normal service monitoring can be done together with service monitoring. Macro information is presented by service tracking, and micro information about individual services/nodes is presented by service monitoring. The current implementation theory of service tracking is basically Google's Dapper paper.
• Service security: In principle, microservice calls between intranets should be able to access and write to each other. Generally, permission control is not required, but sometimes limited to business requirements, there are security control requirements for interfaces and data. This part can exist in the service registry in a configuration mode, and is bound to the service, and is controlled by the service node as the service provider at the time of request. The configuration can be stored in the configuration center to facilitate dynamic modification.

In the case of a small number of microservices, the priority of the above infrastructure decreases from top to bottom. Otherwise, relying only on manual operation will result in a very low input-output ratio.

Also need to mention is the Docker container technology. Although this is not necessary for microservices, the characteristics of container technology that are lightweight, flexible, application-dependent, and shielding environmental differences are critical to the realization of continuous delivery, even for traditional monolithic applications. Brings a substantial increase in delivery efficiency.

Four, architecture design mode

After the introduction of microservices, the traditional monolithic application has become a service. The previous architecture in which an application directly provides an interface for client access is no longer applicable. Under the microservice architecture, the interfaces for different devices are used as the BFF layer (Backend For Frontend), also known as the user experience adaptation layer, which is responsible for aggregating and orchestrating the data of the microservice into the data required by the front end. Calls between services use asynchronous messaging as much as possible when allowed (allowing delay), thus forming a user experience-oriented microservice architecture design pattern. As shown below:

Client -> API Gateway -> BFF（Backend For Frontend） -> Downstream Microservices

• The backend uses a microservice architecture, and the microservices can use different programming languages and different storage mechanisms.
• The front desk adopts the BFF mode to adapt to different user experiences (such as desktop browsers, Native App, and tablet responsive Web).
• BFF, API Orchestration Layer, Edge Service Layer, Device Wrapper Layer are the same concepts.
• BFF can't be too much, too much will cause code logic duplication and redundancy.
• The functions undertaken by the gateway, such as Geoip, current limiting, and security authentication, can be placed on the same layer as the BFF. Although the complexity of the BFF layer is increased, performance advantages can be obtained.

Five, service split

The core link of the microservice architecture is mainly the horizontal division of services. Service splitting refers to the decoupling of a complete business system into services. Services need to have single responsibilities, no coupling relationship between them, and independent development and maintenance.

Service splitting is not accomplished overnight, and the boundaries need to be continuously cleared during the development process. Before completely sorting out the service, try to postpone the split of the service, especially the split of the database.

The split method is as follows

• Split based on business logic
• Based on scalable split
• Split based on reliability
• Split based on performance

Among them, for legacy systems that cannot be modified, the strangling mode is adopted: adding new functions outside the legacy system to create a microservice mode, instead of directly modifying the original system, and gradually replacing the old system.

The specifications that need to be followed during the splitting process are as follows

• First less then more, first coarse and then fine (granularity)
• The service is split vertically into up to three layers, and called twice: Controller, composite service, and basic service
• Only one-way call, cyclic call is prohibited
• Serial call is changed to parallel call or asynchronous
• Interface should be idempotent
• Interface data definition is strictly prohibited to be embedded and transparently transmitted
• Standardized project name
• Split the service first, and then split the database after the service granularity is determined.

Six, microservice framework

The above describes the many infrastructures of the microservice architecture. If each infrastructure needs to be developed by itself, it is a very huge development work. There are already many open source microservice frameworks on the market to choose from.

Spring Boot

Spring Boot is used to simplify the initial setup and development process of new Spring applications. Although it is not a microservice framework, the original intention of its design is essentially the underlying framework of microapplications, so it is very suitable for the development of microservice infrastructure and the application development of microservices. Especially for the Spring technology stack team, it is a natural choice to develop microservice frameworks and applications based on Spring Boot.

Dubbo&&Motan

Dubbo Ali's open source service governance framework. It appeared before the rise of the concept of microservices and can be regarded as a masterpiece of the SOA framework. But it only contains part of the functions of the microservice infrastructure, such as circuit breakers, service tracking, gateways, etc., are not implemented.

Motan is an open source RPC framework similar to Dubbo on Weibo, which is more lightweight than Dubbo.

• Service discovery: service publishing, subscription, notification
• High availability strategy: Failover, Failfast, resource isolation-load balancing: least active connections, consistent hash, random request, polling, etc.
• Extensibility: support SPI extension (service provider interface)
• Others: call statistics, access logs, etc.

Spring Cloud

Spring Cloud is a microservice framework based on Spring Boot, and can also be seen as a set of microservice implementation specifications. It basically covers all aspects of microservice infrastructure, including configuration management, service discovery, circuit breakers, intelligent routing, micro-agents, control buses, global locks, decision-making campaigns, distributed sessions, and cluster state management. It is based on the Spring ecology, and the community support is very good. However, many of its components have not been verified in the production environment and need to be carefully selected.

Spring Cloud Netflix is a sub-project of Spring Cloud and is Spring's integrated implementation of Netflix OSS. Based on the large-scale use of Netflix, the components that have been widely used include:

In addition, another sub-project Spring Cloud Alibaba is Alibaba's open source Spring Boot-based microservice framework, which mainly supports Alibaba Cloud services.

• Eureka: Service registration and service discovery
• Ribbon: Flexible and intelligent inter-process and service communication mechanism, client load balancing
• Hystrix: Fuse, provides delay and fault-tolerant isolation at runtime
• Zuul: Service Gateway

Service Mesh

The above-mentioned microservice frameworks are all intrusive, and the process of servicing requires code transformation. Service Mesh is the next generation of microservice architecture, the most obvious feature is non-intrusive. The sidecar model is used to solve the communication and governance problems between services after the system architecture is micro-serviced. As shown below:

The current mainstream open source implementations include:

Limited to the cost of performance delay caused by Service Mesh and the increase in distribution complexity of sidecars, it will bring about large-scale deployment (large number of microservices), heterogeneous and complex (multiple types of interaction protocols/development languages) microservice architecture The benefits will be greater.

Linkerd and Envoy: take sidecar as the core, focus on how to do a good proxy, and complete some general control plane functions. Lack of management and control of these sidecars.

Istio and Conduit: Currently the most popular Service Mesh implementations focus on more powerful control plane (sidecar is called data plane) functions. The former is a collaboration between Google and IBM, and uses Envoy as the implementation of the sidecar part; the latter is the work of the author of Linkerd. In comparison, Istio has a giant background and is powerful, but its usability and ease of use have not been high, while Conduit is relatively simple and features focused.

Sofastack

Ant Financial opens a set of middleware to build a financial-level distributed architecture. Including a set of distributed application development tools such as microservice development framework, RPC framework, service registry, full link tracking, service monitoring, and Service Mesh.

Especially worth mentioning is SOFAMesh. In fact, the practice of large-scale implementation of the next-generation microservice architecture Service Mesh, based on the improvement and expansion of Istio, should be the most mature open source Service Mesh solution in China.

In addition, we need to mention Kubernetes (K8s), which itself provides part of the microservice feature support (service discovery through the domain name), which is non-intrusive to the code. However, service calls and circuit breakers need to be implemented by themselves.

In summary, the current technology stack of the company's technical team is Spring, and the implementation of existing services is based on Dubbo. Therefore, Spring Cloud Netflix is selected as the basic microservice framework. For the immature or lacking components, the industry is more mature. The components can be replaced.

• API Gateway: Zuul
• Service Registry: Dubbo
• Configuration Center: disconf
• Service monitoring && full link tracking: CAT
• Service development framework: Spring Boot
• Log monitoring and warning: ELK + Elasalert
• Flow control: Sentinel
• Message queue: Kafka

Source: https://www.talkwithtrend.com/Article/245471