Heroku 负载均衡器与 Netflix zuul

Question

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

问题是哪种方法更好？

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

或者

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

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

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

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

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

老实说，我唯一确定的是，我想将rabbitMQ用作消息队列......

Answer 1

我更喜欢方法#1(特别是因为我知道你已经在使用 Heroku)。

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

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

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

所以，在我看来，#1 是一个更好的选择(如果你使用 Heroku)，因为:

一切都已经为您处理好了。

您可以专注于编写可扩展的代码，而不是管理各种其他事情。

您的所有服务都将位于同一个 AWS 区域，因此即使它们通过 HTTPs 相互通信，它也会非常快。