33

花5分钟时间来了解一下高性能网关Kong会有意外收获 - Ron.Liang

 4 years ago
source link: https://www.cnblogs.com/viter/p/11172469.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

前几天开源发布了 Kong.Net 项目，收到了大量园友的反馈，开源当天就突破了 100 个star ，可喜可贺，但是从侧面也说明，我们 .NetCore 阵营真的非常需要拥抱开源，应该敞开心扉，集众家之长，为我所用，针对有些朋友还不太了解 Kong 的使用方法，本文作一些简单的介绍。

项目地址：https://github.com/lianggx/Kong.Net 请为我们点击 star 加⭐⭐

本文准备介绍市面上的一些常见的网关，不吹不黑，实事求是，理性讨论，从我做起。

微服务网关

下图直观的为我们展示了Kong网关在微服务中的作用

26882-20190711201828242-1255065071.png

还可以和 kubernetes 进行无缝集成

26882-20190711201836907-229688430.png

(来源：https://konghq.com/solutions/kubernetes-ingress/)

上图是Kong和K8s相结合的结构图，通过Kong网关，可以使业务系统的集成工作变得更加高效且易于管理。

升级位服务网格等部署方案

除了上面的应用场景，Kong 还带来了下面的服务网格等各种部署方案，任君选择，童叟无欺！

26882-20190711201844392-294254859.png

(来源：https://konghq.com/solutions/kubernetes-ingress/)

为什么选择了 Kong

1. Spring系列

其实在选择 Kong 之前，我也曾尝试了其它的网关，运维级别的比如Nginx咱就不提了，单就 Spring-cloud Gateway 几乎可以一招吃遍天下，况且还有阿里这个大厂做护法，Nacos/Dubbo 这种实验室+超高流量的实践后开源，那也是极其可怕的，唯一的不好就是除了Java外其它语言没什么机会与之结合，非用不可也不是不行，但是就是非常麻烦，中小企业可以通过上云的方案使用云原生，但是对于自建机房、自建网关和服务集群的，或者是不方便上云的企业来说，只能选择Java。

2. 自带网关

.NetCore 在网关方面也不是没有建树，Ocelot 的star也不少了，但是对于成功的商业应用案例来说，缺少一个有力的推广人，特别是对于http请求的转发，其基于HttpClient的特性，使得在大并发的情况下，反应非常迟钝，一句话：底层太重。不能轻装上阵，就好像转换到Linux后，总是在某些方面有点水土不服。

3. 最终选择

博客园也有大量关于Ocelot对于其它网关的性能对比，这里我就不再一一列出了，大家有兴趣可以在站内搜索一下关键字Ocelot。我在Ocelot的github项目上仔细的查看了每一条issue，并且拿这些issue的回答时间和Kong的issue回答作对比，发现Kong的issue问题响应时间大大快于Ocelot，这可能是因为Kong的贡献值高达200多人的原因

Kong的高效得益于lua和高水平的贡献者，该语言是nginx的开发语言，nginx的高效众所周知，Kong通过Kong Igress Controller和K8s完美结合

为什么需要Kong.Net客户端

还有朋友反馈，既然Kong网关如此完善，RESTFul API 如此高效，为什么还需要Kong.Net客户端呢？这个问题提的非常好!

1. 营销故事
沃尔玛曾经有一个经典的营销案例，说的是啤酒和尿片的故事，说营销人员通过调查，，发现许多男人在下班后都会到超市买给孩子买尿片，他们就想到，如果在尿片旁边摆上啤酒，这些男人会不会同时将啤酒丢人购物车中呢，通过一段时间的观察，超市里的啤酒销量大幅提升。从这个故事中我们发现，便利性和易用性是多么的重要，如果尿片和啤酒在分别堆放在两个不同的货架上，那么如果一个买尿片的男人很大概率不会想起来买啤酒，或者说绕很远的距离去购买啤酒。

从这个场景中我们看到，便利性是多么的重要！

2. 为了快速接入

通过Kong.Net，一个从未接触过Kong网关的人就是可以通过几行代码完成接入，他不需要去理解RESTFul API的接口文档，不用担心传错参数，不用关心是否在配置过程中是否由于某个配置错误引起不明BUG，这些都是极大的提升开发效率的行为，特别是进一步，通过社区的力量，我们可以一起完善这个SDK，使之越来越高效，BUG越来越少，接入越来越快，这就是开源的力量！

Kong 的安装部署

Kong网关的安装部署非常简单，有两种部署方式，rpm 和 docker ，建议 docker方式部署，因为实在是太方便了，只需要复制官网的几个命令，相信我，你不用一分钟就可以部署起来，这里我就不再搬运官方的 docker 安装部署教程了，大家可以参考下面的链接，主要怕官网有更新的话，我这搬运有可能就过时了

https://docs.konghq.com/install/docker/?_ga=2.264012361.438943297.1562658881-406131744.1553753787

Kong Dashboard 控制台

Kong 网关的 Dashboard 目前有两个毕竟大的开源的Dashboard，分别是

// pgbi/kong
https://github.com/PGBI/kong-dashboard/commits/3.0

// pantsel/konga
https://github.com/pantsel/konga

从维护更新的频率来看，pgbi/kong 在走下坡路，而konga维护良好，建议大家使用konga，他们俩的操作界面大同小异，比如我目前使用的是Konga

26882-20190711201855774-136680639.png

安装方式推荐：docker

Kong 插件

Kong的插件基于lua编写，内置插件非常丰富，支持验证、安全、流量控制、监控和统计、日志等等，甚至支持自定义插件，你也可以编写自己的插件加入到Kong网关中

26882-20190711201900817-8334991.png

就拿流量控制来说，其控制粒度可以具体某个Target，也可以应用到Global，非常灵活。

Kong 响应

在使用Kong进行转发后，Kong会向客户端写入一个默认的头信息

26882-20190711202852492-1100381610.png

除了默认的头信息，你也可以在Kong服务配置中向客户端写入自定义的响应头信息，非常方便。

Kong的健康检查机制非常有意思，分为主动式检查和被动式检查两种，而且两种健康检查方式的配置基本相同，主动检查会修改客户端的状态，将不健康的客户端移除，将恢复健康后的客户端主动加入服务集群，而被动式检查则正好相反；特别有意思的是，其健康检查的路径为根目录“/”，当然也支持定义路径，最重要的是可以自定义httpstatus代码，比如你可以定义4.3、404为健康状态，也可以定义 200、302等一切httpstatus代码。

优秀的开源产品值得我们深入了解，并结合.NetCore实际使用，这会让.NetCore的生态越来越完善，让社区更强大。
项目地址：https://github.com/lianggx/Kong.Net 请为我们点击 star 加⭐⭐


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK