AspNetCore微服务下的网关-Kong(一)

Kong是Mashape开源的高性能高可用API网关和API服务管理层。它基于OpenResty,进行API管理,并提供了插件实现API的AOP。Kong在Mashape 管理了超过15,000 个API,为200,000开发者提供了每月数十亿的请求支持。本文将从架构、API管理、插件三个层面介绍Kong。

架构

按照康威定律,我们系统架构会拆的很散,系统由一堆服务组成,如下图所示:

库存服务、优惠券服务、价格服务时之前都会做一些特殊处理,如限流、黑白名单,日志、请求统计。而这些处理几乎是所有服务都需要的,这不就是我们常说的AOP嘛,当我们服务多起来的时候,应该将这些通用处理集中到一个地方进行管理,如下图所示:

和下图有点相似:

1.为什么要用Kong作为NetCore下的API网关?

1.开源,云生(Cloud-Native),ServiceMesh,快速,弹性,RESTful还有分布式微服务的抽象层

2.基于NGINX构建的网关,拥有更高的性能,并且在2015开源

3.活跃的社区,在github上有111个Contributors,修复bug迅速,基本每3个月一个版本

4.支持插件化,目前支持的插件有32个,包含授权,安全,限流,Serverless,分析和监控,转换,日志。

5.支持企业版本和社区版本

架构预览

基于OpenResty(Nginx & Lua Scripting)

上图很清晰的看见Kong的架构图,以Nginx作为基础, OpenResty构建RESTful,支持集群和数据库存储数据,插件化,还有支持用RESTful来管理端。

集群架构预览

这里讲下Kong的集群原理吧,Kong在0.11.0版本之前用的是serf来做集群的,那么为什么不用serf做集群呢?开发者给出的理由如下:

1.依赖serf,serf并不属于Nginx/OpenResty

2.这种依赖相互间通信来同步的机制对于deployment和容器化都有些不便

3.在运行的Kong节点触发serf需要一些租塞的I/O

0.11.0版本的实现思路是以数据库为中心,增加一个cluster events的表,任何Kong node都可以向数据库发送变更消息,其他节点轮训数据库改动,然后更新缓存内容,如果有节点重启连上数据库节点就可以工作了。

Kong的安装

Kong的安装方式支持很多主流的平台,目前不支持Windows,支持的安装方式如下:

Kong的安装,为了方便我这里就使用docker安装了

1.创建专属kong的网络(docker的最佳实践)--link 过时了啊

docker network create kong-net

2.选择你使用的数据库,默认使用的是PostgreSQL

如果你使用的是Cassandra数据库:

提示下:Cassandra >=3.0

docker run -d --name kong-database \ --network=kong-net \ -p 9042:9042 \ cassandra:3

如果你使用的是PostgreSQL

docker run -d --name kong-database \ --network=kong-net \ -p 5432:5432 \ -e "POSTGRES_USER=kong" \ -e "POSTGRES_DB=kong" \ postgres:9.6

3.数据库迁移,初始化库表结构:

 docker run --rm     --network=kong-net     -e "KONG_DATABASE=postgres"     -e "KONG_PG_HOST=kong-database"     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database"     kong:latest kong migrations up

4.启动kong

docker run -d --name kong     --network=kong-net     -e "KONG_DATABASE=postgres"     -e "KONG_PG_HOST=kong-database"     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database"     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout"     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout"     -e "KONG_PROXY_ERROR_LOG=/dev/stderr"     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr"     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl"     -p 8000:8000     -p 8443:8443     -p 8001:8001     -p 8444:8444     kong:latest

5.看网关有没有启动

在本机 curl -i http://localhost:8001/,或者用浏览器访问8001端口。如果出来一大堆json,表示成功

以AspNetCore为例子访问

mkdir AspNetCore

cd AspNetCore

dotnet new webapi

dotnet run

我们以netcore做的api为例子访问localhost:5001/api/values,前面网关搭建起来了,并且支持RESTful,现在有开源的dashboard,我们就用KongDashboard来演示,如何构造搭建和访问。

# 全局安装kong-dashboard
npm install -g kong-dashboard

# 启动 kong-dashboard
kong-dashboard start --kong-url http://localhost:8001

# 启动kong-dashboard,并且自定义端口
kong-dashboard start   --kong-url http://kong:8001   --port [port]

# 启动kong-dashboard并且启动基础认证
kong-dashboard start   --kong-url http://kong:8001   --basic-auth user1=password1 user2=password2

# 看kong-dashboard 启动参数
kong-dashboard start --help

启动成功后用浏览器打开localhost:8080如下图所示:

那么我们增加一个NetCoreAPI,在DashBoard,如图所示:

因为是GET请求,那我我们用浏览器访问,浏览器 -> 网关 -> NetCore程序。

打开浏览器直接访问http://localhost:8000/api/values,返回["value1","value2"]则代表正常。

如下图所示:

最后,AspNetCore微服务下的网关-Kong系列,后面会继续更新,会讲解到Kong的插件的使用,插件的开发,使用的一些坑,网关性能分析和日志可视化,源码解析等,欢迎大家关注我的github: https://github.com/WithLin

原文地址:https://www.cnblogs.com/WithLin/p/9343406.html

时间: 2024-10-11 18:52:44

AspNetCore微服务下的网关-Kong(一)的相关文章

微服务之API网关 kong 使用场景之路由功能

API网关,在介绍spring cloud的时候我们也曾提到过zuul,并使用zuul做了一个简单的实验证明zuul是可以实现网关的路由功能的,在这篇文章中,我们会同样使用类似简单的例子来验证kong在此种场景下的使用. spring cloud之zuul的类似实现 spring cloud的zuul的类似功能和实现,可参看下文: spring cloud之api网关 https://blog.csdn.net/liumiaocn/article/details/53941354 场景说明 项目

微服务下使用网关 Spring Cloud Gateway

Spring Cloud Gateway 工作原理 客户端向 Spring Cloud Gateway 发出请求,如果请求与网关程序定义的路由匹配,则将其发送到网关 Web 处理程序,此处理程序运行特定的请求过滤器链. 过滤器之间用虚线分开的原因是过滤器可能会在发送代理请求之前或之后执行逻辑.所有 "pre" 过滤器逻辑先执行,然后执行代理请求,代理请求完成后,执行 "post" 过滤器逻辑. 如何启动 Spring Cloud Gateway 1.新建 Maven

买单侠微服务的API网关演化之路

伴随着买单侠业务的快速发展,能够支持独立开发.独立部署.独立扩展的微服务在秦苍得到了广泛应用和蓬勃发展,短短3年左右时间,已经发展到了300+个微服务,并且还在快速增长中. 研发逐渐意识到伴随着微服务规模化的增长,必需要重视微服务的基础设施建设(API网关.服务注册中心.调用链跟踪等)才能保持开发效率和产品的质量. API网关作为访问微服务的大门, 是访问后台服务的入口,作为最常用的基础服务之一,其重要性不言而喻.在买单侠微服务的发展道路上,经过了以下摸索发展阶段,希望能给规模化应用微服务的攻城

.net core 微服务之Api网关(Api Gateway)

原文:.net core 微服务之Api网关(Api Gateway) 微服务网关目录 1. 微服务引子 2.使用Nginx作为api网关 3.自创api网关(重复轮子) 3.1.构建初始化 3.2.构建中间件 4.结语 引用链接 1. 微服务引子 首先恭喜你,进入微服务的开发世界.微服务属于架构演进中的一种阶段,其特点是根据业务模块水平划分服务种类,每个服务可以独立部署并互相隔离,并对外提供轻量的Api调用,服务具有高可用特性. 微服务应遵循的设计原则: 单一职责原则: 每个微服务只需要实现自

从本地事务到分布式事务到微服务下事务

从本地事务到分布式事务到微服务下事务 一.传统本地事务 传统单服务器,单关系型数据库下事务比较简单,完全可用很简单的实现ACID,实际中我们实现一个业务时只需要:开启一个事务-操作数据库-提交/回滚这个事务,这样就完美的实现了一次事务操作,更简单点我们通常会通过spring集成事务直接指定在哪些服务什么样的方法执行什么样的事务即可,更甚至我们业务实现基本都忽略了事务,具体图如下: 二.传统分布式事务 在传统一服务,一个关系数据库架构基础上,随着访问量的增大,单机很明显已满足不了现状,于是我们顺其

Net分布式系统之六:微服务之API网关

本人建立了个人技术.工作经验的分享微信号,计划后续公众号同步更新分享,比在此更多具体.欢迎有兴趣的同学一起加入相互学习.基于上篇微服务架构分享,今天分享其中一个重要的基础组件“API网关”. 一.引言 随着互联网的快速发展,当前以步入移动互联.物联网时代.用户访问系统入口也变得多种方式,由原来单一的PC客户端,变化到PC客户端.各种浏览器.手机移动端及智能终端等.同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接.共享数据的需求.所以系统需要升级框架满足日新月异需求变化,支持业务发展,并

微服务,ApiGateway 与 Kong

一. 微服务 二. Api Gateway 三. Kong 的使用 一. 微服务 对于一些传统的 大型项目,传统的方式会有一些缺陷,比如说 新人熟悉系统成本高(因为整个系统作为一个整体,彼此会有一定的牵连),项目重 启时间长,重构困难(对于一个新技术的引入,可能需要对整个项目推到重来),不易于更换新的技术,并且整个项目会慢慢变成巨无霸. 所以说就会有微服务这种概念,一个服务实现一个不同的特性或者功能.每一个独立的微服务都是一个小型应用.一些微服务可能会暴露一些api 给 其他的一些微服务或者是客

微服务下的持续交付环境

背景 随着互联网行业的兴起,敏捷开发.Devops被越来越多的公司提及或实施,力求有效地降低交付过程所耗费的成本并提高交付的效率. 持续交付通过建立自动化的构建.测试.部署机制,实现业务快速上线的过程. 在微服务架中,由于每个服务都是一个独立的,可部署的单元,由一个服务或多个服务组合对外提供服务,服务拆分粒度更细.服务之间依赖更加的复杂,服务的开发.测试.上线也必将带来更大的挑战. 微服务环境下持续交付面临的挑战 任何事情都有两面性,在享受微服务便利的同时,也必须面对微服务交付所带来的挑战. 经

基于spring-cloud的微服务(4)API网关zuul

API网关是微服务架构中的很重要的一个部分,内部有多个不同的服务提供给外部来使用,API网关可以对外做统一的入口,也可以在网关上做协议转换,权限控制和请求统计和限流等其他的工作 spring-cloud封装了Netflix提供的开源的API网关实现zuul,我们可以很方便地启动一个zuul网关的实例,并支持向eureka进行注册,并对在eureka上已经注册的服务进行代理 使用IDEA的spring initializer来创建一个zuul项目 填写相关的group类型等信息,选择使用gradl