网站建设 的公司哪家好,万网博通,网页翻译英文,铁岭房地产网站建设api网关和esb区别我最近谈论了微服务模式的演变#xff0c;以及来自Lyft的Envoy之类的服务代理如何帮助将弹性#xff0c;服务发现#xff0c;路由#xff0c;指标收集等责任推到应用程序下一层。 否则#xff0c;我们冒着希望并祈祷各种应用程序将正确实现这些关键功能或… api网关和esb区别 我最近谈论了微服务模式的演变以及来自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-*JBICanonical 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.htmlapi网关和esb区别
