关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。
随着Istio 1.16.0[1]的正式发布，也宣布了 Istio 基于Kubernetes Gateway API[2]的实现进入到了 Beta 阶段，这意味着 Istio 中所有南北向（Ingress）流量管理都可以迁移至 Kubernetes Gateway API。未来随着 Kubernetes Gateway API 的发展和成熟，Istio 东西向（Mesh）流量管理 API 也会被其慢慢代替。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
数字化生态，以创新客户体验为核心，所有我们身边能感知到的变化都来自于渐近的创新。这些创新需要试错，需要不断的升级，并且创新往往与我们熟知的功能分离开来分别呈现。微服务对于传统单体架构的优势之一就在于，服务的拆分带来了更新、部署、管理的隔离性，让一些单独的服务可以进行创新和实验。从而支撑了用户体验的不断升级，为实现企业数字化转型的过程，提供了技术架构层面的支撑。
Kubernetes Gateway API 是 Kubernetes 1.18 版本引入的一种新的 API 规范，是 Kubernetes 官方正在开发的新的 API，Ingress 是 Kubernetes 已有的 API。Gateway API 会成为 Ingress 的下一代替代方案。Gateway API 提供更丰富的功能,支持 TCP、UDP、TLS 等,不仅仅是 HTTP。Ingress 主要面向 HTTP 流量。 Gateway API 具有更强的扩展性,通过 CRD 可以轻易新增特定的 Gateway 类型,比如 AWS Gateway 等。Ingress 的扩展相对较难。Gateway API 支持更细粒度的流量路由规则,可以精确到服务级别。Ingress 的最小路由单元是路径。
距离 Kubernetes Gateway API 发布v1.0版本已经过去一个月了，这标志着其一些关键 API 的毕业到普遍可用的状态。
微服务框架中的服务提供了一些公用的认证和传输（业务）请求接口，用于给外部客户端调用。API Gateway提供了一个 shared layer（共享层），可用来处理服务协议，并满足特殊的客户端如桌面浏览器、手机设备或比较旧的系统的需要。
【编者的话】本系列的第一篇介绍了微服务架构模式。它讨论了采用微服务的优点和缺点，除了一些复杂的微服务，这种模式还是复杂应用的理想选择。 当你决定将应用作为一组微服务时，需要决定应用客户端如何与微服务交互。在单体式程序中，通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中，每一个微服务暴露一组细粒度的服务提供点。在本篇文章中，我们来看它如何影响客户端到服务端通信，同时提出一种API Gateway的方法。 介绍 假定你正在为在线购物应用开发一个原生手机客户端。你需要实现一个产品最终页来展示商品信息
前段时间，Kubernetes SIG-Network[1] 发布了备受期待的 Gateway API 0.5.0 版。主要组件的 Api 正在升级到 beta (v1beta1)，这意味着我们很快就会看到更多使用这些原语的项目。
当你决定将应用作为一组微服务时，需要决定应用客户端如何与微服务交互。在单体式程序中，通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中，每一个微服务暴露一组细粒度的服务提供点。在本篇文章中，我们来看它如何影响客户端到服务端通信，同时提出一种API Gateway的方法。
Contour 项目文章作者：Nick Young、Daneyon Hansen 和 Alex Xu
Gateway API 作为新一代的流量管理标准，对原有 Ingress 的扩展不规范、移植性差等问题做出了改进。从兼容K8s生态和优化网关体验出发，Rainbond 支持以插件的形式扩展平台网关能力，目前已经有多家社区提供了 Gateway API 的实现，将其制作成平台插件后，一键部署后即可在平台中使用拓展网关能力。我们可以制作不同的网关实现插件来应对不同的场景和需求，同时可以将自己制作的插件发布到应用商店供大家使用。
初始的 Kubernetes 内部服务向外暴露，使用的是自身的 LoadBlancer 和 NodePort 类型的Service，在集群规模逐渐扩大的时候，这种 Service 管理的方式满足不了我们的需求，比如 NodePort 需要大量的端口难以维护，多了一层NAT，请求量大会对性能有影响；LoadBlancer 需要每个 Service 都有一个外部负载均衡器。接着 Kubernetes 提供了一个内置的资源对象 Ingress API 来暴露 HTTP 服务给外部用户，它的创建是为了标准化的将 Kubernetes 中的服务流量暴露给外部，Ingress API 通过引入路由功能，克服了默认服务类型 NodePort 和 LoadBalancer 的限制。在创建 Ingress 资源的时候通过 IngressClass 指定该网关使用的控制器，主要是靠 Ingress 控制器不断监听 Kubernetes API Server 中 IngressClass 以及 Ingress 资源的的变动，配置或更新入口网关和路由规则。IngressClass实现了网关与后台的解耦，但也有着很多的局限性。Ingress 配置过于简单，只支持 http 和 https 协议的服务路由和负载均衡，缺乏对其他协议和定制化需求的支持，而且 http 路由只支持 host 和 path 的匹配，对于高级路由只能通过注解来实现，当然这取决于 Ingress 控制器的实现方式，不同的 Ingress 控制器使用不同的注解，来扩展功能，使用注解对于 Ingress 的可用性大打折扣；路由无法共享一个命名空间的网关，不够灵活；网关的创建和管理的权限没有划分界限，开发需要配置路由以及网关。当然也有很多第三方的网关组件，例如 istio 和 apisix 等，提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等，还可以处理南北流量以及服务之间的东西向流量。对外提供路由功能，对内提供流量筛选，已经很好的满足了当下网络环境的所有需求。但对于小集群来说，这两个网关的部署成本有点高；而且太多类型的网关，不同的配置项、独立的开发接口、接口的兼容性、学习成本、使用成本、维护成本以及迁移成本都很高。急需一种兼容所有厂商 API 的接口网关。所以应运而生，Kubernetes 推出了 Gateway API。Gateway API 是 Kubernetes 1.19 版本引入的一种新的 API 规范，会成为 Ingress 的下一代替代方案。它有着 Ingress 的所有功能，且提供更丰富的功能，它支持更多的路由类型选择，除了 http路由外，还支持 tcp 以及 grpc 路由类型；它通过角色划分将各层规则配置关注点分离，实现规则配置上的解耦；并提供跨 namespace 的路由与网关支持使其更适应多云环境等。与 Ingress Api 工作类似的，Gateway Controller 会持续监视 Kubernetes API Server 中的 GatewayClass 和 Gateway 对象的变动，根据集群运维的配置来创建或更新其对应的网关和路由。API 网关、入口控制器和服务网格的核心都是一种代理，目的在于内外部服务通信。更多的功能并不等于更好的工具，尤其是在 Kubernetes 中，工具的复杂性可能是一个杀手。
Web应用在防火墙内部运行，它们通过高带宽、低延迟的局域网访问服务。其他客户端在防火墙之外运行，通过较低带宽、较高延迟的互联网或移动网路访问。
FastGateway提供了基本的管理服务，提供简单的登录授权，和实时配置管理，从而实现动态路由的管理。
Gateway API 是由 SIG-NETWORK 社区管理的开源项目，项目地址：https://gateway-api.sigs.k8s.io/。主要原因是 Ingress 资源对象不能很好的满足网络需求，很多场景下 Ingress 控制器都需要通过定义 annotations 或者 crd 来进行功能扩展，这对于使用标准和支持是非常不利的，新推出的 Gateway API 旨在通过可扩展的面向角色的接口来增强服务网络。
Consul API Gateway 0.4 引入了对新 beta 版 Kubernetes Gateway API 和 HTTP 路径重写的支持。
随着管理众多独立部署的微服务变得越来越复杂，Kubernetes API Gateway已经成为高效系统架构的不可或缺的一部分。这些Gateway充当复杂的中间人，促进无缝的服务间通信，加强安全性，并优化 Kubernetes 生态系统内的资源利用。
作者： Mark Church（谷歌）、Harry Bagdi（Kong）、Daneyon Hanson（Red Hat）、Nick Young（VMware）、Manuel Zapf（Traefik Labs）
Flagger 团队很荣幸为你带来 Kubernetes Gateway API 支持，作为1.19.0 版本[1]的一部分。阅读本文，了解为什么这是 Flagger 的一个重大发展，以及如何利用它。
Gateway API（之前叫 Service API）是由 SIG-NETWORK 社区管理的开源项目，项目地址：https://gateway-api.sigs.k8s.io/。主要原因是 Ingress 资源对象不能很好的满足网络需求，很多场景下 Ingress 控制器都需要通过定义 annotations 或者 crd 来进行功能扩展，这对于使用标准和支持是非常不利的，新推出的 Gateway API 旨在通过可扩展的面向角色的接口来增强服务网络。
在我本人研究Yarp的时候经常用于公司项目的业务网关代理，这时候就个大佬问我是否可以实现动态加载HTTPS证书？那时候我说不太可能实现，然而在某一天我看到
网络安全已成为每个企业都面临的关键问题。几乎每天都有关于黑客如何窃取公司数据的头条新闻。
在 Kubernetes 集群边缘对外提供网络服务的时候，通常需要借助 Ingress 对象，这个对象提供了暴露 Service 所必须的核心要素，例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候，往往会有更多的具体需求，这时 Ingress 对象所提供的核心功能就有些力不从心了，各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解，来完成对 Ingress 特定行为的控制，完成各自的个性化功能，例如认证、路径变更、黑白名单等，这就让 Ingress 对象变成了一个奇怪的东西：结构化的核心结构，和非结构化的标注结合起来形成各种 Ingress 方言，并且后期还出现了 Traefik Middleware 这样的 CRD 配置，这给 Ingress 功能的集中管理造成了一个较大的困扰；另外 Ingress 中可以随意定制主机名、路径以及后端服务，也给共享集群的用户造成了一定的安全隐患。包括 Contour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达，客观上也让 Ingress 世界更为分裂。
利用 Gateway API 作为你可信赖的盾牌,保护你的 Kubernetes 王国。
Kubernetes Gateway API 是一组 API 类型，用于提供动态基础设施配置和高级流量路由功能。这些 API 面向角色、协议感知，并可扩展，适用于多种组织角色，如基础设施提供商、集群操作员和应用程序开发者。它们通过定制资源定义，并受到多种实现的支持。
Spring Cloud Gateway是一种用于构建微服务应用程序的开源API网关。它可以作为服务网格的入口，为微服务提供路由、负载平衡、安全、限流等功能。在开发过程中，可能会遇到一些问题，需要进行调试。本文将介绍如何进行Spring Cloud Gateway的调试，并给出相应的示例。
在分布式架构中，一个复杂的应用被拆分为多个小而独立的服务，每个服务都运行在自己的进程中，并通过轻量级的机制（如HTTP RESTful API）进行通信。每个服务都围绕一个特定的业务功能进行构建，并可以独立地进行开发、部署和扩展。
网络安全已成为每个企业都面临的关键问题。几乎每天都有关于黑客如何窃取公司数据的头条新闻。为了开发安全的软件并远离头条新闻，企业需要解决各种安全问题，包括硬件的物理安全性、传输和静态数据加密、身份验证、访问授权以及修补软件漏洞的策略，等等。无论你使用的是单体还是微服务架构，大多数问题都是相同的。本文重点介绍微服务架构如何影响应用程序级别的安全性。
作者 Envoy Gateway 社区：Alice Wasko (Ambassador Labs), Arko Dasgupta (Tetrate), Congqi Zhu (CECloud), Guy Daich (SAP), Huabing Zhao (Tetrate), Jianpeng He (Tetrate), Xunzhuo Liu (Tencent)
导读：网络安全已成为每个企业都面临的关键问题。几乎每天都有关于黑客如何窃取公司数据的头条新闻。为了开发安全的软件并远离头条新闻，企业需要解决各种安全问题，包括硬件的物理安全性、传输和静态数据加密、身份验证、访问授权以及修补软件漏洞的策略，等等。无论你使用的是单体还是微服务架构，大多数问题都是相同的。本文重点介绍微服务架构如何影响应用程序级别的安全性。
因为之前的测试结果让笔者对PHP使用GRPC很失望，如果使用HTTP的方式Guzzle还可以提供并发能力来降低接口消耗，Grpc只能阻塞，但是如果使用HTTP的话对于调用限制和GO调用GO来说不太友好，有没有一个两全其美的方式可以使用Grpc的前提下又兼容HTTP调用，让客户端可以更具自身情况自由选择，服务端工作只需要做一份呢？还别说真还有一个准备好的轮子那就是今天的主角《grpc-gateway》。
Ingress 是 Kubernetes 中使用最广泛的资源之一。该组件负责基础设施和应用程序，并有助于将应用程序和服务暴露到集群外。然而，Kubernetes 网络技术已经有了长足的发展，许多新的用例很快暴露了 Ingress 的局限性。
最近在 Kubernetes 生态中比较大的事情就是 KubeCon NA 2023 成功举办了，会上有很多不错的内容，也有很多重磅消息。目前会议的相关视频已经全部上传完成， 感兴趣的小伙伴可以通过 https://sourl.cn/xTUCvn 观看。
在微服务架构中，API Gateway扮演着至关重要的角色，它作为客户端与后端服务的统一入口，负责路由转发、安全控制、负载均衡等功能。本文将深入浅出地介绍API Gateway的基本配置，讨论常见问题、跨平台配置差异，以及如何避免易错点，附带代码示例，帮助你更好地理解和部署API Gateway。
Kubernetes SIG Network发布 了 Gateway API 的 1.1 版本。这次更新将多个关键特性转移到了标准通道（GA），包括对 服务网格 和 GRPCRoute 的支持。此外，还引入了会话持久性和客户端证书验证等新的实验性特性。
随着组织采用基于微服务的应用程序，管理这些服务的多种和分布式性质变得越来越具有挑战性。
在 Kubernetes 集群边缘对外提供网络服务的时候，通常需要借助 Ingress 对象，这个对象提供了暴露 Service 所必须的核心要素，例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候，往往会有更多的具体需求，这时 Ingress 对象所提供的核心功能就有些力不从心了，各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解，来完成对 Ingress 特定行为的控制，完成各自的个性化功能，例如认证、路径变更、黑白名单等，这就让 Ingress 对象变成了一个奇怪的东西：结构化的核心结构，和非结构化的标注结合起来形成各种 Ingress 方言，并且后期还出现了 Traefik Middleware 这样的 CRD 配置，这给 Ingress 功能的集中管理造成了一个较大的困扰；另外 Ingress 中可以随意定制主机名、路径以及后端服务，也给共享集群的用户造成了一定的安全隐患。包括 Cotour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达，客观上也让 Ingress 世界更为分裂。 例如要移除路径前缀，Nginx Ingress 控制器需要使用 nginx.ingress.kubernetes.io/rewrite-target 注解，而 Traefik 1.7 中则需要使用 traefik.ingress.kubernetes.io/rule-type: PathPrefixStrip 注解。
银联支付 之前做过一次银联支付的配置工作，然而第二次配置，虽然有点印象，但最终还是翻查了半天资料和代码，才完成了配置。这里对银联支付所需做一个简单的整理说明，以便后期查阅，同时分享给大家。 至于如何申请账号，那是公司层面的操作，这里我不清楚，也不做相关的介绍了，我只清楚拿到账号之后的操作。 申请成功以后你会拿到以下四个文件，按照文档流程生成相应的证书即可： License.doc 附件1：生产证书下载、导出及上传流程.docx 附件2：自助化入网测试平台说明书.doc 附件3：云闪付业务商户入网服务指引.
Spring Cloud Gateway是类似Nginx的网关路由代理，有替代原来Spring cloud zuul之意：
AI-Gateway是一款针对大语言模型的统一API接口，该接口可以用在应用程序和托管的大语言模型（LLM）之间，该工具可以允许我们通过一个统一的API接口将API请求转发给OpenAI、Anthropic、Mistral、LLama2、Anyscale、Google Gemini等大语言模型。
顾名思义，网关限流是通过网关层对我们的服务进行限流，达到保护后端服务的作用。在微服务架构的系统中，网关层可以屏蔽外部的请求直接对服务进行调用，网关层可以对内部服务进行隔离，保护的作用。
SIA-GATEWAY是基于SpringCloud微服务生态体系下开发的一个分布式微服务网关系统。具备简单易用、可视化、高可扩展、高可用性等特征，提供云原生、完整及成熟的接入服务解决方案。本文介绍API网关的安装部署。
AddRequestHeader GatewayFilter Factory通过配置name和value可以增加请求的header。 application.yml：
大家都知道在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调 用。
普元EOS 8 API Gateway作为一个独立模块，可以对API进行创建、发布、维护、监控等全生命周期管理。
关于 gRPC 的文章，我们之前写过几篇，如果读者朋友还对 gRPC 不了解，我建议您可以翻阅一下公众号的历史文章。
Spring Cloud Gateway 是一款基于 Spring 5，Project Reactor 以及 Spring Boot 2 构建的 API 网关，是 Spring Cloud 微服务生态的主要组件之一。Spring Cloud Gateway 主要负责接口请求的路由分发，并且支持对请求的安全验证，流量监控和流量控制等扩展操作。另外值得一提的点是，Spring Cloud Gateway 默认采用了非阻塞 I/O 模型实现请求路由的分发。对于处理一些I/O 耗时长的请求上，相比其他一样用 Java 编写采用的同步阻塞I/O 模型的网关性能更高，处理的并发数也更高，避免了因为 I/O 阻塞（网络调用，数据库操作等）导致线程空闲下来，仍能继续处理响应其他请求。
之前做过一次银联支付的配置工作，然而第二次配置，虽然有点印象，但最终还是翻查了半天资料和代码，才完成了配置。这里对银联支付所需做一个简单的整理说明，以便后期查阅，同时分享给大家。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
