We have different microservices which calls each other. Many calls in these are redundant so we are planning to use varnish as a cache layer so we can save the redundant calls.
I have following questions -
1) Is varnish suitable for such use case. If not is there any other tool ?
2) How can we configure Varnish for maximum throughput and minimum latency between different services. We have vert.x based services with async calls.
Related
Suppose we're building an SPA (Single Page Application) which depends on a couple of independent back-end systems. Basically a Microservices-esque implementation of SignalR-hubs.
Each of these back-end systems expose a separate SignalR endpoint with a separate set of hubs;
The separation of these hubs across different back-end systems is intentional in design and cannot be unified into a single one;
Basically, a single browser session to the app will have to maintain a separate SignalR-connection for each endpoint on which we depend.
From what we have gathered, this approach will not scale due to the fact - at this time of writing - most browsers seem to implement an arbitrary limit of concurrent websocket connections.
This leads us to the following questions:
Are we correct in our assumption that this will not scale in the browser?
If our assumption is correct, what are our options? Will we need to implement a single encompassing SignalR-endpoint?
I want to create Sails.js (Node.js) server app, which will provide API for single-page-app. This server will consist of multiple modules:
user management
forum
chat
admin GUI
content management
payment gateway
...
All these modules will share one database. The server must be able to handle as many requests and web sockets as possible. Clean architecture and performance are my primary goals.
My questions:
Should I create multiple servers running on multiple ports? I mean, one server for content management module. Another server for forum management module.
Or is it better to create only one big universal server, which will consists of multiple separate modules (hooks in Sails.js) and runs on one port? Will performance of the server decrease in this case ?
I was thinking about vertical scaling one big universal server, running on single port with pm2. Or is it better to scale Node.js horizontaly and split server to multiple smaller servers ?
Im new to Node.js so I appreciate any advice.
I think it really boils down to the scale of the project.
For very simple things there's no real reason to scale past a single but reliable server is there?
However for broader projects that have a back-end that is resource intensive and a lot of users and traffic, you may a want to split the back / front end aspects depending on the requirements.
In which case you might have a single server (or more) dealing with the specific administrative requests or routines then have the client / user API running through a load balancer and spread across multiple servers in multiple regions or break it down further into an auto scaling group so as to accommodate for fluctuations in traffic.
It would be worthwhile to note too that this is really suited for higher volumes of traffic or resource usage as you're dedicating the server infrastructure for this purpose, for smaller applications where there is infrequent usage then breaking things down into micro services from the start and getting billed for the runtime rather than dedicated infrastructure utilization might make more sense to me. You could take a look at AWS API Gateway and Lambda services for some more information on that (I am not affiliated to AWS in any way, I just appreciate what they have managed to put together there).
I learned about microservices from here
Now, I want to use microservices architecture in my next sails.js project.
One way I could think of is:
Breaking my one sails.js application into multiple small sails.js sub-projects/repositories.
Having one controller-model in one sub-project. For example, If we consider simple eCommerce app with entities say User, Products, Orders, etc. then there will be separate sails.js repositories for each of them with respective sails.js model-controller. Then this single sub-repository will from my one microservice.
Each sub-repository then will obviously have its own configs.
These microservices will them communicate with each other using some HTTP node module.
Then writing my own API gateway for routing in node.js, which will be responsible for invoking methods/web-services from these sub-repositories depending on the request from clients.
Is this the best way OR is there alternative way to design your project using microservices architecture?
What will be the best way to implement inter-service communication, API gateway with sail.js? If one microservice designed with above mentioned approach get bigger, and if I have to split it up in 2, how sails.js model should be changed?
The most important aspect of designing microservices is the separation of concerns which means each microservice will have a defined boundary under which they need to work.
Each microservice is designed to do a defined work so, first you need to find the independent functionalities in you project and try to create a microservice for it.
The most important thing to note is you should first start with a monolithic architecture and if you identify that some functionalities needs to be separated then you can create a microservice out of it.
As far as sails is considered then it is a good candidate for MVC and if the project is monolithic but if the number of microservices is large then it is not a good choice because running large number of microservices with sails.js will consume more of your system RAM.Sails.js internally uses so many libraries which you will not need. You can make a simple microservice with just node.js core modules and they will consume less memory too.
Also when each microservices handles small functionalities so the amount of
code will be less and there is no need for mvc arcitecture. you can use less number libraries to create it.
Conclusion
If number of services is less and you don't worry about system RAM then go for multiple sails application.
If number of services going to be more then try to make your services without using sails
I agree with the previous answer and I would add that Sails is a great candidate for clustering and in an environment where you may wish to scale horizontally to improve availability. I do not believe sails is the right candidate for the micro service architecture, however it is most likely the focus for an application which requires the usage of multiple services in its own right.
I use a message service to glue together multiple applications, with sails consuming these messages in order to update a webpage. I probably see those applications as offering smaller services, with defined boundaries and my sails application as the front end, with the controller gluing what is necessary to satisfy the requirements of the end user.
I'm programming a server-side application which will manage requests from:
Game client
Website (HTTP requests)
API
As of now I'm using only one (NodeJS) application for every type of requests, the problem is that with a growing user base, this approach will generate a bottle-neck.
I would like some advices on how to develop the server-side architetture so that it'll be scalable.
The only solution that I know of is to use multiple servers with the same application running which will share the same memory (Redis server).
Is it possible in nodeJS to split the management of these types of request into multiple servers? Maybe one or more servers for each type of request?
Currently I'm using:
NodeJS
Redis
MySQL
Express
Socket.io
Thanks in advance, can you recommend some books on this matter?
On one machine to handle the power of multicore architecture you can use node.js Cluster module (https://nodejs.org/api/cluster.html).
I think it is a good idea to split API and Website on different applications. If you decide to run multiple node.js applications on one machine try to use pm2 (http://pm2.keymetrics.io/). You could probably split your API on a bunch of small applications - which called microservice architecture. I personally don't like microservice approach you can check the web for pros and cons.
Also if you deploy your application (or bunch of applications) on different virtual/phisycal machines (which is usual in production) you can use haproxy for balancing and
fault tolerance (http://www.haproxy.org/).
As Node.js beginner coming from Enterprise IT, I am unable to comprehend one aspect of node.js usage. I am framing my question in two parts.
Question-1) Strictly from scalability standpoint, how can an I/O heavy web application scale using node.js unless we scale back-end I/O resources that it is consuming?
A database server can serve only "X" number of concurrent users. Even if node based HTTP server is able to handle more incoming requests, overall throughput is going to be dictated by number of concurrent connections DB can handle.
Same applies for other enterprise resources like content retrieval from file servers or invocation of legacy APIs etc. I understand that we would be less worried about cloud resources which can elastically scale and are not in our direct purview.
Question-2) If answer to above question is "Node is not one-size-fit-all solution", how are companies like PayPal, Walmart, LinkedIn et al able to gain scale using node? They too would integrate within their existing system landscape, and are not totally network based applications (or are they?).
Node.js is typically used as an orchestration layer in SOA.It is mainly used as front-end for the backend services.It is true that
the throughput is going to be dictated by number of concurrent connections DB can handle but there is also the time involved
for the presentation layer to present the content.
Web technologies like JSP,Ruby on rails are designed to get the content on the server and serve as a single page to the client and are not suited for orchestration layer.Today we need services that handle mobile clients(where there are lot of API calls to retrieve small amount of data)Thus node.js reduces the response time and increases the user expierence.
Look at http://nodejs.org/video/ video by Eric Hammer to understand how Node.js is being used in Walmart.