Integration of Spring Cloud Microservices and Service Mesh


This document focuses on solving a problem: What is the correct posture of Spring Cloud integrated with Kato’s native Service Mesh?

Kato natively supports Service Mesh microservice architecture. In other words, no matter what it is, as long as it is deployed on Kato, it will naturally become a Service Mesh microservice. This is also a major feature of the Service Mesh microservice architecture: no intrusion into the original application.

After Spring Cloud is deployed on Kato, the entire business is a complete Spring Cloud microservice and a set of Service Mesh microservices. So how to make the business system retain the characteristics of the original Spring Cloud microservice architecture and enjoy the various benefits brought by Service Mesh? This involves the integration of Spring Cloud microservices and Service Mesh.

The core idea of ​​fusion is that the functions maintained by the Spring Cloud framework remain unchanged; the functions that the Spring Cloud framework cannot maintain are handed over to Service Mesh and Kato.

What Spring Cloud does not Maintain

We will not discuss in depth what the Spring Cloud microservice framework maintains. There are many such posts on the Internet.

Here, we want to explain that when readers choose to deploy their original Spring Cloud microservices in Kato, what work should be done by Kato.

Registration to Eureka

The eureka registry is a standard registry solution in the Spring Cloud microservice framework. The Service provider in the microservice framework registers its service address in eureka for remote call by Service consumer. This mechanism of service registration and discovery is designed in the microservice architecture to disassemble the original one-stop service into several independent services and decouple them from each other, but they can interact with each other. Based on this mechanism, all Spring Cloud microservice components can dynamically learn the service address of the Service Provider they need; they can also register themselves as a Service Provider to provide services to other components.

However, such a flexible service registration/discovery mechanism does not maintain the registration of other service components with eureka itself. The address registered with eureka is often configured in the configuration file, such as the eureka registration method set in the code cloud 6K+ star Spring Cloud project PIG background management framework as follows:

# Registration center configuration
    prefer-ip-address: true
      defaultZone: http://pig:pig@pig-eureka:8761/eureka/

In Kato, the domain name pig-eureka needs to be resolved to, and this operation can be completed with the help of the export network management plug-in that comes with Kato:

In Kato, you can use dependencies to connect microservice components with eureka to help Spring Cloud complete the registration:

  • Eureka opens the port internal service and completes the service registration of its Service Mesh layer with the Kato platform

  • Other microservice components connect to eureka through dependencies, and you can complete service registration and service subscription to eureka without making any changes

Export network management plugin By default, the domain name specified in Domains of downstream applications will be resolved to

Docking Various Middleware

In a complete Spring Cloud microservice system, a variety of data middleware will inevitably be used. Take PIG as an example, with MySQL as the data storage and REDIS as the cache. In Spring Cloud, the docking method of this type of middleware is also configured through configuration files. There is no other registration mechanism in the microservice framework. In the same way, Kato’s dependencies can be used to connect microservices with service middleware.

We recommend using environment variables to define the connection information of pig-db redis. In Configuration File, the following statement needs to be made:

#Mysql Related
  name: ${MYSQL_USER}
  passwd: ${MYSQL_PASSWORD}
  host: ${MYSQL_HOST}
  port: ${MYSQL_PORT}
  database: ${MYSQL_DATABASE}

# Spring Related
    password: ${REDIS_PASS}
    host: ${REDIS_HOST}
    port: ${REDIS_PORT}

Service Component Startup Sequence

The startup sequence of Spring Cloud microservice components is more important. A component starts automatically before the dependent service is started, which may cause errors. The Spring Cloud microservice framework itself does not maintain the startup sequence of service components. This problem can be solved by Kato.

Kato supports startup sequence control based on dependencies. The startup sequence logic is that the dependent services are started first, and the startup process will only start after the services that the current service depends on are all started normally.

Spring Cloud Adapts to Kato

In order to better integrate Spring Cloud into the Kato system, it is recommended to use the following configuration for adaptation:

Register IP

On the premise of retaining the service registration discovery mechanism native to Spring Cloud like eureka, we need all the microservice components to register their real IP as the service address. Kato will solve the networking strategy between microservice components by itself. The key configuration categories are as follows:

# Registration center configuration
    prefer-ip-address: true

Heartbeat Detection and Fast Offline

Kato supports the full life cycle management of each microservice component. After we configure a component and click update, we hope that in eureka, after the new instance goes online, the old instance that has been shut down and destroyed can quickly go offline to ensure that the service registration address in the registry has no unavailable items. The key configuration is as follows:

# eureka server configuration
    enable-self-preservation: false #Turn off self-preservation
    eviction-interval-timer-in-ms: 4000 #Clean-up interval (in milliseconds, the default is 60*1000)
# eureka client configuration
    lease-expiration-duration-in-seconds: 30 #Service expiration time configuration, EurekaServer will remove this instance if no heartbeat is received after this time
    lease-renewal-interval-in-seconds: 10 #Service refresh time configuration, will take the initiative to heartbeat once every this time

The above configuration is suitable for testing scenarios and debugging scenarios. If the service has stabilized and you decide to apply it in a production environment, it is recommended to set up an appropriate configuration scheme by yourself.