LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub

What's on this Page

  • Introduction
  • Configuring the APIs
    • API A
    • API B
    • API C
    • API D
  • Starting Consul
  • Starting the Servers
  • Testing the Servers
  • Adding another API
  • Testing the added Server

Multiple Instances with Environment Segregation

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

Introduction

In the previous step, we’ve set up the services to register and discover downstream services through Consul. If there are multiple instances for the same serviceId, then the client will load balance these instances.

In real service delivery, there are a lot of complicated testing scenarios that need to be addressed, and one of the use cases is environment segregation

In this step, we are going to use an environment tag to separate multiple instances during testing so that we can have segregated environments using the same Consul server.

Configuring the APIs

First, let’s copy our current state from the last step into the tag directory.

cd ~/networknt
cp -r light-example-4j/discovery/api_a/consul light-example-4j/discovery/api_a/tag
cp -r light-example-4j/discovery/api_b/consul light-example-4j/discovery/api_b/tag
cp -r light-example-4j/discovery/api_c/consul light-example-4j/discovery/api_c/tag
cp -r light-example-4j/discovery/api_d/consul light-example-4j/discovery/api_d/tag

API A

In order to register the service with a tag to indicate a separate environment, We need to update server.yml with an environment tag. Here we are using test1 as our tag.

environment: test1

API B

Let’s update API B server.yml with environment tag.

environment: test1

API C

Let’s update API C server.yml with environment tag.

environment: test1

API D

Let’s update API D server.yml with environment tag.

environment: test1

Starting Consul

Here we are starting the consul server in docker to serve as a centralized registry. To make it simpler, the ACL in consul is disabled by setting acl_default_policy=allow. If you follow the previous step, then your consul server should be running, and you don’t need to restart it.

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

Starting the Servers

Now let’s start four terminals to start servers.

API A

cd ~/networknt/light-example-4j/discovery/api_a/tag
mvn clean install -Prelease
java -jar target/aa-1.0.0.jar

API B

cd ~/networknt/light-example-4j/discovery/api_b/tag
mvn clean install -Prelease
java -jar target/ab-1.0.0.jar

API C

cd ~/networknt/light-example-4j/discovery/api_c/tag
mvn clean install -Prelease
java -jar target/ac-1.0.0.jar

API D

And start the first instance that listen to 7444 as default

cd ~/networknt/light-example-4j/discovery/api_d/tag
mvn clean install -Prelease
java -jar target/ad-1.0.0.jar

Now you can see the registered services from Consul UI.

http://localhost:8500/ui

You can find tag test1 for all services registered on the Consul.

Testing the Servers

curl -k https://localhost:7441/v1/data

And the result will be

["API D: Message 1 from port 7444","API D: Message 2 from port 7444","API B: Message 1","API B: Message 2","API C: Message 1","API C: Message 2","API A: Message 1","API A: Message 2"]

Adding another API

Now let’s start the second instance of API D. Before starting the server, let’s update server.yml with port 7445 and with environment tag test2.

httpsPort:  7445
environment: test2

And start the second instance:

cd ~/networknt/light-example-4j/discovery/api_d/tag
mvn clean install -Prelease
java -jar target/ad-1.0.0.jar

Take a look at the Consul UI, you can see the tag test2 for API D.

You can use the following command line to lookup API with test1 or test2 and you will see one instance returns for each query.

curl http://localhost:8500/v1/health/service/com.networknt.ad-1.0.0?passing&wait=600s&index=0&tag=test1
curl http://localhost:8500/v1/health/service/com.networknt.ad-1.0.0?passing&wait=600s&index=0&tag=test2

Can you guess what will be returned if you don’t have tag query parameter? The answer is all available instances will be returned.

Testing the added Server

Let’s issue the same command again.

curl -k https://localhost:7441/v1/data

And the result should be the same.

["API D: Message 1 from port 7444","API D: Message 2 from port 7444","API B: Message 1","API B: Message 2","API C: Message 1","API C: Message 2","API A: Message 1","API A: Message 2"]

Shut down the server with port 7444. Now when you call the same curl command, you will have an error although instance 7445 server is running.

This is because that 7445 server has tag test2 and API B is looking up API D with tag test1.

In summary, this step shows you how to use environment tag to separate testing instances for microservices.

In the next step, Consul ACL will be enabled so that only services with a token can register and discover from it.

  • About Light
    • Overview
    • Testimonials
    • What is Light
    • Features
    • Principles
    • Benefits
    • Roadmap
    • Community
    • Articles
    • Videos
    • License
    • Why Light Platform
  • Getting Started
    • Get Started Overview
    • Environment
    • Light Codegen Tool
    • Light Rest 4j
    • Light Tram 4j
    • Light Graphql 4j
    • Light Hybrid 4j
    • Light Eventuate 4j
    • Light Oauth2
    • Light Portal Service
    • Light Proxy Server
    • Light Router Server
    • Light Config Server
    • Light Saga 4j
    • Light Session 4j
    • Webserver
    • Websocket
    • Spring Boot Servlet
  • Architecture
    • Architecture Overview
    • API Category
    • API Gateway
    • Architecture Patterns
    • CQRS
    • Eco System
    • Event Sourcing
    • Fail Fast vs Fail Slow
    • Integration Patterns
    • JavaEE declining
    • Key Distribution
    • Microservices Architecture
    • Microservices Monitoring
    • Microservices Security
    • Microservices Traceability
    • Modular Monolith
    • Platform Ecosystem
    • Plugin Architecture
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • SOA
    • Spring is bloated
    • Stages of API Adoption
    • Transaction Management
    • Microservices Cross-cutting Concerns Options
    • Service Mesh Plus
    • Service Discovery
  • Design
    • Design Overview
    • Design First vs Code First
    • Desgin Pattern
    • Service Evolution
    • Consumer Contract and Consumer Driven Contract
    • Handling Partial Failure
    • Idempotency
    • Server Life Cycle
    • Environment Segregation
    • Database
    • Decomposition Patterns
    • Http2
    • Test Driven
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
  • API Styles
    • Light-4j for absolute performance
    • Style Overview
    • Distributed session on IMDG
    • Hybrid Serverless Modularized Monolithic
    • Kafka - Event Sourcing and CQRS
    • REST - Representational state transfer
    • Web Server with Light
    • Websocket with Light
    • Spring Boot Integration
    • Single Page Application
    • GraphQL - A query language for your API
    • Light IBM MQ
    • Light AWS Lambda
    • Chaos Monkey
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Mesh
    • Light Router
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • COVID-19
    • Light OAuth2
    • Metrics and Alerts
    • Config Server
    • Tokenization
    • Light Controller
  • Tool Chain
    • Tool Chain Overview
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Benchmark
    • Benchmark Overview
  • Tutorial
    • Tutorial Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“Multiple Instances with Environment Segregation” was last updated: June 20, 2019: fixes #112 rewrite service discovery tutorial and add security and OpenTracing (0ed89f5)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Benchmark
  • Tutorial
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute