微服务网关Kong – 简介

746次阅读
没有评论

Kong系列文章

1、微服务网关Kong – 简介

2、微服务网关Kong – 安装

3、微服务网关Konga – 安装

4、微服务网关Kong – 代理

5、微服务网关Kong – 身份验证

6、微服务网关Kong – 安全

7、微服务网关Kong – 流量控制

为什么需要 API 网关?

当使用单体应用程序架构时,客户端(Web 或移动端)通过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。然后应用程序会查询各种数据库表,并将响应返回给客户端。微服务架构下,单体应用被切割成多个微服务,如果将所有的微服务直接对外暴露,势必会出现安全方面的各种问题。

客户端可以直接向每个微服务发送请求,其问题主要如下:

  • 客户端需求和每个微服务暴露的细粒度API不匹配。

  • 部分服务使用的协议不是Web友好协议。可能使用Thrift二进制RPC,也可能使用AMQP消息传递协议。

  • 微服务难以重构。如果合并两个服务,或者将一个服务拆分成两个或更多服务,这类重构就非常困难了。

服务端的各个服务直接暴露给客户端调用势必会引起各种问题。同时,服务端的各个服务可扩展和伸缩性很差。API 网关是微服务架构中的基础组件,位于接入层之下和业务服务层之上,如前所述的这些功能适合在 API 网关实现。

什么是kong?

当我们决定对应用进行微服务改造时,应用客户端如何与微服务交互的问题也随之而来,毕竟服务数量的增加会直接导致部署授权、负载均衡、通信管理、分析和改变的难度增加。

面对以上问题,API GATEWAY是一个不错的解决方案,其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能,可以解放开发者去把精力集中在具体逻辑的代码,而不是把时间花费在考虑如何解决应用和其他微服务链接的问题上。

为什么使用kong?

提供类似的API网关不止一家,Kong侧重于解决如下传统方式的四大痛点:

痛点 说明
重复多 在多个微服务中,共通的功能重复,比如认证或者日志相关共通模块
巨石化 单个服务仍然后变成尾大不掉的巨石应用的趋势
影响大 影响较大,很难做到扩展功能而能不影响其他服务
效率低 由于系统限制,导致生产性低下

kong的基本架构

Kong 是 Mashape 开源的高性能高可用 API 网关和 API 服务管理层,一款基于 Nginx_Lua 模块写的高可用服务网关,由于 Kong 是基于 Nginx 的,所以可以水平扩展多个 Kong 服务器。通过前置的负载均衡配置把请求均匀地分发到各个 Server,来应对大批量的网络请求。

Kong 主要有三个组件:

  • Kong Server :基于nginx的服务器,用来接收 API 请求。

  • Apache Cassandra/PostgreSQL:用来存储操作数据。

  • Kong dashboard:官方推荐 UI 管理工具,当然,也可以使用restfull方式管理 admin api。

Kong dashboard 支持的版本

Kong 采用插件机制进行功能定制,插件集(可以是 0 或 N 个)在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写,基础功能包括:HTTP 基本认证、密钥认证、CORS(Cross-Origin Resource Sharing,跨域资源共享)、TCP、UDP、文件日志、API 请求限流、请求转发以及 Nginx 监控等。

微服务网关Kong

Honest1y
版权声明:本站原创文章,由Honest1y2020-12-29发表,共计1341字。
转载提示:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)
载入中...