Apache Camel: Service Discovery with Consul

Daniel S. Blanco
4 min readOct 6, 2021

Today we are going to see how to use a ServiceRegistration and Discovery in an Apache Camel project. But this time using Consul from HashiCorp. We have already seen this same functionality but with Eureka Netflix, here. So this new example will not differ much.

But first, let’s find out a little more about Consul. Like Eureka is a tool that allows us to register services centrally, allowing the discovery of them to other customers without needing to know their real IP, only with an identifier. But it can also be used to store information or the configuration to be used by the different clients. But about this last section, we will not see anything concrete in this example.

The first thing we are going to do is to raise Consul. For the case of a demo, we can raise a single instance of Consul through a simple docker command. But we will make it a bit more complex since Consul can also be raised as a cluster of servers, where one the server will be the main one. To carry out this approach, we will create a docker-compose that will allow us to raise several instances of Consul and leave them active for the example. Here below we have the docker-compose and if we access the URL http://localhost:8500 we can access its graphical interface.

The next step will be to create a microservice with Apache Camel. It would be an easy one. And it will be connected as a client to Consul. Registering its routes on the Service Registry. In this way and through an identifier, it will be consumable by other clients of the same server.

To do this, on one hand, we add the following dependencies, in addition to the normal ones for a microservice:

  • spring-boot-starter-actuator: This allows us to expose routes for the verification of the state and data of the application.
  • camel-consul-starter: This allows us to preconfigure Consul in our application.

Besides, we will indicate the following properties in the configuration file:

  • management.endpoints.web.exposure.include: Allows us to indicate monitoring paths to be managed by Spring Actuator.
  • camel.cloud.consul.enabled: Enable the use of Consul.
  • camel.cloud.consul.service-host: Indicate the server where Consul is located. This property will be in charge of setting the service address tag to the service in Consul.
  • camel.cloud.consul.url: To indicate the complete path where Consul is deployed.

And now we are going to show how to create the routes to register in the Consul registry. For each one of the routes, we have to indicate which will be its identifier and other metadata associated to the route/service. This can be done through the ServiceRegistrationRoutePolicy class and the routeProperty method that will allow us to indicate such data.

With this simple service we can check two things. First of all, it’s that if we invoke the route http://localhost:9092/api/book, we will see the list of books associated to the first of the routes. And second, if we access to Consul again, we will be able to see that we have two more registered services now. Clicking on the on them, we will be able to see the details that we have indicated in the source code.

To finish the example and see how it works the registration of applications dynamically in Consul. But also the discovery of these services works, we will create next another microservice with Apache Camel that will make use of the serviceCall method to invoke Consul.

This new service will be even simpler, since it will only need the dependencies to use Consul in an Apache Camel application. And in terms of configuration, it will only need two specific ones:

  • camel.cloud.consul.enabled: To enable the use of Consul.
  • camel.cloud.consul.service-discovery.url: To indicate the path where Consul is located.

And now to create the path to discover and invoke our previous service:

Each of the new services invokes a different service through the serviceCall method. By indicating the identifier of the service to be consulted, Consul will generate the route associated with that service and we will be able to invoke it. That route is composed based on the metadata indicated in the other microservice.

And with this, we have learned a little more about the operation of Apache Camel and another magnificent Service Discovery. As always, you can see all the code here.

--

--