我们使用nomad部署我们的应用程序（提供gRPC个端点）作为任务。然后使用Consul将任务注册到nomad's service stanza。
我们的应用程序的路由是通过envoy proxy实现的。我们正在IP 10.1.2.2运行负载均衡的中央特使实例。
要路由的端点/任务当前基于host标头的决定，并且每个任务都在<$JOB>.our.cloud下注册为服务。这导致了两个问题。
访问服务时，必须为负载均衡器IP注册DNS名称，这会导致/etc/hosts条目，如
10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud
使用dnsmasq可以部分缓解此问题，但在添加新服务时仍然有点烦人
不可能同时运行多个提供相同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这样的标签来做这件事......但这看起来真的很恶心： - （
所以我的问题是：
答案 0 :(得分：1)
我认为这是Istio完全支持的用例。 Istio将帮助您使用Consul进行服务发现，您可以使用路由规则来指定将提供服务的部署。您可以从https://istio.io/docs/tasks/traffic-management/
开始探索答案 1 :(得分：0)
我们使用自己的产品Turbine Labs做类似的事情。
我们的筹码略有不同，但想法是：
tbn_cluster，stage和version（例如here）。由于version对我们而言是版本的SHA，因此我们不会遇到格式问题。此外，它们不必是唯一的，因为tbn_cluster标记定义了层次结构的第一级。
一旦我们有了这些，我们使用UI / API来定义所有路线（例如app.turbinelabs.io/stats - ＆gt; stats_service）。这些规则包括标记，因此当我们部署新版本（deploy != release）时，不会将流量路由到它。通过更新规则来完成发布。
（甚至还有一些不错的UI功能，用于更新这些规则以及＃34;将10％的流量释放到新版本，＆＃34;像滑块一样！）
希望这有帮助！您可以查看LearnEnvoy.io - 关于什么适用于Envoy的许多教程和最佳实践。 Service Discovery Integration和Incremental Blue/Green Releases上的文章可能会有所帮助。