在服务网格架构中，从服务 A 到服务 B 的调用必须通过中央组件进行？
假设我们有以下设置：
Service A 由 Kubernetes 集群中的一个 pod 组成，其中包含两个容器 Api A 和 Sidecar A 。 Api A通过Sidecar A与外界进行通信。 Sidecar A 已注册为消费者。
服务 B 由 Kubernetes 集群中的一个 pod 组成，其中包含两个容器 Api B 和 Sidecar B。 Api B通过Sidecar B与外界通信。 Sidecar B 已注册为生产者。
服务 A 和服务 B 可能有多个实例。
服务通过中央机构向服务网格注册自己，我们称之为服务发现，它了解每个服务的特定实例及其公开的端点。 服务 A 还可以通过此服务发现中央机构订阅服务 B 的特定端点。 （中央机构还处理安全、令牌和证书，但我想简化）
Sidecar A 和 Sidecar B 定期与服务发现进行通信确认可用性。
服务A应该如何调用服务B的端点：
- 直接通过特定的url，因为Sidecar A应该知道的实例服务 B 通过服务发现应该选择一个健康的服务吗？
- 或者间接通过调用服务发现的通用 API，该 API 应该知道可以调用的健康实例是什么，并相应地将请求重定向到其中之一？
- 或者以其他方式？
Let's say we have the following setup:
Service A consists of a pod in a Kubernetes cluster with two containers Api A and Sidecar A. Api A communicates with the outside world through Sidecar A. Sidecar A is registered as a consumer.
Service B consists of a pod in a Kubernetes cluster with two containers Api B and Sidecar B. Api B communicates with the outside world via Sidecar B. Sidecar B is registered as a producer.
Service A and Service B could potentially have multiple instances.
The services register themselves with the service mesh through a central authority, let's call it Service Discovery, that knows about the specific instances of each service and the endpoints that they expose. Service A can also subscribe to a specific endpoint of Service B via this Service Discovery central authority. (The central authority also deals with security, tokens and certificates but I want to simplify)
Sidecar A and Sidecar B regularly communicate with Service Discovery to confirm availability.
How should Service A call an endpoint of Service B:
- directly via a specific url because the Sidecar A should know about the instances of Service B via service discovery and should choose a healthy one?
- or indirectly by calling a generic api of Service Discovery which should know what are the healthy instances that can be called and redirect the request to one of them accordingly?
- or in some other way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我发现推荐的方法是服务 A 直接通过特定 URL 调用端点 B，因为 Sidecar A 应该通过服务发现了解服务 B 的实例，并应该选择一个健康的实例。
服务发现的目的就是：让服务可被发现。它不应该充当调用之间的代理。
I found out that the recommended way is for service A to call endpoint B directly via a specific URL because the Sidecar A should know about the instances of Service B via service discovery and should choose a healthy instance.
The purpose of service discovery is just that: to allow services to be discoverable. It should not serve as a proxy between calls.