假设我们有S1、S2子图和G网关。
S1子图服务需要来自S2服务的一些数据。应该如何通过网关和模式级别来处理它？我们应该在这种通信中使用网关吗？
我们应该有一个单独的模式&Apollo服务器在每个包含内部查询和突变的子图中？如果CCD_ 6直接呼叫CCD_；内部apollo服务器"；？
默认情况下，所有面向用户的请求都需要JWT授权，但内部通信应该在没有授权的情况下工作。
子图在公共网络上不可用，但它们在同一个内部网络上运行。从技术上讲，他们可以看到对方。他们在GKE上主持。
这其实是我最喜欢的话题之一！一开始，和往常一样，答案是，这取决于。抛开这些，让我们来了解一些细节。。。
需要关注的主要变量是，根据您需要的子图数量，您的系统需要以多快的速度进行扩展。以下是一些具有不同复杂程度和实施工作量的解决方案。
呼叫网关
对于一些服务，比如您的示例2，您可以很容易地从任一服务调用网关。这具有易于实现的优点，对于只有10个子图或通常稀疏的数据的较小公司来说，这是一种使用联邦的好方法。这种方法有明显的缺点：
-
每跳为1。重新授权和2。增加了往返行程的延迟。在非常大的微服务环境中(比如谷歌、脸书、奈飞等)，这可能会成为问题，因为一些功能可能有10-20个服务的垂直调用堆栈，并且所有这些都需要在200毫秒内解决，以满足SLO要求。如果在每一跳都需要执行一次到网关的往返旅行，包括授权和加密，这将是一个交易破坏者。如果没有任何用户隐私问题，许多服务甚至不进行服务间加密。
-
您需要小心循环依赖关系。网关将不知道内部服务正在进行呼叫，而只是像往常一样完成请求。如果你是一个小团队，这听起来很容易，但随着事情的发展，你最终可能会依赖S1->S2->S3->S4->S5->S1甚至没有意识到它，并且它可能在小的边缘情况下爬行，并且很难调试。循环依赖关系在大型系统中总是一个潜在的问题，但如果不深入了解每个查询的整个调用树，使用网关就很难发现。
-
您将被限制为与客户端具有相同的视图字段。使用这种方法，服务无法在内部提供对执行某些操作有用的附加信息。这可能类似于库存，您可能不希望用户能够查询。
需要注意的是，这些问题中的大多数在中等规模左右才开始成为交易破坏者，因此在决定反对这种方法之前，评估您的需求是值得的。
直接调用子图
如果子图是用适当的基于关注的分离来设计的，那么你需要的信息应该可以从子图中获得，而不需要网关来解析额外的字段。这解决了直接调用网关的延迟问题，并使管理依赖关系图变得更容易。它不能解决上面讨论的视野问题。这是我个人所做的，但这似乎是一个有点争议的模式。
注意：您提到GKE中的所有内容都在运行。你可以使用集群本地dns来访问服务，但我强烈建议研究服务网格来解决子图之间的路由问题。Istio、Nginx Service Mesh和LinkerD是需要考虑的几个选项。
使用内部背板
随着系统的不断发展，将超图视为产品的后端变得越来越重要。产品的内部设计可能不会只使用graphql。如果能解决他们经常遇到的问题，大公司甚至会开发整个独立的内部平台。在这个例子中，这些系统可能不需要添加到超级图中。这与您使用"；内部apollo服务器"；，但我真诚地建议只使用REST或gRPC。为了保持微服务架构的精神，您甚至可以让主服务使用gRPC，并且向网关注册的子图将只是gRPC服务器的视图层。