Heroku 负载均衡器与 Netflix zuul

Question

根据这个答案https://stackoverflow.com/a/41811770/2849613，我想了解更多有关 Heroku 微服务最佳实践的信息。

问题是哪种方法更好？

1. 将每个服务安装为独立的应用程序，并将其中一个服务用作 REST“代理”（例如 Netflix Eureka）？

或者

1. 创建基于 docker 的方法，例如 Netflix Zuul 作为负载平衡器？

就我自己而言，我已经看到了这两种方法的一些优缺点：

1. 优点：更好的可扩展性（易于为更大的负载创建新机器）。 缺点：服务之间的通信“在 heroku 之外”，换句话说：因为 heroku 应用程序有公共地址，每个人都可以直接连接到服务（而不用扔 Eureka），因为每个服务都需要提供一些身份验证方法并在彼此之间共享 - 我认为这很容易发生风险。

2. 优点：易于重现生产环境以进行测试和开发（docker 映像），服务之间的通信是“内部”完成的（映像到映像而不是应用到应用）。 缺点：难以扩展（我认为 Heroku 应用程序和 docker 图像之间的负载平衡有点开销）。

哪种方法更好？也许我可以把它们混合在一起？或者也许有一些不同的更好的解决方案？

说实话，我唯一确定的是，我想使用 rabbitMQ 作为消息队列...

Answer 1

我更喜欢方法 #1（尤其是因为我知道您已经在使用 Heroku）。

Docker 很棒，但是如果您在 Heroku 上进行部署，那么好处非常有限。原因是 Heroku 已经完成了 docker 所做的一切：管理依赖项、安装和进程管理。 Heroku 已经为您完成了所有这些工作，而无需对您的环境进行 Docker 化的额外工作。

关于负载平衡：实际上并不重要。在这两种情况下，如果您想在 Heroku 上运行，您将使用 Heroku 负载均衡器。这是因为没有办法“绕过” Heroku 堆栈的那一层。

如果你想使用 Docker / zuul，你肯定需要在 Heroku 之外进行。这意味着你需要做各种其他的事情，找到一个 docker 主机，管理你自己的基础设施等等。

所以，在我看来，#1 是更好的选择（如果您使用 Heroku），因为：

1. 一切都已经为您处理好了。
2. 您可以专注于编写可扩展的代码，而不是管理各种其他事情。
3. 您的所有服务都将位于同一个 AWS 区域中，因此即使它们通过 HTTPs 相互通信，速度也会非常快。