我有一种涉及 5 种不同应用程序的复杂架构：
- 1 API
- 1 前板
- 1 个仪表板
- 1 管理面板
- 1 个公共文件托管应用程序
所有这些应用程序实际上都托管在单个专用服务器上并在 Node.js 中运行
我想在 Amazon AWS 云中推动我的架构，但我仍然在质疑自己想要建立的新架构。
我是否需要拆分我的应用程序并为每个应用程序运行一个 EC2 实例（并且可能为每个应用程序组运行 1 个负载均衡器）或者我是否可以在一个实例中运行所有应用程序并在其上使用单个负载均衡器。
我希望我可以更精确，但我不习惯缩放技术。
雨果。
答案1
假设您不关心高可用性，如果一个实例可以处理负载，那么将它们全部放在一个实例上。也就是说，我会对这些特定服务进行一些监控，以便您知道它们何时需要拥有自己的主机。您可能会发现不同的服务需要以不同的速率扩展。关注这一点的唯一好方法是使用良好的监控和检测。
通过在服务之间引入一些抽象，您可以省去很多麻烦。例如，确保当一个服务调用 API 时，它会通过某个名称调用它（DNS 非常适合这种情况）。像 api.myapp.com 这样的名字就可以了。也许最初，所有名称都指向同一主机。但将来，当您需要扩展时，您可以将该名称指向一个 Elastic Load Balancer，其背后有一堆实例，并且您的应用程序中无需进行任何更改即可与新实例通信。
如果您关心高可用性，则需要多个盒子。句号。
答案2
根据您上面提供的信息，如果您要将服务放在一个盒子里，我建议将它们彼此区分开或抽象化。作为系统管理员，我不愿意建议将整个架构都放在一个盒子里，但如果您不关心高可用性，并且已经为希望在发生故障时保留的任何数据制定了合适的备份解决方案，那么请继续（即使您将架构分布为每项服务一个盒子，您仍然应该备份数据和配置！）
但是，如果您愿意将服务分布在多个 EC2 实例上（这将有助于以后的可扩展性），请记住使用 DNS 名称或 EC2 弹性 IP 地址，因为盒子的内部 IP 地址可能会发生变化。但是，由于内部 IP 地址之间的流量更便宜，如果您将有大量组件间流量，您可能需要研究使用这些和动态 DNS。
还请记住，如果您需要在某个阶段扩展每个服务的单个实例，那么您的设计应该考虑到未来可能使用 AWS 的弹性负载均衡器和自动扩展。
如果您需要您的 CEO 在出现问题时能够快速启动新堆栈，我建议您研究一下 AWS 的 Cloud Formation 服务。这允许您使用 JSON 配置文件定义由多个 AWS 资源组成的堆栈，并以最少的交互启动和终止您的服务。