大型NodeJS应用程序独特的潜在复杂性/问题是什么？
我来自“传统的Web应用程序”背景：认为Java，.NET，PHP，ColdFusion等
在评估NodeJS作为非平凡应用程序的主要服务器端技术时，我想知道开发人员和操作人员可能期望面对哪些NodeJS特有的复杂性，问题和挑战。 总之，我想减less我的未知数。 一些（不是全部）例子：
- 它如何适应大型团队的发展？ 对于Node，在20或50或200个开发人员团队中存在哪些独特的挑战？
- 数据库访问存在哪些独特的挑战？ “Enterprisey”的数据访问问题在Java（连接池，安全性等通过Spring）中大部分都是处理的。 这是节点的情况吗？
- 报表繁重的应用程序通常需要Excel，PDF，甚至是PNG导出…节点如何在这种types的应用程序中运行？
- Node是否在开发时debugging方面提出任何独特的挑战？
- 存在哪些独特的运营挑战？ 从服务器重启/热代码交换/负载平衡到监视和pipe理生产群集的工具。
等等。 在开发，维护和生产pipe理100 + K LoC代码库方面存在哪些经验教训？
我会尽量回答你的一些问题
它如何适应大型团队的发展？ 对于Node，在20或50或200个开发人员团队中存在哪些独特的挑战？
- 和其他语言一样，它也是这样; 没有！ 程序员团队通常使用git，svn，mercurial等版本控制系统来处理在同一个文件上工作的同事
数据库访问存在哪些独特的挑战？ “Enterprisey”的数据访问问题在Java（连接池，安全等等，通过Spring）中大部分都被处理。 这是节点的情况吗？
- 节点是数据库不可知的。 您可以使用任何数据库与驱动程序/包装存在的节点（与PHP相同）。 关系数据库（MySQL，SQLite）和NoSQL（MongoDB）有许多驱动程序/包装器，
报表繁重的应用程序通常需要Excel，PDF，甚至是PNG导出…节点如何在这种types的应用程序中运行？
- Node可以像php和其他一样访问正常的shell。 所以如果你用php处理图像，你使用ImageMagick或GD的包装。 GD需要安装在WebServer上才能工作，因为PHP将命令下发到命令行。 与节点相同; find一个包装（http://search.npmjs.org）并使用你想要的function。
Node是否在开发时debugging方面提出任何独特的挑战？
- 节点是Javascript，所以它不编译，但没有JIT。 所以只有在执行失败时才会被检测到。 你需要一个本地环境，让每个开发者在你的staging / dev机器和活动服务器旁边，这样他们可以在将代码提交到登台服务器之前testing代码
存在哪些独特的运营挑战？ 从服务器重启/热代码交换/负载平衡到监视和pipe理生产群集的工具。
- 没有“独特的”挑战，我知道。 你会像所有其他语言一样处理监视/心跳（是的，有这样的语言，像Erlang）。 你需要像永远或supervisord服务启动服务器重新启动节点，但这与Apache + PHP / Perl相同。
- （节点有一个集群模块，可以帮助你处理多个工作者（对于多核服务器））
看看Git来pipe理你的代码。 并根据你想要做什么select语言（高并发性，可伸缩性）
我将评论我所认定的事情：
-
连接池到数据源。 标准的节点HTTP（S）服务器工具默认实现池化，并且可以configuration旋钮来改进或控制性能。 社区非常活跃，还有很多其他项目（如poolee ）实施通用或专业连接池。 你将需要环顾四周。 事实上，鉴于您的传统Webdev背景…
1.1 附注：第三方库在使用Node进行开发时，您可能会发现自己使用了许多第三方库。 取决于你的特定背景，这可能看起来很奇怪。 要理解为什么，考虑.NET或Java：这些平台的标准库是庞大的 。 因此，在使用这些平台时，您可能会select很less的第三方工具或插件来帮助您完成工作。 节点，比较而言，有一个有意识的狭窄和严格控制的标准库。 为了服务器性能的利益，所有必要的API将“事情的写法”统一起来，但没有更多。
为了帮助pipe理第三方库，
npm包pipe理器被很早的devise和包含在节点中。 这是众所周知的高品质。 作者显然期待了很多第三方的使用。 -
计算能力您提到的图像导出。 所有这些东西都存在Javascript库，所以就“可以轻松完成”而言，它可以。 请记住，如果你有一个计算繁重的任务，JavaScript可能不是实现核心计算最有效的语言。 如果需要的话，v8引擎允许你用C编写模块，但是将请求转发到专门的后端服务器是Node非常好的事情。
-
操作挑战 Node.js不会扩展到您的硬件。 如果您的服务器具有多个内核（到目前为止确实如此），则需要在同一物理硬件上运行多个服务器进程以实现高利用率。 这可能会使操作有所不同：比您通常看到的更多的进程，这些进程可以通过物理或虚拟机进行分组。
顺便说一句，将服务器分解为进程并不是一件可靠的事情：一个大型的传统进程会在一个未处理的exception上崩溃，同时会占用八个（或者其他）核心活动会话。 多个节点进程仍将单独崩溃，但影响比例较小。 考虑到性能和监控能力，可能有探索“多less进程太多”的空间。 实际上，每个服务器使用更多的节点进程可能比有可用的内核更值得。