Abandon Dubbo and choose the most popular Spring Cloud microservice architecture practice and experience summary

Spring For All Community Author: Pure, original address Portal

Last time I wrote an article called Can Spring Cloud be used in small and medium-sized companies in China? It introduced whether Spring Cloud can be used in small and medium-sized companies. This article is its companion article. In fact, we have been on this road for more than a year, from the beginning of 2016 to the present. Before using Spring Cloud, we did not have much experience and experience with microservice practices. From the initial open source software cloud collection to familiarize yourself with Spring Boot, to the slow use in the project, and finally to the full embrace of Spring Cloud. This article will introduce you to our experience of using Spring Boot/Cloud for more than a year.

Before we start, let's introduce a few concepts. What is a microservice and what are its characteristics? What are Spring Boot/Cloud doing? What is the connection between the three of them?

technical background

What are microservices

The concept of microservices originated from an article " Microservices " written by Martin Fowler in March 2014 .

Microservice architecture is an architectural pattern that advocates dividing a single application into a set of small services that coordinate and cooperate with each other to provide ultimate value to users. Each service runs in its own process, and services communicate with each other using a lightweight communication mechanism (usually HTTP-based RESTful API). Each service is built around a specific business and can be independently deployed to production environments, production-like environments, etc. In addition, a unified and centralized service management mechanism should be avoided as much as possible. For a specific service, appropriate languages and tools should be selected to build it according to the business context.

Microservices is an architectural style in which a large, complex software application consists of one or more microservices. Each microservice in the system can be deployed independently, and each microservice is loosely coupled. Each microservice only focuses on doing one task and doing it well. In all cases, each task represents a small business capability.

Advantages of Microservice Architecture

Controllable complexity : While decomposing the application, it avoids the endless accumulation of original complexity. Each microservice focuses on a single function and clearly expresses service boundaries through well-defined interfaces. Due to its small size and low complexity, each microservice can be fully controlled by a small-scale development team, which is easy to maintain high maintainability and development efficiency.

Independent deployment : Since microservices have independent running processes, each microservice can also be deployed independently. There is no need to compile and deploy the entire application when a microservice changes. An application composed of microservices is equivalent to having a series of parallel release processes, which makes the release more efficient, reduces the risk to the production environment, and ultimately shortens the application delivery cycle.

Flexible technology selection : Under the microservice architecture, technology selection is decentralized. Each team can freely choose the most suitable technology stack according to the needs of its own services and the status quo of industry development. Since each microservice is relatively simple, the risk of needing to upgrade the technology stack is low, and even a complete refactoring of a microservice is feasible.

Fault tolerance : When a component fails, under the traditional architecture of a single process, the failure is likely to spread within the process, resulting in global application unavailability. In a microservices architecture, failures are isolated within a single service. If the design is good, other services can achieve fault tolerance at the application level through mechanisms such as retry and smooth degradation.

Expansion : Monolithic architecture applications can also achieve horizontal expansion, which is to completely replicate the entire application to different nodes. When different components of the application have different scaling requirements, the microservices architecture demonstrates its flexibility, because each service can be scaled independently according to actual needs.

What is Spring Boot

Spring Boot is a new framework provided by the Pivotal team, designed to simplify the initial setup and development of new Spring applications. The framework uses a specific way to configure, so that developers no longer need to define boilerplate configuration. In my words, Spring Boot is not actually a new framework. It configures many ways to use frameworks by default, just like maven integrates all jar packages, and Spring Boot integrates all frameworks (I don’t know if this analogy is appropriate. ).

Spring Boot simplifies the development of Spring-based applications by creating a standalone, production-level Spring application with a small amount of code. Spring Boot provides out-of-the-box setups for the Spring platform and third-party libraries, so you can get started in an organized manner. The core idea of Spring Boot is that convention is greater than configuration, and most Spring Boot applications only require very little Spring configuration. Using Spring Boot can greatly simplify your development mode. All the common frameworks you want to integrate have corresponding component support.

What does Spring Cloud do?

Spring Cloud is an ordered collection of a series of frameworks. It uses the development convenience of Spring Boot to subtly simplify the development of distributed system infrastructure, such as service discovery registration, configuration center, message bus, load balancing, circuit breaker, data monitoring, etc., all of which can be done in the development style of Spring Boot. to one-click launch and deployment. Spring does not repeat the manufacture of wheels, it just combines the more mature and practical service frameworks developed by various companies, and re-encapsulates the complex configuration and implementation principles through Spring Boot style. The author has left a set of distributed system development toolkits that are easy to understand, easy to deploy, and easy to maintain.

The following are the core features of Spring Cloud:

Distributed/versioned configuration
Service registration and discovery
routing
service-to-service calls
load balancing
breaker
Distributed Messaging

Let's look at another picture:

Through this picture, let's take a look at the configuration and operation process of each component:

1. Request unified access to internal services through API gateway (Zuul).
2. After the gateway receives the request, it obtains the available services from the registration center (Eureka)
3. After the load is balanced by Ribbon, it is distributed to the back-end specific instances
4. Communication between microservices through Feign
5. Hystrix is responsible for handling service timeout fuse
6. Turbine monitors the invocation and fuse related indicators between services

Introduction to Spring Cloud System

The above picture is only part of the Spring Cloud system. Spring Cloud integrates a total of 19 sub-projects, all of which contain one or more third-party components or frameworks!

Spring Cloud Tool Framework

1. The Spring Cloud Config configuration center uses git to centrally manage the configuration of the program.
2. Spring Cloud Netflix integrates many Netflix open source software
3. Spring Cloud Bus message bus, which uses distributed messages to connect services and service instances to propagate state changes in a cluster
4. Spring Cloud for Cloud Foundry uses Integrating your application with Pivotal Cloudfoundry
5. Spring Cloud Cloud Foundry Service Broker provides a starting point for building service brokers that manage cloud-hosted services.
6. Spring Cloud Cluster is based on the abstraction and implementation of leader election and civilian status mode implemented by Zookeeper, Redis, Hazelcast, and Consul.
7. Spring Cloud Consul implements service discovery and configuration management based on Hashicorp Consul.
8. Spring Cloud Security provides load balancing for OAuth2 rest client and authentication header forwarding in Zuul proxy
9. Spring Cloud Sleuth SpringCloud application distributed tracing system, compatible with Zipkin, HTrace, ELK.
10. Spring Cloud Data Flow A cloud-native program and operation model that composes data microservices on a structured platform.
11. Spring Cloud Stream is a message microservice based on Redis, Rabbit, and Kafka, and a simple declaration model is used to send and receive messages in Spring Cloud applications.
12. Spring Cloud Stream App Starters provides spring integration for external systems based on Spring Boot.
13. Spring Cloud Task microservices with short life cycle, adding functional and non-functional features to SpringBooot application simple declaration.
14. Spring Cloud Task App Starters
15. Spring Cloud Zookeeper Service discovery and configuration management are based on Apache Zookeeper.
16. Spring Cloud for Amazon Web Services quickly integrates with Amazon Web Services.
17. Spring Cloud Connectors facilitate PaaS applications on various platforms to connect to backend services like databases and message brokers.
18. Spring Cloud Starters (the project has been terminated and the version after Angel.SR2 has been merged with other projects)
19. Spring Cloud CLI plugin uses Groovy to quickly create Spring Cloud component applications.

Of course this number keeps increasing...

relationship between the three

Microservice is a concept of architecture, which proposes the design principles of microservices, and provides guiding ideology for the implementation of specific technologies from theory. Spring Boot is a set of rapid configuration scaffolding that can quickly develop a single microservice based on Spring Boot; Spring Cloud is a service management toolkit based on Spring Boot; Spring Boot focuses on a single microservice individual that is fast and easy to integrate, and Spring Cloud focuses on A global service governance framework.

Spring Boot/Cloud is the best solution for microservice practice.

combat experience

Encounter a problem, find a solution

At the beginning of 2015, due to the massive development of the company's business, we began to split the original business, and the new business lines were all developed using independent projects, and the projects and projects were accessed through the http interface. In the past 15 years, the business has developed very rapidly, and the number of projects has expanded accordingly. At the end of 2015, there were more than 60 projects. When the number of projects reached more than 30, we actually encountered problems. Often a certain project was expanded due to expansion. With the addition of a new IP address, we need to passively update several related items. There are more and more services, and the calling relationship between services is becoming more and more complex. Sometimes I want to draw a picture to represent the dependencies between projects, but the lines are too dense to see clearly. There is a picture online that expresses our mood.

At this time, we wanted to find a solution that could manage so many of our distributed services, and conducted technical research on the Internet. We found that there are two open source software that are more suitable for us, one is Dubbo and the other is Spring Cloud.

In fact, at the beginning we took some detours. We were not familiar with these two frameworks at the time. At that time, there were very few domestic companies using Spring Cloud for development, and I hardly found too many application cases on the Internet. However, the use of Dubbo in China was quite common at that time, and the relevant information was relatively complete in all aspects. Therefore, when the company expanded the crowdfunding platform for the new business line, the technology selection was based on Dubbo, because it is also a brand-new business without any burden. We developed this project for about six months and put it into production, and we also encountered some problems at the beginning of the launch. , but in the end it was relatively smooth.

While Dubbo was used in the selection of new business lines, we did not completely abandon Spring Cloud. We selected one or two developers to learn Spring Boot and I also participated in it. Time used Spring Boot to develop an open source software cloud collection . After the actual combat verification of this project, we have confidence in Spring Boot. The most important thing is that after you realize the various conveniences of using Spring Boot, you no longer want to use traditional methods for development.

But there is still another problem. While choosing Spring Boot for new business development, it did not solve the above problem. Direct invocation of services is still relatively complex and traditional. At this time, we began to study Spring Cloud. Because everyone has enough understanding of Spring Boot in the early stage, learning Sprig Cloud seems to be smooth sailing. So after using Dubbo for half a year, we have fully embraced Spring Cloud.

Why choose Spring Cloud over Dubbo

You may ask, why did you choose to use Spring Cloud in an all-round way after choosing to use Dubbo? There are several reasons for this:

1) Talking from the background of two companies: Dubbo is the core framework of Alibaba's service-oriented governance and is widely used in various Internet companies in China; Spring Cloud is a product of the famous Spring family. Alibaba is a commercial company. Although it has open sourced many top projects, from an overall strategic point of view, it still mainly serves its own business. Spring focuses on the research and development of enterprise-level open source frameworks, which are widely used in China and the world. It is their main business to develop a general, open source, and robust open source framework.

2) From the perspective of community activity, although Dubbo is also a very good service governance framework, and it is better than Spring Cloud in terms of service governance, grayscale publishing, and traffic distribution, except that Dangdang.com is based on Apart from the addition of rest support, there have been hardly any updates for over two years. There are problems during use, and there are few replies to the Issues submitted to github.

On the contrary, Spring Cloud has been developing at a high speed since its development. It can be seen from the frequency of submitting code on github and the time interval of release versions. Now Spring Cloud is about to release version 2.0, which will be more complete and stable in the later stage.

From the perspective of the entire large platform architecture, the dubbo framework only focuses on the governance between services. If we need to use the configuration center and distributed tracking, we need to integrate them ourselves, which will increase the difficulty of using dubbo invisibly. Spring Cloud has considered almost all aspects of service governance, and has the support of Spring Boot, which is very convenient and simple to develop.

4) From the perspective of technological development, the technical concept of Dubbo just came out was still very advanced, it solved the problem of service governance of major Internet companies, and small and medium-sized companies in China also benefited a lot from it. After so many years of development, more advanced technologies and concepts have emerged in the Internet industry. Dubbo has been stagnant, and it is naturally a little behind. Sometimes I personally feel a little pity, if Dubbo has been developing along the original line , and extended to the surrounding area, it may be another scene today.

Spring launched Spring Boot/Cloud for many reasons of its own. The lightweight framework originally advocated by Spring has become larger and larger with continuous development. With more and more integrated projects, the configuration files are becoming more and more confusing, and gradually deviates from the original concept. With so many years of development and the emergence of more new technical concepts such as microservices and distributed link tracking, Spring urgently needs a framework to improve the previous development model, so the Spring Boot/Cloud project will appear. We now visit On Spring's official website, you will find that Spring Boot and Spring Cloud have been placed in the first two of the three most important projects on the home page, which shows the importance Spring attaches to these two frameworks.

To sum up, dubbo used to be really awesome, but Spring Cloud is developed on the basis of technological development in recent years, so it is more technically representative.

How to evolve a microservice architecture

When we use the Spring Cloud architecture for all new businesses, there will be such a phenomenon. The company's system is divided into two parts, one is the traditional architecture project, and the other is the microservice architecture project. How to make this The combination of the two sets becomes the key. At this time, a key component in Spring Cloud solves our problem, which is Zuul. All microservices in the Spring Cloud architecture system provide a unified access entry through Zuul, and all requests that need to communicate with the internal services of the microservice architecture go through the unified gateway. As shown below:

As can be seen from the above figure, we have classified services into four types: basic services, business services, combined services, and pre-services. Different services have different priorities for migration

Basic services are some basic components that have nothing to do with specific businesses. For example: SMS service, mail service. The services here are the easiest to take out as microservices, and they are also the services that are separated from our first priority.
Business services are some vertical business systems that only deal with a single business type, such as: risk control system, point system, and contract system. This type of service has relatively simple responsibilities, and whether to migrate or not is selected according to the business situation. For example, if there is a sudden need to greatly optimize the points system, we will take the opportunity to transform the points system, which is our second priority service.
Front-end services , front-end services are generally access or output services of services, such as front-end services of websites, service interfaces of apps, etc. This is a service separated by our third priority.
Combination services , which involve specific businesses, such as the bidding process, need to call a lot of vertical business services. We generally put this type of service at the end and then carry out the transformation of the microservice architecture, because this type of service is the most complex. Unless it involves a big business logic change, we don't migrate easily.

In addition to these four types of services, all newly launched businesses use the technology stack of Sprng Boot/Cloud. In this way, we started from the open source project cloud collection , launched several Spring Boot projects, and now most of the company's projects are in the Spring Cloud architecture system.

experiences and lessons

Steps in Architecture Evolution

Before deciding to use the Spring Boot/Cloud technology stack for microservice transformation, first sort out the services of the platform and classify different services to confirm the rhythm of evolution.
Let the team be familiar with Spring Boot technology first, and give priority to technical transformation on basic services, and push the modified project to be put into production and online.
After the team is familiar with Spring Boot, it will advance to use Spring Cloud to transform the original project.
In the process of microservice transformation, it is firstly applied to new business systems. In the early stage, only a small number of projects can be transformed into microservices. As everyone's familiarity with the technology increases, the scope of microservice transformation can be accelerated.
The coexistence of traditional projects and microservice projects is a very common situation. Unless there are major changes in the company's business, it is not recommended to directly migrate core projects.

Service Splitting Principle

The service split has the following principles to share with you

Horizontal split . Split according to different business domains, such as orders, marketing, risk control, and point resources. Form independent business domain microservice clusters.

Split vertically . Split different modules or components in a business function. For example, splitting public components into independent atomic services and sinking them to the bottom layer to form a relatively independent atomic service layer. In this way, the service division of the business can be realized.

To do a good job in the layering of microservices: sort out and extract core applications and public applications, and sink them into the core and public capability layers as independent services, and gradually form a stable service center, so that front-end applications can respond more quickly to the changing market. need

Is the service split the smaller the better? Microservices are big and small. For example, in the early days, we split the transaction into a microservice, but with the increase of business volume, a transaction system may have gradually become large, and the concurrent traffic is not small. In order to support more transaction volume, I will split the trading system into order services, bidding services, transfer services, etc. Therefore, the splitting of microservices needs to be combined with specific businesses. The general principle is high cohesion within services and low coupling between services.

Microservices vs Traditional Development

I have been using microservices for a while, and this development model is very different from the traditional development model.

The division of labor is different. In the past, we may be a module, and now it may be a system for one person.
With different architectures, the splitting of services is a highly technical issue, and whether the splitting is reasonable will have a huge impact on future development.
The deployment method is different. If the deployment is still exhausted as before, automated operation and maintenance are indispensable.
Disaster tolerance is different. A good microservice can isolate faults to prevent the service from going down as a whole. A bad microservice design can still cause a chain reaction due to a problem with a subservice.

Challenges to the database

Each microservice has its own independent database, so how to deal with the joint query managed by the background? This should be a common problem that everyone will encounter, and there are three solutions.

1) Strictly follow the division of microservices. Microservices are independent of each other, and each microservice database is also independent. When data needs to be displayed in the background, the interface of each microservice is called to obtain the corresponding data, and then the data is processed and displayed. It is the standard usage and the most troublesome usage.

Put highly business-related tables into a library, and split tables with not very close business relationships strictly according to the micro-service model, so that micro-services can be used, and the background system statistics function that is difficult to achieve due to database dispersion is avoided. A compromise solution.

3) The database is divided in strict accordance with the requirements of microservices to meet the high concurrency of the business. The data of each microservice database is synchronized to the NoSQL database in real time or in quasi-real time, and data cleaning is performed during the synchronization process to meet the background business system. It is recommended to use MongoDB, HBase, etc.

I have used three solutions in different companies. The first solution is suitable for small companies with relatively simple businesses; the second solution is suitable for companies that gradually evolve into a microservice architecture based on the original system; the third solution is suitable for Large high-concurrency Internet company.

Microservices experience and advice

1. It is recommended not to use Jsp as much as possible, and Thymeleaf is recommended for page development. It is recommended to deploy Tomcat independently for Web projects, and do not use the embedded Tomcat. When deploying Jsp projects with embedded Tomcat, there will be occasional turtle-speed access.

2. Service orchestration is a good thing, and its main function is to reduce interdependence in projects. For example, now project a calls project b, project b calls project c... until h, it is a call chain, then when the project goes online, it needs to update the bottom h and then update g... update c update b and finally Update item a. This is just one call chain. There are many calls in a complex business. If you have to remember each call chain, it will be a disaster for developers and operators.

There is such a good way to minimize the interdependence of projects, that is, service orchestration, a core business processing project, responsible for dealing with various microservices. For example, a called b before, b used c, and c called d. Now they are unified in a core project W. When the W service uses a, it calls b, and when it uses b, W calls c. For example: In the third-party payment business, a core payment item is service orchestration, which is responsible for processing the business logic of payment. When the W item uses merchant information, it calls the "merchant system", and when the device needs to be verified, it calls the "terminal system". ", when the risk control is required, the "wind control system" is called, and the dependent parameters required by each project are controlled by W. When the project is deployed in the future, you only need to start the service orchestration project at the end.

3. Don’t pursue technology for the sake of technology. Before determining the transformation of the microservice architecture, you need to consider the following factors:
1) Whether the technical personnel of the team already have the relevant technical foundation.
2) Whether the company's business is suitable for microservice transformation. Not all platforms are suitable for microservice transformation. For example, there are many complex vertical business systems in traditional industries.
3) There are many technologies in the Spring Cloud ecosystem, not every technical solution needs to be used, and the one that suits you is the best.

Summarize

Spring Cloud is a boon for small and medium-sized Internet companies , because such companies often do not have the strength or sufficient capital to develop their own distributed system infrastructure. Using Spring Cloud's one-stop solution can easily deal with business While developing, the development cost is greatly reduced. At the same time, with the popularity of microservice architecture and Docker container concept in recent years, Spring Cloud will also have a place in the increasingly "cloud" software development style in the future, especially in the current variety of distributed solutions. It provides a standardized, full-stop technical solution, which may be comparable to the birth of the current Servlet specification, effectively promoting the technical level of the server-side software system.