21

大家下午，

只是想找人仔细检查我的工作。以下是保护微服务的有效方法吗？

前提

将我们的单体应用程序和单体合作伙伴 API 分解为面向特定业务功能的微服务。它们很可能是在弹性 beantalk 上运行在 docker 容器中的小型 expressjs 应用程序，谁知道呢。他们会住在某个地方:)

我正在考虑将Kong作为我的 API 网关，或者使用 AWS API 网关来封装我的微服务的细节。此外，它只是感觉很好。

Kong的JWT 插件将验证 JWT 的签名，然后将customer_id标头中的签名传递给微服务。我还应该提到，我们也有第 3 方开发人员，他们也将参与到集成的乐趣中。这是我所看到的情况的基本草图：

执行

  1. 为我们拥有的每个平台和第 3 方开发人员生成“消费者”。（Web 应用程序、移动应用程序以及我们目前拥有的集成合作伙伴。注意：我不希望为每个登录的用户创建消费者。虽然肯定更安全，但这会增加很多工作。另外，如果你弄清楚如何从我的 API 网关中获取秘密我显然还有其他问题）
  2. 让Kong为我验证请求。有点像门口的保镖，没有授权，只是身份验证。
  3. 我不需要知道令牌到达微服务后是否有效，我可以使用一些中间件对其进行解码并使用自定义逻辑来决定该用户是否真的应该做他们想做的任何事情。

额外的东西

  • Kong 有一个不错的访问控制插件。我们的应用程序和移动应用程序将以“上帝”特权运行，但我绝对可以将开发人员锁定在特定的路线和方法上。

  • 撤销 3rd 方访问权限将很容易，撤销最终用户访问权限不会那么简单，除非我愿意通过生成一个新的秘密来一次使所有 JWT 无效。也许我可以将令牌时间限制在 10 分钟左右，并让我们的应用程序检查它们是否已过期，获取新令牌，然后继续处理原始请求。这样我可以在数据库或其他东西中“标记”它们，而不是让 JWT 生成。

  • SSL 无处不在，JWT 存储在 Web 浏览器中的仅 SSL cookie 中，并且在任何声明中都没有存储敏感信息。

多谢你们。

4

1 回答 1

20

我最近致力于解决这个问题和前提，将一个大型单体架构重构为 AWS 架构中的多个服务。

这个问题没有正确、错误或确定的方法。
但是，我们确实实施了与上述问题中描述的解决方案非常相似的解决方案。
我希望这个答案可以为第一次看到这个的人提供一个很好的方向感。

我们就是这样处理的……

我们需要从 API 网关获得什么？

  1. 高度可用
  2. 安全的
  3. 高性能
  4. 权威性
  5. 可扩展

解决方案 1：AWS API 网关

优点

  1. 高度可用的托管解决方案。
  2. 无需担心可扩展性。
  3. 支持 SSL 和自定义域。
  4. 通过 lambda 和 IAM 具有权威性。
  5. 与其他 AWS 服务配合得很好。
  6. 支持开箱即用的 API 版本控制。
  7. 使用 CloudWatch 轻松监控。

缺点

  1. 流量不能直接路由到内部网络（私有 VPC 网段），这意味着需要额外的网关。
    编辑： Amazon API Gateway 支持与私有 VPC 的终端节点集成。感谢@Red 提到这一点。
  2. 慢，我们的基准测试显示通过 API 网关的每个请求都会增加 100-150 毫秒的延迟。

解决方案2：Kong

优点

  1. 可扩展，但需要在我们端实施和管理。
  2. 支持 SSL 和自定义域。
  3. 通过插件进行授权，已经打包了 JWT 和 OAUTH2 的解决方案。
  4. RESTful API，可轻松与我们的身份验证服务器集成。
  5. 可扩展，以防我们需要一些自定义逻辑。
  6. 很快，我们的基准测试显示通过 Kong 的每个请求都会增加 20-30 毫秒的延迟。

缺点

  1. 需要我们进行管理（升级、部署、维护）。
  2. 为了实现 HA，需要一个额外的端点，以负载均衡器的形式将流量路由到实际的 GW(s)。

执行

我们决定和Kong一起去。
托管解决方案的主要问题是无法将流量路由到我们的私有网络，我们还在那里托管一个私有 DNS 区域。
此外，Kong 的可扩展性使我们能够创建具有与我们的解决方案相关的逻辑的自定义插件。
我们使用ALB在不同 AZ 中的多个 Kong 实例之间进行循环，以实现冗余和高可用性。
API 配置保存在 Postgres RDS 上，该 RDS 也是内部多可用区。

流动

  1. 客户端根据我们的身份验证服务器进行身份验证。身份验证服务器是 Kong GW 背后的一个微服务，上游公开。
  2. 身份验证服务器为单个客户端创建一个带有JWT的消费者。
  3. 身份验证服务器回复 JWT。
  4. 客户端使用 JWT 从 API 请求访问，流量通过 Kong 路由。
  5. Kong 验证 JWT 并将请求路由到带有消费者信息的微服务。
  6. 微服务响应客户端。

其他

  1. 撤销用户访问权限就像删除令牌一样简单。
  2. JWT 声明中不存储任何敏感信息。
  3. 所有服务都通过私有 DNS 区域相互了解。

架构：

Kong网关模式

于 2017-02-08T18:03:16.653 回答