In this tutorial, you'll build an application and learn how to set up communication between its microservices using Consul, Ribbon, and Feign.
Build a Volunteer microservice using Spring Boot.
Build a Patient microservice using Spring Boot.
Set up Consul agent for service registry and discovery.
Integrate microservices to register with Consul.
Patient microservice calls a service in Volunteer microservice using a traditional Spring RestTemplate.
Patient microservice calls a service in the Volunteer microservice using Feign as a REST client.
Before we proceed to building the solution, let’s quickly go over all these components.
A microservice is a single autonomous component which is loosely coupled with other microservices working together to provide a business solution.
Consul is a peer to peer, strongly consistent data store that uses a gossip protocol to manage membership and form dynamic clusters and a raft protocol to provide consistency. It supports a variety of network protocols such as HTTP, TTL, and TCP. It supports health checking, such as whether the web server is unavailable (not returning a 200 HTTP code), memory utilization (let’s say > 90%, etc). Consul also supports multi-datacenter out of the box.
There are a few other products in the market to choose from for service discovery, such as Eureka or Zookeeper. Eureka is a Netflix product which has a less consistent communication protocol, but is easy to integrate with other Netflix products, such as Ribbon and Hysterix. Zookeeper is a clustered system that is mostly geared towards big data architecture such as Hadoop and Kafka. The comparison among these products is out of the scope of this article. You may find more detail here.
Ribbon is a client-side load balancer which rotates requests between a list of servers based on logic such as round robin or weigh based.
What Is a Feign Client?
Feign provides an abstraction over REST-based calls via annotation, by which microservices can use to communicate with each other without writing detailed REST client code.
Now, let's start on our simple project to learn these components.
Note - /vs is the application context assigned in the application.yml file of the microservice.
Step 2 - Unzip the downloaded file. It will be unzipped to Consul.exe. You may add this path to your PATH variable for easy access.
Step 3 - Verify the installation. Run Consul version from a command line and verify the version.
Optionally, you can run consul catalog services to see the list of services running under Consul.
Note that the default port it uses is 8500. Default configurations can be overridden either by passing command line arguments, adding a configuration file or setting up environment variables.
Note that Actuator dependency is added to the application here. Actuator automatically configures and enables monitoring endpoints for an application. Application health is exposed /health URI. In the next step, we will add this endpoint to register with Consul.
The value provided in healthCheckPath gets registered with Consul. Here, the application registers /ps/health with Consul. Note that /ps is the application context for the patient application. You may use any other application endpoint for monitoring with the consideration that the heartbeat check by Consul to monitor the endpoint does not impact the business processing. We have a few more Consul monitoring properties disabled, as we are not interested in those at this point.
Add the same properties to the application.yml file of the Volunteer application, then update healthCheckPath to /vs/health.
Step 4 - Restart both the Volunteer application and Patient application.
Note that the services are registered to Consul by the property value defined in spring.application.name.
Step 1 - Add logical URL of the volunteer service in the Patient application.
Note that we are not providing the ctaul host r port information here to reach out to VolunteerService. Service discovery will do it for us during runtime.
Note that @LoadBalanced allows us to get the reference to service URL used in the RESTTemplate.
We learned that the web client discovers the web application from Consul via logical name and calls a service. However, it still has to know how to construct the service URL, pass parameters, and unmarshall return values.
The Feign client removes the need to write boilerplate code for the REST client. The REST client can just keep the same signature as the REST service and the internals will be handled by the Feign client.
The volunteer service source code is available here.
The patient service source code is available here.