Redis Based Lightweight Microservices

This is another blog post is based on a youtube video I have watched in youtube. This whole post is the summarised version of the video and my understanding of the use-cases. :)

Summery:

The main discussion is about how to use a single redis instance to build a system of microservices.

Learning:

• To build microservices we gonna need these things
  • Service discovery
  • Messaging
  • Load balancing
  • Health
  • Presence
  • Logging queuing

• How to share key space with all of the services. To do that we need to maintain a specific type of pattern while saving/retrieving keys in redis. Like in the video the author used the pattern like this:

  Prefix:service_name:instance_unique_id:type

  Example:

  • hydra:service:order-svc:289347928374982:health:log
  • hydra:service:order-svc:service
  • hydra:service:order-svc:2893479223474982:presence
  • hydra:service:order-svc:routes

  This way in a shared redis all of the information can be stored and all other services can access/filter these without any hassle. Like service 1 can create routes of order service, service 2 can get the routes of order service by accessing the order-svc routes keys without using extra api calls or other stuff.

• Check if a service is present This is needed for load balancing, service discovery, routing etc.

  • So the idea is when a service is being upped it will create a presence key with it’s instance id in the redis key store with a ttl. After the ttl the key will expire. It will be the service's responsibility to update the ttl or regenerate the presence key if needed.
  • So using this other services can find a service instance just by filtering proper keys. Like filtering hydra:service:order-svc will provide the list of services

• Service health check: A shared key similar to presence can be used to store a service's health after each 5 sec. This way a key can be used in any place to check service wise health checks, or other information.

• Service discovery: for service discovery using some customized query can help find you service instances, instance presences, routes.

• Service routes: again this can be easily achieved by querying proper way. We can find all service’s routes by querying generic routes type query, ger service specific routes by querying service routes query. We can easily store a list of routes in each service keys.

• Load balancing: This can be done by service discovery, presence, routing features. Redis keys, list, string etc feature can be used for this

• Messaging: We can use redis pubshub to use messaging between microservices. Like each service will listen to two channels one is a channel name of its own instance id, service name and another is service name. Whenever a normal message needs to be processed, services should go through the message to the global service channel, if the message needs to be sent to an individual service that message will be sent to an instance id specific channel.

• Queues: using redis message queue can be a very easy solution for us. We can use redis lpush and rpoplpush along with service sacrifice queues. Publishers can push data/messages in service specific queues by lpush then listeners can consume those by pop methods.

• Logging: can be used as a distributed logging system. Same as the queuing process.

• Config management: can be used as shared config management across the whole system. Can store config using service keys prefix.

The original Link can be found here, Building Lightweight Microservices Using Redis