Introduction

Using HydraRouter external clients can connect to services without knowing their IP or port information. HydraRouter takes care of service discovery and routing.

Additionally, HydraRouter can route to a website being hosted by a service. If the router is accessed using a service name as the first url path segment and the request is an HTTP GET call, then the request is routed to an available service instance.

When more than one service instance exists for a type of service, requests made through the HydraRouter are load balanced among available instances.

Hydra router also exposes a RESTful endpoint which can be used to query service health and presence information.

Using Hydra microservices can locate one another using functions such as findService, sendServiceMessage and makeAPIRequest. This all works quite well without the need for DNS, or a service router.

However, when remote API requests arrive into the cloud infrastructure, determining how to flexibly route requests intended for upstream services becomes problematic. Consider that services may launch using different IPs and or random ports. To handle these requirements one approach involves the use of DNS, Elastic Load Balancers, and Elastic IPs. One still has to manage the machines attached to each load balancer and running multiple services on a machine further complicates the situation.

This is where Dynamic Service Registries and Routers come into play. They're designed to simplify the above requirements by being services-aware and performing intelligent routing.

Hydra-Router, using Hydra, implements a Dynamic Service Registry and Router. To do so, it uses the route information that Hydra-enabled services publish during their start-up and initialization phase. It then routes incoming messages directly to services regardless of the following challenges:

• There may be one or more service instances available to handle a specific request.
• Services might come and go, each time starting with a different IP address or port.
• Service routes might change (updated or removed), as services are added or improved.
• No changes to infrastructure would be required to address the above concerns.

So how does this work?

As noted earlier, during startup, Hydra services perform automated registration. That's done behind the scenes when the hydra.registerService method is called. When building services using Hydra-Express, the service's routes can be registered automatically during the initialization phase.

hydraExpress.init(config, version, () => {
  hydraExpress.registerRoutes({
    '/v1/offers': require('./offers-v1-api')
  });
});

The HydraRouter then uses the resulting service registration information to later route messages to specific services.

Services can be started on any machine on a network with or without the use of random IP ports. Because each service registers itself - it can be located by a HydraRouter. That's the Dynamic Service Registry bit.

But is it really a router? Yes! Hydra-Router uses route-parser an AST-based tree parser for matching routes.

When a message is sent to the HydraRouter it checks whether the request matches a registered route. If so, the request message is routed to an active instance of the service which registered the route. When multiple service instances exist for a service, Hydra-Router will load-balance the requests to spread the load among available services.

☕ A key takeaway here is that this happens automatically without the need to update configuration and infrastructure. This works using Hydra's built-in service discovery and routing functionality.