石家庄自适应网站建设,wordpress房地产插件,写作网站,源码论坛有哪些通讯网关 api网关这些年来#xff0c;API网关正在经历一些身份危机 。 它们是否是集中的共享资源#xff0c;从而促进了API对外部实体的公开和治理#xff1f; 它们是集群入口哨兵#xff0c;可以严格控制哪些用户流量进入或离开集群吗#xff1f; 还是他们根据自己拥有… 通讯网关 api网关 这些年来API网关正在经历一些身份危机 。 它们是否是集中的共享资源从而促进了API对外部实体的公开和治理 它们是集群入口哨兵可以严格控制哪些用户流量进入或离开集群吗 还是他们根据自己拥有的客户端类型使用某种API合并胶来更简洁地表达API 当然房间里的大象和我经常听到的一个问题“服务网格会使API网关过时吗” 一些背景 随着技术的发展日新月异以及整个行业通过技术和架构模式进行快速洗牌您会被认为是“所有这些都使我旋转”。 在本文中我希望归纳出“ API网关”的不同身份阐明组织中的哪些组可以使用API​​网关他们正在尝试解决的问题并重新关注第一原理。 理想情况下在本文结束时您将更好地理解API基础结构在不同层次上对不同团队的作用以及如何从各个层次中获得最大价值。 在深入探讨之前让我们先清楚一下术语“ API”。 我对API的定义 一个明确定义的目的明确的接口旨在通过网络调用该接口使软件开发人员能够以受控且舒适的方式对组织内的数据和功能进行编程访问。 这些接口抽象了实现它们的技术基础结构的细节。 对于这些设计的网络端点我们希望获得一定程度的文档使用指南稳定性和向后兼容性。 相反仅因为我们可以通过网络与另一软件进行通信并不一定意味着远程端点就是此定义的API。 许多系统相互通信但是通信更加随意发生并且在耦合和其他因素之间进行权衡取舍。 我们创建API来为业务的各个部分提供周到的抽象以实现新的业务功能以及偶然的创新。 在谈论API网关时首先要列出的是API管理。 API管理 许多人从API管理的角度考虑API网关。 这是公平的。 但是让我们快速看一下此网关的功能。 借助API Management 我们正在寻求解决“何时我们希望公开现有的API供其他人使用”的问题我们如何跟踪谁使用这些API实施关于允许谁使用它们的策略建立安全性流程以进行身份​​验证和授权许可使用并建立可在设计时使用的服务目录以促进API使用并为有效治理奠定基础。 我们要解决“我们想与其他人共享但要按我们的条件共享这些现有的经过策划的API”的问题。 API管理也做得很好它允许用户潜在的API使用者进行自助服务签署不同的API使用计划请考虑给定时间范围内指定价格点上每个终结点的每个用户的调用次数。 我们能够执行这些类型的管理功能的基础架构是我们的API流量经过的网关 。 至此我们可以执行诸如身份验证速率限制指标收集其他策略执行等操作。 等 利用API网关的API管理软件示例 Google Cloud Apigee 红帽3Scale Mulesoft Kong 在此级别上我们正在考虑API如上定义以及如何最好地管理和允许对其进行访问。 我们不是在考虑服务器主机端口容器甚至服务另一个定义不明确的词但请坚持我。 API管理以及它们相应的网关通常被实现为“平台团队”“集成团队”或其他API基础架构团队所拥有的受严格控制的共享基础架构。 需要注意的一件事我们要小心不允许任何业务逻辑进入这一层。 如前一段所述API管理是共享的基础结构但是由于我们的API流量经过了它因此它倾向于重新创建“全知全能”认为是企业服务总线治理门必须所有人协调以更改我们的服务。 从理论上讲这听起来不错。 在实践中这最终可能成为组织瓶颈。 有关更多信息请参见这篇文章 具有ESBAPI管理和Now…Service Mesh的应用程序网络功能 集群入口 为了构建和实现API我们专注于代码数据生产力框架等内容。 但是要想使这些事情中的任何一个产生价值就必须对其进行测试部署到生产中并进行监控。 当我们开始部署到云原生平台时我们开始考虑部署容器服务主机端口等并构建我们的应用程序以生活在这种环境中。 我们可能正在设计工作流CI和管道CD以利用云平台快速移动进行更改将其展示在客户面前等等。 在这种环境下我们可能会构建和维护多个群集来承载我们的应用程序并且需要某种方式来访问这些群集中的应用程序和服务。 以Kubernetes为例思考。 我们可能使用Kubernetes Ingress控制器来允许访问Kubernetes集群集群中的其他所有内容都无法从外部访问。 这样我们就可以通过定义明确的入口点例如域/虚拟主机端口协议等严格控制哪些流量可以进入甚至离开我们的集群。 等 在此级别上我们可能希望某种“入口网关”成为允许请求和消息进入群集的流量哨兵。 在这个级别上您的思考更多是“我的集群中有此服务我需要集群外的人才能调用它”。 这可能是服务公开API现有的整体组件gRPC服务缓存消息队列数据库等。有些人选择将其称为API网关其中有些人实际上可能会做更多比流量的入口/出口要大但是重点是在集群操作级别存在此级别的问题。 随着我们倾向于部署更多集群相对于一个单一的高度多租户的集群我们最终会有更多的入口点并且需要这些入口点之间进行交互。 这些类型的入口实现的示例包括 Envoy代理及其基础上的项目包括 数据线大使 代理 包括OpenShift的路由器 NGINX 特拉菲克 此级别的集群入口控制器由平台团队操作但是这部分基础架构通常与更分散的自助服务工作流相关联正如您对云原生平台所期望的那样。 参见Weaveworks的好伙伴介绍的“ GitOps”工作流程 API网关模式 术语“ API网关”的另一种扩展是我在听到该术语时通常会想到的扩展它与API网关模式最相似。 克里斯·理查德森Chris Richardson在第8章的“微服务模式”一书中很好地介绍了这种用法。我强烈建议您将此书用于此以及其他微服务模式教育。 可以在他的microservices.io网站上的API Gatway Pattern上进行快速浏览。简而言之API-gateway模式是管理API以使不同类别的消费者更好地使用。 此策展涉及一个API间接级别。 您可能会听到另一个代表API网关模式的术语是“后端的后端”其中“前端”可以是文字前端UI移动客户端IoT客户端甚至其他服务/应用程序开发人员。 在API网关模式中我们显着简化了一组API的调用以针对特定的用户客户端或使用者组为“应用程序”模拟内聚的API。 回想一下当我们使用微服务构建系统时“应用程序”的概念就消失了。 API网关模式有助于恢复此概念。 这里的关键是API网关一旦实现它将成为客户端和应用程序的API并负责与任何后端API和其他应用程序网络端点不满足上述API定义的端点进行通信。 与上一节中的Ingress控制器不同此API网关更接近于开发人员对世界的看法并且较少集中在暴露给集群外使用的端口或服务上。 此“ API网关”也不同于我们管理现有API的API管理世界观。 该API网关将对后端的调用混搭在一起这些调用可能会公开API但也可能会与未描述为API的事物进行对话例如对旧系统的RPC调用协议与“ REST”的外观不符例如被黑通过HTTPgRPCSOAPGraphQLwebsocket和消息队列的JSON。 也可以调用这种类型的网关来进行消息级转换复杂的路由网络弹性/后备以及响应的聚合。 如果您熟悉REST API的Richardson Maturity模型则将调用实现API网关模式的API网关以集成比Level 1 – 3实现更多的Level 0请求及其之间的所有内容。 这些类型的网关实现仍需要解决速率限制身份验证/授权断路度量收集流量路由等问题。 这些类型的网关可以在集群的边缘用作集群入口控制器也可以在集群内部用作应用程序网关。 此类API网关的示例包括 Spring Cloud Gateway 格洛 Netflix Zuul IBM-Strongloop回送/微网关 也可以使用更多通用的编程或集成语言/框架来构建此类网关例如 阿帕奇骆驼 Spring整合 Ballerina Eclipse Vert.x 节点JS 由于这种类型的API网关与应用程序和服务的开发密切相关我们希望开发人员能够参与帮助指定API网关公开的API了解所涉及的任何mashup逻辑以及需求快速测试和更改此API基础结构的能力。 我们还希望操作或SRE对API网关的安全性弹性和可观察性配置有一些意见。 这种级别的基础结构还必须适应不断发展的按需自助服务开发人员工作流。 再次查看GitOps模型以获取更多信息。 启用服务网格 在云基础架构上运行服务体系结构的一部分包括难以在网络中构建正确级别的可观察性和控制。 在解决此问题的先前迭代中 我们使用了应用程序库和希望的开发人员治理来实现此目的 。 但是在大规模和跨多种环境的情况下服务网格技术的出现提供了更好的解决方案 。 服务网格通过透明地实现为平台及其组成服务带来以下功能 服务到服务即东西向交通的弹性 安全性包括最终用户身份验证相互TLS服务到服务RBAC / ABAC 黑匣子服务的可观察性专注于网络通信例如请求/秒请求延迟请求失败断路事件分布式跟踪等 服务到服务速率限制配额执行等 精明的读者会认识到 API网关和服务网格在功能上似乎有所重叠 。 服务网格的目标是通过在L7透明地解决所有服务/应用程序的这些问题。 换句话说服务网格希望融合到服务中实际上并没有被编码为服务的代码。 另一方面API网关位于服务网格上方并与应用程序一起使用L8。 服务网格为服务主机端口协议等东西方流量之间的请求流带来了价值。 他们还可以提供基本的集群入口功能以将某些此功能引入南北交通。 但是这不应与API网关可以带来北/南通信量的功能如在集群的北/南和应用程序或一组应用程序在北/南中混淆。 Service Mesh和API网关在某些方面在功能上有重叠但是是互补的因为它们位于不同的级别并解决不同的问题。 理想的解决方案是将每个组件API管理API网关服务网格插入并播放到您的解决方案中并在需要时在组件之间建立良好的边界或在不需要时排除它们。 同样重要的是找到适合分散式开发人员和运营工作流程的这些工具的实现。 即使这些不同组件的术语和标识存在混淆我们也应该依靠基本原理并了解这些组件在我们的体系结构中带来了价值以及它们如何独立存在和互补并存。 我们很乐意为您服务 你们中的有些人可能知道我非常热衷于帮助人们尤其是在云微服务事件驱动的体系结构和服务网格领域。 在我的公司Solo.io中 我们正在帮助组织消除混乱并以适当的级别以及成功使用它们的步伐如果需要更重要的是成功地采用网关和服务网格之类的API技术。 。 我们正在建设的工具如GLOO 东张西望 并SuperGloo技术类似的顶部特使代理 GraphQL和Istio以帮助实现API网关和服务网格管理。 请直接与我们联系 soloio_inc http : //solo.io 或与我联系 christianposta blog 以深入了解我们的愿景以及我们的技术如何为您的组织提供帮助。 在接下来的系列博客中我们将更深入地探讨API网关模式多个集群的困难多服务网格的困难等等 敬请关注 还相关阅读 http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/ 翻译自: https://www.javacodegeeks.com/2019/01/api-gateways-going-identity-crisis.html通讯网关 api网关