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

四个假设

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

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

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

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

3）了解网络有很多价值

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

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

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

应用网络功能

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

网络

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

这些传输单元是通过网络中的不同点发送的，这些点决定是否允许该单元通过，是否将其路由到其他网络或将其传递给预期的接收者。 这些传输单元可以在路径上的任何位置被丢弃，复制，重新排序或延迟。 我们的操作系统的网络堆栈中存在TCP等更高级别的“可靠性”功能，可以跟踪重复，确认，超时，排序，丢失单元等情况，并可以重试失败，重新排序数据包等。

这些类型的功能是由基础结构提供的，并且没有与业务逻辑混合使用-并且可以很好地扩展（Internet规模！）。我刚刚遇到了Phil Calcado的精彩博客，也对此做了很好的解释 。

应用

在应用程序级别，我们做类似的事情。 我们将与合作者服务进行的对话分为“消息”（请求，事件等）的传输单元 。 当我们通过网络拨打电话时，我们必须能够对应用程序消息执行超时，重试，确认，施加反压等操作。 这些是普遍的应用程序级问题，并且在我们构建服务风格的体系结构时总是会出现。 我们需要以某种方式解决它们。 我们需要一种实现应用程序网络功能的方法。

例如：过去，我们尝试通过消息传递代理解决这些问题。 我们有一套集中的，面向消息传递的中间件（甚至可能具有多协议支持，因此我们可以转换消息有效负载并“集成”客户端），这些中间件负责在客户端之间传递消息。 在我看到的许多示例中，该模式基本上是在消息传递系统上执行请求/答复（RPC）。

这默认地帮助解决了有关应用程序网络功能的一些问题：诸如负载平衡，服务发现，背压，重试等之类的事情都委托给了消息传递代理。 由于所有流量都打算通过这些代理进行流动，因此我们有一个中心点可以从中观察和控制网络流量。 但是，正如@tef_ebooks在Twitter上指出的那样，这种方法非常繁琐 。 它也往往是体系结构中的一个大瓶颈，并且在交通控制，路由，策略执行等方面并没有我们想象的那么容易。

因此，我们也尝试这样做。 我们认为“好吧，让我们只添加路由，转换，策略控制”到我们已经拥有的集中式消息总线中。 实际上，这是自然发展的过程–我们可以使用消息传递主干来提供集中化/控制和应用程序网络功能，例如服务发现，负载平衡，重试等–但是，我们还将在诸如协议中介，消息转换之类的更多内容之上，消息路由，业务流程等。我们认为，如果我们可以将这些看似水平的东西推入基础架构，我们的应用程序可能会更轻/更薄/更敏捷等。这些担忧确实是ESB真正发展起来的，可以帮助解决这些问题。

正如我的同事Wolfram Richter指出的那样：“关于ESB的概念，IBM在2005年发布的有关SOA架构的白皮书（ http://signallake.com/innovation/soaNov05.pdf第2.3.1章 ）将ESB定义如下：”

The enterprise service bus (ESB) is a silent partner
in the SOA logical architecture. Its presence in the
architecture is transparent to the services of your
SOA application. However, the presence of an ESB is
fundamental to simplifying the task of invoking
services – making the use of services wherever they
are needed, independent of the details of locating
those services and transporting service requests
across the network to invoke those services wherever
they reside within your enterprise.

似乎是合法的！ 甚至似乎是我们正在尝试的新兴技术中要做的一些事情。 你知道吗？ 我们是！！！ 过去的问题不仅已经神奇地消失了 ，而且背景和环境也发生了变化。 希望我们能够从过去的未兑现承诺中学习。

例如，在大型供应商所设想的SOA时代（通过委员会等编写了无休止的规范，对EAI进行了品牌重塑等），我们发现三件事促成了“ ESB”的未兑现承诺：

• 组织结构（让我们再建一个筒仓！）
• 技术很复杂（SOAP / WS-*，JBI，Canonical XML，专有格式等）
• 需要业务逻辑来实现诸如路由，转换，中介，编排等操作

最后一点是什么过分的事情。 我们希望敏捷，但是我们将重要的业务逻辑从我们的服务中分散到了另一个团队拥有的集成层中。 现在，当我们想对我们的服务进行更改（敏捷）时，我们就不能了。 我们必须停止并与ESB团队进行重大同步（脆弱）。 随着这个团队和这个体系结构成为许多应用程序的中心，我们可以了解ESB团队是如何被请求（敏捷）所淹没，却无法跟上（脆弱）的。 因此，尽管意图很好，但我们发现将核心应用程序网络功能与与业务逻辑相关性更高的功能混合在一起并不是一个好主意。 我们最终会出现膨胀和瓶颈。

随之而来的是REST革命和以API为先的思维方式。 这一运动在某种程度上是对SOAP / ESB / SOA的复杂性的抵制，再加上一种新的思考方式（通过API）将我们的数据内翻以激发新的业务模型并扩展现有模型。 我们还为我们的体系结构引入了新的基础架构：API管理网关。 该网关为我们提供了集中式控制方式，以通过安全ACL，访问配额和API使用计划，指标收集，计费，文档编制等来控制外部对我们业务API的访问。但是，就像我们在前面的示例中看到的消息代理一样，当我们进行某种集中式治理时，我们冒着想要用它完成太多事情的风险。 例如，当API调用通过我们的网关进行时，为什么不添加路由，转换和编排之类的内容呢？ 问题在于，我们开始着手构建将基础架构级别的网络问题与业务逻辑相结合的ESB。 这是一个死胡同。

但是，即使在REST /非SOAP时代，我们仍然必须解决服务之间的上述问题（不仅是所谓的“南北”流量，而且我们还需要解决“东西向”流量）互动）。 更具挑战性的是，我们需要找出一种使用商品基础架构环境（又名云）的方法，这种环境会加剧这些问题。 传统的消息代理，ESB等不太适合此模型。 相反，我们最终在业务逻辑中编写了应用程序网络功能。 …我们开始看到诸如Netflix OSS堆栈 ， Twitter Finagle甚至我们自己的Fuse Fabric之类的东西可以解决这些问题。 这些通常是旨在解决上述某些问题的库或框架，但是它们是特定于语言的，并与我们的业务逻辑（或我们遍布整个基础架构的业务逻辑）混合在一起。 该模型也存在问题。 这种方法需要在每种语言/框架/运行时上进行大量投资。 我们基本上必须跨语言/框架重复工作，并期望所有不同的实现都能高效，正确且一致地工作。

经过这些试验和磨难，我们可以将应用程序网络功能以最低的开销和高度的分散性推入基础架构，并具有控制/配置/监视应用程序级请求的能力，从而解决了一些较早的问题。 我们一直称其为“服务网格”。 一个很好的例子是基于Envoy Proxy的istio.io项目。 这使我们在架构上将应用程序网络功能的关注点与侧重于区分业务逻辑的关注点分开：

正如Phil Calcado解释的那样 ，这与我们对TCP / IP网络层所做的非常相似。 网络功能被推出到操作系统中，并且不直接属于应用程序。

那么这与…有什么关系？

通过服务网格，我们将应用程序网络功能与应用程序代码，业务逻辑明确分离，并将其向下推入一层（进入基础结构），这与我们对网络堆栈，TCP等所做的操作类似）。

有问题的网络功能包括：

• 简单的基于元数据的路由
• 自适应/客户端负载平衡
• 服务发现
• 断路
• 超时/重试/预算
• 限速
• 指标/记录/跟踪
• 故障注入
• A / B测试/流量调整/请求屏蔽

明确不包括的内容（更适合您的业务逻辑/应用程序/服务，而不是某些集中式基础结构）：

• 信息转换
• 消息路由（基于内容的路由）
• 服务编排

那么，服务网格与…有何不同？

ESB

• 某些网络功能重叠
• 分散的控制点
• 特定于应用程序的策略
• 不尝试处理业务逻辑问题（映射，转换，基于内容的路由等）

消息经纪人

• 服务发现，负载平衡，重试，背压方面的重叠（从30,000英尺高度开始）
• 分散的控制点
• 特定于应用程序的策略
• 对消息不承担任何责任

API管理

• 在策略控制，速率限制，ACL，配额安全性的某些方面存在重叠
• 不处理API的业务方面（定价，文档，用户到计划的映射等）
• 相似之处在于它不执行业务逻辑

关于API管理，似乎确实有些重叠，但是我想将这些东西视为高度互补。 API管理提供有关API的高级语义（例如文档，用户注册/访问，生命周期管理，针对开发人员的API计划，用于计费和退款的计量等）。 调用API时，诸如断路器，超时，重试等较低级别的应用程序网络至关重要，但它们非常适合服务网格层。 重叠点，例如ACL，速率限制，配额和策略实施等，可以由API管理层定义，但实际上由服务网格层实施。 这样，我们可以拥有完整的端到端策略和访问控制，并可以增强对北/南流量和东/西流量的弹性。 正如@ZackButcher （来自Istio团队） 在Twitter上指出的那样： “随着您的规模越来越大，从产生和管理服务的角度来看，东西向的流量开始越来越像南北向。”

汇集全部

点击查看完整图片

我们需要对我们的系统架构采用API优先的方法。 我们还必须解决诸如弹性之类的问题。 我们还发现我们面临整合挑战。 并且在许多方面，基于异步事件传递和事件处理作为API和微服务交互的底板的体系结构可以帮助提高可用性，弹性和减少脆弱性。 过去，解决这些问题一直是充满挑战的产品，因为竞争产品和解决方案重叠并混淆了关注点–当我们转向云架构时，很明显，我们需要梳理这些关注点并将它们放在我们架构的适当位置，否则我们将会屈从于一些相同的经验教训。

从上图中，我们可以看到一些事情：

• 北/南入口流量的API管理
• 服务网格（控制+数据平面），用于服务之间的应用程序网络功能
• 用于东西方流量的Service Mesh强制API管理策略
• 集成（业务流程，转换，反腐败层）作为应用程序的一部分
• 事件驱动的消息背板可实现真正的异步/事件驱动的交互

如果我们不听前面提出的四个假设，那么我们将努力解决这些问题：

• 第一点：服务通过网络进行交互–我们使用服务网格数据平面/服务代理
• 要点二：交互是不平凡的–在服务本身中实现业务集成
• 第三点：控制和可观察性–使用API​​管理+服务网格控制平面
• 第四点：您的特定业务逻辑； 使用服务网格/消息传递/等进行优化

您真的可以分离出业务逻辑吗？

我想是的。 但是，会有模糊的线条。 在服务网格中，我们是说我们的应用程序应了解应用程序网络功能，但不应在应用程序代码中实现。 关于应用程序网络功能/服务网格层到底在做什么，使应用程序变得更智能，这是有话要说的。 我认为我们会在这种情况下看到库/框架。 例如，如果Istio服务网格引发断路器，重试某些请求或由于特定原因而失败，那么对于应用程序而言，可以更好地了解这些情况或上下文将非常有用。 我们需要一种方法来捕获它并将其传达回服务。 另一个示例是在服务之间传播跟踪上下文（像OpenTracing这样的分布式跟踪），并使其透明地完成。 我们可能会看到这些专用于应用程序/语言的精简库，这些库可以使应用程序/服务更智能，并允许他们采用特定于错误的资源。

我们从这里去哪里

今天，该体系结构的各个部分处于不同的成熟度级别。 即使这样，对我们的服务体系结构采取有原则的方法也是关键。 将业务逻辑与应用程序网络分开。 使用服务网格来实现应用程序网络，使用API​​管理层来处理以更高阶的API为中心的问题，特定于业务的集成驻留在服务层中，并且我们可以通过事件驱动的背板构建数据密集型/可用系统。 我认为，随着我们的前进，我们将继续看到这些原理在特定的技术实现中得到体现。 在红帽（我工作的地方），我们看到这样的技术3比例 ， Istio.io上Kubernetes ， Apache的骆驼和消息传递技术，如ActiveMQ的阿蒂米斯 / Apache的Qpid调度路由器 （包括非红帽的技术，如Apache的卡夫卡恕我直言）强积木建立遵循这些原则的服务架构。

翻译自: https://www.javacodegeeks.com/2017/08/application-network-functions-esbs-api-management-now-service-mesh.html