Linux 为什么不在一个Amazon EC2实例上运行Node.js和Neo4j呢

我将在Amazon上建立一个服务器架构。我不熟悉最佳实践，而且在学习的过程中也学到了很多东西

我的老板让我启动一个Amazon EC2实例，在同一个实例上运行Node.js和Neo4j（图形数据库）。两者都应该使用不同数量的可用CPU。随着应用程序越来越大，需要更多的资源，我们只需克隆实例。我的老板也没有这方面的经验

我必须说，我对将Node.js和Neo4j放在一个实例/机器上感觉不好。我想我会使用AmazonLinuxHVM发行版，因为他们已经将其设置为可以很好地使用他们的服务。遗憾的是，官方并不支持Neo4j，而是支持apt（AmazonLinux基于Ubuntu，使用yum而不是apt）。因此，Neo4j建议使用Debian/Ubuntu来运行他们的数据库

为什么将Node.js和Neo4j放在一个实例上不是一个好主意

---

我可以想象的一个原因是，可伸缩性不再像运行每个服务的两个独立实例那样动态

可伸缩性可能是主要原因。我认为这里的“node.js”是指使用node.js编写的应用程序。在运行neo4j的同一台机器上安装node.js包本身没有问题

请注意，部署neo4j的一个好方法是将其作为服务器，让应用程序与该服务器通信。当然，它们可能在同一个虚拟机上，但这会带来一些复杂性：

• 虚拟机上的安全/防火墙设置必须更加复杂，以考虑两者共存的所有方面
• 内存/磁盘配置必须足以满足这两种需求。若你们的应用程序需要增长，那个么当neo4j占用了大量内存并且并没有为你们的节点应用程序留下太多内存时会发生什么，反之亦然

通过将它们拆分为两个单独的虚拟机，您可以分别对它们进行性能调优，以确保其中运行的一件事情运行得非常好。稍后，如果您需要HA集群，可以将单个neo4j虚拟机作为HA集群的前端，node.js应用程序可以继续使用服务器，就好像什么都没有改变一样。因此，可伸缩性带来了好处

---

在安全和网络配置上，将它们拆分为两个虚拟机意味着您必须考虑如何在第一次正确配置它们。你不希望任何人都能连接到你的neo4j数据库，你只希望你的应用程序能做到这一点

根本问题是运行数据库的计算机和运行代码的计算机有不同的需求

Node.js代码：您的代码是无状态的（意味着它本身不包含任何数据）。它的所有状态都存储在数据库中。如果出现问题，你可以重新启动机器，或者杀死它，让一台新的相同的机器运行相同的代码，没有人能分辨出区别。如果您以后需要更多的可伸缩性，您可以将代码作为服务移动到平台上，如AWS Elastic Beanstalk或Heroku，它将为您管理所有这些。把它指向你的数据库

---

数据库：需要持久性和持久性。如果重新启动它，整个应用程序将在整个过程中关闭。如果它被破坏，您将丢失所有数据。虽然Neo4j有一个高可用性软件包，可以帮助您管理其中一些/将风险分散到多台计算机上，但听起来您不可能很快做到这一点。设置数据库计算机并且不触摸它（更新node.js代码）将减少任何事情出错的可能性。当您移植到高可用性时，它将使这种转换更加无缝，因为您不必寻找新的地方来托管代码

谢谢你的解释。这些观点对我来说很有意义。通过将这两个实例拆分为两个实例，我可以有一个安全规则，规定只允许我节点实例的IP连接到neo4j实例。然后，您可以自由扩展neo4j数据库，而不影响对AppInsight的任何依赖性。我还没有考虑更新Node.js，也没有考虑弹性Beanstalk。当我提到更新Node.js代码时，我指的是框架（尽管这也很重要），我指的是更新代码本身。假设是手动完成的，则每次进行更改时都需要复制代码并重复重新启动node.js服务器（平台即服务解决了这一问题）。您可能不想在更复杂的数据库服务器上进行sshing并不断重新启动程序。如果这回答了您的问题，请接受答案。