kong微服务网关

举个不恰当的例子。api网关就是所有的api请求都要先经过我这里，相当于银行大门，端口相当于银行柜台，处理不同的事务。对银行里的每个用户（实际IP和端口）进行分配卡号（服务名），这就是服务注册。

架构原理

每个客户端对API的请求将首先到达Kong，然后被代理到最终API，在请求和响应之间，Kong将执行任何已安装的插件，扩展API功能集，Kong有效的成为每个API的入口点。

使用kong前后对比

api网关的角色（聚合服务）

如果用户需要访问订单信息又需要访问用户地址信息，而这两个服务在不同的服务器IP上，那么就需要一个API网关来做服务聚合。用户只需要访问一个api地址就可以一起查出两个api的数据。

架构原理总结为：Kong = OpenResty + Nginx + Lua

Kong 对外暴露了 Restful API，最终的配置便是落地在了数据库之中。1.1版本之后支持无DB。

Kong大概有以下几个管理对象：节点信息、服务、路由、用户、插件、证书、SNI、上游信息、目标。需要特别关注的是服务和路由。下面会聊到。

kong的特性

安装与启动

支持多种安装方式：

安装的方式比较多，总体步骤归结为（具体参考此文）：

1、启动任一数据库服务，目前官方支持postgresql和cassandra；

2、设定数据库；

3、启动kong服务。

服务注册与路由添加

路由用来匹配客户端请求的规则，每一个路由都要与一个服务相关联，当一个请求到达Kong的时候，会先给路由匹配，如果匹配成功，那么会将请求转发给服务，服务再去后端请求数据。所以路由是Kong的入口。

在Kong0.13.0之前的版本有API实体，因为API实体使用用起来并不方便，所以将API实体拆分成路由和服务，这样提供了最大的自由度。

Kong的一个API实体必须是路由和服务的组合。

添加路由：

添加服务：

配置可以参考本文。但小马觉得kong与consul的结合这和服务和路由的概念有关。

kong与consul的结合

1、我们看过kong与consul的结合，那是怎么结合的呢？

您可以通过指定dns_resolver属性（在kong.conf配置文件中）以指向Consul服务器（或通过设置KONG_DNS_RESOLVER=环境变量）来使Kong与Consul一起使用。这样，您将迫使Kong使用Consul来解析upstream_urlAPI 中的主机名地址。

2、这句话非常简明概括了它们两者如何结合。为什么需要结合？

小马总结为：consul 的加入kong主要发挥了    DNS负载均衡  + 服务配置中心    的作用。

Nacos和Consul这类产品有着服务配置中心的作用，但是其只能基于IP和端口进行微服务组件的发现，对于类似/path 端点地址(API接口)的发现是做不到的。正式基于这一点，与kong网关的结合仅仅就局限在DNS层面了。

上面讲到可以通过指定kong的DNS_RESOLVER来实现结合。kong是通过DNS来实现IP和端口的负载均衡，不能实现端点和API的自动注册发现（大胆更正一下，这里说的是DNS做不到支持端点和API的负载均衡）。

因此consul的加入更大的是发挥服务配置中心的作用，如果你要使用服务配置中心功能，那就需要结合，如果仅仅使用服务注册中心，那么是完全没有必要的，因为kong为请求多个后端服务提供了多种负载均衡方案：一种是简单的基于DNS，另一种是更加动态的环形均衡器，在不需要DNS服务器的情况下也允许服务注册。

啥意思呢？当kong需要服务配置中心的时候要结合consul，负载均衡如果选择基于DNS，那么只能支持IP和端口的负载均衡，而consul也只能支持IP和端口层面的负载均衡，对于类似/path 端点地址(API接口)的发现是做不到的。

与kong同一类型的产品有：enovy（边车模式+自带配置api），nginx，zuul等网格软件或者说网关软件，也就是发挥请求路由转发，负载均衡以及热更新动态配置api等作用。

那么其与k8s的区别是，后者是容器编排工具，后者与docker warm是同级的，负责容器管理，集群管理，以及集群之间的通信，使集群对外就像单机一样。

 Service Mesh最近很火,它的核心组件之一Envoy代理也很火。

相关文献：

github  kong

---