使用 Kubernetes 和 KEDA 扩展 Didit Webhook 消费者 (ZH)

容器化是关键将您的 webhook 消费者逻辑封装在 Docker 容器中，以实现跨各种环境的可移植性、一致性和高效部署。

Kubernetes 进行编排利用 Kubernetes 进行强大的编排、自动化部署、自我修复能力以及高效管理大规模容器化 webhook 消费者。

KEDA 实现事件驱动的扩缩容实施 KEDA（Kubernetes 事件驱动自动扩缩容），根据 Didit webhook 事件的实际负载自动扩缩您的 webhook 消费者，确保最佳资源利用和响应能力。

Didit 的无缝集成Didit 提供了一个安全、可靠的 webhook 系统，支持 HMAC 签名验证，能够实时处理身份验证结果，并简化与可扩展消费者架构的集成。

实时身份验证事件处理的挑战

在当今快节奏的数字环境中，实时处理身份验证事件不再是奢侈品，而是必需品。利用 Didit 等平台进行身份验证、被动和主动活体检测或AML 筛选的企业通过 webhooks 接收关键更新。这些事件，从成功的验证到欺诈警报，都需要立即采取行动，以维持流畅的用户体验并确保合规性。然而，这些 webhooks 的数量和速度可能会剧烈波动。例如，用户注册量突然激增可能会使未能充分扩展的消费者应用程序不堪重负，导致处理延迟、事件丢失甚至系统崩溃。这就是为什么一个健壮且可扩展的 webhook 消费架构变得至关重要。

传统方法通常涉及过度配置服务器，导致在低流量时期浪费资源，或者手动扩缩容，这是一种被动且容易出错的方法。理想的解决方案是能够自动适应传入 webhook 负载的基础设施，无需人工干预即可高效处理每个事件。这篇博文将指导您如何容器化 webhook 消费者并使用 Kubernetes 和 KEDA 有效地扩展它们，确保您的应用程序随时准备好迎接下一波 Didit 验证事件。

使用 Docker 容器化您的 Webhook 消费者

构建可扩展的 webhook 消费者系统的第一步是容器化。Docker 提供了一种标准化的方式，将您的应用程序及其依赖项打包到一个轻量级、可移植的容器中。这确保了您的 webhook 消费者在任何环境中（从本地开发机器到生产 Kubernetes 集群）都能一致运行。您的消费者应用程序，无论是用 Python、Node.js、Java 还是任何其他语言编写的，都应设计为接收来自 Didit webhook 服务的 HTTP POST 请求，验证签名，然后处理有效负载。

一个典型的 webhook 消费者的 Dockerfile 可能如下所示（以 Node.js 为例）：

# Use a lightweight base image
FROM node:18-alpine

# Set the working directory
WORKDIR /app

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install --production

# Copy the application code
COPY . .

# Expose the port your app runs on
EXPOSE 3000

# Command to run the application
CMD ["node", "server.js"]

一旦容器化，您的 webhook 消费者就成为一个不可变单元，简化了部署并确保在开发环境中有效的功能在生产环境中也能正常工作。当处理来自 Didit 的关键身份验证数据时，这种一致性至关重要，因为处理错误可能会对用户体验和合规性产生重大影响。

Kubernetes：编排您的容器化消费者

当您的 webhook 消费者容器化后，Kubernetes 将作为编排器介入。Kubernetes 提供了一个强大的平台，用于部署、管理和扩展容器化应用程序。它提供了自我修复、自动化发布和回滚以及声明式配置等功能，使其成为运行现代云原生应用程序的事实标准。对于 Didit webhook 消费者，Kubernetes 确保了高可用性和可靠性。

您将把 webhook 消费者定义为一个 Kubernetes Deployment，指定 Docker 镜像、所需的副本数、资源请求和限制以及任何必要的环境变量（例如，用于签名验证的 Didit webhook 共享密钥）。相应的 Service 将您的消费者 pod 暴露给网络，通常在 Ingress 控制器后面，以接收来自 Didit 的传入 webhook 请求。然后，通过 API 或 Business Console 配置的 Didit webhooks 将事件发送到您的 Kubernetes 服务暴露的公共端点。

Kubernetes 管理 pod 生命周期 的能力意味着，如果一个消费者 pod 失败，Kubernetes 将自动重新启动或替换它，确保 Didit 实时更新的持续处理。这种弹性对于维护身份验证工作流的完整性至关重要，尤其是在处理来自 Didit 的NFC 验证或1:1 人脸比对产品的大量数据时。

KEDA：事件驱动的自动扩缩容以实现最佳效率

虽然 Kubernetes 可以根据 CPU 或内存利用率来扩展应用程序，但这种反应式方法对于像 webhook 消费者这样的事件驱动型工作负载来说并不总是理想的。Didit webhook 的突然爆发可能会导致 CPU 飙升，但 pod 可能无法足够快地扩展，从而导致积压。这就是 KEDA（Kubernetes Event-Driven Autoscaling）的用武之地。KEDA 允许您根据各种外部事件源（例如消息队列，如 Kafka、RabbitMQ、SQS）中需要处理的事件数量来扩展您的 Kubernetes 部署。

要有效地将 KEDA 用于 Didit webhooks，您通常会首先将传入的 webhooks 导入消息队列。您的 Kubernetes 部署随后从该队列中消费消息。KEDA 监控队列长度并相应地向上或向下扩展您的消费者 pod。如果 Didit 发送大量验证结果，队列长度会增加，KEDA 会自动配置更多的消费者 pod 来处理它们。当队列清空时，KEDA 会缩减 pod，优化资源利用率并降低成本。

这种异步模式提供了以下几个好处：

• 解耦：您的 webhook 端点可以快速确认 Didit 的 webhook，然后将事件排队等待处理，防止超时。
• 弹性：如果您的消费者应用程序宕机，事件会安全地存储在队列中，一旦消费者恢复，就可以进行处理。
• 可扩展性：KEDA 确保您的消费者精确地随需求扩展，防止瓶颈和资源浪费。

Didit 强大的 webhook 系统和 HMAC 签名验证确保接收到的事件是真实的且未被篡改，为这种事件驱动架构提供了安全的基础。您可以配置您的 Didit webhooks（推荐 v3）以发送与您的处理逻辑对齐的有效负载版本，并根据需要轮换您的 secret_shared_key 以增强安全性。

Didit 如何提供帮助

Didit 的设计秉承开发者优先的原则，使得与 Kubernetes 和 KEDA 等可伸缩架构的集成无缝衔接。我们强大的 webhook 系统为所有身份验证结果提供实时通知，无论是身份验证结果、地址证明确认，还是年龄估算结果。Didit 的 webhooks 是安全的，利用 HMAC 签名，您可以在消费者应用程序中轻松验证，以确保数据完整性和真实性。这对于维护信任和合规性至关重要，尤其是在处理敏感用户数据时。

Didit 的模块化架构允许您即插即用各种身份检查，生成各种 webhook 事件，您的可伸缩消费者系统可以高效处理这些事件。通过Didit 的免费套餐，您可以免费开始构建和测试您的容器化 webhook 消费者，利用我们的人工智能原生平台进行准确快速的身份验证。我们的 API 驱动方法和全面的文档使得设置、更新和管理您的 webhook 配置变得简单，包括直接通过 API 或业务控制台指定 webhook_url、webhook_version（推荐 v3），甚至轮换您的 secret_shared_key。Didit 确保您收到必要的数据以实现信任自动化和风险编排，同时提供以任何规模处理这些数据的工具。

准备好开始了吗？

准备好亲身体验 Didit 了吗？立即获取免费演示。

使用Didit 的免费套餐免费开始验证身份。