1. Background
spring cloud is the de facto standard for microservices in the java application world, it provides very rich and complete microservice components and is very easy to integrate with java applications. However, as many features of spring cloud are integrated into applications through java jar packages in the form of SDK calls (e.g. eureka client, spring cloud config client, etc.), applications developed in other languages (e.g. go, python, php, js, etc.) do not directly use These jar packages are integrated into the spring cloud microservices system.
However, due to various practical reasons, it is not very realistic to require all components of the business system to adopt java technology stack. At the same time, an important starting point for adopting microservices technology is that different components of the system can independently choose technology stacks for independent design, development, testing and deployment upgrades, and it would be against the original intention of microservices design thinking to constrain all components of the microservices system to adopt a single java technology stack.
If you want a non-java application to integrate into the spring cloud system, one way is to develop a series of corresponding client components for each language, embed them in the application, and still integrate them through SDK calls, the same way as the current java application takes, this way is invasive; the other way is to introduce a separate The other way is to introduce a separate intermediate component through sidecar, non-java applications can reuse most of the spring cloud’s microservices base capabilities with minimal adaptation, which is (basically) non-invasive.
Here is a look at how spring cloud can integrate non-java applications via sidecar by introducing a sidecar implementation, the spring cloud netflix sidecar provided by netflix.
2. spring cloud netflix sidecar working principle
2.1 Process of java application and non-java application calling each other via sidecar
2.1.1 java application calls non-java application service process
- sidecar registers itself with the registry.
- java-app gets the information of sidecar’s instance list from the registry.
- java-app selects a specific instance from the list of instances of sidecar based on a certain load balancing algorithm and sends the request to the selected instance.
- After receiving the request, sidecar finds out that it is calling the non-java-app service it represents, and then forwards the request to the corresponding non-java-app.
- non-java-app processes the request and sends the response to sidecar.
- sidecar forwards the response to java-app.
2.1.2 Non-java application calls java application service process
- java-app registers itself with the registry.
- non-java-app sends the request to sidecar, the first value of the request url path is the service name of java-app.
- sidecar gets the instance list information of java-app from the registry.
- sidecar selects a specific instance from the java-app instance list based on a certain load balancing algorithm, and sends the request to the selected instance.
- java-app processes the request and sends the response to sidecar.
- sidecar forwards the response to non-java-app.
2.2 spring cloud netflix sidecar internal principles
The core work inside spring cloud netflix sidecar is provided by netflix open source microservice gateway component zuul, sidecar is actually a secondary development based on zuul.
-
sidecar and non-java-app must be deployed on the same node, and a sidecar uniquely corresponds to a non-java-app.
-
sidecar is equivalent to the proxy of non-java-app, the service is registered by sidecar to the registry, the service name of non-java-app seen by other microservices is registered by sidecar, the service port number is the port number of sidecar.
-
How the registry detects the health status of non-java-app.
Non-java applications that wish to integrate into the spring cloud system via sidecar need to provide a health detection interface. When the state of the non-java application is normal, this health interface returns a json string with the following content.
When sidecar feeds its health status to the registry, it will call the health detection interface provided by the corresponding non-java application, so that only when the non-java application status is normal, the status of the corresponding service instance registered by sidecar in the registry is normal.
-
How sidecar determines whether the request is from the proxied non-java-app or is sent to the non-java-app.
When sidecar receives a request, it determines whether the first segment of the path path of the http url is a service name. If it is, it will select a specific instance by certain load balancing algorithm based on the instance information registered in the registry and forward the request to the selected instance. Otherwise, sidecar assumes that it is calling the service of the non-java application it proxies, changes the host of the request to 127.0.0.1 and the port to the port of the corresponding non-java application, and then forwards the request to the corresponding non-java application.
3. spring cloud netflix sidecar application example
The following is an example of how sidecar supports multilingual microservice integration through a java application and a go application calling each other via spring cloud microservices, in this case using eureka as the registry.
3.1 Example of a golang application
The code snippet for the golang application is shown below.
|
|
The application listens to port 8093 and provides three http services.
-
/health.json
is used for sidecar to detect the health status of the application, and eureka to determine the health status of the application indirectly through sidecar.
-
/hellogo
The service interface provided by the application, which returns the string “hellogo” when it is called.
-
/remoteHellojava
This interface will indirectly call the interface of other microservices by calling the interface of sidecar. url format is as follows.
1
http://{sidecar-host}:{sidecar-port}/{目的服务的服务名}/{目的服务的path}
3.2 sidecar example
The sidecar code snippet is as follows.
As you can see, the base code of sidecar is very simple, just add a few annotations. The @EnableSidecar
annotation is used to enable sidecar functionality
The basic configuration is as follows.
|
|
As you can see from the above configuration, except for two configuration items related to sidecar: sidecar.port
and sidecar.health-uri
, the rest of the configuration is the same as a normal spring cloud application, or to be more precise, the same as configuring the microservice gateway zuul.
sidecar.port
is used to tell the service port that the sidecar go application listens on (the reason for not providing go application host is that sidecar invokes the go application service with a fixed 127.0.0.1 address), and sidecar.health-uri
is used to tell the health Health testing interface
Start the go application and sidecar separately, and you can see the service instances registered by sidecar in eureka, as follows.
|
|
3.3 Example of a java application
The code snippet of the java application is as follows.
The remote microservice is invoked via feign. @FeignClient(value = "go-app-service")
specifies the name of the microservice, which is the name of the service registered by sidecar with eureka as we know from the previous.
|
|
The configuration file reads as follows.
Start the program and you can see the service instances registered by the application in eureka, as follows.
|
|
3.4 Mutual call test
Calling the /remoteHellojava
interface of the go application returns hellojava
, which means the call was successful.
Calling the /remoteHellogo
interface of a java application returns hellogo
, indicating that the call was successful.
Reference https://www.jianshu.com/p/9754b1a9929b