目录

文章目录

• 目录
• 微服务架构中的 API 问题
• 微服务架构 APIGW
• • APIGW 的功能清单
  • API 的分组聚合
• OpenResty
• • 为何 OpenResty 适合用于 APIGW 开发/li>
  • Lua Nginx Module
• Kong APIGW
• Kong 的软件架构
• Kong 的安装部署
• • 安装 Kong Server
  • 安装 Kong Dashboard
  • 配置 Kong Server
• Kong Admin API 的核心逻辑对象
• • Service（服务）
  • Route（路由）
  • Upstream（上游）
  • Target（目标）
  • Consumer（消费者）
  • Plugins（插件）
  • CA Certificate（CA 证书）
  • Certificate 与 SNI
  • • Certificate（证书）
    • SNI（Server Name Indication，服务器名称指示）
• Kong 的基本使用
• • 非安全访问
  • • 创建 Service
    • 创建 Route
    • 创建 Upstream
    • 创建 Targets
    • 调用测试
  • Front-End 安全访问，Backend 非安全访问
  • • 使用默认 Kong Proxy API Domain Name 的 TLS 证书
    • • 创建 Service
      • 创建 Route
      • 创建 Upstream
      • 测试验证
    • 使用用户自定义的 Domain Name 的 TLS 证书
    • • 创建 Certificate
      • 创建 Service
      • 创建 Route
      • 创建 Upstream
      • 调用测试
  • Front-End 安全访问，Backend 安全访问

微服务架构中的 API 问题

根据 Gartner 对微服务的定义：“微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件。”

与将模块高度耦合并部署为一个大的应用程序相比，微服务的目标是将应用程序充分分解或者解耦为松散耦合的许多微服务或者模块，这样做对下面几点有很大帮助：

1. 每个微服务都可以独立于应用程序中的同级服务进行部署、升级、扩展、维护和重新启动。
2. 通过自治的跨职能团队进行敏捷开发和敏捷部署。
3. 运用技术时具备灵活性和可扩展性。

在微服务架构中，我们根据各自的特定需求部署不同的松耦合服务，其中每个服务都有其更细粒度的 API 模型，用以服务于不同的客户端（Web，移动和第三方 API）。

在考虑客户端与每个已部署的微服务直接通信的问题时，应考虑以下挑战：

1. 如果微服务向客户端公开了细粒度的 API，则客户端应向每个微服务发出请求。在典型的单页中，可能需要进行多次服务器往返，才能满足请求。对于较差的 络条件下运行的设备（例如：移动设备），这可能会更糟。
2. 微服务中存在的多种通信协议（例如：gRpc、thrift、REST、AMQP 等）使客户端很难轻松采用所有这些协议。
3. 必须在每个微服务中实现通用 关功能（例如：身份验证、授权、日志记录）。
4. 在不中断客户端连接的情况下，很难在微服务中进行更改。例如：在合并或划分微服务时，可能需要重新编写客户端部分代码。

APIGW，顾名思义，是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务，这里的边界是企业 IT 系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。APIGW 是系统对外的唯一入口，封装了系统内部架构，为每个客户端提供定制的 API。所有的客户端和消费端都通过统一的 关接入微服务，在 关层处理所有非业务功能。

• 单节点 关
  

简而言之，APIGW 的行为就像 API 管理员一样，但重要的是：不要将 API 管理与 API Gateway 混为一谈。

APIGW 的功能清单

• 路由：动态路由规则， 关封装了底层系统并与客户端分离，为客户端提供了与微服务系统进行通信的单个入口点。
• 安全：IAM 权限认证、鉴权、授权、脱敏，流量清洗，后端签名（保证全链路可信调用），IP 黑白名单（非法调用的限制）。
• 缓存：缓存响应结果。
• 监控：记录请求响应数据，API 耗时分析，性能监控。
• 限流：流量控制，错峰流控，可以定义多种限流规则。
• 高可用：API 高可用，负载均衡，容错机制。
• 服务发现。
• 重试策略、熔断。
• 日志、链路追踪。

APIGW 具有以下优势：

• 易于监控：可在微服务 关收集监控数据并将其推送到外部系统进行分析。
• 易于认证：可在微服务 关上进行认证，然后再将请求转发到后端的微服务，从而无需在每个微服务中进行认证。
• 减少了客户端与各个微服务之间的交互次数。

APIGW 实现的注意事项：

• 可能产生的单点故障或者瓶颈。
• 由于通过 APIGW 进行了额外的 络跳转以及复杂性风险，意味着响应时间增长了。

API 的分组聚合

APIGW 中的一些 API 请求直接映射到单个服务的 API 上，可以通过将请求路由到相应的微服务来提供服务。但是，在需要从多个微服务获得结果的复杂 API 操作的情况下，可以通过 API 组合/聚合来提供服务。在需要同步通信的情况下，如果服务彼此依赖，则必须遵循链式组合模式。组合层必须支持很大一部分的集成功能，例如：转换、编排、弹性和稳定性模式。

微服务架构软件系统必须配备特殊的分发器和聚合器功能（或微服务）。分发者负责分解成细粒度的任务，并将这些任务分发给微服务实例。聚合器负责聚合业务工作流从组合微服务中得出的结果。

具备复杂功能的 关会增大测试和部署的难度。强烈建议大家避免在 APIGW 中进行聚合和数据转换。领域专属的功能更应该遵循软件开发实践的定义，在应用程序的代码中完成。Netflix API Gateway Zuul 2 从他们在 Zuul 到原始系统的 关中，删除了许多业务逻辑。

Lua Nginx Module

由于 Nginx 把一个请求分成了很多阶段，这样第三方模块就可以根据自己行为，挂载到不同阶段进行处理达到目的，OpenResty 应用了 Nginx 的这个特性。

Kong APIGW

Kong 是一款由 Mashape 公司开源的 APIGW 软件，基于 OpenResty（Nginx + Lua 模块）实现，具有高可用、易扩展的特性。Kong 在 Mashape 上管理了超过 15,000 个 API，为 200,000 开发者提供了每月数十亿的请求支持。

• 官 ：https://konghq.com/kong/
• Github：https://github.com/Kong/kong
• Docs：https://docs.konghq.com/
• 中文文档：https://github.com/qianyugang/kong-docs-cn

Kong 和 OpenResty 一起打包发行，其中已经包含了 lua-nginx-module。可以简单理解为：Kong > OpenResty > Nginx + lua-nginx-module。

Kong 的软件架构

Kong 有 3 个核心组件：

1. Kong Server：主体程序，基于 Nginx 的 HTTP APIGW 服务器，用来接收 API 请求。
2. Apache Cassandra/PostgreSQL：后端数据库。
3. Kong Dashboard：UI 管理工具。

Kong 的分层架构：

1. Nginx 层：Niginx Server。
2. OpenResty 层：可以通过 Lua 模块来进行功能扩展是 Nginx 的一大特点，OpenResty 就是一组实现了 Web 平台的基础 Lua 模块，并与 Nginx 一起打包发布。
3. Cluster & Data Store 层：持久化 Kong 所需要的配置和生产数据，目前支持 Apache Cassandra 和 PostgreSQL 两种后端数据库。Cassandra 是分布式的 NoSQL 数据库，天然支持高可用。
4. Plugin 层：Kong 基于 OpenResty 可以继续实现各类 Plugin 继而满足 APIGW 的基本功能，且可以通过添加新的插件进行扩展，这些插件可以通过 RESTful Admin API 轻松配置。
5. RESTful APIs 层：包括 RESTful Admin API 和 RESTful Proxy API。

可见，Kong 覆盖了 Nginx 的所有功能，包括：反向代理、负载均衡以及基本的缓存、安全的认证、限流限速等。同时还支持 Nginx 等 Web 服务器实现不了的功能，例如：动态上游、动态 SSL 证书、动态限流限速，以及主动/被动健康检查、服务熔断等。

3. Prepare your database (Migrations)
4. Start Kong
5. Use Kong

Kong Server 启动后监听了 4 个端口：

1. 8000：HTTP Proxy API
2. 8443：HTTPS Proxy API
3. 8001：HTTP Admin API
4. 8444：HTTPS Admin API

Kong Server 的进程：

Kong 指令行选项：

配置 Kong Server

安装完 Kong Server 后主要关注两个文件目录：

1. 配置文件目录：/etc/kong
2. 运行文件目录：/usr/local/kong

如果我们需要修改 Nginx 的配置，实际上我们可以直接通过 Kong 的配置文件注入到 Nginx 配置，Kong 在启动的时候会生成 Nginx 的配置文件 nginx.conf 和 nginx-kong.conf。

Kong 的配置，分为以下几种：

• 常规配置：服务运行目录，插件加载，日志等。
• Nginx 配置：Nginx 监听 IP、端口配置等，用于 Kong 在启动的时候生成 Nginx 配置文件。
• 数据库存储配置：数据库类型，地址、用户名密码等。
• 数据库缓存配置：数据的缓存规则，Kong 会缓存诸如 API 信息、用户、凭证等信息，以减少访问数据库次数提高性能。
• DNS 解析器配置：默认情况会使用系统设置，如：hosts 和 resolv.conf 的配置，你也可以通过 DNS 的解析器配置来修改。
• 其他杂项配置：继承自 lua-nginx 模块的其他设置允许更多的灵活性和高级用法。

Admin Server：

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！