让我们跳过微服务的推销 - 你已经知道它们是什么以及为什么它们有意义。事实上，近年来几乎没有什么话题能够获得如此多的报道，因为将一件大东西分解成许多小东西可以让它更容易处理。
麻烦的是：一旦我们打碎了我们的单体巨石，我们如何将它重新组合成一个仍然有意义的更大的系统？尽管Istio，Kong或Kafka的爱好者都会回答你，这个问题肯定不止有一个答案，不同的解决方案对应于不同的需求。
本文旨在阐明在微服务之间组织通信的各种方法，以及Service Mesh，API Gateway或Message Queue可能是满足您需求的最佳解决方案。
但在我们谈论解决方案之前，让我们谈谈这个问题：
有什么问题？
为了正常运行，基于微服务的架构必须解决特定于其分布式特性的许多挑战：
1.弹性
任何给定的微服务可能有几十甚至几百个实例 - 由于各种原因，每个实例都可能在任何时间点失败。
2.负载平衡和自动扩展
由于可能有数百个端点能够完成请求，因此路由和扩展都是重要的。实际上，大型架构最有效的节省成本措施之一是提高路由和扩展决策的精度。
3.服务发现
应用程序越复杂和分布式，找到现有端点并与它们建立通信通道就越困难。
4.跟踪和监控
微服务架构中的单个交易可能会通过多个服务进行传输，因此很难跟踪其行程。
5.版本
随着系统的成熟，更新可用端点和API变得至关重要，同时确保旧版本仍然可用。
解决方案
服务网格，API网关和消息队列都可以解决这些问题，当然，还有许多其他方法，从简单的静态负载平衡和固定IP到中央编排服务器 - 但是这里只看一下目前最流行和最复杂的选项。
API网关
API网关是类似HTTP反向代理的更大兄弟。它是一个可扩展的，通常面向Web的服务器，可以接收来自公共互联网和内部服务的请求，并将它们转发到最适合的微服务实例。API网关通常具有许多有用的功能，包括负载平衡和运行状况检查，API版本控制和路由，请求身份验证和授权，数据转换，分析，日志记录，SSL终止等。流行的开源API网关的示例是Kong或Tyk。大多数云提供商也提供自己的实施，例如AWS API Gateway，Azure Api Management或Google Cloud Endpoints。
优点
API网关功能强大，复杂程度相对较低，它们为公共互联网提供了坚实的防御层，并卸载了许多重复性任务，例如用户身份验证或数据验证。
缺点
API网关相当集中。它们可以以水平可扩展的方式部署，但与服务网格不同，它们仍然需要单点来注册新API或更改配置。从组织的角度来看，它们很可能由一个团队维护
服务网格
Service Meshes是微服务实例之间的分散和自组织网络，用于处理负载平衡，端点发现，运行状况检查，监视和跟踪。它们通过将一个小代理（称为“边车”）附加到每个调解流量并处理实例注册，度量标准收集和维护的实例来工作。虽然在概念上是分散的，但大多数服务网格都带有一个或多个中心元素来收集数据或提供管理界面。流行的例子包括Istio，Linkerd或Hashicorp的Consul。
优点
服务网格更加动态，可以轻松改变形状并适应新的功能和端点。它们的分散性使得在相当孤立的团队中处理微服务变得更加容易。
缺点
服务网格可能非常复杂，需要大量移动部件。例如，充分利用Istio需要为每个节点部署单独的流量管理器，遥测收集器，证书管理器和边车流程。它们还是一个非常新的发展中技术，使用其构成你的架构的骨干，可能让你担忧它的年轻。
消息队列
首先看一下，将服务网格与消息队列进行比较似乎比较苹果和橙子：它们是完全不同的东西，但它们解决了同样的问题，尽管方式截然不同。
消息队列允许您通过解耦发送方和接收方在服务之间建立复杂的通信模式，它们使用许多概念实现此目的，例如基于主题的路由或发布 - 订阅消息传递，以及缓冲的任务队列，使多个实例变得容易随着时间的推移处理任务的不同方面。
消息队列已存在很长时间，因此有多种选择可供选择：流行的开源替代品包括Apache Kafka，AMQP Broker（如RabbitMQ或HornetQ）和云提供商版本（如AWS SQS或Kinesis，Google PubSub或Azure Service Bus）。
优点
简单地解耦发送方和接收方是一个强有力的概念，它使许多其他概念，如健康检查，路由，端点发现或负载平衡变得不必要。实例可以在缓冲队列准备好的时候从缓冲队列中选择相关任务。当自动编排和扩展决策基于每个队列中的消息计数时，这变得尤其强大，从而导致高度资源有效的系统。
缺点
消息队列不擅长请求/响应通信。有些人认为这可以在现有概念的基础上进行，但实际上并非如此。由于它们的缓冲特性，它们还可以为系统增加显着的延迟。它们也相当集中单点风险（虽然可以横向扩展），并且在大规模运行时成本非常高。
选择哪个？
API网关是公共面向API的前端；服务网格可处理服务间通信(同步)；使用消息队列进行异步任务调度。
但是，如果我们将重点仅仅放在服务间通信上，那么可能的答案可能是：
- 如果您已经为面向公众的API运行API网关，那么您可能还要保持较低的复杂性并将其重用于服务间通信
- 如果您在一个拥有孤立团队和沟通不畅的大型组织内工作，服务网络可以为您提供最高程度的独立性，从而可以轻松地随着时间的推移添加新服务。
- 如果您正在设计一个系统，其中各个步骤随着时间的推移而间隔开来，例如，像上传，处理和发布视频的服务这样的youtube可能需要几分钟，请使用消息或任务队列。
(banq注：服务网关是属于复杂的基础设施，可实现服务之间直接同步调用，如同在一个机器内部调用一样，虽然使用起来很方便，但是网络不是百分百可靠，虽然有复杂监控。请放弃RPC！分布式编程第一谎言：网络是可靠的 - David Boike)