Microservices Architecture in NodeJS

17
votes

I was working on a side project and i deiced to redesign my Skelton project to be as Microservices, so far i didn't find any opensource project that follow this pattern. After a lot of reading and searching i conclude to this design but i still have some questions and thought.

enter image description here

Here are my questions and thoughts:

  • How to make the API gateway smart enough to load balnce the request if i have 2 node from the same microservice?
  • if one of the microservice is down how the discovery should know?
  • is there any similar implementation? is my design is right?
  • should i use Eureka or similar things?
2
node.jsmicroservices
API gateways typically have load balancing feature built-in. Some even implement features like sticky sessions etc. The three most popular API gateways are all load balancers (they were not originally designed as API gateways): haproxy, Nginx and Apache. The problem with using webservers and load balancers as API gateways is that you need to restart the gateway if you want to add or remove a node. I've written an API gateway specifically to allow dynamic adding and removing of nodes without restarting: github.com/slebetman/typhos. It's not ready for production but you can fork it - slebetman
Also, since API gateways are typically load balancers they usually have features to detect nodes returning 400 and 500 errors. So usually discovery services just return the url to the service and that url almost always point to the API gateway. Some architectures don't use API gateways (Amazon) so they depend on the discovery service to detect downed nodes - slebetman
@slebetman yah i know that but i'm building it from scratch since i did not found any good gateway for nodejs do you recommend any ? - Sideeq Youssef
@SideeqYoussef have you used any particular libraries to implement this architecture? - MrfksIV

2 Answers

10
votes

Your design seems OK. We are also building our microservice project using API Gateway approach. All the services including the Gateway service(GW) are containerized(we use docker) Java applications(spring boot or dropwizard). Similar architecture could be built using nodejs as well. Some topics to mention related with your question:

  • Authentication/Authorization: The GW service is the single entry point for the clients. All the authentication/authorization operations are handled in the GW using JSON web tokens(JWT) which has nodejs libray as well. We keep authorization information like user's roles in the JWT token. Once the token is generated in the GW and returned to client, at each request the client sends the token in HTTP header then we check the token whether the client has the required role to call the specific service or the token has expired. In this approach, you don't need to keep track user's session in the server side. Actually there is no session. The required information is in the JWT token.
  • Service Discovery/ Load balance: We use docker, docker swarm which is a docker engine clustering tool bundled in docker engine (after docker v.12.1). Our services are docker containers. Containerized approach using docker makes it easy to deploy, maintain and scale the services. At the beginning of the project, we used Haproxy, Registrator and Consul together to implement service discovery and load balancing, similar to your drawing. Then we realized, we don't need them for service discovery and load balancing as long as we create a docker network and deploy our services using docker swarm. With this approach you can easily create isolated environments for your services like dev,beta,prod in one or multiple machines by creating different networks for each environment. Once you create the network and deploy services, service discovery and load balancing is not your concern. In same docker network, each container has the DNS records of other containers and can communicate with them. With docker swarm, you can easily scale services, with one command. At each request to a service, docker distributes(load balances) the request to a instance of the service.
5
votes

Your design is OK.

  1. If your API gateway needs to implement (and thats probably the case) CAS/ some kind of Auth (via one of the services - i. e. some kind of User Service) and also should track all requests and modify the headers to bear the requester metadata (for internal ACL/scoping usage) - Your API Gateway should be done in Node, but should be under Haproxy which will care about load-balancing/HTTPS

  2. Discovery is in correct position - if you seek one that fits your design look nowhere but Consul.

  3. You can use consul-template or use own micro-discovery-framework for the services and API-Gateway, so they share end-point data on boot.

  4. ACL/Authorization should be implemented per service, and first request from API Gateway should be subject to all authorization middleware.

  5. It's smart to track the requests with API Gateway providing request ID to each request so it lifecycle could be tracked within the "inner" system.

  6. I would add Redis for messaging/workers/queues/fast in-memory stuff like cache/cache invalidation (you can't handle all MS architecture without one) - or take RabbitMQ if you have much more distributed transaction and alot of messaging

  7. Spin all this on containers (Docker) so it will be easier to maintain and assemble.

  8. As for BI why you would need a service for that? You could have external ELK Elastisearch, Logstash, Kibana) and have dashboards, log aggregation, and huge big data warehouse at once.