减少微服务架构中的多跳延迟（南北流量）（FE -> API Gateway --> BFF --> 服务层 --> 后端）答案

【问题标题】：Reducing Latency with multiple hops in a microservices architecture (North South Traffic) (FE -> API Gateway --> BFF --> Service Layer --> Backend)减少微服务架构中的多跳延迟（南北流量）（FE -> API Gateway --> BFF --> 服务层 --> 后端）
【发布时间】：2020-03-19 03:21:57
【问题描述】：

如何通过微服务架构中针对南北流量的强制性多跳来减少延迟，即前端 -> API 网关 -> 前端的后端 -> 服务层 -> 后端

对于东西方流量，可以使用异步通信，可以使用 kafka 等事件代理。

但是，对于南北流量，同步通信，由于不同组件之间的许多跃点导致的延迟没有得到解决。

关于如何减少这种南北多跳流量的延迟有什么技巧吗？

【问题讨论】：

您在使用安全性吗？跟踪记录？分布式跟踪？注入中间件？压缩明文协议？所有这些都会增加延迟，因此请删除或改进它们......事实上，这个问题太模糊了

标签： performance architecture microservices latency eda

【解决方案1】：

早上好。我假设 API Gateway 和 Forntend 的后端是相同的。

A. UI -> B. API 网关 -> C. 中间层/后端服务 -> D. 缓存层 -> E. 数据库。

以下几点需要考虑。这些应该基于内容，它们的恒定性。 1.可以在UI缓存内容，这样就不会调用Server了。 2. 您可以在中间层/后端服务层缓存内容。 3.你可以有一个缓存层，这将有助于不到达数据库。

网址：https://dotnet.microsoft.com/download/e-book/microservices-architecture/pdf

【讨论】：

【解决方案2】：

玩过运输大亨吗？

获取更多交付产品的单位。
减少负载的大小。
在中间人送货的长途目的地之间设置代理操作。

或者我最喜欢的...

集成流程以完全消除交付。

由于分布式流程是自然的，真正的工作和收益来自于集成它们。

【讨论】：

这听起来像是一个单片应用程序...感叹设计一个拥有一切的东西并不容易
但是制造工厂不是单一的。它拥有一切，可以轻松成长或重塑。在不了解集中化和分布式制造的后果的情况下，建模过程会产生后果。我在 powersemantics.com 上的文章教授这些您在学校不会学到的基础知识。我是这方面的专家。消除有问题的延迟是集成的一个原因。无状态代码（微服务）无法解决适用于实际服务的物流问题。问题在于无状态的分布式模型。