我有一种复杂的体系结构，涉及5个不同的应用程序：
所有这些应用程序实际上都托pipe在单个专用服务器上，并在Node.js中运行
我想推动我的架构在亚马逊AWS云，但我仍然质疑我自己想要build立的新架构。
是否需要拆分我的应用程序并为每个应用程序运行一个EC2实例（并且可能为每个应用程序组configuration一个负载平衡器），还是可以在一个实例中运行所有应用程序，并在其上使用单个负载平衡器。
我希望我可以更精确，但我不习惯缩放技术。
雨果。
假设你不关心高可用性，如果一个实例可以处理负载，那么把它们全部放在一个实例上。 也就是说，我会对这些特定的服务进行一些监控，以便知道何时有他们自己的主机。 您可能会发现不同的服务将需要以不同的价格向外扩展。 保持密切关注的唯一好方法是使用良好的监测和仪器。
稍后通过引入服务之间的抽象，可以节省很多头痛的时间。 例如，确保当一个服务调用API时，它通过某个名称（DNS对此很好）进行调用。 就像api.myapp.com会没事的。 也许最初，所有的名字都指向同一个主机。 但是在将来，当您需要扩展时，您可以将该名称指向一个弹性负载均衡器，后面有一堆实例，应用程序中的任何内容都不需要更改为与新实例交谈。
如果您担心高可用性，则需要多个盒子。 句号
根据上面提供的信息，如果要将它们保存在一个盒子上，我build议将对方的服务进行分区或抽象化。 作为一个系统pipe理员，我不build议依赖整个体系结构的一个盒子，但是如果你不关心高可用性，并且你有一个合适的备份解决scheme来保存你希望保留的任何数据失败，然后继续（即使你分发你的架构每个服务一盒，你应该仍然是备份你的数据和configuration！）
但是，如果您愿意将您的服务分散到多个EC2实例上（这将有助于提高可伸缩性），请记住使用DNS名称或EC2弹性IP地址，因为这些框的内部IP地址可能会更改。 由于内部IP地址之间的stream量比较便宜，如果您将要使用大量的组件间stream量，则可能需要使用这些dynamicDNS进行调查。
请记住，如果您需要在某个阶段针对每个服务扩展一个实例，那么您的devise应该考虑将来可能使用的AWS Elastic Load Balancer和Auto Scaling。
如果您需要您的首席执行官能够迅速启动一个新的堆栈，以防出现问题，我build议您调查AWS的Cloud Formation服务。 这使您可以使用JSONconfiguration文件来定义由多个AWS资源组成的堆栈，并以最less的交互启动和终止您的服务。