kong 官方文档： https://docs.konghq.com/getting-started-guide/2.4.x/overview/ https://docs.konghq.com/enterprise/2.4.x/admin-api/#service-object
目前互联网后台架构一般是采用微服务，或者类似微服务的形式，应用的请求通常需要访问多个后台系统。如果让每一个后台系统都实现鉴权、限流、负载均衡、审计等基础功能是不合适的，通用的做法是把这些功能抽离出来放到网关层。Kong是目前最流行的网关平台。
upstream是Kong网关将流量转发到的多个target的集合，target可以是域名、ip，不同target可以有不同的port，且可分配不同的权重。通过使用upstream，Kong网关提供如下功能：
Kong API网关专为混合和多云构建，针对微服务和分布式架构进行优化。它是一个开源的API网关和微服务管理平台，它提供了统一的入口和出口，使得微服务架构下的API对外访问变得更加便捷和安全。
Api网关我们之前是用 .netcore写的 Ocelot的，使用后并没有完全达到我们的预期，花了些时间了解后觉得kong可能是个更合适的选择。
最近在学习Kong网关，因此根据老习惯，我会将我的学习过程记录下来，一来体系化整理，二来作为笔记供将来翻看。由于我司会直接使用Kong企业版，学习过程中我会使用Kong开源版。
作者 | 屠正松 苏钰 责编 | 梦依丹 出品 | APISIX 技术团队投稿 云原生时代下，企业逐渐向云上迁移，越来越多的应用和服务都在进行容器化改造，服务之间的流量也开始爆发性的增长。为了能高效地管理这些规模庞大的 API，API 网关开始在技术领域大展身手。 用户除了需要 API 网关提供请求代理、熔断限流、审计监控等常规能力外，更多开始关注云原生兼容性、支撑场景的多样性，以及更好的性能及稳定性。在这样的背景下，以 Apache APISIX 和 Kong 等为代表的云原生 API 网关
最近公司打算重构API网关，给定的硬性条件是支持lua脚本，kubernetes可部署，可解析lua，另外需要支持身份认证，IP黑白名单，限流，负载均衡等一些功能，为此，在技术选型上锁定了kong以及APISIX，最终选择了kong。
多租户方案是指由多个客户或租户共同使用应用的解决方案。 租户不同于用户，来自单个组织、公司或组的多个用户形成一个租户。
Kong 是 Mashape 开源的一款云原生架构下的分布式 API 网关，其性能和可扩展性在同类组件中，表现都很优异。Kong 官方提供了很多直接可用的插件，此外，Kong 还可以通过插件扩展已有功能。
，有点懒怠。最近抽空捣鼓了 Kong 网关的使用实践，微服务网关之前的文章也写过，读者可以翻看之前的文章推送。插件是 Kong 扩展的重要特性，这次除了会介绍 Kong 的相关实践之外，还会讲解 Kong 自定义插件的实现。
本文主要分析了 NGINX、Kong、APISIX、Tyk、Zuul、Gravitee 几个开源 API 网关架构及基本功能，测试了一定场景下各个 API 网关的性能。
来源：https://zhuanlan.zhihu.com/p/358862217 强烈推荐大家试试国产开源的 API 网关 https://github.com/apache/apisix，非常不错。 本文，我们会看到 APISIX 和其它开源的网关对比，给胖友的武器库提供更多选择！ “ 这篇文章由刚哥授权分享，刚哥是 Splunk Information Technology 的架构师，Linkedin：https://www.linkedin.com/in/taogang/。 本文主要分析了 NGINX、Kong、APISIX、Tyk、Zuul、Gravitee 几个开源 API 网关架构及基本功能，测试了一定场景下各个 API 网关的性能，文末附有源码地址。” 正文从这里开始： 春未老，风细柳斜斜。试上超然台上望，半壕春水一城花。烟雨暗千家。 寒食后，酒醒却咨嗟。休对故人思故国，且将新火试新茶。诗酒趁年华。 苏轼·送《望江南·超然台作》 温哥华的春天来了，上面的图就是我家门口的 Marine Gaetway，我今天就在这春色中和大家探讨一下 API Gateway。
上篇文章中，我们介绍了如何通过Kong网关来将API对外暴露服务，但是这样并没有体现Kong的优势。接下来我们就介绍几种API常见功能(限流、鉴权等)，这些功能传统需要开发介入才能完成，我们看看Kong怎么免开发实现这些功能。
在微服务架构之下，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。如上图左所示，在旧的服务治理体系之下，鉴权，限流，日志，监控等通用功能需要在每个服务中单独实现，这使得系统维护者没有一个全局的视图来统一管理这些功能。API 网关致力于解决的问题便是为微服务纳管这些通用的功能，在此基础上提高系统的可扩展性。如右图所示，微服务搭配上 API 网关，可以使得服务本身更专注于自己的领域，很好地对服务调用者和服务提供者做了隔离。
本文主要分析了 Nginx、Kong、APISIX、Tyk、Zuul、Gravitee 几个开源 API 网关架构及基本功能，测试了一定场景下各个 API 网关的性能，文末附有源码地址。
Kong开源版不提供dashboard支持，只有Kong企业版才有该功能。但有第三方控制台Konga同样可以友好地管理Kong Admin API对象，快速安装如下：
Kong、OpenResty都是基于Nginx打造的新一代服务器。它们兼具Web服务器的功能，但侧重于网关层特性的延伸
8月动态 云原生网关 【商业化】Kong网关正式商业化：自2022年8月28日起，微服务引擎 TSE 云原生网关中的 Kong 已经结束免费公测，正式开始计费。 【新功能】Kong网关上线带宽调整能力：Kong网关上线公网带宽调整能力，您可以根据实际业务情况，修改公网带宽，调整为适合您业务的配置。 【新功能】Kong网关支持对接注册中心（包括TSE或自建的 Nacos、Consul 和 PolarisMesh）和容器服务（包括TKE，EKS）：您可以将注册有后端服务的注册中心或部署在容器的服务添加到网关服务
微服务实践的第二个关键组件，微服务API网关设计，API网关是对微服务做统一的鉴权、限流、黑白名单、负载均衡等功能实现,这篇我们先来介绍Api网关的意义和安装kong/konga需要的组件。
在微服务架构中，API网关是核心的基础服务之一。在微服务流行之前，API网关已经在很多架构中扮演重要的角色，尤其是开放平台，此时的API网关是系统的统一入口，肩负了很多的业务责任，比如限流，计费等功能。而在微服务架构中，API网关可能往往需要兼顾内部和外部的所有微服务，承担更多的职责。
四段分别代表 userId, 时间戳 time, 随机数 nonce, 加密算法得到的 sign
本文整理自爱奇艺高级研发师何聪在 Apache APISIX Meetup - 上海站的演讲，通过阅读本文，您可以了解到基于 Apache APISIX 网关，爱奇艺技术团队是如何进行公司架构的更新与融合，打造出全新的网关服务。欢迎感兴趣的同学点击阅读原文访问 bilibili 观看视频。 作者何聪，高级研发师，IIG 基础架构部 - 计算云，主要负责爱奇艺网关开发和运维工作
今天准备再详细讲解下 API 网关的基础概念，使用场景和核心功能，以及基于 API 网关核心引擎做的 API 全生命周期管理功能扩展等，最好再介绍下当前主流的开源 API 网关引擎。
温铭 支流科技 CEO 兼联合创始人 本文将从云原生时代的机遇和挑战说起，介绍一个全新的开源高性能云原生 API 网关——Apache APISIX，探讨如何解决云原生时代 API 网关所面临的一些痛点，最后介绍该开源项目未来的规划。 背景 云原生的机遇和挑战 很多应用和服务都在向微服务、容器化迁移，形成新的云原生时代。云原生是下一个 5-10 年的技术颠覆，重写了传统企业的技术架构，例如云原生中的 Kubernetes 颠覆了传统操作系统，所有的“主机”（node 上的容器）由 Kubernetes
前面两篇文章介绍了微服务为什么需要API网关及Kong网关的特点，本篇文章就实际安装部署Kong，看看Kong的目录结果及是如何配置管理的，加深对Kong的理解。
在前后端分离的设计中，不管使用什么语言，后端都需要提供 WebAPI 给前端使用。如果是一个平台级的产品，还有可能需要将平台的公共 API 提供给第三方系统使用，这些都要考虑到 API 的设计。
随着业务的扩展，微服务会不对增加，相应的其对外开放的 API 接口也势必增多，这不利于前端的调用以及不同场景下数据的返回，因此，我们通常都需要设计一个 API 网关作为一个统一的 API 入口，来组合一个或多个内部 API。
微服务架构中，API网关充当着非常重要的一环，它不仅要负责外部所有的流量接入，同时还要在网关入口处根据不同类型请求提供流量控制、日志收集、性能分析、速率限制、熔断、重试等细粒度的控制行为。API网关一方面将外部访问与微服务进行了隔离，保障了后台微服务的安全，另一方面也节省了后端服务的开发成本，有益于进行应用层面的扩展。与此同时，API网关也具备解决外界访问带来的安全问题，如TLS加密、数据丢失、跨域访问、认证授权、访问控制等。因而笔者认为云原生API网关暴露的风险值得我们去进一步探索。
本文准备围绕七个点来讲网关,分别是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关对比,对基础概念熟悉的朋友可以根据目录查看自己感兴趣的部分。
在整个微服务架构中，API网关充当着非常重要的一环，它不仅要负责外部所有的流量接入，同时还要在网关入口处根据不同类型请求提供流量控制、日志收集、性能分析、速率限制、熔断、重试等细粒度的控制行为。API网关一方面将外部访问与微服务进行了隔离，保障了后台微服务的安全，另一方面也节省了后端服务的开发成本，有益于进行应用层面的扩展。与此同时，API网关也应具备解决外界访问带来的安全问题，例如TLS加密、数据丢失、跨域访问、认证授权、访问控制等。本文尝试分析目前主流的云原生微服务API网关成熟度以及各自具备的安全功能，并比较各自带来的优劣，尤其在安全层面上，开源软件都做了哪些工作，是否全面，若不全面我们又该如何弥补。
API网关定位为应用系统服务接口的网关，区别于网络技术的网关，但是原理是一样的。API网关统一服务入口，可方便实现对平台众多服务接口进行管控，如对访问服务的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权，以及响应数据的脱敏、流量与并发控制，甚至基于API调用的计量或计费等。
严选自 2016 年诞生以来，不论从业务、技术还是体量，每年都在飞速发展。而作为严选对外服务的总入口，网关承接了主要的业务流量，保障着严选业务的稳定运行，并帮助业务进行更好的容灾和降级。
在 0.13.X 版本之前，Kong 的核心域模型名为 API Object Routes，从 0.13.X 版本开始，Kong 引入了 Service/Route Object，把 API Object 标记为 deprecated。在当前的 1.1.X 版本中关于 API Object 部分的配置已经被移除了。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
本文准备围绕七个点来讲网关，分别是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关对比，对基础概念熟悉的朋友可以根据目录查看自己感兴趣的部分。 什么是网关 网关，很多地方将网关比如成门， 没什么问题， 但是需要区分网关与网桥的区别， 网桥 工作在数据链路层，在不同或相同类型的LAN之间存储并转发数据帧，必要时进行链路层上的协议转换。可连接两个或多个网络，在其中传送信息包。 网关 是一个大概念，不具体特指一类产品，只要连接两个不同的网络都可以叫网关，网桥一般只转发信息，而网关可能进行包
入门篇 第1章 全面了解Kong网关 Kong是一款基于OpenResty（Nginx+Lua模块）编写的高可用、易扩展的开源API网关，专为云原生和云混合架构而建，并针对微服务和分布式架构进行了特别的优化 微服务网关具有负载均衡、缓存、路由、访问控制、服务代理、监控、日志等多项功能。API网关在微服务架构中正是以微服务网关的身份存在 由于企业间信息交流和共享变得日益频繁，企业需要将自身数据、能力等向外开放，通常以接口的方式向外提供，如淘宝开放平台、腾讯的QQ开放平台和微信开放平台。开放平台的引入必然涉及客
Kong 是一个企业级服务网关，底层是使用lua语言，整合Nginx 实现了强大的服务转发，路由，验证功能，
客户端与各个业务子系统的通信必须通过一个统一的外观对象进行，外观模式提供一个高层次的接口，使得子系统更易于使用：
大家好，很久没有写博客了，最近半年也是比较的忙，所以给关注我的粉丝们道个歉。去年和朱永光大哥聊的时候提了一下我们的这个方案，他说让我有空写篇博客讲一下，之前是非常的忙，所以这次趁着有些时间就写一下我们这边关于版本控制的方案吧。
Kubernetes已经成为在服务中编排容器和服务的实际方法。但是我们如何让集群外部的服务访问集群内部的内容呢？Kubernetes附带了Ingress API对象，用于管理对集群内服务的外部访问。
为了提高系统的性能和可靠性，将应用服务进行拆分微服务化。作为系统入口的 API 网关也逐渐成为了标配。
用 Spring Cloud 微服务实战中，大家都知道用 Zuul 作为智能网关。API 网关（API Gateway）主要负责服务请求路由、组合及协议转换。下面是大家的总结：
网关，就是指一个流量的集中式出入口。而 API Gateway，顾名思义，就是在 Gateway 上再添加了一些 API 相关的功能后得到的东西。 具体而言，API Gateway 就是比普通的网关多干了一些以前我们在应用内部实现的事：身份认证，权限控制，基于来源的流量控制，日志服务等，甚至是直接在第七层魔改 HTTP 请求的内容。好处有：
所谓网关，主要作用就是连接两个不同网络的设备，而今天所讲的 API 网关是指承接和分发客户端所有请求的网关层。
领取专属 10元无门槛券
手把手带您无忧上云
