kong

charset UTF-8; error_log syslog:server=kong-hf.konghq.com:61828 error; error_log logs/error.log notice; client_max_body_size 0; proxy_ssl_server_name on; underscores_in_headers on; lua_package_path './?.lua;./?/init.lua;;;'; lua_package_cpath ';;'; lua_socket_pool_size 30; lua_max_running_timers 4096; lua_max_pending_timers 16384; lua_shared_dict kong 5m; lua_shared_dict kong_db_cache 128m; lua_shared_dict kong_db_cache_2 128m; lua_shared_dict kong_db_cache_miss 12m; lua_shared_dict kong_db_cache_miss_2 12m; lua_shared_dict kong_locks 8m; lua_shared_dict kong_process_events 5m; lua_shared_dict

参考：https://www.cnblogs.com/chenjinxi/p/8724564.html 一、简介 Kong，是由 Mashape 公司开源的，基于Nginx的API gateway。 二、特点 可扩展：支持分布式 模块化 功能：授权、日志、ip限制、限流、api 统计分析（存在商业插件 Galileo 等、也可自己研发）、请求转化、跨域（CORS）、其他功能通过lua编写插件实现。 ... 三、调用流程 Once Kong is running, every request being made to the API will hit Kong first, and then it will be proxied to the final API. In between requests and responses Kong will execute any plugin that you decided to install, empowering your APIs. Kong is effectively going to be the entry point for every API request. 译文：Kong启动之后，每个请求先经过Kong，然后由Kong代理 访问最终的API。在请求和响应之间，Kong可以执行任何已配置的插件

使用的软件 Unbuntu 虚拟机（有自己的服务器更好） PostgreSQL kong kong-dashboard docker spring boot 安装 PostgreSQL kong 需要使用到数据库，目前支持PostgreSQL和Cassandran ,我选择大象数据库，安装过程省略，可以参考这篇文章。 Ubuntu PostgreSQL安装和配置 安装完后建一个kong的用户、密码为kong、建一个kong 数据库: sudo -u postgres psql 进入，提示符变成： postgres=# postgres=# create user kong with password 'kong'; CREATE ROLE postgres=# CREATE DATABASE kong OWNER kong; CREATE DATABASE postgres=# 至此，PostgreSQL已经安装和配置好了。 安装kong 下载kong的源文件，下载地址： https://getkong.org/install/ubuntu/ 下载完成之后会有这样一个文件kong-community-edition-0.11.0.*.deb，cd到这个文件的目录： $ sudo apt-get update $ sudo apt-get install openssl

一. 微服务 二. Api Gateway 三. Kong 的使用 一. 微服务 对于一些传统的 大型项目，传统的方式会有一些缺陷，比如说 新人熟悉系统成本高（因为整个系统作为一个整体，彼此会有一定的牵连），项目重 启时间长，重构困难（对于一个新技术的引入，可能需要对整个项目推到重来），不易于更换新的技术，并且整个项目会慢慢变成巨无霸。 所以说就会有微服务这种概念， 一个服务实现一个不同的特性或者功能。每一个独立的微服务都是一个小型应用。 一些微服务可能会暴露一些api 给 其他的一些微服务或者是客户。如下图1（把各个业务拆分）： 图1 对于微服务，目前 像Netflix ，亚马逊，ebay 等都有应用。 当然，微服务也有一定的缺陷，比如说 每个服务（每个应用） 如果都有一个 数据库的话，那么如何维持 数据库事务。再比如说，服务之间的调用可 能会由于 网络的原因变得不可达，那么 代码中要额外增加 请求失败的代码。 二. Api Gateway api gateway 即 api 网关。所有的请求首先会经过这个网关。这有点类似于前端控制器模式，也有点类似于 Facade模式。如下图2所示： 图2 由于所有的请求会先经过这个 api 网关， 所以 可以在 这里做 权限控制，安全，负载均衡，请求分发，监控等等 。 那么，为什么要用 这个 api gateway 这个东西，主要原因在于

Kong Canary 插件 用于程序的灰度发布 文档地址在 这里 版本：商业版，或免费试用版 词汇表 plugin：在 Kong 向后端转发一个请求 之前/之后，可执行指定操作 Service：Kong中的实体(entity)，代表一个后端API或微服务 Route：Kong中的实体(entity)，代表一个转发规则 Consumer：Kong中的实体(entity)，为向Kong发起请求的外部用户/服务 Credential：伴随 Consumer 的唯一字符串，也用于指代一个API key upstream service：Kong 代理的业务 API/服务 API：代表后端服务的实体。CE 0.13.0 和 EE 0.32 后，更倾向用 Service 来替代 API 配置 在 Service 上配置 plugin 当有数据库配合时 运行以下命令 $ curl -X POST http://kong:8001/services/{service}/plugins \ --data "name=canary" 当没有数据库配合时 把以下内容加入配置文件 plugins: - name: canary service: {service} config: {service}是plugin作用的服务 id/name，需要用实际值替换 对 Route 生效 当有数据库配合时

使用 Kong Community Edition（社区版 v1.3.0）来搭建一个负载均衡器，由于 Kong 是基于 Openresty 的，而 Openresty 又是 Nginx 的二次封装，所有很多配置项和 Nginx 类似。 来看一个较为典型的 Nginx 负载均衡配置 upstream hello { server localhost:3000 weight=100; server localhost:3001 weight=50; } server { listen 80; location /hello { proxy_pass http://hello; } } nginx 监听来自本地 80 端口的请求，如果路径与 /hello 匹配，便将请求原封不动的转发到名称为 hello 的upstream，而该 upstream 我们配置了一个负载均衡器，会路由到本地的 3000 端口和 3001 端口。 @SpringBootApplication @RestController public class KongDemoApplication { public static void main(String[] args) { System.setProperty("server.port","3000"); //System.setProperty("server

修改kong配置文件 vim /usr/local/kong/.kong_env 修改属性 real_ip_header = X-Forwarded-For # 从哪个header字段取真实IP real_ip_recursive = on # 是否递归过滤IP trusted_ips = 10.116.0.0/16 # 需要过滤的IP，可以用网段表示，多个用逗号分隔 重载kong cd /usr/local/bin/ ./kong reload 备注 前提是之前的代理服务器将真实IP已经设置进X-Forwarded-For里了，这样无论你的服务被代理几层，你都能获取真实IP。 来源： CSDN 作者： stone5751 链接： https://blog.csdn.net/stone5751/article/details/103911676

通过详细解释Kong的路由功能和内部工作原理来介绍Kong的代理功能 Kong公开几个接口，可以调整两个配置属性： proxy_listen：定义了一个地址/端口列表——Kong将接受来自客户端的流量并代理上游服务 admin_listen：同样定义了一个地址/端口列表——但这些仅限于管理员访问 从0.13.0版本开始，API实体被弃用，使用 Routes 及 Services 实体替代 术语 client：指下游客户端向Kong的代理端口发出请求 upstream service：指位于Kong后面的API/服务，客户端请求被转发到该服务 Service：服务实体是每个上游服务的抽象。如数据转换微服务、计费API等 Route：指Kong实体——Route是进入Kong的入口，并为要匹配的请求定义规则，并路由到给定的服务 Plugin：指Kong的Plugins，在代理生命周期中运行的业务逻辑。插件可以通过管理API进行配置——可以全局配置(所有入口)，也可以在特定的路由和服务上配置 概览 从上层看，Kong在其配置的代理端口上监听HTTP流量(默认为8000和8443)。Kong将根据配置的路由评估任何传入HTTP请求，并尝试找到匹配的路由。如果请求与路由规则匹配，Kong将处理代理请求。因为每个路由都链接到一个服务，Kong将运行在路由及其关联服务上配置的插件

最近工作需要，加上国内Kong的文章相对缺乏（搜来搜去就那么两篇文章），而且官方文档在某些demo上也有一些过时的地方，遂提笔记录下这些，希望能有帮助。 先随大流介绍下KONG（主要参考官网）： 官方站点：https://getkong.org 官方描述：Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware) . Kong runs in front of any RESTful API and is extended through Plugins , which provide extra functionality and services beyond the core platform. Kong是一个可扩展的，开源的API层，运行在RESTful前端，可通过插件扩展（认证，安全，流量控制，分析&监控，转换，日志） 使用Kong前，内部API架构 1.通用模块在各API中没有复用 2.难以维护 3.不影响其他服务状态下难以扩展 4.由于系统限制生产效率低下 使用Kong后的API架构 1.Kong统一管理通用插件 2.高效，可扩展的分布式架构体系 3.通过简单的命令即可完成扩展 4.团队专注于业务，Kong来处理 REST 来源： https:/

/etc/kong/kong.yml services: name: my-service url: http://www.kuaidi100.com/ plugins: name: key-auth routes: name: my-route paths: /aa consumers: username: my-user keyauth_credentials: key: my-key plugins: name: syslog consumer: my-user service: my-service 加载： kong reload -c /etc/kong/kong.conf 测试： curl -i -X GET --url " http://192.168.8.106:8000/aa/query?type=yuantong&postid=11111111111 " --header "apikey:my-key" --header "host:www.kuaidi100.com" 返回： {"message":"ok","nu":"11111111111","ischeck":"1","com":"yuantong","status":"200","condition":"F00","state":"3","data":[{"time":"2019-10-05 16:51