<commit_before>![logo](hydra-router.png)

A [Dynamic Service Registry and Router](http://microservices.io/patterns/service-registry.html) for use with Hydra-enabled microservices.

## Introduction

Using Hydra, microservices can locate one another using functions such as [findService](https://github.com/flywheelsports/hydra#findservice), [sendServiceMessage](https://github.com/flywheelsports/hydra#sendservicemessage) and [makeAPIRequest](https://github.com/flywheelsports/hydra#makeapirequest). This all works quite well without the need for DNS or a service router.

![service-peers](assets/service-peers.jpg)

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.

![dns-approach](assets/dns-approach.jpg)
<commit_msg>documentation update<commit_after>![logo](hydra-router.png)

Hydra Router is a service-aware router which can direct HTTP and websocket message requests to registered services.

## Introduction

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

Additionally, hydra router 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 hydra router 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](https://github.com/flywheelsports/hydra#findservice), [sendServiceMessage](https://github.com/flywheelsports/hydra#sendservicemessage) and [makeAPIRequest](https://github.com/flywheelsports/hydra#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.


{'fraction_non_alphanumeric': 0.05637171165015374, 'fraction_numerical': 0.0, 'mean_word_length': 5.550335570469799, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6658484', 'n_tokens_mistral': 708, 'n_tokens_neox': 674, 'n_words': 354}