Microservice Architecture in NodeJS

Question

I was working on a side project, and I decided to redesign the Skelton project as Microservices, so far I have not found any open source project that follows this pattern. After much reading and searching, I am finishing this project, but I still have some questions and thoughts.

Here are my questions and thoughts:

• How to make the API gateway smart enough to load a balnce request if I have 2 node from the same microservice?
• If one of the microservices does not work, how should the discovery be known?
• Is there a similar implementation? is my design right?
• Should I use Eureka or similar things?

Answer 1

Your design looks fine. We are also building our microservice project using the API Gateway approach. All services, including the Gateway Service (GW), are containerized (we use dockers) Java applications ( spring boot or dropwizard ). A similar architecture can be built using nodejs. Some topics to mention in relation to your question:

• Authentication / Authorization: The GW service is the only entry point for clients. All authentication / authorization operations are processed in GW using JSON web tokens , which also have nodejs libray. We store authorization data, such as user roles in the JWT token. As soon as the token is generated in GW and returned to the client, for each request the client sends the token in the HTTP header, then we check the token whether the client has the required role to call a specific service or the token has expired. In this approach, you do not need to monitor the user session on the server side. In fact, the session is missing. The required information is indicated in the JWT token.
• Service Detection / Load Balance: We use dockers , dockers , which are a docker kernel clustering tool built into the docker engine (after docker v.12.1). Our services are docker containers. A docker-based containerized approach makes it easy to deploy, maintain, and scale services. At the beginning of the project, we used Haproxy, Registrator, and Consul to implement service discovery and load balancing, similar to your drawing. Then we realized that we did not need them to discover services and load balancing while we were building a docker network and deploying our services with a dock . Using this approach, you can easily create isolated environments for your services, such as dev, beta, prod on one or more machines, creating different networks for each environment. After you create a network and deploy services, service discovery and load balancing are not a problem for you. In the same docker network, each container has DNS records of other containers and can communicate with them. With docker swarm, you can easily scale services with a single command. At each service request, the docker distributes (balances the load) the request to the service instance.

Answer 2

Your design is fine.

• If your API gateway should implement (and probably this is) CAS / some Auth (through one of the services - that is, some kind of user service), as well as track all requests and change headers to support request metadata (for internal use of ACL / scope). Your API gateway must be run in Node, but must be under Haproxy, which will take care of load balancing / HTTPS

• Discovery is in the right position - if you're looking for the one that fits your design, don't look anywhere, but Consul .

• You can use the consul template or use your own micro-discovery infrastructure for services and the API gateway, so they share the endpoint data at boot time.

• ACL / authorization must be implemented for each service, and the first request from the API gateway must be subordinate to all intermediate authorization tools.

• Intelligently track requests using the Gateway API by providing a request identifier to each request so that the life cycle can be monitored in the internal system.

• I would add Redis for messaging / work / queues / fast files in memory, such as cache / cache invalidation (you cannot process the entire MS architecture without it) - or take RabbitMQ if you have a much more distributed transaction and many messages

• Hide it all on containers (Docker) to make it easier to maintain and assemble.

• As for BI, why do you need a service? You can have an external ELK (Elastisearch, Logstash, Kibana) and immediately have dashboards, log aggregation and a huge large data warehouse.