我有一个通用Java微服务（"DB服务"）的ReplicaSet，它可以基于元数据与任何JDBC数据库接口。当一个上游微服务调用这个DB微服务时，它将分配一个JDBC连接池。假设数据库DBA给了我50个连接，让我为一个特定的用例（我的系统可以 "执行 "一些元数据部署单元）工作。
我想让两个DB副本在本地连接池中各创建25个连接（最大2个）。因此，上游微服务现在应该只将调用路由到这两个副本，这两个副本现在包含这两个连接池，同时绕过其他没有创建任何连接的X个DB副本。
如果上游微服务为这个用例添加了一个唯一的HTTP头（"StatefulRoute=ConnectionName"），是否可以欺骗K8s和Istio将请求路由到DB复制的子集，这些子集已经为这个用例创建了这些本地JDBC连接池？
请注意，随着时间的推移，用户可以通过部署许多其他用例，每个用例也可能需要JDBC连接。这些用例应该基于对已经繁忙的DB复制体的Readiness检查，将其扩散到其他DB复制体。
我设想了一个额外的资源管理器微服务(conductor)，每个DB副本都会与之交互，询问1)我能否为这个请求分配一个连接池，2)我可以分配多少个连接。
当第一个（未初始化的）DB副本收到一个新请求（尚未建立路由）时，它将与资源管理器进行交互。这个管理器则应该 动态 配置K8s Istio(REST调用?)，从此将请求(针对特定用例)路由到这个副本。
资源管理器将是一个Singleton，或者如果它成为一个瓶颈，则是一个ReplicaSet，使用分布式缓存来跟踪 "连接池授予"。如果它的连接用完了，它会ping DB复制体，这些复制体已经有一段时间没有发送心跳了（可能被K8s重启了）。如果它发现有一个副本没有响应，它就会根据剩余的可用连接数（在数据库侧），允许一个新的新鲜副本分配一个连接池。
如果之前初始化的所有副本都还活着，并且在为请求服务（因此最大的物理db连接也因此在使用），管理器将拒绝连接请求，然后请求的db副本将返回一个错误（"没有更多的连接可用来服务请求"）给上游微服务。
有人面对过这个需求吗？
这不是用户会话亲和力，通常涉及到入口。这涉及到集群内部两个微服务之间的亲和性。
谢谢。
如果你想配置istio流量路由，有几个链接可以遵循。
对于开始，我会看一下 书籍信息示例它的安装非常简单，你可以在上面试试你的设置。
然后按照这个istio文档介绍 请求路由它解释了如何使你的虚拟服务和目标规则来匹配正确的子集的荚。
如上所述，它解释了如何使你的虚拟服务和目的地规则匹配正确的子集。此处 和 此处在这里，我们可以学习如何添加你的头，这将是用来路由流量到适当的版本的pod。
看看这个例子
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
...
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
所以我们有3个子集的审核部署，分别是v1、v2和v3，以及对它们的服务。你可以看这里 如何 它的建立，每一个审查部署都有一个应用程序和版本标签，我们可以在我们的虚拟服务和目标规则中使用。
kubectl get pods
reviews-v1-874083890-f0qf0 2/2 Running 0 6m
reviews-v2-1343845940-b34q5 2/2 Running 0 6m
reviews-v3-1813607990-8ch52 2/2 Running 0 6m
kubectl get services
reviews 10.0.0.170 <none> 9080/TCP 6m
如上图所示，在上面的虚拟服务中，如果有一个用户的终端用户名是jason，那么它就会把所有的流量发送到v2，如果没有，那么默认情况下，它会把所有的流量发送到v1。