「第二部:容器和微服务架构](10) API网关模式与客户端直接通信2

本文涉及的产品
云原生 API 网关,700元额度,多规格可选
简介: 「第二部:容器和微服务架构](10) API网关模式与客户端直接通信2

接上一部分「第二部:容器和微服务架构](9) API网关模式与客户端直接通信


API网关模式的主要特性


一个API网关可以提供多种功能。根据产品,它可能提供更丰富或更简单的特性,但是,任何API网关最重要和最基本的特点是以下设计模式:

  • 反向代理或网关路由。API网关提供一个反向代理,用于将请求(第7层路由,通常是HTTP请求)重定向或路由到内部微服务的端点。网关为客户端应用程序提供一个端点或URL,然后在内部将请求映射到一组内部微服务。此路由功能有助于将客户端应用程序与微服务分离,但通过将API网关置于单片API和客户端应用程序之间,使单片API现代化时也非常方便,然后,您可以添加新的API作为新的微服务,同时仍然使用传统的单片API,直到将来将其拆分为许多微服务。由于API网关,客户端应用不会注意到所使用的API是作为内部微服务还是单片API实现的,更重要的是,在将单片API演化和重构为微服务时,由于API网关路由,客户端应用不会受到任何URI更改的影响。

有关详细信息,请参阅网关路由模式。



  • 请求聚合。作为网关模式的一部分,您可以将针对多个内部微服务的多个客户端请求(通常是HTTP请求)聚合为一个客户端请求。当客户端页面/屏幕需要来自多个微服务的信息时,此模式特别方便。使用这种方法,客户端应用程序向API网关发送一个请求,API网关向内部微服务发送多个请求,然后聚合结果并将所有内容发送回客户端应用程序。这种设计模式的主要好处和目标是减少客户端应用程序和后端API之间的聊天,这对于微服务所在的数据中心之外的远程应用程序尤其重要,如移动应用程序或来自SPA应用程序的请求(来自客户端远程浏览器中的Javascript)。对于在服务器环境中执行请求的常规web应用程序(如ASP.NET核心MVC web应用程序),此模式并不重要,因为延迟比远程客户端应用程序小得多。

根据您使用的API网关产品,它可能能够执行此聚合。但是,在许多情况下,在API网关的作用域下创建聚合 微服务更为灵活,因此可以在代码(即C#代码)中定义聚合:


有关更多信息,请参阅网关聚合模式

  • 交叉问题或网关卸载。根据每个API网关产品提供的功能,您可以将功能从单个微服务卸载到网关,从而通过将横切关注点整合到一个层来简化每个微服务的实现。这对于在每个内部微服务中正确实现复杂的专用功能(如以下功能)尤其方便:
  1. 认证和授权
  2. 服务发现集成
  3. 响应缓存
  4. 重试策略、断路器和QoS
  5. 速率限制和节流
  6. 负载平衡
  7. 记录、跟踪、关联
  8. 头、查询字符串和声明转换
  9. IP白名单

有关更多信息,请参阅网关卸载模式


使用具有API网关功能的产品

根据每个实现,API网关产品可以提供更多的交叉关注点。我们将在这里探索:

  • Azure API Management
  • Ocelot


    Azure API管理

  • Azure API管理(如图14所示)不仅解决了API网关的需求,还提供了一些功能,比如从API中收集见解。如果您使用的是API管理解决方案,那么API网关只是该完整API管理解决方案中的一个组件。

  • 图14 为你的API网关使用Azure API管理

  • Azure API Management解决了你的API网关和管理需求,如日志记录、安全性、计量等。在这种情况下,当使用Azure API Management这样的产品时,你可能拥有一个单独的API网关并不那么危险,因为这类API网关“更薄”,也就是说,你没有实现定制的C代码,这些代码可能会演变成一个单一的组件。

  • API网关产品通常充当入口通信的反向代理,在这里,您还可以从内部微服务中筛选API,并将授权应用于此单层中发布的API。

  • API管理系统提供的洞察帮助您了解API是如何使用的,以及它们是如何执行的。他们通过让你查看近乎实时的分析报告和识别可能影响你业务的趋势来做到这一点。另外,您还可以拥有关于请求和响应活动的日志,以便进一步进行联机和脱机分析。

  • 使用Azure API管理,您可以使用密钥、令牌和IP过滤来保护API。这些特性允许您实施灵活的细粒度配额和速率限制,使用策略修改api的形状和行为,并通过响应缓存提高性能。

  • 在本指南和参考示例应用程序(eShopOnContainers)中,该体系结构仅限于更简单和自定义的容器化体系结构,以便在不使用诸如Azure API Management之类的PaaS产品的情况下专注于普通容器。但是对于部署到Microsoft Azure中的大型基于微服务的应用程序,我们鼓励您将Azure API管理作为生产中API网关的基础进行评估。

  • Ocelot

  • Ocelot是一个轻量级API网关,推荐用于更简单的方法。Ocelot是一个开源的基于.NET核心的API网关,特别是为需要统一进入系统入口点的微服务体系结构而设计的。它轻量级、快速、可扩展,并提供路由和身份验证等许多功能。

  • 为eShopOnContainers reference应用程序选择Ocelot的主要原因是Ocelot是一个.NET Core轻量级API网关,您可以将其部署到部署微服务/容器(如Docker主机、Kubernetes等)的同一应用程序部署环境中,并且由于它基于.NET Core,它是跨平台的,允许您在Linux或Windows上部署。

  • 前面显示在容器中运行的自定义API网关的图表正是如何在容器和基于微服务的应用程序中运行Ocelot的。
  • 此外,市场上还有许多其他产品提供API网关功能,如Apigee、Kong、MuleSoft、WSO2和其他产品,如linker和Istio,用于服务网格入口控制器功能

  • 在最初的架构和模式解释部分之后,接下来的部分将解释如何使用Ocelot实现API网关。

API网关模式的缺点

  • 最重要的缺点是,当您实现API网关时,您将该层与内部微服务耦合。这样的耦合可能会给您的应用程序带来严重的困难。Azure服务总线团队的架构师Clemens Vaster在GOTO 2016的“消息和微服务”会话中将这个潜在的困难称为“新ESB”。
  • 使用microservices API网关会产生额外的单点故障。
  • 由于额外的网络调用,API网关可以增加响应时间。然而,这个额外的调用通常比客户端接口直接调用内部微服务的影响要小。
  • 如果扩展不当,API网关可能成为瓶颈。
  • 如果API网关包含自定义逻辑和数据聚合,则需要额外的开发成本和未来的维护。开发人员必须更新API网关才能公开每个微服务的端点。此外,内部微服务中的实现更改可能会导致API网关级别的代码更改。但是,如果API网关只是应用安全性、日志记录和版本控制(如使用azureapi管理时),则可能不会应用此额外的开发成本。
  • 如果API网关是由一个团队开发的,则可能存在开发瓶颈。这也是为什么更好的方法是有几个细粒度的API网关来响应不同的客户端需求的另一个原因。您还可以在内部将API网关隔离到多个区域或层中,这些区域或层由处理内部微服务的不同团队拥有。

额外资源


相关文章
|
9天前
|
Cloud Native 云计算 Docker
云原生之旅:从容器化到微服务架构
【9月更文挑战第27天】本文将引领读者进入云原生的世界,探索如何通过容器化技术实现应用的快速部署与扩展,并深入理解微服务架构的设计哲学。我们将一起见证代码如何转化为可在云端无缝运行的服务,同时讨论云原生生态中的最佳实践和面临的挑战。
|
12天前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
12天前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
14天前
|
JSON 监控 安全
探索微服务架构中的API网关模式
【9月更文挑战第22天】在微服务架构的海洋中,API网关如同一位智慧的守门人,不仅管理着服务的进出,还维护着整个系统的秩序。本文将带你一探究竟,看看这位守门人是如何工作的,以及它为何成为现代云原生应用不可或缺的一部分。从流量控制到安全防护,再到服务聚合,我们将一起解锁API网关的秘密。
|
18天前
|
运维 Kubernetes Cloud Native
探索云原生技术:容器化与微服务架构的融合之道
【9月更文挑战第18天】在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性成为企业创新的强大引擎。本文将深入探讨云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同推动现代应用的开发与部署。通过实际代码示例,我们将揭示这些技术如何简化运维,加速产品上市时间,并提高系统的可靠性和弹性。无论你是开发人员、架构师还是IT决策者,这篇文章都将为你提供宝贵的洞见和实践指导。
23 2
|
11天前
|
Kubernetes Go Docker
掌握微服务架构:从Go到容器化的旅程
摘要,通常简短概述文章内容,要求精炼。在本文中,我们将打破常规,采用一种故事化叙述的摘要,旨在激发读者的好奇心和探究欲: “从宁静的海滨小城出发,我们踏上了一场技术探险之旅,探索微服务架构的奥秘。我们将学习如何用Go编写微服务,以及如何通过Docker和Kubernetes将它们打包进小巧的容器中。在这场旅程中,我们将遇到挑战、收获知识,最终实现应用的快速部署与可扩展性。”
|
12天前
|
Cloud Native Java 对象存储
揭秘微服务架构之争:Spring Cloud与Netflix OSS巅峰对决,谁将称霸弹性云原生时代?
近年来,微服务架构成为企业应用的主流设计模式。本文对比了两大热门框架Spring Cloud和Netflix OSS,探讨其在构建弹性微服务方面的表现。Spring Cloud依托Spring Boot,提供全面的微服务解决方案,包括服务注册、配置管理和负载均衡等。Netflix OSS则由一系列可独立或组合使用的组件构成,如Eureka、Hystrix等。两者相比,Spring Cloud更易集成且功能完善,而Netflix OSS则需自行整合组件,但灵活性更高。实际上,两者也可结合使用以发挥各自优势。通过对两者的对比分析,希望为企业在微服务架构选型上提供参考。
32 0
|
23天前
|
弹性计算 运维 持续交付
探索Docker容器化技术及其在生产环境中的应用
探索Docker容器化技术及其在生产环境中的应用
70 5
|
15天前
|
Linux iOS开发 Docker
Docker:容器化技术的领航者 —— 从基础到实践的全面解析
在云计算与微服务架构日益盛行的今天,Docker作为容器化技术的佼佼者,正引领着一场软件开发与部署的革命。它不仅极大地提升了应用部署的灵活性与效率,还为持续集成/持续部署(CI/CD)提供了强有力的支撑。
198 69
|
3天前
|
Kubernetes Cloud Native 持续交付
云原生之旅:Docker容器化与Kubernetes集群管理
【9月更文挑战第33天】在数字化转型的浪潮中,云原生技术如同一艘航船,带领企业乘风破浪。本篇文章将作为你的航海指南,从Docker容器化的基础讲起,直至Kubernetes集群的高级管理,我们将一起探索云原生的奥秘。你将学习到如何封装应用、实现环境隔离,以及如何在Kubernetes集群中部署、监控和扩展你的服务。让我们启航,驶向灵活、可伸缩的云原生未来。

热门文章

最新文章

下一篇
无影云桌面