0

我们使用nomad将我们的应用程序（提供gRPC端点）部署为任务。然后使用nomad 的 service stanza将任务注册到Consul。

我们的应用程序的路由是通过envoy proxy实现的。我们在 IP 上运行负载均衡的中央特使实例10.1.2.2。

路由到哪个端点/任务的决定当前基于host标头，并且每个任务都注册为<$JOB>.our.cloud. 这导致了两个问题。

  1. 访问服务时，必须为负载均衡器 IP 注册 DNS 名称，这会导致/etc/hosts类似的条目

    10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud

    使用 可以部分缓解这个问题dnsmasq，但是当我们添加新服务时仍然有点烦人。

  2. 不可能同时运行多个提供相同 gRPC 服务的服务。例如，如果我们决定测试一个服务的新实现，我们需要以job相同的名称以相同的名称运行它，并且需要实现在 gRPC 服务文件中定义的所有服务。

我们一直在讨论的一个可能的解决方案是使用tags该service节的 来添加定义提供的 gRPC 服务的标签，例如：

service {
  tags = ["grpc-my.company.firstpackage/ServiceA", "grpc-my.company.secondpackage/ServiceB"]
}

但是Consul不鼓励这样做：

Dots are not supported because Consul internally uses them to delimit service tags.

现在我们正在考虑使用像这样的标签来做这件事grpc-my-company-firstpackage__ServiceA......这看起来真的很恶心，虽然:-(

所以我的问题是：

  • 有没有人做过这样的事情？
  • 如果是这样，关于如何路由到由 Consul 自动发现的 gRPC 服务有什么建议？
  • 有人对此有其他想法或见解吗？
  • 这是如何在例如istio中完成的？
4

2 回答 2

1

我认为这是 Istio 完全受支持的用例。Istio 将通过 Consul 帮助您进行服务发现，您可以使用路由规则来指定哪个部署将提供服务。您可以从https://istio.io/docs/tasks/traffic-management/开始探索

于 2018-03-22T22:14:44.240 回答
0

我们使用我们自己的产品 Turbine Labs 做类似的事情。

我们的堆栈略有不同，但想法是：

  • 将服务发现信息拉入我们的控制平面。（我们使用Kubernetes，但支持Consul）。
  • 按服务和版本组织此服务发现信息。我们使用tbn_cluster, stage, and version（就像这里）。

由于version对我们来说是发行版的 SHA，因此我们没有格式问题。此外，它们不必是唯一的，因为tbn_cluster标签定义了层次结构的第一级。

一旦我们有了这些，我们使用 UI / API 来定义所有的路由（例如app.turbinelabs.io/stats-> stats_service）。这些规则包括标签，所以当我们部署新版本（部署！=发布）时，没有流量被路由到它。发布是通过更新规则来完成的。

（对于“将 10% 的流量释放到新版本”的常见情况，甚至还有一些不错的 UI 功能可以更新这些规则，比如滑块！）

希望这会有所帮助！您可以查看 LearnEnvoy.io - 很多关于 Envoy 的教程和最佳实践。有关服务发现集成和增量蓝/绿版本的文章可能会有所帮助。

于 2018-03-26T20:56:29.953 回答