kong

目录 npm方式安装 1. 准备依赖环境 2. 安装konga 3. 配置 4. 环境变量( more ) 5. 数据库 配置 初始化/迁移 6. 运行 Docker方式安装 关于Kong-Dashboard 前言 ： 当前KONG的社区版是没有dashboard的，但是付费的企业版是有带的。 GitHub上开源且还在更新维护的dashboard有两个 ： kong-dashboard ：Kong Dashboard 3.3.0 is only partially compatible with Kong 0.13. It does not support the new Service and Route objects introduced in Kong 0.13. konga ：From 0.14.0 onwards, Konga is ONLY compatible with Kong >= 1.0.0 根据GitHub说明得知 ： kong-dashboard 最新版本v3.6.0，只能支持到kongv0.14.x，对于kong的更高版本，功能支持不齐全； konga 从0.14.0开始，仅与Kong> = 1.0.0兼容。Konga 0.12+与Kong 0.14+完全兼容。较早的Kong版本仍然兼容，但不能保证。 虽然，市面上 kong-dashboard

介绍 upstream 就是一个虚拟的服务。可用于配置多个target目标服务时实现负载均衡的效果。 注意：service的host指的就是upstream的name。 同时upstream提供了一个health check方法，用于检查target目标服务是否健康。以此控制启用或禁用target目标服务 和upstream关联的kong模块:service ,target 主要参数: algorithm 负载算法： round-robin（默认） , consistent-hashing , or least-connections healthchecks.active.http_path 健康检查路径：默认/，该地址是指在目标服务器上，适用于目标服务器的所有请求 命令 1、add upstream 方法 post api: /upstreams 2,list upstream ,retrieve upstream 方法：get api： /upstreams /upstreams /upstream id or name /targets/{target host:port or id}/upstream 关联指定target目标服务的upstream 3，update upstream 方法：patch api: /upstreams/{upstream name or

介绍 route 是一套匹配客户端请求的规则。每个route都会匹配一个service，每个service可定关联多个route。 可以说service：route=1：n。一对多的关系。每个匹配到route的请求都会代理到对应的service上。 路由可以设定不同的协议，不同的协议配置的属性不一样。官网介绍如下： For http , at least one of methods , hosts , headers or paths ; For https , at least one of methods , hosts , headers , paths or snis ; For tcp , at least one of sources or destinations ; For tls , at least one of sources , destinations or snis ; For grpc , at least one of hosts , headers or paths ; For grpcs , at least one of hosts , headers , paths or snis . 在kong网关服务中，可以和路由route匹配的有两类：service和plugin 在操作route的命令中也可以依赖这两类进行操作

具体命令行操作只需按照官网一步一步来即可（ https://docs.konghq.com/1.4.x/getting-started/configuring-a-service/ ），这里介绍图形化操作 1.配置注意地址(kong的管理地址,默认为http://kong server机器或绑定的域名:8001)后面不要多加"/"如下图 否则点击API会出现not found api之类的提示,当然也要确保kong server正常运行中 2.新增API与使用新增的API时,需要注意如果需要使用地址方式指向api即 需要勾选strip-request path 如果使用head中带请求地址的方式,需要在head中带 X-Host-Override post.demo (即request host) 使用时需要注意,请求的地址为http://kong server机器或绑定的域名:8000 (下图为在url中带请求的api的方式) 3.插件使用实例,使用key-auth。 i.需要在api基础上新建插件auth key ii.设置插件 keyname(需要注意此keyname会在后面url中使用) 当启用插件后 如果后面keyname在地址栏或header中不正确会有如下提示 iii.新建customer并设置其key的内容也可以认为为keyname对应的值上面

service介绍： service 是声明了一组name、host、port、protocol等配置的函数。可以绑定route、upstream上下游服务。并且对于route、upstream可以绑定多个。 新增service后，kong会自动分配一个id值，该id为service的唯一标识。可用于后期修改、查看以及绑定route、upstream。 -------------------------------------------------------------------------------------------------------------------------------------------------------------- 命令： kong网关的命令接口基本符合restful api风格。官网上的addservice、list service只是模块名称，不是命令，不要混淆。 不同的命令主要区分在http的请求方法（get、post、put、patch、delete）。 1、addservice（新增服务） post 方法，api： http://127.0.0.1:8001/services 参数主要放置在requestBody内。 上图是使用postman发起的请求，可以看出使用的是post请求，参数放置在body里。 创建成功后

目录 Installation 使用数据库 Configuration Kong Run 【官方链接】 https://docs.konghq.com/install 【Packages】 GPI: https://kong.bintray.com/kong-rpm/centos/7/ Community: https://kong.bintray.com/kong-community-edition-rpm/centos/7/ Installation yum install epel-release yum install https://kong.bintray.com/kong-community-edition-rpm/centos/7/kong-community-edition-1.1.2.el7.noarch.rpm --nogpgcheck whereis kong # [output] kong: /etc/kong /usr/local/bin/kong /usr/local/kong 如上，/ect/kong目录为配置文件目录，安装后会有一个官方的默认配置文件kong.conf.default 复制这个文件为kong.conf即可启动Kong. /usr/local/kong为Kong的运行目录，Kong启动后会生成nginx的配置文件放在此目录

目录 为什么需要 API 网关( more ) 为什么使用Kong Kong 的管理方式 高可扩展性的背后—插件机制 [前言] : Kong 是一个云原生，高效，可扩展的分布式 API 网关。 自 2015 年在 github 开源后，广泛受到关注，目前已收获 1.68w+ 的 star，其核心价值在于高性能和可扩展性。 为什么需要 API 网关( more ) 在微服务架构之下，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。如上图左所示，在旧的服务治理体系之下，鉴权，限流，日志，监控等通用功能需要在每个服务中单独实现，这使得系统维护者没有一个全局的视图来统一管理这些功能。API 网关致力于解决的问题便是为微服务纳管这些通用的功能，在此基础上提高系统的可扩展性。如右图所示，微服务搭配上 API 网关，可以使得服务本身更专注于自己的领域，很好地对服务调用者和服务提供者做了隔离。 为什么使用Kong SpringCloud 玩家肯定都听说过 Zuul 这个路由组件，包括 Zuul2 和 Springcloud Gateway 等框架，在国内的知名度都不低。没错，我称呼这些为组件 Or 框架，而 Kong 则更衬的上产品这个词。在此我们可以简单对比下 Zuul 和 Kong。 举例而言，如果选择使用 Zuul，当需要为应用添加限流功能，由于 Zuul

apiVersion: v1 kind: Namespace metadata: name: kong --- apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: kongconsumers.configuration.konghq.com spec: additionalPrinterColumns: - JSONPath: .username description: Username of a Kong Consumer name: Username type: string - JSONPath: .metadata.creationTimestamp description: Age name: Age type: date group: configuration.konghq.com names: kind: KongConsumer plural: kongconsumers shortNames: - kc scope: Namespaced validation: openAPIV3Schema: properties: credentials: items: type: string type: array custom_id: type

global加入了分页内存管理 对比linux内存伙伴系统 来源： https://www.cnblogs.com/bloomingFlower/p/11911873.html

对于刚开始学习kong网关，总是一脑子浆糊迷迷糊糊。虽然已经安装好，但却不知道接下来如何下手， 因为包含项太多：service、routes、upstream、consumer、plugins等等。一时不知从何下手配置服务。 最后又重新打开kong网关的基本介绍，看完之后决定先把问题简单化。所以第一步就先搭建一个service和route， 随后又构建了upstream。这三部分完成之后，一个基本的网关功能就算实现了。 简单画了一个流程图，基本表现了kong网关的调用过程。一共分为五部分：用户客户端、routes、services、upstream、target服务端。 客户端就是调用方， routes路由匹配客户端的请求规则。匹配成功后分配到service层。一个路由指向一个service，一个service可以被多个不通规则的路由routes指向。 　　访问地址是kong网关地址+代理端口（默认http:8000,https:8443） service服务是一个抽象服务层，可以用于指向具体物理服务（target），也可以指向upstream用于实现物理服务的负载效果。一个service对于upstream、target都是一对一的关系。 upstream主要用于实现kong的负载功能，一个service匹配到一个upstream后