Using Docker as service registry for microservices

Question

I've followed some tutorial that walks through setting up 3 microservices (app, products and feedback) and 1 service registry.

After working with Docker for a while I feel the service registry is redundant. Because Docker can kick instances while injecting hostnames and ports via environment variables to each other.

For instance in the following Docker Compose file, I'm passing db credentials from a MySQL microservice to Node.js microservice and in the similar way, if there were other Node.js microservices, I could wire them up.

version: '3'

services:

  mysql:
    image: "mysql:5.7"
    container_name: "mysql"
    ports:
      - "6603:3306"
    volumes:
      - ./assets/schema.sql:/docker-entrypoint-initdb.d/init.sql
    environment:
      DATABASE_HOST: mysql
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: database
      MYSQL_USER: mysql
      MYSQL_PASSWORD: password

  products_service:
    build: .
    command: bash -c "/wait && npm start"
    volumes:
      - "./src/:/service/src/"
    image: "node"
    container_name: "products"
    ports:
      - "8080:8080"
    depends_on:
      - mysql
    environment:
      DATABASE_HOST: mysql
      MYSQL_PORT: 3306
      MYSQL_DATABASE: database
      MYSQL_USER: mysql
      MYSQL_PASSWORD: password
      WAIT_HOSTS: mysql:3306
    restart: on-failure

Do I really need to code and program a registry service in Node.js?

Answer 1

Assuming your product service exposes rest endpoints which external world uses https://myserver/myservice .

After some time your product service became very popular and you want to scale it further without breaking current contract(the endpoint above).

To scale your product service you will start more than one instance which are running on same or different host(s).

The service that keeps track of how many instance of your product service is running is called discovery service.

This is not enough outside traffic that is coming to your service endpoint should be routed to all the instances of your product services. That is the job of API gateway which acts like a reverse proxy. You can specify policy such as round robin to route traffic to all the instances.

Thus API gateway and service discovery together provides scalability and fault tolerance for your service.

References-

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

https://auth0.com/blog/an-introduction-to-microservices-part-3-the-service-registry/

Answer 2

You do really need some sort of automation beyond just composing up containers, if you want to be reactive to traffic loads and service failures. All of the major container management tools have some strategy to do service discovery for you. Also there are various ways to do service discovery ( like heart-beats and SWIM ).

Frankly, you can start with starting up some instances for your services and serve your users. But you won't be able to react to loads and failures and also be resource efficient. That's where tools like k8s shine and handle service discovery and resource utilization for you.

Check this talk to understand more about service discovery.