Registry and Discovery

Services typically need to call one another. In monolithic applications, services invoke one another through language-level methods or procedure calls. In a traditionally distributed system deployment, services run at fixed, well-known locations (hosts and ports), so they can easily call one another using HTTP/REST or some RPC mechanism. However, a modern microservice-based application typically runs in a virtualized or containerized environments where the number of instances of a service and their locations (IP and port) changes dynamically.

This tutorial shows how to use the service registry and discovery feature of the Light platform to discover services and invoke them with the client module.

Introduction and Code Generation

The starting point of the discovery tutorials will walk you through code generation for the services that will be used throughout. Read More »

Static Configuration

Statically connecting microservices in a realistic call hierarchy where each service is hard-bounded to a known ip and host. Read More »

Dynamic Service Discovery with Direct Registry

Service discovery through endpoints defined in a configuration allows a seamless move to external registries without code changes. Read More »

Multiple Instances of the same Service

Client-side load balancing through direct service discovery using configuration with multiple instances. Read More »

Consul Service Registry and Discovery

Use Consul as a resilient and fault tolerant registry for service discovery by service id. Read More »

Multiple Instances with Environment Segregation

Using tags to denote and differentiate services deployed in the same cluster into logical environments. Read More »

Securing Consul with acl_token

Securing Consul by requiring a secret token that will only allow services which own that token to register thus ensuring discovered instances are valid. Read More »

Service Discovery with Docker Containers

Using service discovery patterns in a containerized environment. Read More »

Kubernetes

Deploying services to Kubernetes and using Consul for service registry and discovery Read More »

Router Assisted Service Discovery

Service discovery with light-router for client that is not running in a JVM. Read More »

Portal Registry

Until recently, we always recommend our customers to use Consul for the global registry and discovery. However, we found some issues with Consul reported from our customers. So we started to work on our own registry on the portal to replace the Consul. For more information about this component, please refer to [Portal Registry][]. To make it simple, we are going to copy the four projects from consul-tls folders. cd api_a cp -r consul-tls portal-registry cd . Read More »

Enable Security

In previous steps, we have explored all different options of service discovery. In this step, we are going to build on top of http-health codebase and enable the security with light-oauth2. It is requested by some users who want to see how different features work together in a distributed application. Start Consul docker run -d -p 8400:8400 -p 8500:8500/tcp -p 8600:53/udp -e 'CONSUL_LOCAL_CONFIG={"acl_datacenter":"dc1","acl_default_policy":"allow","acl_down_policy":"extend-cache","acl_master_token":"the_one_ring","bootstrap_expect":1,"datacenter":"dc1","data_dir":"/usr/local/bin/consul.d/data","server":true}' consul agent -server -ui -bind=127.0.0.1 -client=0.0.0.0 Start light-oauth2 The default security for light-4j is OAuth 2. Read More »

Compose Consul

In the previous step, we have shown how to use docker-compose with Consul for service registry and discovery. To make the use case simple and let users focus on the registry and discovery only, we used a docker instance of the Consul with only HTTP support. Also, we didn’t explore host network in the docker-compose and dynamic port allocation in the server.yml In this tutorial, we are going to use the chain-write and chain-reader service for taiji-chain to show you what production-like configuration should be if you don’t want to use Kubernetes but stay with docker-compose or docker-swarm for your target deployment environment. Read More »

Consul HTTP Health Check

In the previous Consul TLS tutorial, we have set up Consul to ping the service IP address and port number to determine if the service is healthy. It works in certain cases, but not all the cases. It has a flaw as described below. A service registers itself to the consul and asks consul to ping the IP and port. When the service is crashed without a chance to deregister itself. Read More »

Openshift Deployment

In this tutorial, we are going to deploy the four APIs to an Openshift project. Openshift is built on top of Kubernetes, but there are still a lot of differences. It has a different command line oc than kubectl with similar syntax. Assmption Let’s assume that you have an Openshift project available and you have access to the OC command line to deploy applications. Overview This is a snapshot of a sample app created by to demonstrate microservices service registration/discovery with Consul. Read More »

External Config

Externalize the configuration files for services deployed to Kubernetes cluster and discovered with a production ready consul cluster. Read More »

Consul Production with TLS

Service discovery with a production ready Consul cluster with TLS enabled from Kubernetes cluster. Read More »