Why node.js is not suitable for large projects

Preface

First of all, we need to clarify what large-scale applications are. In fact, this is a matter of opinion, and it is a philosophical issue, not a technical issue. If someone asks you, is a website that can conduct online sales, such as Uniqlo, big? You might say big, because it is indeed much more complicated than the logic of blogs, corporate websites, etc. that you usually see. Or if it is small, it means you have developed a system more complex than it. So how does it compare to Taobao? The comparison between big and small requires a reference.

1. Application components

Is it possible for a complete web application to consist of only one language or one technology? impossible. Because a complete web application is actually a combination of multiple technologies, there are many solutions to solve a certain problem. For example, there are many back-end logical solutions, including Java, PHP, Python, Ruby, etc.

To briefly summarize, the components of an application may include:

Web interface display logic; backend business logic; cache; database; message queue.

In fact, you can also add log analysis, data analysis, etc., but the above ones are just the most well-known.

2. Types of Applications

I/O intensive; CPU intensive.

For common Internet products, the bottleneck is not in the logic of the backend business, but in I/O, that is, the reading and output of data returned to users. For applications, reading refers to obtaining data from the database, and output refers to outputting this data to the user's browser after certain processing. This is I/O intensive.

CPU intensive refers to applications that perform frequent computing tasks, and Node.js is indeed shortcoming in this regard.

3. Application Service Process

As shown in the figure, the user sends a request through the browser, the network card receives the TCP connection, notifies the kernel, and the kernel then calls the corresponding server program.

Request Request process

Response return process

As shown in the figure below, if a Web application wants to return data, it must first obtain the data, call the disk driver through the kernel, and read the data into the cache. In this way, the data can be obtained and processed in the Web application, and finally the kernel is called to send the data to the client through the network card.

4. Application bottleneck

Usually, the bottleneck of I/O intensive services is the reading and writing of disks, so when purchasing a cloud server, you can purchase SSD disks to improve performance. Generally, the data of database software is stored in files. First, consider adding a memory cache to solve this bottleneck. Cache frequently accessed data to see if it can solve the problem in the current scenario, such as using Redis. Secondly, consider building or expanding a database cluster to improve concurrency.

The bottleneck of CPU-intensive applications is the CPU, and the only way to solve the bottleneck is to increase the CPU processing cores.

5. Distributed Applications

Large-scale ordinary applications and distributed applications are actually different concepts. Readers can simply understand distributed applications as a team, where each member is a node. A large project requires members to work together to complete it, so there are some communication costs between members. Some members may even engage in intrigue, speak insincerely, and shirk responsibilities. It is also possible that a member is sick and recuperating at home, unable to work, and so on. When faced with these problems, the advantages of Node.js cannot be fully demonstrated (it’s not that it cannot be done, but there is no perfect infrastructure).

The true definition of distributed is to deploy different service modules in multiple different servers, take processes as the basic unit, dispatch them to the servers, communicate and work together through remote procedures (RPC), and finally provide services to the outside world.

Compared with the current distributed infrastructure of Node.js, the infrastructure of Go language is much more complete, especially in the Docker project, which fully demonstrates the advantages of Go language. This is why TJ Holowaychuk, a "big shot" in the Node.js community, turned to Go language because he wanted to develop distributed applications.

In fact, there is no need to worry too much about the distribution issue. After all, JavaScript was originally just a scripting language running on the browser. JavaScript is not omnipotent, so why must it be used in operating system-level development? Wouldn't it be better to find a more suitable language? Just like now we choose JavaScript to build web applications.

6. Multi-process Node.js

After understanding the above knowledge points, readers should now know that Node.js has little to do with large-scale applications. Most developers who learn Node.js are front-end developers, so they don’t know the basic knowledge of the back-end. When searching for some information on the Internet, they find that Node.js can only use a single core. When they hear that TJ Holowaychuk has turned to the Go camp, some developers wonder if Node.js is not suitable for developing large applications.

The problem that Node.js can only use a single core has been solved. The Egg-Cluster module in the Egg.js framework used later solves this problem very well by using multiple processes.

The above is the details of why node.js is not suitable for large projects. For more information about node.js, please pay attention to other related articles on 123WORDPRESS.COM!