Before opening, I would like to state my attitude towards micro services:
There are many architectural patterns. Microservices are not the only choice, nor is it a silver bullet. The vast majority of small and medium-sized companies in China are blindly pursuing innovation when introducing microservices. We can also see the lack of infrastructure quality of engineers doing this technology selection.
“You must be tall enough to use microservices.”. Microservice infrastructure, especially container technology, automated deployment and automated testing, is incomplete. Microservices exist in vain and will not bring any qualitative improvement.
The key of microservice architecture is not the specific implementation, but how to reasonably divide the service boundary and whether the organizational structure matches. It is a bad technology selection to blindly provide micro services without considering the size and composition of the R & D team.
Spring boot is the upper package of spring family bucket. It is not a new technology, nor is it a technology worthy of being your own killer.
The components of spring cloud Netflix in spring cloud have been verified by the production environment, and others are recommended to be selected carefully.
1、 What is 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 pipeline design concept of UNIX. In 2014, Martin Fowler and James Lewis jointly put forward the concept of microservice and defined the microservice architecture style. It is a method to develop a single application through a set of small services. Each service runs in its own process and communicates through a lightweight mechanism (HTTP API). The three key points are small, automated and lightweight.
Compared with SOA, microservices can be regarded as a subset of SOA, lightweight SOA, finer granularity services, independent processes and data separation, and pay more attention to agility, continuous delivery, Devops and decentralized practice. Its common architecture principle:
- Single responsibility
- Separation of attention: separation of control and logic
- Modularity and divide and rule
- Componentization with services
- Organize around business capabilities
- It’s a product, not a project
- Endpoint intelligence and dumb pipeline: the control logic is at the endpoint, and the pipeline is only transmission
- Fully automated deployment
- Decentralized control of language and data
- Failure oriented design
- Progressive design
The advantages and disadvantages are as follows
- Strong boundary of modules
- Independent deployment
- Diversity of technology selection
- Distributed brings programming complexity and consumption of remote call
- Abandon strong consistency to achieve final consistency
- Operation complexity requires a mature operation and maintenance team or operation and maintenance infrastructure
2、 Why microservices
The choice of microservices depends on the complexity of the system you want to design. Microservices are used to control complex systems, but the complexity of microservices is introduced. It is necessary to solve the problems faced by other distributed systems, including automatic deployment, monitoring, fault-tolerant processing, final consistency and so on. Even if there are some commonly used solutions, they still have a large cost.
The relationship between productivity and complexity is shown in the figure. It can be seen that the more complex the system is, the greater the benefits brought by microservices. In addition, whether it is a single application or a micro service, the skills of the team need to be able to control it.
Martin Fowler’s view is that microservices should not be considered unless the cost of managing individual applications is too complex (too large to modify and deploy). Most applications should choose a single architecture and do a good job in the modularization of single applications rather than splitting them into services.
Therefore, at the beginning, the system adopts single architecture and modularization. Then, as the system becomes more and more complex and the boundary between modules / services becomes clearer, it is a reasonable architecture evolution path to reconstruct it into micro service architecture.
There are four situations where microservices can be considered:
- When multiple people develop a module / project, a large number of conflicts occur frequently when submitting code.
- The modules are seriously coupled and interdependent. Each change needs to involve multiple teams. There are too many online requirements and high risks.
- The main business and secondary business are coupled, and the horizontal expansion process is complex.
- Fuse degradation depends on if else.
Three stages of microservices
- Microservice 1.0: it only uses registration discovery and is developed based on spring cloud or Dubbo.
- Microservice 2.0: it uses service governance strategies such as fusing, current limiting and degradation, and is equipped with complete service tools and platforms.
- Microservice 3.0: service mesh takes service governance as a general component and sinks to the platform layer for implementation. The application layer only focuses on business logic. The platform layer can automatically schedule and adjust parameters according to business monitoring to realize aiops and intelligent scheduling.
3、 Microservice architecture
- Fast environment provision capability: it relies on cloud computing and container technology to quickly deliver the environment.
- Basic monitoring capabilities: including basic technical monitoring and business monitoring.
- Rapid application deployment capability: the deployment pipeline is required to provide rapid deployment capability.
- Devops culture: it needs to have good continuous delivery capability, including full link tracking, rapid environment provision and deployment, rapid response capability (rapid response to problems and faults), and collaborative work of development, operation and maintenance.
In addition, according to Conway’s law and inverse Conway’s Law (the technical structure forces the improvement of the organizational structure), the organizational structure is also a key factor. Corresponding to the microservice architecture, the organizational structure needs to follow the following principles:
- A microservice is maintained by a team with three members.
- The task 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-management.
The implementation of microservices depends on many underlying infrastructures, including the compilation, integration, packaging, deployment and configuration of microservices. PAAS platform is used to solve the whole life cycle management of microservices from development to operation. At the same time, heterogeneous environment management, container resource isolation and interworking, service scaling drift, service upgrade and fallback, service fusing and degradation Service registration and discovery.
The most basic infrastructure
- Interprocess communication mechanism: microservices are independent processes, and the communication mode between them needs to be determined.
- Service discovery + Service Routing: provide service registry, service providers and consumers obtain service information through service discovery, so as to call services and realize service load balancing.
- Service fault tolerance: in the microservice architecture, because there are many services, one service is often suspended, and the services of the whole request link are affected. Therefore, service fault tolerance is required to handle errors or rapid failures when service calls fail, including fusing, fallback, Retry, flow control and service isolation.
- Distributed transaction support: as businesses are split into services, sometimes cross service transactions, that is, distributed transactions, are unavoidable. The principle is to avoid distributed transactions as much as possible. If it cannot be avoided, the message system or cqrs and event sourcing schemes can be used to achieve final 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 connection and internal development
- API gateway: responsible for access to external systems and public level work across cross sections, 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 world, and reverse route xx.com/user and xx.com/trade according to the first level directory. Each level of directory, such as user and trade, corresponds to the domain name of a service. In addition, API gateway can also have the function of service orchestration (not recommended).
- Interface framework: standardize the data format, parsing package and self explanatory document used for communication between services, so as to facilitate service users to get started quickly.
Improve test and operation and maintenance efficiency
- Continuous integration: this part is not specific to microservices, but is generally necessary for previous single applications. It mainly refers to the continuous compilation, construction and automatic testing of the code process through automatic means, so as to obtain fast and effective quality feedback, so as to ensure the smooth delivery of the code. Automated testing includes code level unit testing, single system integration testing, and inter system interface testing.
- Automated Deployment: the number of microservice architecture nodes is often hundreds or thousands. Automated deployment can improve the deployment speed and frequency, so as to ensure continuous delivery. Including version management, resource management, deployment operation, rollback operation and other functions. The deployment methods of micro services include blue-green deployment, rolling deployment and Canary deployment.
- Configuration center: runtime configuration management can solve the problem of dynamically modifying configuration and batch effectiveness. It includes 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: the number of nodes under the microservice architecture is large, and the number of machines, networks, processes and interfaces to be monitored is greatly increased. A powerful monitoring system is needed to provide real-time information collection, analysis and early warning based 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. It is also called full link tracking. Common service monitoring can be combined with service monitoring. The macro information is presented by service tracking, and the micro information of a single service / node is presented by service monitoring. The current implementation theory of service tracking is basically Google’s dapper paper.
- Service Security: in principle, micro service calls between intranets can 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, data, etc. This part can exist in the service registry in the form of configuration and is bound to the service. When requesting, it is controlled by the security policy of the service node as the service provider. The configuration can be stored in the configuration center to facilitate dynamic modification.
When the number of microservices is small, the priority of the above infrastructure is reduced from top to bottom. Otherwise, only relying on manual operation, the input-output ratio will be very low.
Docker container technology should also be mentioned. Although this is not necessary for microservices, the lightweight, flexible, application dependent and environment shielding characteristics of container technology are very important for the implementation of continuous delivery. Even for traditional single applications, it can greatly improve the delivery efficiency.
4、 Architecture design pattern
After the introduction of microservices, the traditional single application becomes a service, and the previous architecture that an application directly provides an interface to the client is no longer applicable. Under the microservice architecture, the interfaces for different devices are used as the BFF layer (back for front), also known as the user experience adaptation layer, which is responsible for aggregating and arranging the data of microservices into the data required by the front end. The invocation between services uses asynchronous messaging as much as possible when allowed (delay is allowed), so as to form a micro service architecture design pattern for user experience. As shown in the figure below:
Client -> API Gateway -> BFF（Backend For Frontend） -> Downstream Microservices
- Microservice architecture is adopted in the background, and microservices can adopt different programming languages and different storage mechanisms.
- The front desk adopts BFF mode to adapt different user experiences (such as desktop browser, native app and tablet responsive WEB).
- BFF, API orchestration layer, edge service layer and device wrapper layer are the same concepts.
- BFF cannot be too many, which will cause code logic duplication and redundancy.
- The functions undertaken by the gateway, such as geoip, current limiting, security authentication and other cross-sectional functions, can be on the same layer as BFF. Although it increases the complexity of BFF layer, it can obtain performance advantages.
5、 Service splitting
The core link of microservice architecture is mainly the horizontal splitting of services. Service splitting means that a complete business system is decoupled into services. Services need a single responsibility, no coupling relationship between them, and can be developed and maintained independently.
Service splitting is not achieved overnight. We need to constantly clear the boundaries in the development process. Before the services are completely sorted out, try to delay the splitting of services, especially the splitting of databases.
The splitting method is as follows
- Split based on business logic
- Based on extensible split
- Reliability based splitting
- Performance based splitting
Among them, for legacy systems that cannot be modified, the strangler mode is adopted: new functions are added outside the legacy system to form a micro service mode, rather than directly modifying the original system to gradually replace the old system.
The specifications to be observed in the disassembly process are as follows:
- First less then more, first coarse then fine (particle size)
- The service can be vertically split into three layers at most, and called twice: controller, composite service and basic service
- Only one-way call, circular call is prohibited
- Change serial call to parallel call or asynchronization
- The interface should be idempotent
- The interface data definition shall not be embedded or transmitted through
- Normalized project name
- Split the service first, and then split the database after the service granularity is determined.
6、 Microservice framework
The above describes many infrastructures of microservice architecture. If each infrastructure needs to be developed by itself, it is a huge development work. At present, there are many open source microservice frameworks on the market.
Spring boot is used to simplify the initial construction and development process of new spring applications. Although it is not a micro service framework, its original intention is the underlying framework of micro application, so it is very suitable for the development of micro service infrastructure and micro service application development. Especially for the team of spring technology stack, it is a natural choice to develop micro service framework and application based on spring boot.
Dubbo Alibaba’s open source service governance framework. It appeared before the rise of the concept of micro services, which can be regarded as a masterpiece of SOA framework. However, it only includes some functions of micro service infrastructure, such as fuse, service tracking, gateway and so on.
Motan is an open source RPC framework similar to Dubbo, which is lighter than Dubbo.
- Service discovery: service publishing, subscription, notification
- High availability policies: failover, failfast, resource isolation load balancing: least active connections, consistent hash, random requests, polling, etc
- Extensibility: support SPI extension (service provider interface)
- Others: call statistics, access logs, etc
Spring cloud is a microservice framework based on spring boot implementation, which can also be regarded as a set of microservice implementation specifications. It basically covers all aspects of micro service infrastructure, including configuration management, service discovery, circuit breaker, intelligent routing, micro agent, control bus, global lock, decision-making, distributed session 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 by the production environment and need to be carefully selected.
Spring cloud Netflix is a sub project of spring cloud and the integrated implementation of Netflix OSS by spring. Based on the large-scale use of Netflix, the widely used components 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 to provide delay and fault-tolerant isolation during operation
- Zuul: service gateway
The above micro service frameworks are intrusive, and the service-oriented process needs code transformation. Service mesh is the next generation microservice architecture, and its most obvious feature is no intrusion. Sidecar mode is adopted to solve the problems of inter service communication and governance after microservicing of system architecture. As follows:
Current mainstream open source implementations include:
Limited to the overhead of performance delay caused by service mesh and the increase of distribution complexity caused by sidecar, it will bring greater benefits to microservice architectures with large-scale deployment (a large number of microservices) and heterogeneous complexity (many interaction protocols / development language types).
Linkerd and envoy: take sidecar as the core, focus on how to do proxy well, and complete some functions of general control plane. Lack of management and control of these sidecars.
Istio and conduct: at present, the most popular service mesh implementation scheme focuses on more powerful control plane (sidecar is called data plane). The former is cooperated by Google and IBM, and uses envoy as the implementation of sidecar; The latter is the work of linkerd author. In contrast, istio has a giant background and powerful functions, but its availability and ease of use have not been high. Conduct is relatively simple and function focused.
Ant financial is an open source middleware to build a financial level distributed architecture. It includes a complete set of distributed application development tools such as micro service development framework, RPC framework, service registry, full link tracking, service monitoring, service mesh and so on.
In particular, sofamesh is worth mentioning. In fact, the large-scale implementation scheme practice of the next generation micro service architecture service mesh is based on the improvement and expansion of istio. It should be the most mature open source service mesh scheme in China.
In addition, it should be mentioned that kubernetes (k8s) itself provides partial microservice feature support (service discovery through domain name) and has no intrusion into the code. However, service invocation and fusing need to be implemented by themselves.
To sum up, at present, the technical 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 micro service framework. For immature or missing components, select more mature components in the industry to replace them.
- API gateway: zuul
- Service registry: Dubbo
- Configuration center: disconf
- Service monitoring & & full link tracking: cat
- Service development framework: spring boot
- Log monitoring and alarm: Elk + elaalert
- Flow control: Sentinel
- Message queue: Kafka