大家好，又见面了，我是你们的朋友全栈君。
传统服务如下左图，通用函数重复使用在多个服务中，系统庞大僵化难以管理，由于会冲击其他服务导致的扩展困难，由于系统限制导致生产率低，如下右图是kong的解决方案
kong特点：
云原生：平台无关，kong可以在裸机和Kubernetes上运行。
动态负载平衡：跨多个上游服务的流量负载均衡。
基于哈希的负载平衡：具有一致的哈希和粘性会话。
断路器：智能跟踪不健康的上游服务。
健康检查：主动和被动监控您的上游服务。
服务发现：解析第三方DNS解析程序（如Consul）中的SRV记录。
Serverless：直接从kong调用AWS lambda或openswish函数。
WebSockets：通过WebSockets与上游服务通信。
OAuth2.0：轻松地向API添加OAuth2.0身份验证。
日志记录：通过HTTP、TCP、UDP或磁盘记录对系统的请求和响应。
安全性：ACL、bot检测、白名单/黑名单IP等…
系统日志：记录到系统日志。
ssl：为基础服务或api设置特定的ssl证书。
监控：实时监控提供关键的链路和性能指标。
转发代理：使Kong作为透明的HTTP代理。
认证：HMAC、JWT、BASIC等 。
速率限制：基于多个变量的阻塞和限制请求。
转换：添加、删除或操作HTTP请求和响应。
缓存：在代理层缓存和响应服务。
cli：从命令行控制您的Kong集群。
REST API：Kong可以使用RESTful API进行管理操作，以获得最大的灵活性。
地理复制：配置跨不同区域的更新。
故障检测和恢复：如果您的Cassandra节点之一发生故障，Kong不会受到影响 。
集群：集群中kong节点自动保持更新。
可伸缩性：Kong支持横向扩展。
性能：Kong核心通过扩展和使用nginx，可以轻松地处理负载。
插件：支持向Kong和API添加功能的可扩展的架构。有关插件和集成的更多信息，您可以查看KongHub。
kong架构：
OpenResty—定制的Nginx模块(Lua虚拟机) Kong—在OpenResty中运行的Lua脚本网关程序 配置数据中心—基于数据库 Router—三种路由规则 LoadBalance—Dns解析和Ring-balancer Plugin—可扩展的插件 Kong核心基于OpenResty构建，对请求/响应使用Lua脚本处理； Kong Restful API提供了管理kong的功能； 数据中心用于存储Kong集群节点信息、API、消费者、插件等信息，目前提供了PostgreSQL和Cassandra支持，如果需要高可用建议使用Cassandra； Kong使用了DNS-Balancer和Ring-Balancer两种均衡模式 Kong会代理HTTP请求，根据HTTP主机头、请求URI和请求方式(GET/POST等)匹配路由规则，找到实际处理请求的后端服务 Kong插件支持裁剪添加插件，插件不仅可以处理请求，还可以定义API，操作数据库，本身提供了许多插件，支持鉴权认证、安全控制、流量调控和请求报文转换等 DNS解析器将使用标准配置文件/etc/hosts和etc/resolv.conf ，会将主机名解析为SRV或A记录
流程：
init_by_lua* 发生在master进程启动阶段。这里会对数据访问层进行初始化，加载插件的代码，构造路由规则表。
init_worker_by_lua* 发生在worker进程启动阶段。这里会开启数据同步机制，执行每个插件的init_worker方法。
set_by_lua* 处理请求第一个执行阶段。这里可以做一些流程分支处理判断变量初始化。kong没有使用该阶段。
rewrite_by_lua* 这里可以对请求做一些修改。kong在这里会把处理代理给插件的rewrite方法。
access_by_lua* kong在这里对请求进行路由匹配，找到后端的upstream服务的节点。
balancer_by_lua* kong在这里会把上一阶段找到的服务节点设置给nginx的load balancer。如果设置了重试次数，此阶段可能会被执行多次。
header_filter_by_lua* 这里可以对响应头做一些处理。kong在这里会把处理代理给插件的header_filter方法。
body_filter_by_lua* 这里可以对响应体做一些处理。kong在这里会把处理代理给插件的body_filter方法。
log_by_lua* kong在这里会通过插件异步记录日志和一些metrics数据。
功能：
Service：对外提供的服务 Route：路由规则 插件：包含丰富的功能 Consumers：与Service使用方关联，可用于跟踪，访问管理等 配置：具有丰富的功能，支持注入Nginx指令 存储：Cassandra或PostgreSQL
1、添加服务 $ curl –i -X POST —url http://localhost:8001/services/ –data ‘name=example-service’ –data ‘url=http://mockbin.org‘
2、添加路由 $ curl –i -X POST —url http://localhost:8001/services/example-service/routes –data ‘hosts[]=example.com‘
3、添加插件 $ curl –i -X POST —url http://localhost:8001/services/example-service/plugins/ –data ‘name=key-auth‘
4、Consumers与使用您的Service的个人相关联，并可用于跟踪，访问管理等 添加consumer $ curl -i -X POST –url http://localhost:8001/consumers/ –data “username=Jason«
5、Kong将把所有数据（例如路由，服务，消费者和插件）存储在Cassandra或PostgreSQL中，并且属于同一群集的所有Kong节点必须将它们自己连接到同一个数据库。
6、origin配置 http://upstream-foo-bar:1234=http://localhost:5678服务端口：
8000 Kong用来监听来自客户端的HTTP流量，并将其转发到上游服务 8443 Kong用来监听传入的HTTPS流量。此端口具有和8000端口类似的行为，但它仅用于HTTPS流量。可以通过配置文件禁用此端口。 8001 Admin API用于接收管理命令。 8444 Admin API监听HTTPS流量。 路由功能：
三种规则 { “hosts”: [“example.com”, “foo-service.com”], “paths”: [“/foo”, “/bar”], “methods”: [“GET”] } 首先尝试匹配具有最多规则的路由 Host 匹配示例：GET / HTTP/1.1 Host: service.com -> GET / HTTP/1.1 Host: <my-service-host.com> Paths 匹配规则：最长路径规则，支持正则表达式， Method方法匹配：{ “methods”: [“GET”, “HEAD”], “service”: { “id”: “…” } } -> GET / HTTP/1.1 Host: … HEAD /resource HTTP/1.1 Host: …
负载均衡：
基于DNS的负载均衡： Kong从DNS服务器获取信息，按如下顺序解析记录： 1、上一次成功解析的类型 2、SRV 记录：包含ip、port、weight 3、A 记录：只包含ip 4、CNAME 记录 环装负载均衡：Kong维护节点信息，基于一致性hash 这种方法可支持灰度发布/多版本部署及流量分配 Upstream：权重分配、健康检查、session sticky Target：维护机器信息
kong会根据配置定期对后端服务节点机器调用检查url进行检查，如果检查超时或HTTP返回码满足失败条件的次数超过限制，负载均衡器会把该节点标记为不可用。 kong集群：
集群节点使用同一db，共享相同配置 集群与负载均衡无关，组建集群前仍需负载均衡
拥有一个Kong集群并不意味着您的客户流量将在您的Kong节点之间进行负载均衡。 您仍需要在Kong节点前面安装负载均衡器来分配流量 数据库缓存配置：1、db_update_frequency (default: 5s) ，此值确定Kong节点将为无效事件轮询数据库的频率；2、db_update_propagation (default: 0s)，延迟更新，为了确保更改有时间跨数据库节点传播；3、db_cache_ttl (default: 0s)，Kong将缓存数据库实体（命中和未命中）的时间（以秒为单位），0表示不会清除缓存
用户管理：
支持Restful管理Api： 1、功能强大，2、可发到集群任何节点，3、自动下沉至db数据中心，4、kong定时刷新缓存保证信息一致性 支持命令行管理命令： kong check kong migrations kong prepare kong quit kong reload kong restart kong stop kong version kong health
kong check 检查给定Kong配置文件的有效性 kong health 验证Kong 的服务组件是否正常运行 kong migrations 管理数据库迁移 kong prepare 此命令用来准备Kong前缀文件夹及其子文件夹和文件 kong quit 优雅地退出一个正在运行的Kong节点（Nginx和其他节点）在给定的前缀目录中配置的服务 kong reload 重新加载Kong节点（并启动其他已配置的服务）在给定的前缀目录中 kong restart 重新启动Kong节点（以及其他配置的服务，如Serf）在给定的前缀目录中。 kong stop 停止给定的正在运行的Kong节点（Nginx和其他已配置的服务）在指定的前缀目录 kong version 打印kong的版本
健康检查和断路器：
1、主动检查 定期向上游的每个目标的已配置路径发出HTTP或HTTPS请求 TCP failures”，“HTTP failures”或“timeouts”计数器达到配置的阈值，则目标将被标记为不健康。 “Successes”计数器达到其配置的阈值，则目标将标记为健康。 2、被动检查—断路器
主动探测（在主动健康检查上）或代理请求（在被动健康检查上）会生成用于确定目标是健康还是不健康的数据。请求可能会产生TCP错误，超时或产生HTTP状态代码。根据此信息，运行状况检查器会更新一系列内部计数器：
如果返回的状态代码是一个配置为“healthy”的状态代码，它将递增目标的“Successes”计数器，并清除所有其他计数器;
如果连接失败，它将递增目标的“TCP failure”计数器，并清除“Successes”计数器;
如果超时，它将递增目标的“超时”计数器并清除“成功”计数器;
如果返回的状态代码是配置为“unhealthy”的状态代码，它将递增目标的“HTTP failure”计数器并清除“成功”计数器。
认证：
通过插件支持身份验证 支持匿名访问 支持多重认证： 1、多客户端对同服务可以使用不同认证方法 2、支持多个认证插件的与和或逻辑
Kong支持给定服务的多个身份验证插件，允许不同的客户端使用不同的身份验证方法来访问给定的服务或路由。
在评估多个身份验证凭据时，可以将auth插件的行为设置为执行逻辑AND或逻辑OR。行为的关键是config.anonymous属性。
验证插件的通用方案/流程如下：
1、将auth插件应用于服务或全局（您不能将其应用于消费者）
2、创建一个消费者consumer实体
3、为消费者提供特定身份验证方法的身份验证凭据
4、现在每当有请求进入Kong时，都会检查提供的凭据（取决于身份验证类型），如果请求无法验证，它将阻止请求，或者在header中添加使用者和凭据详细信息并转发请求。
日志：
debug:含调试信息 info/notice:包含正常行为 warn:警告日志。 error:错误日志。 crit:当Kong在紧急条件下工作而不能正常工作从而影响多个客户时，使用此级别。 支持编写规则屏蔽某些日志
debug:它提供有关插件的runloop和每个插件或其他组件的调试信息。只是在调试期间使用，因为它的消息量太多了。
info/notice:kong没有在这两个级别上产生很大的差异。提供有关正常行为的信息，其中大多数行为可以忽略。
warn:要记录任何不会导致事务丢失但需要进一步调查的异常行为，应使用警告级别。
error:用于记录导致请求被停止的错误（例如，获取HTTP 500错误）。需要监控此类日志的速率。
crit:当Kong在紧急条件下工作而不能正常工作从而影响多个客户时，使用此级别。
插件：
Lua插件使用插件开发工具包(PDK)，与Kong的核心和其他组件交互
模块文件名称 | 是否必须 | 描述 |
|---|---|---|
api.lua | No | 定义Admin API中可用的端点列表，用来与插件处理的自定义实体进行交互。 |
daos.lua | No | 定义DAO（数据库访问对象）列表，这些DAO是插件所需的自定义实体的抽象，存储在数据存储区中。 |
handler.lua | Yes | 接口的实现。每个函数都由Kong在请求或连接所需的时刻运行。 |
migrations/xxxx.lua | No | 数据库迁移（如创建表）。只有当您的插件必须在数据库中存储自定义实体并通过daos.lua定义的其中一个DAO与它们进行交互时，才需要进行迁移。 |
schema.lua | Yes | 保存插件配置的schema约束，以便用户只能输入有效的配置值。 |
插件继承基类base_plugin.lua并在handler.lua中实现功能
在nginx启动阶段加载plugins目录中插件
插件列表：
认证
Basic Authentication 基础认证插件
HMAC Authentication 认证插件
JWT 插件
Key Authentication 密钥认证插件
LDAP Authentication 认证插件
OAuth 2.0 Authentication 认证插件
Session 插件
安全
CORS 插件
IP Restriction 插件
Bot Detection 机器人检测插件
日志
File Log 插件
TCP Log 插件
变更
Correlation ID 关联 ID插件
Request Transformer 请求变更插件
Response Transformer 响应变更插件
传输限制
ACL 插件
Proxy Caching 代理缓存插件
Rate Limiting 速率限制插件
Response Rate Limiting 响应率限制插件
Request Termination 请求终止插件
Request Size Limiting 请求大小限制插件
分析与监测
Datadog 插件
Zipkin 插件
部署
Kubernetes Sidecar 注入插件
插件开发套件：
插件开发工具包 Plugin Development Kit（或“PDK”）是一组Lua函数和变量 插件可以使用这些函数和变量来实现自己的逻辑
kong.configuration 包含当前Kong节点配置的只读表，基于配置文件和环境变量
kong.db Kong的DAO实例（kong.db模块）。 包含各种实体的访问者对象。
kong.dns Kong 的DNS解析器实例，来自lua–resty–dns-c模块的客户端对象
kong.worker_events Kong的IPC模块实例，用于来自lua–resty-worker-events模块的worker进程间间通信
kong.cluster_events 用于节点间通信的Kong的集群事件模块的实例
kong.cache 来自kong.cache模块的Kong数据库缓存对象的实例
kong.client 客户信息模块一组函数，用于查询在给定请求的上下文中连接到Kong的客户端的信息
kong.ctx 客户信息模块函数组，用于查询在给定请求的上下文中连接到Kong的客户端的信息。
kong.ip 此模块可用于确定给定IP地址是否在trusted_ips配置属性定义的可信IP地址范围内
kong.log 允许日志以插件的名称作为前缀，以便进行调试
kong.node 返回节点信息
kong.request request 模块是一组函数，用于获取有关客户端发出的传入请求的信息。
kong.response 此模块允许在将响应发送回客户端之前改变响应
kong.routerRouter 模块用于访问请求的路由属性的一组功能。
kong.serviceservice 模块包含一组函数来操作对service的请求的连接
kong.service.request 操作对service的请求
kong.service.response 用来操作Service的响应
kong.table 表的公用程序
kubernetes&service mesh：
Kubernetes sidecar injector plugin 使用iptables 分为数据面和控制面板 服务与数据面kong在一个pod 通过kong-admin管理mesh
Origins配置在Kong用于服务网格(service mesh)时是必需的 http://upstream-foo-bar:1234=http://localhost:5678
配置在db中(Postgre和cassandra)，控制面kong-admin写入配置
servicea -> servicea-kong -> serviceb-kong -> serviceb
kong对比istio envoy：
功能点 | kong-mesh (community) | istio envoy | 分析 |
|---|---|---|---|
服务发现 | 通过admin api添加服务，并只能发现通过api添加的服务 | 支持对接k8s, consul等注册中心进行服务发现 | 从平台独立性来看，kong mesh占优; 从服务接管易用性来看，istio占优 |
服务协议 | 支持http, http2, websocket, stream | 支持http, http2, grpc, websocket, stream | istio envoy占优 |
服务路由 | 支持根据源、目标地址，method、host、path、protocol等细粒度的路由 | 支持除左侧列举的所有能力外，还支持按header以及subset（标签）的路由 | istio envoy占优 |
负载均衡 | 支持轮询、权重、一致性hash的负载均衡模式 | 支持除左侧列举的所有负载均衡模式外，还支持随机、最低负载等模式 | istio envoy占优 |
健康检查 | 支持主动健康检查以及被动健康检查（熔断） | 支持主动健康检查以及被动健康检查（熔断） | 基本对等 |
安全 | 支持Certificate证书管理，支持JWT TLS加密传输 | 支持证书下发及更新，JWT mTLS加密传输 | 基本对等 |
多用户 | 支持按consumer授权 | 支持RBAC用户–角色授权 | istio envoy占优 |
故障注入 | 不支持 | 支持 | istio envoy占优 |
监控统计 | 继承nginx的统计能力，支持按请求、连接、健康状态等维度的统计 | 支持更细粒度的比如按协议、Zone的统计 | istio envoy占优 |
可扩展性 | 背靠openresty，提供强大的自定义插件能力，使用lua进行开发 | 提供lua插件开发能力，但能力比较基础 | kong mesh占优 |
学习曲线 | kong自身提供控制面和数据面能力，组网简单，纯lua语言上手较轻松 | istio envoy一起至少4个组件，跨两种语言，上手较难 | kong mesh占优 |
引用：
1、Nginx、OpenResty和Kong的基本概念与使用方法 https://www.cnblogs.com/lijiaocn/p/9769771.html
2、kong-docs-cn https://github.com/qianyugang/kong-docs-cn
3、kong mesh深度分析报告 https://www.servicemesher.com/blog/kong-mesh-analyse-report/
4、kong docs https://docs.konghq.com/install/kubernetes/
5、kong源码导读 http://techblog.ppdai.com/2018/04/16/20180416/
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/195083.html原文链接：https://javaforall.cn
