如何扩展复杂的node.js应用程序

Question

想象一下，一个大型的node.js应用程序，有一个多用途的移动api，前端有一个服务的静态文件，一个websocket服务器，大量的cron作业和工人。基本上，我可以水平或垂直缩放整个应用程序，使用负载均衡器等。

但从业务逻辑的角度来看，整个应用程序是一个大的“包”，其中一些部分比其他部分使用得更多，而一些部分对应用程序性能的影响比另一部分更大。例如，移动API可能比一些每小时启动一次的cron多使用100倍来进行一些清理。那么，是否有必要对整个应用程序进行缩放？

它不是更好的比例应用程序分开的模块和规模，只需要？例如

• 移动api
• 权贵和工人
• websocket
• 不管什么..。

如果是，那么处理业务逻辑的正确方法是什么？在应用程序的每个子模块中都需要代码的一部分，例如数据库模型、迁移(种子器？)，也许我需要一些通用功能，比如一些特定的实用程序函数或枚举定义。因此，我可以为它们创建git子模块，但是使用2-4 git子模块处理4-6个git存储库和在多个环境中处理整个应用程序(开发、阶段、uat、prod)是有风险的。对这种方法是否还有其他的注意事项？还是不能用？

我潜入互联网的水域，搜索一些资源，比如node.js最佳实践、缩放node.js、缩放node.js、良好的定标实践，但它并没有完全回答我的所有问题。

Answer 1

正如在最近的O‘Reilly软件架构会议讨论中所指出的那样，拆分服务比加入服务容易。因此，尽管您提出了可能指示微服务体系结构的独立扩展的问题，但是您也可能从错误的一方("monolith")或少量的服务开始时受益。如果您从多个服务开始，您将有数据管理、消息传递和服务编排的开销(Kubernetes?)否则你就不会和独角兽在一起。

如果您确实分解了服务，那么您的“移动api”列表.“看上去是个好开始。以“有界上下文”来自领域驱动设计为例。

你在考虑什么数据库(S)？您能接受普通SQL数据库(即CA或CP in 帽子)的性能吗？如果是这样的话，那是一条简单而辉煌的道路。如果您选择这条路线，您将不会真正受益于微服务，因为您的服务无论如何都共享一个数据库。相反，如果您可以容忍最终的一致性(来自CAP的AP)，从而选择使用一个通用的分布式NoSQL数据库(例如Cassandra)，那么它更适合于一个微服务体系结构，每个服务负责自己的数据(例如Cassandra )，并且您可以使用一个消息层(例如Kafka )来跨服务通信状态更改。分布式数据库通常更难管理，而且(由于消息传递和反规范化)也更难为其编写服务。这对你有关系吗？

关于共享库，这无疑是减少跨服务实现工作量的一种尝试和真实的方法。拥有npm模块，可能是回购，每个库是一个好主意。

从实用主义的角度来看，要开始这一切，有几个想法:你可以尝试一个独角兽，你可以理解，为了扩大规模，你以后可能不得不把它分开。或者，您可以尝试使用类似于2种非常简单的服务，并尝试遵循microservices模式，并在提交之前查看您如何喜欢它。如何选择？第一种可能会让你更快地找到一个演示。从长远来看，第二种方法可能会节省您的时间--如果您对如何分解您的服务做出了一个很好的决定(这并不是一件简单的事情)。第一个可能是较低的风险。

Answer 2

我相信没有一个正确的答案适用于每一种情况，而且你在这里没有足够的信息让别人给你一个完整的答案，但我能给你的是一种思考你的问题的方式，希望它能帮助你回答你自己的问题。

首先，您需要查看您的单块项目，并确定其中哪些部分作为应用程序实际上更好，哪些部分作为库更好。

我这么说是什么意思？好吧，一个应用程序可以被你合理地想象成独立运行的东西，做某种“工作”。也许这个“作业”是监听和响应网络事件(例如REST请求)。也许这个“任务”是监视时钟并执行一些工作(例如，定期重新索引数据库或处理电子邮件通知的cron作业)。

相反，库是希望允许多个应用程序重用的代码块。这可能是您的业务逻辑、验证逻辑、安全框架等。

这些“东西”，无论是应用程序还是库，都应该作为节点模块进行版本化，并存储在它们自己的git存储库中，并在每次发布想要采用的版本时发布到公司的工件存储库中(例如，工件工厂，或者您自己托管的NPM，或者公共NPM (如果您正在打开源代码)。

因此，您的库通过您的package.json在应用程序(或概念上，在其他库中)中引用，并在使用npm基础结构时绘制。相反，您的应用程序是作为包构建和部署的，这些包在某个地方成为正在运行的进程，可能作为单独的坞容器，或者在Linux盒上使用systemd等等。

那么，随着您的扩展，您实际上只是根据应用程序被使用的数量水平地复制它们。同样，对每个人来说，什么才是合适的“大小”，这实际上是一种艺术，而不是科学，但经验法则是使其尽可能小，而不是变小。