Last time I wrote an article called Spring Cloud can it be used in domestic small and medium-sized companies? This article is a companion article on whether Spring Cloud can be used by small and medium-sized companies. In fact, we have been on this road for more than a year, from the beginning of 2016 to now. We didn’t have much experience with microservices practices before using Spring Cloud. From getting familiar with Spring Boot as an open source software Cloud collection, to using it slowly in projects, to finally embracing Spring Cloud fully. This article will introduce you to our experience with Spring Boot/Cloud for over a year.

Before we get started, let’s introduce a few concepts. What are microservices and what are their characteristics? What does Spring Boot/Cloud do? What is the connection between them?

Technical background

What are microservices

The concept of Microservices originated in an article “Microservices” written by Martin Fowler in March 2014.

Microservices architecture is an architectural pattern that advocates the partitioning of a single application into a set of small services that coordinate with each other to provide ultimate value to users. Each service runs in its own separate process and communicates with each other using a lightweight communication mechanism (usually RESTful apis based on HTTP). Each service is built around a specific business and can be independently deployed to a production environment, class production environment, and so on. In addition, the unified and centralized service management mechanism should be avoided as far as possible. For a specific service, appropriate language 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 is only focused on completing one task and doing it well. In all cases, each task represents a small business capability.

Advantages of microservices architecture

Controllable complexity: The application is decomposed while avoiding the endless accumulation of 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 development team, making it easy to maintain high maintainability and development efficiency.

Independent deployment: Because 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. Applications made up of microservices have a series of parallel distribution processes, making distribution more efficient, reducing the risk to the production environment, and ultimately shortening the application delivery time.

Flexible technology selection: Under the microservice architecture, technology selection is decentralized. Each team is free to choose the most appropriate technology stack based on its own service needs and industry development status. Because each microservice is relatively simple, the risk of upgrading the technology stack is low, and even a complete refactoring of a microservice is feasible.

Fault tolerance: When a component fails, in the traditional single-process architecture, the failure is likely to spread throughout the process, resulting in application-wide unavailability. In a microservice architecture, faults are isolated within a single service. If well designed, other services can achieve fault tolerance at the application level through retry, smooth degradation and other mechanisms.

Scale-out: Monolithic applications can also achieve scale-out by copying the entire application to different nodes. Microservices architectures are flexible when different components of an application have different scaling requirements, because each service can scale independently based on actual needs.

What is Spring Boot

Spring Boot is a new framework from the Pivotal team designed to simplify the initial setup and development process for new Spring applications. The framework uses a specific way to configure so that developers no longer need to define boilerplate configurations. The way I understand it is that Spring Boot is not a new framework. It has a lot of frameworks configured by default, just like Maven integrates all jars and Spring Boot integrates all frameworks.

Spring Boot simplifies spring-based application development by making it possible to create a stand-alone, production-level Spring application with a small amount of code. Spring Boot provides out-of-the-box setup for the Spring platform and third-party libraries so you can get started. The core idea of Spring Boot is that convention is greater than configuration, and most Spring Boot applications require very little Spring configuration. Spring Boot is a great way to simplify your development model. It has components for all the common frameworks you want to integrate.

What Spring Cloud does

Spring Cloud is an ordered collection of frameworks. It takes advantage of the development convenience of Spring Boot to subtly simplify the development of distributed system infrastructure, such as service discovery registry, configuration center, message bus, load balancing, circuit breakers, data monitoring, etc., which can be started and deployed with one click using Spring Boot’s development style. Spring did not repeat the wheel, it is only to the companies to the development of more mature, stand the test the actual service framework, through the Spring to encapsulate the Boot style block out the complex configuration and implementation principle, finally to developers to set aside a set of simple, easy deployment and maintenance of the distributed system development kit

The following are the core features of Spring Cloud:

  • Distributed/versioned configuration
  • Service registration and discovery
  • routing
  • Services and calls between services
  • Load balancing
  • The circuit breaker
  • Distributed messaging

Let’s look at another picture:

Through this figure, we can understand the running process of configuration and use of each component:

  • 1. Requests are unified through the API Gateway (Zuul) to access internal services.
  • 2. Upon receiving the request, the gateway retrieves the available services from the registry (Eureka)
  • 3. The Ribbon balances the load and distributes it to back-end instances
  • 4. Microservices communicate with each other through Feign
  • 5. Hystrix is responsible for handling service time-out fuses
  • 6. Monitor indexes related to call and fuse between services

Introduction to Spring Cloud system

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

Spring Cloud tool framework

1. Spring Cloud Config configuration center, using Git to centrally manage the configuration of programs. 3. Spring Cloud Bus message Bus, which uses distributed messages to connect services and service instances. Integrate your applications with the Pivotal Cloud Foundry Service The Broker provides a starting point for establishing a service Broker that manages cloud managed services. 6. Spring Cloud Cluster abstracts and implements leadership election and civilian state mode based on Zookeeper, Redis, Hazelcast, Consul implementation. 7. Spring Cloud Consul implements service discovery and configuration management based on Hashicorp Consul SpringCloud Security provides load balancing for OAuth2 REST client and authentication header forwarding in Zuul proxy. ELK compatible. Spring Cloud Data Flow is a Cloud native application and operation model that consists of Data microservices on a structured platform. 11. Spring Cloud Stream is a messaging microservice based on Redis,Rabbit and Kafka, with a simple declarational model for sending and receiving messages in Spring Cloud applications. Spring Cloud Stream App Starters provide Spring integration for external systems based on Spring Boot 13. Spring Cloud Task short life cycle micro services, Simple declarations for SpringBooot applications add functional and non-functional features. Spring Cloud Task App Starters Spring Cloud Zookeeper service discovery and configuration management based on Apache Zookeeper. Spring Cloud for Amazon Web Services fast integration with Amazon Web Services 17. Spring Cloud Connectors make it easy for PaaS applications to connect to backend databases and messaging broking services on a variety of platforms. The Spring Cloud CLI plugin uses Groovy to quickly create Spring Cloud component applications.

And of course the number is increasing all the time…

The relationship between the three

Microservice is a concept of architecture, and the design principle of microservice is put forward, which provides a guiding ideology for specific technology implementation from the theory. Spring Boot is a fast configuration scaffolding that allows you to quickly develop individual microservices based on Spring Boot. Spring Cloud is a service governance toolkit based on Spring Boot. Spring Boot focuses on a single microservice individual that is quickly and easily integrated, while Spring Cloud focuses on a global service governance framework.

Spring Boot/Cloud is the best implementation of microservices practices.

Actual combat experience

When you encounter problems, look for solutions

At the beginning of 2015, due to the massive development of the company’s business, we began to split the original business, and all the new business lines were developed by independent projects, which were accessed through HTTP interfaces. 15 years of business development is very rapid, the project number also corresponding increasing dramatically, by the end of 15 projects amounted to more than 60, when the number reached 30, when in fact, we had a problem, often a project because extension increases the new IP address, we need passive update several related projects. There are more and more services, and the invocation relationship between services is also more and more complex. Sometimes I want to draw a graph to represent the dependency relationship between projects, but the lines are too dense to see clearly. There’s a picture on the Internet that shows how we feel.

At this time, we wanted to find a solution to manage so many of our distributed services, and conducted technical research on the Internet. We found two open source software that worked well for us: Dubbo and Spring Cloud.

Actually, we took some detours in the beginning. We were not familiar with these two frameworks at that time. At that time, there were very few enterprises using Spring Cloud for development in China, and I hardly found many application cases on the Internet. However, Dubbo was widely used in China at that time, and relevant materials were relatively complete in all aspects. Therefore, when the company expanded the crowdfunding platform for a new business line, the technology selection was first chosen as Dubbo, because it was a brand new business with little burden. We developed this project for about six months and put it into production. At the beginning of its launch, we also encountered some problems, but it went smoothly in the end.

While using Dubbo for the new business line selection, we did not completely abandon Spring Cloud. We selected one or two developers to learn Spring Boot, and I also participated in it. In order to verify whether Spring Boot can reach the actual standard, In our spare time, we developed a cloud collection of open source software using Spring Boot. After the actual practice of this project, we gained confidence in Spring Boot. The most important thing is that once people see the benefits of using Spring Boot, they don’t want to develop in the traditional way anymore.

However, there was still a problem. While choosing Spring Boot for new business development, the problem above was not solved. The direct invocation of services was still complicated and traditional, so we began to study Spring Cloud. With enough knowledge of Spring Boot up front, learning Sprig Cloud is easy. So after using Dubbo for six months, we are fully embracing Spring Cloud again.

Why choose Spring Cloud over Dubbo

Why, you might ask, do you choose to use Dubbo instead of Spring Cloud? There are several reasons for this:

1) From the background of the two companies: Dubbo is the core framework of Alibaba’s servitization governance and has been widely used in Various Internet companies in China; Spring Cloud is the product of the well-known Spring family. Alibaba is a commercial company, although it has opened many top-level projects, but from the overall strategy, it still mainly serves its own business. Spring focuses on the development of enterprise-level open source frameworks, which are widely used both in China and around the world. Developing common, open source and robust open source frameworks is their main business.

2) From the perspective of community activity, although Dubbo is also an excellent service governance framework, and does better than Spring Cloud in service governance, grayscale publishing and traffic distribution, except dangdang added REST support on the basis, there has been almost no update for more than two years. There are few replies to issues submitted to Github due to problems in use.

On the contrary, Spring Cloud is still developing rapidly since its development. As can be seen from the frequency of submitting code on Github and the time interval of release, Spring Cloud is about to release version 2.0, which will be more perfect and stable in the later stage.

3) In terms of the overall platform architecture, 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 by ourselves, which will increase the difficulty of virtually using Dubbo. Spring Cloud considers almost every aspect of service governance and is supported by Spring Boot, making it very convenient and simple to develop.

4) From the perspective of technology development, the technology concept of Dubbo was very advanced when it just came out, which solved the problems of service governance of major Internet companies and benefited many small and medium-sized companies in China. After so many years of development, the Internet industry has also emerged more advanced technology and ideas, Dubbo has been stagnant, naturally some lag behind, sometimes I personally feel a little pity, if Dubbo has been along the original line of development, and extended to the surrounding, today may be a different scene.

Spring launched Spring Boot/Cloud for many reasons of its own. Spring’s original lightweight framework has grown larger over time, with more integration projects and more cluttered configuration files, slowly moving away from the original concept. Over the years, with the advent of new technology concepts such as microservices, distributed link tracking, and more, Spring desperately needed a framework to improve its development model, hence the Spring Boot/Cloud project. You’ll notice that Spring Boot and Spring Cloud have been placed in the top two of the three most highlighted projects on the home page, indicating the importance Spring attaches to these two frameworks.

To sum up, Dubbo used to be awesome, but Spring Cloud was developed on top of recent technology developments and is therefore more representative of technology.

How to evolve the microservices architecture

When all of our new businesses use the Spring Cloud architecture, there will be such a phenomenon that the company’s system is divided into two parts, one is the traditional architecture project, the other is the microservices architecture project, how to use these two sets of work together becomes the key. A key component in Spring Cloud that solved our problem at this point was Zuul. Zuul provides unified access to all microservices in the Spring Cloud architecture. All requests that need to communicate with the services in the microservices architecture go through the unified gateway. The diagram below:

From the figure above, we can see that we classify services into four categories: basic services, business services, composite services, and front-end services. Different services have different priorities for migration

  • Basic services, which are basic components, are not business specific. For example: SMS service, email service. The services here are the easiest to pick out and do microservices, which are also our first priority to separate out services.
  • Business services are vertical business systems that deal with a single type of business, such as risk control systems, points systems, and contract systems. 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 separated service.
  • Front-end services are generally access or output services, such as front-end services of websites and service interfaces of APPS, which are the services separated from our third priority.
  • Composite services, composite services is involved in specific business, such as a standard process, you need to call a lot of vertical business services, this kind of service we generally in the final again micro architecture of service innovation, because this kind of service is the most complex, unless involve big business logic changes, we are not easily to migrate.

Besides these four types of services, the newly launched services all use Sprng Boot/Cloud technology stack. In this way, we started with 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.

Lessons learned

Steps of architectural evolution

  • Before deciding to use the Spring Boot/Cloud technology stack for microservice transformation, we should first sort out the services of the platform and classify different services to confirm the rhythm of evolution.
  • First, let the team get familiar with Spring Boot technology, and give priority to technical transformation in basic services, so as to promote the production and launch of the modified project
  • When the team is familiar with Spring Boot, it pushes forward to use Spring Cloud to transform the original project.
  • In the process of micro-service transformation, priority should be given to the application of micro-service transformation in new business systems. In the early stage, micro-service transformation can only be carried out in a small number of projects. With the increase of people’s familiarity with technology, the scope of micro-service transformation can be accelerated
  • It is common for legacy projects to coexist with microservices projects, and unless there is a major change in the business, direct migration of core projects is not recommended.

Service Separation Principles

Here are some principles for service splitting

Horizontal split. Split by business domains, such as orders, marketing, risk control, points resources, etc. Form an independent business domain microservice cluster.

Split vertically. The separation of different modules or components within a business function. For example, a common component can be split into separate atomic services and then sunk down to form a relatively separate atomic service layer. In this way, one vertical and one horizontal can realize the service separation of business.

To do a good job in the stratification of micro-services: sorting out and extracting core applications and public applications, as independent services to sink to the core and public capability layer, gradually form a stable service center, so that front-end applications can respond to the changing market demand more quickly

Is service fragmentation as small as possible? Microservices are relative in size and size. For example, at the initial stage, we split the transaction into a micro service. However, with the increase of business volume, the transaction system may have gradually become large and the concurrent flow is not small. In order to support more transaction volume, I will split the transaction system into order service, bidding service and transfer service. Therefore, the separation of microservices should be combined with specific services. The general principle is high cohesion within services and low coupling between services.

Microservices vs. traditional development

Microservices have been used for some time, and this development mode is very different from the traditional development mode.

  • The division of labor is different, before we may be a module, now we may be a system.
  • Architecture is different, service split is a high technical content of the problem, whether the split is reasonable to the future development of a huge impact.
  • Deployment mode is different, if the same as before deployment is estimated to be dead, automatic operation and maintenance must be on.
  • Different from DISASTER recovery, a good microservice can isolate faults to prevent the whole service from going down, while a bad microservice design can still cause a chain reaction due to the failure of a sub-service.

Challenges to the database

Each microservice has its own independent database, so how to deal with the joint query of backstage management? This should be a common problem, and there are three ways to deal with it.

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

2) It is a compromise solution to put the tables that are highly related to business into a library and split the tables that are not closely related to business in strict accordance with the microservice mode. In this way, microservices can be used and the statistical function of background system is difficult to be realized due to the scattered database.

3) The database is segmented strictly in accordance with the requirements of micro-services to meet the high concurrency of services. Data of micro-services database is synchronized to the NoSQL database in real time or quasi-real time. Data cleaning is performed during the synchronization to meet the requirements of background service systems.

I have used all three solutions in different companies. The first solution is suitable for small companies with relatively simple business. The second option is suitable for companies that gradually evolve into microservices architecture on top of the original system. The third is suitable for large, highly concurrent Internet companies.

Experiences and suggestions for microservices

1. It is recommended to use Thymeleaf instead of Jsp. It is recommended to deploy Tomcat independently for Web projects. Do not use the embedded Tomcat, because the embedded Tomcat deployment Jsp project will occasionally have slow access.

2. Service choreography is a good thing, and its main purpose is to reduce interdependencies in projects. For example, now project A calls project B, and project B calls project C… All the way up to H, it is a call chain, so when the project goes online, it needs to update the bottom H first and then update g… Update C update B and finally update project A. This is just one call chain, and there are so many calls in a complex business that keeping in mind each call chain is a disaster for the shipping and maintenance staff.

A good way to minimize project interdependence is service choreography, a core business processing project that deals with microservices. For example, a used to call B, B used C, and C called D. Now it is uniformly handled in a core project W. When W service uses A, it calls B, and when W service uses B, it calls C. In third-party payment business, there is a core payment project service choreography, responsible for processing payment business logic, when using business information for the W project to call “merchants”, need to check equipment to call “terminal system”, when I was in need of risk control is called “risk control system,” individual projects need to depend on the parameters of W to do master. Later when the project is deployed, you just need to start the service Choreography project last.

3. Do not pursue technology for the sake of pursuing technology. The following factors need to be considered before the micro-service architecture transformation: 1) Whether the technical personnel in the team have the relevant technical foundation. 2) Whether the company’s business is suitable for micro-service transformation? Not all platforms are suitable for micro-service transformation. For example, there are many complex and vertical business systems in traditional industries. 3) There are many technologies in the Spring Cloud ecosystem, and not every technical solution needs to be used. The one that suits you is the best.

conclusion

Spring Cloud is a boon for small and medium sized Internet companies, which often do not have the resources or financial resources to develop their own distributed system infrastructure. Using Spring Cloud’s one-stop solution can significantly reduce development costs while taking their business in stride. At the same time, with the popularity of microservice architecture and Docker container concept in recent years, Spring Cloud will also have a neutral place in the future more and more “Cloud” software development style, especially in the current various distributed solutions to provide standardized, full-site technology solutions. The significance may be comparable to the birth of the current Servlet specification, effectively advancing the technological level of the server software system.

I’ll be sharing with GitChat about what Spring Cloud is doing from an architectural evolution perspective. If you are interested, you can listen to it.

Like my article, please follow my official account