Vertx.io 3.3.0 Service Discovery: Getting Started

DZone 's Guide to

Vertx.io 3.3.0 Service Discovery: Getting Started

Vert.x is a tool-set to make reactive applications. Find out how to get service discovery working in this article.

· Integration Zone ·
Free Resource

Developing failsafe and scalable Java applications contains domain specific challenges and the solutions contain misunderstandings. Even developing failsafe and scalable Java backends, on top of frameworks or toolkits claimed to be easy-to-use, it is still a problem to automate these services in dynamically changing environments such as microservices, for multiple environments. Recently, we published an article related to dynamically changing configuration problem. For a faster development process in a rapidly changing environment, dynamic configuration management should not be an obstacle for developers.

Vert.x is a tool-set to make reactive applications by applying an event-driven and non-blocking model which lets us scale applications easily with a bunch of configurations. Therefore we can create high-performance microservices at scale. This becomes possible with the Vert.x’s nervous system, which is called event bus. Any node whose member of the specific cluster has its own responsibility and the information is being exchanged via event-bus. Vert.x relies on its cluster-manager interface to be able to discover other nodes on the network. One popular cluster manager of Vert.x is the Hazelcast cluster manager.

It is a little tricky to understand how the cluster initialization progress actually runs. Thanks to discussions like this, it is easier to understand which configuration set changes the discovery logic accordingly in the background.

  1. Any newly created node with clustered configuration enabled, reads its Hazelcast configuration (cluster.xml or default-cluster.xml) and tries to join to the cluster by discovering the environment. Hazelcast provides few options for different cases:
    1. Multicast enabled means that nodes will be discovered by providing the multicast ip:port bindings in the given network interface, therefore any newly created node will publish join message all over the network so that it can be found with given multicast group id.
    2. Tcp-ip enabled option has a section which takes members as inputs for discovery. In this scenario, any new incoming node should now the already running members to join them.
    3. AWS specific configuration is a domain specific configuration for the cloud.
  2. When the nodes are aware of each other, they can engage a cluster. All nodes simply watch one or more topics and either receive or send messages to these topics over the event bus. Event bus has its configuration parameters such as clusterHost (which interface the pub-sub service should bind on startup) or clusterPort (which port the pub-sub service should listen on startup). If no port information is provided in the configuration, then an arbitrary port will be used.

Since this seems fair enough, in a microservice environment where configurations change rapidly, these static definitions simply do not work out practically. In a containerized environment where there are virtual network stack layers between processes, each deployment means a new interface or even maybe a new VM. Therefore, the new processes requires a dynamically generated cluster.xml file.

Image title

Before the version of 3.3.0 of Vert.x, all these service discoveries were statically defined properties. Whoever wants to use these Vert.x in a Docker container needs to solve service discovery problem internally. However, with Vert.x 3.3.0, many changes have been applied and below is the one that solves our Service Discovery issue:

  1. Latest stable version of Hazelcast (3.6.3) becomes standard.
  2. With Hazelcast 3.6.3, plugin based service discovery feature added. Within this release, service discovery backends (such as zookeeper, etcd, consul) become available as configuration to the Hazelcast. Therefore in the cluster.xml file you can see that there is a new section called discovery-strategies. Within this section, one can specify the desired service discovery backends.
  3. We found out that the Zookeeper plugin (developed by the same community) is the most mature one to get it to the production line. Zookeeper-Plugin requires curator-x-discovery as a dependency in the project. Here please note that Zookeeper 3.5.x is still alpha and compatible with the latest stable version of curator which is 3.2. In order to use a stable version of Zookeeper (3.4.8 for now) the curator needs to be downgraded to 2.11.0. Below sample dependency from our build.gradle.
dependencies {
  compile 'org.apache.curator:curator-x-discovery:2.11.0'
  compile 'org.apache.curator:curator-test:2.11.0'
  compile "io.vertx:vertx-core:3.3.0"
  compile 'io.vertx:vertx-rx-java:3.3.0'
  compile "io.vertx:vertx-hazelcast:3.3.0"
  compile 'com.hazelcast:hazelcast-zookeeper:3.6.1'
  compile 'com.hazelcast:hazelcast-client:3.6.3''
  runtime 'org.slf4j:slf4j-log4j12:1.7.5'
 compile 'org.slf4j:jcl-over-slf4j:1.7.5
  compile 'org.apache.logging.log4j:log4j:2.5'
  testCompile 'io.vertx:vertx-unit:3.3.0'
  testCompile 'junit:junit:4.12'
vertx.io ,microservice architecture ,docker ,hazelcast 3.6 ,zookeeper ,java

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}