api网关和esb区别_具有ESB，API管理和Now .. Service Mesh的应用程序网络功能。

api网关和esb区别

我最近谈论了微服务模式的演变，以及来自Lyft的Envoy之类的服务代理如何帮助将弹性，服务发现，路由，指标收集等责任推到应用程序下一层。 否则，我们冒着希望并祈祷各种应用程序将正确实现这些关键功能或依靠特定于语言的库来实现这一目标的风险。 有趣的是，这种服务网格的想法与企业空间中的客户所知道的其他概念有关，并且我对此关系有很多疑问。 具体来说，服务网格与ESB，消息代理和API管理之类的事物有何关系？ 这些概念肯定存在重叠，因此让我们深入研究吧。 欢迎在Twitter上关注@christianposta，以获取有关此主题的更多信息！

四个假设

1）服务通过网络进行通信

首先要说的是：我们正在谈论通过异步，分组交换网络相互通信和交互的服务。 这意味着它们在自己的进程和自己的“时间边界”（因此在这里是异步性）中运行，并通过网络发送数据包进行通信。 不幸的是， 不能保证异步网络的交互 ：我们可能会以失败的交互，停滞/潜在的交互等为最终结果，而这些场景彼此之间是无法区分的。

2）如果仔细观察，这些相互作用是不平凡的

第二点是：这些服务如何相互交互并非易事； 我们必须处理失败/部分成功，重试，重复检测，序列化/反序列化，语义/格式转换，多语言协议，路由到正确的服务以处理我们的消息，处理消息泛滥，服务编排，安全性等问题含义等。很多事情可能并且确实会出错。

3）了解网络有很多价值

第三：了解应用程序之间如何通信，消息如何交换以及潜在地控制此流量的方法具有很大的价值。 这一点与我们对3/4层网络的看法非常相似； 了解哪些TCP段和IP数据包正在穿越我们的网络，控制有关如何路由它们，允许什么的规则等，这很有价值。

4）最终是应用程序的责任

最后：正如我们从头到尾的论点所知道的那样，是应用程序本身负责其声称的业务逻辑的安全性和正确的语义实现–不管我们从底层基础结构（重试，事务，重复检测等）获得什么可靠性。我们的应用程序仍必须防范用户的愚蠢行为（两次下订单）–有助于实现这一目标的任何事情都是实施/优化细节。 不幸的是，这没有办法。

应用网络功能

我认为，无论您喜欢哪种服务体系结构（微服务，SOA，对象请求代理，客户端/服务器等），这些观点都是有效的–但是，在过去，我们模糊了关于优化属于何处的界限。 在我看来，有水平的应用程序网络功能是公平的游戏，可以优化我们的应用程序（并放入基础架构中，就像我们在较低级别的堆栈中所做的一样），还有其他一些与我们的业务更紧密相关不应轻易“优化”的逻辑 。

网络

让我们快速退后一步，了解我们的应用程序下面的网络是什么样的（非常琐碎和高级：）。 当我们从一项服务向另一项服务发送“消息”时，我们将其传递到操作系统的网络堆栈，然后该网络堆栈将弄清楚如何将其放入网络。 网络根据级别来处理传输单元 （帧，数据报，数据包）等。这些传输单元通常由一个结构组成，该结构包括一个“标头”和一个“有效载荷”，而“标头”包含有关该标头的足够元数据。我们可以做一些基本的事情