我觉得, 如果每个微服务都设计合理, 那么直接调用B会被拒绝的话,那间接调用B也应该被拒绝. 但是也不绝对, 毕竟系统刚开始设计的内容与后面增加的内容无法预料, 很有可能导致你说的这种情况, 实际问题实际分析

在微服务架构中，gRPC服务之间的通信是否需要授权取决于你的安全需求和设计决策。以下是一些建议：

服务内部通信：
如果A服务和B服务是同一组织内的内部服务，可以考虑不使用授权机制。在这种情况下，服务之间的通信被认为是信任的，因为它们属于同一组织。在gRPC服务内部通信时，可以省略授权验证，以减轻开发和运维的复杂性。

服务之间的授权：
如果A服务和B服务不属于同一组织，或者存在安全隐患，建议使用授权机制确保服务之间的通信是受保护的。可以考虑使用gRPC提供的认证和授权机制，例如使用TLS/SSL进行加密和身份验证，以及使用gRPC的认证和授权拦截器来实现更精细的访问控制。

服务代理：
另一种方法是通过在微服务架构中引入API网关或服务代理来处理授权。API网关可以负责验证用户的身份和权限，并在服务之间转发请求。这种方式将授权的逻辑集中在一个地方，减轻了每个服务的负担。

JWT令牌：
在微服务架构中，使用JWT（JSON Web Token）作为身份验证和授权的机制也是一种常见的选择。通过在gRPC的元数据中传递JWT令牌，可以在服务之间进行认证和授权。

最终，决定是否在gRPC服务之间使用授权取决于你的具体需求和安全策略。如果服务之间的通信是受信任的，可能不需要复杂的授权机制。但如果你需要更细粒度的访问控制或者服务不属于同一组织，考虑引入授权机制是一个明智的选择。

终极方案：ESB

一般来说服务都是通过网关提供对外访问的端口a，这样客户端访问微服务就要走网关，就需要鉴权，微服务之间访问通过etcd/consul服务注册来获取对方地址和实际端口，不需要鉴权