微服务Kong(四)——添加插件

  在本节中,您将学习到,如何配置使用KONG的插件来管理您的API。KONG的核心原则之一就是通过插件来实现API的扩展。插件可以使您更为简单的扩展和管理您的API。

  在以下的步骤中,您将通过配置key-auth插件为您的API添加一个认证的功能。在添加此插件之前,您的所有API都被将代理到上游头。添加并配置此插件后,只有具有正确API密钥的请求会被代理 - 所有其他请求将被KONG拒绝,从而保护您的上游服务免受未经授权的使用,从而实现权限认证功能。

  1. 为您的API配置 key-auth 插件:

  通过以下命令,为之前添加的API新增认证功能:

$ curl -i -X POST   --url http://localhost:8001/apis/example-api/plugins/ \
  --data ‘name=key-auth‘

  NOTE:该插件还接受一个 config.key_names 参数,默认为[apikey]。它表示在一次请求中,应该包含API密钥[apikey]和参数列表,apikey可以放在header中,也可以直接当作一个请求参数来使用。

  2. 确认插件已经正确的配置好了:

  使用以下命令来验证:

$ curl -i -X GET   --url http://localhost:8000/ \
  --header ‘Host: example.com‘

  由于请求中没有指定apikey,所以返回的结果应该是403 Forbidden:

HTTP/1.1 403 Forbidden
...

{
  "message": "Your authentication credentials are invalid"
}

  正确的请求应该是这样的:

$ curl -i -X GET   --url http://localhost:8000/ \
  --header ‘Host: example.com‘
  --header ‘apikey=xxx‘
时间: 2024-10-17 02:00:49

微服务Kong(四)——添加插件的相关文章

微服务Kong(八)——代理参考

Kong侦听四个端口的请求,默认情况是: 8000:此端口是Kong用来监听来自客户端的HTTP请求的,并将此请求转发到您的上游服务.这也是本教程中最主要用到的端口. 8443:此端口是Kong监听HTTP的请求的端口.该端口具有与8000端口类似的行为,但是它只监听HTTPS的请求,并不会产生转发行为.可以通过配置文件来禁用此端口. 8001:用于管理员对KONG进行配置的端口. 8444:用于管理员监听HTTPS请求的端口. 在本文中,我们将介绍Kong的路由功能,并详细说明8000端口上的

微服务Kong(九)——认证参考

客户端访问上游API服务,通常由Kong的认证插件及其配置参数来控制. 通用认证 一般情况下,上游API服务都需要客户端有身份认证,且不允许错误的认证或无认证的请求通过.认证插件可以实现这一需求.这些插件的通用方案/流程如下: 1.向一个API或全局添加AUTH插件(此插件不作用于consumers): 2.常见一个consumer对象: 3.为consumer提供指定的验证插件方案的身份验证凭据: 4.现在,只要有请求进入Kong,都将检查其提供的身份验证凭据(取决于auth类型),如果该请求

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

微服务测试之使用Jmeter插件jmeter_dubbo_plugin测试dubbo接口

1.准备环境 下载Jmeter(现在从官网down下来的jmeter lib/ext下面都会有jmeter_dubbo_plugin.jar包,不用单独下载哦) 待测试接口*.jar包,扔到lib目录下 2.创建脚本 1)新建java请求 2)类名称选择:com.hshbic.cloud.dubbo.DubboJmter 3)参数填写: 如果是dubbo直连,在dubboUrl行输入dubbo地址:如果是zk访问,在zookeeperAdd行输入zk地址. interfaceAddress行,输

spring cloud微服务实践四

spring cloud的hystrix还有一个配搭的库hystrix-dashboard,它是hystrix的一款监控工具,能直观的显示hystrix响应信息,请求成功率等.但是hystrix-dashboard只能查看单机和集群的信息,如果需要将多台的信息汇总起来的话就需要使用turbine. 注:这一个系列的开发环境版本为 java1.8, spring boot2.x, spring cloud Greenwich.SR2, IDE为 Intelli IDEA hystrix-dashb

微服务Kong(七)——CLI参考

KONG提供了一套CLI(命令行界面)命令,您可以通过它来启动.停止和管理您的Kong实例.CLI管理您的本地节点(如在当前机器上). 全局配置 所有命令都采用一组指定的可选标志作为参数: --help:显示命令行帮助信息 --v:启动详情模式 --vv:启动debug模式(noisy) 可用的命令符 kong check: Usage: kong check <conf> Check the validity of a given Kong configuration file. <c

基于Spring Cloud的微服务落地

请点击此处输入图片描述 微服务架构模式的核心在于如何识别服务的边界,设计出合理的微服务.但如果要将微服务架构运用到生产项目上,并且能够发挥该架构模式的重要作用,则需要微服务框架的支持. 在Java生态圈,目前使用较多的微服务框架就是集成了包括Netfilix OSS以及Spring的Spring Cloud.它包括: Spring Cloud Config:配置管理工具,支持使用Git存储配置内容,可以实现应用配置的外部化存储,支持客户端配置信息刷新.加密/解密配置内容等. Spring Clo

利用Spring Cloud实现微服务- 熔断机制

1. 熔断机制介绍 在介绍熔断机制之前,我们需要了解微服务的雪崩效应.在微服务架构中,微服务是完成一个单一的业务功能,这样做的好处是可以做到解耦,每个微服务可以独立演进.但是,一个应用可能会有多个微服务组成,微服务之间的数据交互通过远程过程调用完成.这就带来一个问题,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的"扇出".如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的&

解析微服务架构(三):微服务重构应用及IBM解决方案

解析微服务架构系列文章将分几篇描述微服务的定义.特点.应用场景.企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架构转型. 上一篇文章介绍了融入微服务的企业集成架构的演进,并介绍交互式系统的微服务模式及技术决策例子. 本篇文章将介绍已有IT应用如何进行微服务重构的转型,以及IBM微服务相关解决方案的介绍. 微服务转型 采用微服务架构意味着以更复杂的运维环境为代价,实现更高速的应用交付及更快推出市场.因此企业需要在更快的交付与更复杂的运维之间进行权衡.