当前位置：首页 > news >正文

Node.js 应用开发详解开篇词 Node.j 从工程化工具到后端服务应用的转变

news 来源：原创 2024/5/6 9:04:43

你好，欢迎来到 Node.js 课程，我是清弦。

近 10 年来，我一直在一线大厂从事前端研发工作，负责前端、中台业务，以及跨端平台的研发和管理，曾经负责研发过亿级用户社交项目、千万级用户海外音视频应用平台等大型项目，同时我还自研了 Node.js 框架，为公司内部 10 多个系统项目提供支持。

现在我和我的团队，不仅用 Node.js 来做前端的工程化（即将其作为辅助工具，利用 webpack 提升前端开发效率以及保证开发质量），还用来做一部分后端开发，来发挥 Node.js 更大的价值。

在 Node.js 的应用过程中，有些问题曾经一度困扰着我：

在前端，Node.js 难道只能做工程化应用吗？
既然要学习后端开发，为什么我不学习其他应用更广的 Java 或者 Go？

前端为什么要选择 Node.js 来做后端开发？

作为一个前端工程师，掌握一门后端语言是很有必要的。

在小公司，通常希望你“十八般武艺，样样都懂”，甚至要求你可以独立开发一个项目。当你掌握一门后端语言后，无论是独立开发还是在前端团队需要做部分后台服务的时候，你都可以主动承担这部分工作，从而在团队中凸显个人优势。

在大公司，前后端虽然分工很明确，但是团队间的协作是常态，需要跟后端人员频繁地沟通，如果你不懂后端，不考虑后台，写出来的一些代码可能是无效的，在与后台进行数据交互的时候用不了。如果你掌握了一门后端语言，不仅可以和后端同事更好地交流合作，还可以提升自己的编程能力，使自己的前端开发更合理、更有效，甚至可以写 API 调试自己的前端代码。

另外，技术栈是统一的，有时候可以前后互转，掌握一门后端语言，无可厚非可以使你的职业生涯更广阔一些。

我相信每个程序员，都不会仅仅满足于当下，可能希望成为一个全栈工程师，再到技术负责人，最终能够在一家企业成为 CTO 或者实现更大的目标。而如果你仅仅掌握前端技术，那么无论如何是无法实现这些目标的。

还有一方面就是从招聘信息可以得知，掌握一门后端语言，特别是 Node.js，已经成为一个加分项。在前端竞争如此激烈的今天，甚至可以说是一个必备技能。

Drawing 0.png
Drawing 1.png

这时你肯定会问，我可以学习其他应用更广的 Java 或者 Go，为什么要学 Node.js 呢？

因为前端同学对 JavaScript 甚是了解，而 Node.js 是运行在服务端的 JavaScript。因此从 Node.js 去学习服务端研发技术，是最合适的选择。

从自身经历来讲，我虽然也使用过其他后端语言，比如将 PHP 或者 C++ 作为服务端渲染以及后台服务，然而在这一过程中发现了一些问题。

PHP 处理高并发的能力比较一般，因为多进程非常损耗服务器资源；其次 PHP 作为服务端渲染在研发方面非常低效，前端代码需要融合 PHP 代码，而现在前端也淘汰了这类技术方案。
C++ 作为后台服务性能虽高，但是在研发效率上是比较低的，要不断进行编译调试，根本无法跟上运营与项目需求的进度。

而基于我对 Node.js 的了解，它的一些优点，比如高并发特性以及研发高效能正好可以解决这些问题，所以最终还是回归到 Node.js。

是什么阻碍了前端对于 Node.js 的进阶？

就目前来说，Node.js 应用较多的是前端工程化的部分，作为后台系统应用较少，而 Node.js 本就是后端的语言，如果只做工程化应用，会“大材小用”，没能应用到它的核心特性，没能真正发挥它的最大价值。

特别是在应对一些高并发系统上，因为比较缺乏这方面的实践知识，在出现各类问题后缺少专业人才来解决这些核心问题，团队领导层方面往往基于这层考虑，并不会将 Node.js 应用在核心业务上。

在一些实际场景中，有一部分前端人员也希望应用 Node.js 来做一些后端服务应用，但在应用过程中碰到了各种问题，并且苦于没有一些专业性的文章和指导方法，他们也就浅尝辄止了。

前端在学习 Node.js 后端服务应用的过程中，存在很多技术层面的空缺，这些都阻碍了 Node.js 在工程化应用到后端服务应用的转变。

1. 核心技术点的掌握不足

关于一些技术知识，我们一般会通过官网来进行学习，但是 Node.js 官网文档提供的是核心的 API ，并没有介绍在系统设计中的核心的技术点，特别是对于前端同学来说，官网的技术文档并不能满足 Node.js 应用开发的技术能力要求。

2. 关注点及流程、方法的不同

由于前端工程化和后端服务开发在关注点和流程上的差异，前端同学在学习后端服务应用的过程中，思维还是停留在原来的层面，不能一下子转变。

比如，作为后台服务的核心就是能够安全、稳定地提供服务，避免出现服务异常导致无法提供服务的问题。一旦出现这些问题，必然会影响大部分用户，恢复周期也比较长。而对于前端同学来说这点感知不深。

对于任何一端而言，性能分析和优化都是非常重要的环节，但是对于不同端性能的要求以及性能分析的方法都不同，那么如何从前端性能分析转化到 Node.js 服务端性能分析，这就是非常重要的一个技术点。

服务端研发的流程和方法与前端有着非常大的区别，前端主要基于 UI 和交互，而服务端则基于数据和数据流转。前端可以不绘制 UML 类图或者时序图，但是对于服务端研发流程来说是必需的。在这点上，前端更需要进行一些项目实践，重拾学过的知识点，才能掌握这部分技术能力的实际应用。

课程设计

鉴于以上情况，我希望通过一个系统化的课程来帮你快速掌握 Node.js 的后端服务开发，真正地应用 Node.js 来实现核心的后台业务系统。也因此，我会遵循这样几个设计思路：

紧抓核心技术点：Node.js 基础知识在官网文档中比较详细，我不会赘述，而是针对性介绍服务端开发实践中重点关注的性能、安全和稳定性等方面的知识点及解决方案。当然，这也是 Node.js 相应岗位面试着重关注的点，希望能帮你积累一些面试经验。
贴近项目应用场景：分别从系统的设计、研发到维护，进一步通过项目实践（通用的抢票系统和通用的投票系统），来强化你对 Node.js 服务端研发技术点和核心设计思想的掌握。

具体来讲，专栏分为核心知识点 + 技术应用分析 + 研发实战三大模块，合计 19 讲。

模块一，核心知识点篇：带你掌握 Node.js 服务端技术的核心知识，包括 Node.js 原理、 Node.js RESTful 服务实践、当前 3 大流行架构的对比、多进程方案、性能影响因素、CPU 过载保护方案、密集 I/O 设计思想，以及缓存的介绍和应用。
模块二，技术应用分析篇：在模块一的基础上，讲解和实践 Node.js 服务中最关键的几个要素，系统稳定、内存安全、网络安全和性能分析的解决方法。其次，本模块最后还会介绍一个开源工具，告诉你如何应用该工具来实现服务上线前自动化的系统安全检查。
模块三，系统研发实战篇：为了将本专栏的理论转化为实践，这部分则带你去实践开发一些 Node.js 服务端项目，进一步提升你对 Node.js 服务端技术的理解。本模块包含的实践项目有：RPC 服务实践、通用抢票系统、通用投票系统及当前最为流行的 Serverless。

讲师寄语

世界都在进步，为什么我在止步不前？

虽然这句话说得有点大了，但是想想，科技与技术都在不断推陈出新，那么作为程序员的我们，更不该停滞不前，未来注定会对我们要求更高。安于现状，不如持续更新自身知识结构，每次选择便是一次机会。

希望这门课，能够让你对 Node.js 的后端服务应用有一个全面的认识，从 Node.js 入门服务端研发，往全栈的方向更靠近一些，成为一名优秀的 Node.js 开发工程师。

精选评论

**6400：

太棒了，感觉node.js的学习，官方文档提供的帮助很有限；而真正用在企业内的项目又缺少系统化的教程。希望老师能注重企业和团队中的实战，并提供一个清晰的node.js学习和进阶路线

**杰：

开始学习

**鹏：

我感觉这门课程是目前网上能找到的最实用,但难度最高的课程,很想学,真的太难了

*浩：

希望学完以后我也能写个后台系统

*景：

收获很多

在前端工程师眼里，工程化最重要的就是 Webpack 工具，而 Webpack 核心是基于 Node.js 来运行的，当然还有其他场景比如说 SSR 的实现以及前端的一些工具化场景。这些应用最终目标都是为了提升前端研发效率或者保证研发质量，其实并没有真正地应用到 Node.js 核心特点，而后端服务应用才是真正地应用 Node.js 异步事件驱动的特性，那么本讲就着重来介绍两者存在的差异，并指导你进行一些转型思考。

由于 Node.js 的编程语言就是 JavaScript，因此很多前端同学用起来也是非常顺手，但是顺手和熟练应用区别可太大了。这有段小插曲，有一次我看到一份非常好的简历，精通 React、熟练应用 Node.js，看到这种简历着实让我心情很愉悦，心想终于找到一个对口的人才了。当小伙进来面试后，我问了一个问题，我说：“你主要用 Node.js 做了哪些事情，这些应用中，你觉得哪些场景真正发挥出了 Node.js 的特性”。他最终没有通过我的面试，其主要原因是只用了 Node.js 做一些工具或者简单的服务端应用，并没有真实地了解 Node.js 的特点以及所适用的场景，因此谈不上熟练应用 Node.js。如果你想在简历中带上，熟练应用 Node.js，那你可以带着这些问题来学习下本讲的知识点。

本讲将会从表格 1 的这几个方面来讲解这两者之间的区别。

运行环境

工程化的大部分情况都是基于当前开发环境，运行在本地开发机器上。
而后端服务应用一般运行在远程服务器上。

为什么这两者的差异会导致我们理解或者编程方面的区别呢？

这就好比，你是老板，你需要两个人来帮你分别做一件事情，一个就在你旁边，一个需要出差去其他地方。

在你旁边的，可以关注到他的效率、进展、是否情绪有问题、是否可能会离职，甚至知道他到底为你做了什么贡献价值。

那出差的就没有这么清晰了，所以你需要有一些方法和工具来分析这些问题，因此需要知道出差的地方办公环境或者团队协助是怎么样的，是否能够符合该员工的办公要求；有人反馈员工有问题时，我们还需要远程取证，判断这个举报或者反馈是否真实存在；其次你需要使用一些目标和策略来考证出差的员工是否按照你既定目标在办公，他的工作状态和工作效率是否达到了要求，或者是否超出了你的预期范围等等。

讲了上面的这个例子以后，我们再回过头来思考，Node.js 的服务其实也是一样的：

运行在本地的服务，你可以快速地判断定位、分析、解决问题；
但是在远程的服务，你需要利用一些工具来分析判断或者监控其运行情况。

那因为环境上的差异，会引发什么不同点呢：

首先我们需要应用工具将服务发布到远程机器上，这里就涉及devops 工具；
我们需要保证远程服务的安全与稳定，这就涉及一些进程管理工具，例如我们常见的 PM2；
我们需要判断远程服务运行是否正常，这就涉及远程服务的监控和告警机制；
遇到运行问题时，我们需要通过远程日志来定位分析问题，这就涉及日志打印和跟踪染色。

受众群体

前端工程化一般都是服务于开发者，比如我自己在本地应用 Webpack 打包或者将 ES6、ES7 转为 ES5 语法等，都是基于开发者工具，而这部分用户则是我们开发者自己。
而后端服务应用则服务于真实的用户群体，为用户提供各种交互体验方面的数据处理等。

因为两者的差异，工程化侧重于为开发者提升研发效率或者研发质量。

后端服务应用则必须关注服务的稳定与安全。因为都是基于用户发送的内容，用户有时候发送一些非法或者违法的内容。其次需要关注并发性能，因此必须充分考量服务器所能承载的最大用户并发数，在并发即将达到阈值时，又需要考量平行扩容方案。还有就是为了用户体验，需要充分做好服务的性能优化，做到极致的接口响应时间。

问题调试

因为前端工程化在本地运行，你可以随意地 console.log 打印日志进行调试，因为这些影响的也只是个人，或者说即使变成通用的工具，打印一些 console.log 也对工具的影响不大。
但是在后端服务应用时，你就需要考虑一些方法来进行问题调试和定位策略了。

你需要在每个业务场景中，思考在哪里进行一些关键逻辑或者数据打印日志信息，这里就需要 Node.js 日志服务模块，而这类日志服务又不能影响性能，因此需要考虑一些高性能日志打印工具。其次在服务端运行，你可能会遇到诸如内存泄漏、句柄泄漏或者进程异常退出等问题，因此这里就需要这类工具和方法来分析定位现网问题。

关注点

经过上面的各种对比，最后这点已经非常明确了，即两者的关注点不同，从而导致了两者的差异性。这也是需要你在学习 Node.js 的时候进行一些思维转变，切莫停留在前端工程化应用的角度去学习了，而应该全面地学习上面总结的知识点。只有上面的知识点掌握了，我们才能在简历上说，掌握 Node.js 的应用。

其次我们也来回答下上面的面试题，如果是我，我就会从本讲的两个方面去回答，一个是前端工程化的应用，另外一个是后端服务应用。前者着重于开发效率的提升和研发质量的保证，后者则是真正发挥出了 Node.js 的异步驱动特性。因为异步驱动特性，在主线程不被 CPU 密集型所影响时，可以真正发挥出 Node.js 高并发特性，可以作为大部分网络 I/O 较高的后端服务。

总结

上面讨论的这些差异点，是我们本专栏所需要重点介绍的知识，也是你从 Node.js 前端工程化应用扩展到系统化应用，所必须要掌握的技能点。学完本讲后，希望你能够从思维中有所转变，认识差异重新出发。

那除了我提到的关于两者的差异点，你觉得它们还有什么差异呢，欢迎在评论区与我分享。

下一讲我们就正式进入专栏内容了，第 01 讲我将为你讲解 Node.js 中最基础也是最核心的部分：事件循环的原理。

精选评论

**6400：

分析得很具体，作为服务千万用户产品的前端工程师，node.js使用也仅仅停留在2方面，一个是与wwbpack结合做工程化，另一个是开发脚手架提高研发效率。涉及到日志、监控相关的虽然使用，但研究不多。node.js使用不多主要有两个原因：第一是不知道node.js使用好能对业务有什么价值；第二是服务端相关的知识需要花时间梳理，但不知道哪些知识是最重要的，比如多线程多进程，阻塞非阻塞IO，CPU逻辑核数与进程数的关系