Tác giả: Debasis Rath và Joe Losinski
Ngày phát hành: 23 MAR 2026
Chuyên mục: AWS Lambda, Compute, Intermediate (200)

Các hàm bền vững của AWS Lambda mở rộng mô hình lập trình Lambda để xây dựng các ứng dụng đa bước chịu lỗi và quy trình làm việc AI bằng các ngôn ngữ lập trình quen thuộc. Chúng bảo toàn tiến độ bất chấp gián đoạn và quá trình thực thi có thể tạm dừng tới một năm, cho các phê duyệt của con người, trì hoãn theo lịch trình hoặc các sự kiện bên ngoài khác, mà không phát sinh phí tính toán cho các hàm theo yêu cầu.

Bài viết này sẽ hướng dẫn bạn qua một hệ thống phát hiện gian lận được xây dựng bằng các hàm bền vững. Nó cũng nêu bật các phương pháp hay nhất mà bạn có thể áp dụng cho các quy trình làm việc sản xuất của riêng mình, từ quy trình phê duyệt đến các đường ống dữ liệu và điều phối tác nhân AI. Bạn sẽ học cách xử lý các thông báo đồng thời, chờ phản hồi của khách hàng và phục hồi sau lỗi mà không mất tiến độ. Nếu bạn mới làm quen với các hàm bền vững, hãy xem bài đăng blog Giới thiệu về các hàm bền vững trước.

Phát hiện gian lận với sự can thiệp của con người (human-in-the-loop)

Hãy xem xét một hệ thống phát hiện gian lận thẻ tín dụng, sử dụng một tác nhân AI để phân tích các giao dịch đến và gán điểm rủi ro. Đối với các trường hợp không rõ ràng (điểm rủi ro trung bình), hệ thống cần sự chấp thuận của con người trước khi ủy quyền giao dịch. Quy trình làm việc phân nhánh dựa trên rủi ro:

• Rủi ro thấp (điểm < 3): Ủy quyền ngay lập tức
• Rủi ro cao (điểm ≥ 5): Gửi ngay đến bộ phận gian lận
• Rủi ro trung bình (điểm 3–4): Tạm dừng giao dịch, gửi SMS và email cho chủ thẻ, chờ tối đa 24 giờ để xác nhận (thời gian chờ có thể tùy chỉnh)

Hình 1: Phát hiện gian lận dựa trên tác nhân với các hàm bền vững của Lambda

Với các quy trình làm việc có sự can thiệp của con người, thời gian phản hồi có thể thay đổi từ vài phút đến vài giờ. Những sự chậm trễ này đòi hỏi phải bảo toàn trạng thái một cách bền vững mà không tiêu tốn tài nguyên tính toán trong khi chờ đợi. Với các hệ thống tài chính, chúng ta cũng phải triển khai tính bất biến (idempotency) để chống lại các thông báo trùng lặp (lời gọi) và phục hồi sau lỗi mà không cần xử lý lại công việc đã hoàn thành. Để giải quyết các yêu cầu này, các nhà phát triển triển khai các mẫu thăm dò với các kho lưu trữ trạng thái bên ngoài như Amazon DynamoDB hoặc Amazon Simple Storage Service (Amazon S3) để quản lý tính bất biến, trả tiền cho tài nguyên tính toán nhàn rỗi trong khi chờ đợi các lệnh gọi lại, giới thiệu các thành phần điều phối bên ngoài hoặc xây dựng các hệ thống dựa trên thông báo không đồng bộ để xử lý các tác vụ dài.

Các hàm bền vững của Lambda cung cấp một giải pháp thay thế mới để giải quyết những thách thức này thông qua thực thi bền vững, một mẫu sử dụng các điểm kiểm tra (ảnh chụp nhanh trạng thái đã lưu) để bảo toàn tiến độ và phát lại từ trạng thái đã lưu để phục hồi sau lỗi hoặc tiếp tục sau khi chờ đợi. Với khả năng kiểm tra điểm, bạn không còn cần phải trả phí tính toán Lambda trong khi chờ đợi, cho dù là lệnh gọi lại, trì hoãn theo lịch trình hay các sự kiện bên ngoài. Tìm hiểu cách triển khai các hàm bền vững bằng cách sử dụng triển khai phát hiện gian lận hoàn chỉnh tại kho lưu trữ GitHub này. Bạn có thể triển khai nó vào tài khoản AWS của mình và thử nghiệm với mã khi đọc. Kho lưu trữ bao gồm hướng dẫn triển khai, dữ liệu mẫu và các hàm trợ giúp để kiểm tra.

Khi chúng ta đi qua mã, chúng ta sẽ tập trung vào các phương pháp hay nhất để thiết kế quy trình làm việc với thực thi bền vững và cách áp dụng các mẫu này một cách chính xác trong các quy trình làm việc sản xuất.

Thiết kế các bước để có tính bất biến (idempotent)

Thực thi bền vững được thiết kế để bảo toàn tiến độ thông qua các điểm kiểm tra và phát lại, nhưng mô hình độ tin cậy đó có nghĩa là logic bước có thể thực thi nhiều hơn một lần. Khi các bước thử lại, làm thế nào để bạn ngăn chặn các hành động trùng lặp như tính phí vào thẻ tín dụng hoặc các thông báo SMS hoặc email lặp lại cho khách hàng?

Các hàm bền vững sử dụng thực thi ít nhất một lần theo mặc định, thực thi mỗi bước ít nhất một lần, có thể nhiều hơn nếu xảy ra lỗi. Khi một bước thất bại, nó sẽ thử lại. Có hai chiến lược để thiết kế các bước bất biến nhằm ngăn chặn các tác dụng phụ trùng lặp: sử dụng khóa bất biến API bên ngoài và sử dụng ngữ nghĩa bước tối đa một lần được tích hợp trong các hàm bền vững.

Chiến lược A: Khóa bất biến API bên ngoài

// Strategy A: Use external API idempotency keys
await context.step(`authorize-${tx.id}`, async () => {
  return payment.charges.create({
    amount: tx.amount,
    currency: 'usd',
    idempotency_key: `tx-${tx.id}`, // Prevents duplicate charges
    description: `Transaction ${tx.id}`
  });
});

Lưu ý cấu hình:

• idempotency_key trong lệnh gọi API: Nếu bước thử lại, bộ xử lý thanh toán sẽ nhận ra đó là một yêu cầu trùng lặp và trả về kết quả gốc.
• Phòng thủ theo chiều sâu: Hai lớp bảo vệ: kiểm tra điểm Lambda và tính bất biến của API bên ngoài.

Mỗi lớp cung cấp sự bảo vệ độc lập. Nếu điểm kiểm tra của Lambda thất bại, API bên ngoài sẽ ngăn chặn các khoản phí trùng lặp. Đối với các hệ thống cũ không hỗ trợ tính bất biến, nơi mà việc một hoạt động không được thực thi nhiều hơn một lần là rất quan trọng, hãy sử dụng ngữ nghĩa tối đa một lần:

Chiến lược B: Sử dụng ngữ nghĩa tối đa một lần

Đối với các hệ thống cũ không hỗ trợ tính bất biến, hãy sử dụng thực thi tối đa một lần, một tính năng phân phối thực thi mỗi bước không hoặc một lần, không bao giờ nhiều hơn:

// Strategy B: At-most-once step semantics
await context.step("charge-legacy-system", async () => {
  return await legacyPaymentSystem.charge(tx.amount);
}, {
  semantics: StepSemantics.AtMostOncePerRetry,
  retryStrategy: createRetryStrategy({ maxAttempts: 0 })
});

Điều này kiểm tra điểm trước khi thực thi bước, ngăn chặn bước thực thi lại khi thử lại. Sự đánh đổi? Nếu bước thất bại, bạn phải quyết định có nên thử lại (nguy cơ trùng lặp) hay làm thất bại toàn bộ quy trình làm việc.

Sử dụng tính bất biến cho các tác dụng phụ quan trọng như xử lý thanh toán, ghi vào cơ sở dữ liệu, gọi API bên ngoài, chuyển đổi trạng thái và cấp phát tài nguyên. Đọc thêm về tính bất biến tại đây.

Ngăn chặn các lần thực thi trùng lặp với DurableExecutionName

Các bước bất biến ngăn chặn các tác dụng phụ trùng lặp trong một lần thực thi duy nhất, nhưng còn các lần thực thi quy trình làm việc trùng lặp chạy đồng thời thì sao? Ví dụ, các thông báo trùng lặp trong hàng đợi, người dùng nhấp vào “Gửi” nhiều lần trong giao diện người dùng, hoặc cùng một sự kiện đến qua nhiều kênh như webhook và API. Nếu không có bảo vệ, mỗi lời gọi sẽ tạo ra một lần thực thi bền vững riêng biệt, có khả năng chạy kiểm tra gian lận nhiều lần, gửi thông báo trùng lặp và tạo ra sự nhầm lẫn về lần thực thi nào là có thẩm quyền. Các hàm bền vững cung cấp DurableExecutionName để giúp đảm bảo chỉ có một lần thực thi đồng thời cho mỗi tên duy nhất.

// Invoke fraud detection function with execution name
await lambda.invoke({
  FunctionName: 'fraud-detection',
  InvocationType: 'Event',
  DurableExecutionName: `tx-${transactionId}`,
  Payload: JSON.stringify({
    id: transactionId,
    amount: 6500,
    location: 'New York, NY',
    vendor: 'Amazon.com'
  })
});

Lưu ý cấu hình:

• DurableExecutionName: tx-${transactionId}: Sử dụng ID giao dịch làm định danh thực thi duy nhất.
• InvocationType: ‘Event’: Lời gọi không đồng bộ hỗ trợ các quy trình làm việc dài hơn 15 phút.
• Một lần thực thi cho mỗi giao dịch: Nếu ba lời gọi đến với cùng một ID giao dịch, chỉ lời gọi đầu tiên tạo ra một lần thực thi. Các yêu cầu tiếp theo với cùng tên thực thi và payload sẽ nhận được một phản hồi bất biến trả về ARN của lần thực thi hiện có, thay vì tạo một lần thực thi mới.

Các hàm bền vững của Lambda hoạt động với các nguồn sự kiện Lambda, bao gồm ánh xạ nguồn sự kiện (ESM) như Amazon Simple Queue Service (Amazon SQS), Amazon Kinesis và DynamoDB Streams. ESM gọi các hàm bền vững một cách đồng bộ và kế thừa giới hạn lời gọi 15 phút của Lambda. Do đó, giống như các lời gọi Request/Response trực tiếp, các lần thực thi hàm bền vững sử dụng ánh xạ nguồn sự kiện không thể vượt quá 15 phút.

Đối với các quy trình làm việc vượt quá 15 phút, hãy sử dụng một hàm Lambda trung gian giữa ánh xạ nguồn sự kiện và hàm bền vững:

// Intermediary function for SQS -> Durable function
export const handler = async (event) => {
  for (const record of event.Records) {
    const transaction = JSON.parse(record.body);
    await lambda.invoke({
      FunctionName: process.env.FRAUD_DETECTION_FUNCTION,
      InvocationType: 'Event',
      DurableExecutionName: `tx-${transaction.id}`,
      Payload: JSON.stringify(transaction)
    });
  }
};

Điều này loại bỏ giới hạn 15 phút, cho phép thực thi lên đến một năm và cho phép các tham số tên thực thi tùy chỉnh cho tính bất biến. Sử dụng Powertools for AWS Lambda để ngăn chặn các lời gọi trùng lặp của hàm bền vững khi ánh xạ nguồn sự kiện thử lại hàm trung gian. Ngoài ra, hãy cấu hình xử lý lỗi cho nguồn sự kiện của bạn để ghi lại các lời gọi thất bại để phục hồi hoặc phát lại trong tương lai. Ví dụ, hàng đợi thư chết (dead letter queues) cho SQS, hoặc đích đến khi thất bại (on-failure destinations) cho các nguồn sự kiện khác.

Khớp thời gian chờ với loại lời gọi

Một chi tiết cấu hình quan trọng gắn kết các mẫu này lại với nhau: khớp cài đặt thời gian chờ của bạn với loại lời gọi của bạn. Các lời gọi đồng bộ của Lambda (RequestResponse) có giới hạn thời gian chờ cứng là 15 phút. Nếu bạn cấu hình một lần thực thi bền vững để chạy trong 24 giờ nhưng gọi nó một cách đồng bộ, lời gọi đồng bộ sẽ thất bại ngay lập tức với một ngoại lệ. Các hàm bền vững hỗ trợ các quy trình làm việc lên đến một năm khi được gọi không đồng bộ.

// Lambda function configuration
{
  FunctionName: 'fraud-detection',
  Timeout: 300,
  MemorySize: 512,
  DurableConfig: {
    ExecutionTimeout: 90000
  }
}

Và gọi không đồng bộ:

// Async invocation for long-running workflow
await lambda.invoke({
  FunctionName: 'fraud-detection',
  InvocationType: 'Event',
  DurableExecutionName: `tx-${transactionId}`,
  Payload: JSON.stringify(transaction)
});

Lưu ý cấu hình:

• Timeout: 300: Thời gian chờ của hàm Lambda (5 phút trong ví dụ này, tối đa 15 phút). Điều này định nghĩa thời lượng tối đa cho mỗi giai đoạn thực thi hoạt động, bao gồm lời gọi ban đầu và bất kỳ lần phát lại tiếp theo nào. Đặt giá trị này để bao gồm thời gian xử lý hoạt động dự kiến dài nhất trong quy trình làm việc của bạn.
• ExecutionTimeout: { hours: 25 }: Thời gian chờ thực thi bền vững bao gồm tổng thời lượng dự kiến của quy trình làm việc, bao gồm cả các giai đoạn tạm dừng. Đặt giá trị này cao hơn một chút so với thời gian chờ dài nhất để tránh các trường hợp biên.
• InvocationType: ‘Event’: Lời gọi không đồng bộ loại bỏ giới hạn 15 phút và cho phép thực thi lên đến một năm.

Thời gian chờ của hàm Lambda áp dụng cho các giai đoạn thực thi hoạt động (lời gọi AI, gửi thông báo). Trong thời gian tạm dừng (chờ lệnh gọi lại), hàm không chạy, vì vậy thời gian chờ này không áp dụng. Đặt thời gian chờ thực thi bền vững thành một giới hạn có ý nghĩa sẽ ngăn các quy trình làm việc chạy lâu hơn dự kiến. Nếu không có thời gian chờ rõ ràng, các lần thực thi có thể chạy đến thời gian tồn tại tối đa là một năm.

Thực thi các hoạt động đồng thời với context.parallel()

Trong quy trình làm việc phát hiện gian lận, hệ thống thông báo cho chủ thẻ qua nhiều kênh như SMS và email. Việc bảo toàn logic nghiệp vụ khi thực thi các quy trình làm việc song song gây ra sự phức tạp trong mã như quản lý trạng thái thực thi trên các nhánh, xử lý đồng bộ hóa và điều phối hoàn thành nhánh. Các hàm bền vững đơn giản hóa việc triển khai quy trình làm việc song song bằng cách sử dụng context.parallel(), thực thi các nhánh đồng thời trong khi duy trì các điểm kiểm tra bền vững cho mỗi nhánh và cung cấp các tùy chọn cấu hình để xử lý hoàn thành một phần. Bằng cách kiểm tra điểm và quản lý trạng thái nội bộ, các hàm bền vững giúp đảm bảo rằng trạng thái được bảo toàn ngay cả khi có các lần thử lại hoặc lỗi. Lưu ý rằng context.parallel() quản lý trạng thái thực thi nội bộ cho mỗi nhánh. Nếu các nhánh của bạn tương tác với một trạng thái bên ngoài được chia sẻ (chẳng hạn như cơ sở dữ liệu), bạn chịu trách nhiệm quản lý quyền truy cập đồng thời vào trạng thái bên ngoài đó.

// Human-in-the-loop: verify via email AND SMS (first response wins)
let verified = await context.parallel("human-verification", [
  (ctx) => ctx.waitForCallback("SendVerificationEmail",
    async (callbackId) => sendCustomerNotification(callbackId, 'email', tx)
  ),
  (ctx) => ctx.waitForCallback("SendVerificationSMS",
    async (callbackId) => sendCustomerNotification(callbackId, 'sms', tx)
  )
], {
  maxConcurrency: 2,
  completionConfig: {
    minSuccessful: 1 // Continue after 1 success
  }
});

Lưu ý cấu hình:

• maxConcurrency: 2: Cả hai thông báo được gửi cùng một lúc.
• minSuccessful: 1: Chúng ta chỉ cần một kênh thành công, kênh nào phản hồi trước sẽ thắng.

Mỗi nhánh song song chờ lệnh gọi lại của nó một cách độc lập, và quá trình thực thi bền vững kiểm tra điểm mỗi nhánh như một phần của trạng thái thực thi. Sử dụng tham số minSuccessful, bạn kiểm soát số lượng tối thiểu các lần thực thi nhánh thành công cần thiết để hoạt động song song hoàn thành. Trong ví dụ này, chỉ một trong hai nhánh cần thành công. Xác minh qua SMS hoặc email đều hợp lệ, và quy trình làm việc tiếp tục ngay khi một trong hai kênh hoàn thành thành công. Chúng ta gọi đây là mẫu phản hồi đầu tiên thắng. Mẫu này hoạt động tốt khi bạn chỉ cần một kết quả thành công duy nhất từ bất kỳ nhánh song song nào và muốn các nhánh còn lại ngừng chặn tiến độ.

Nhưng điều gì sẽ xảy ra nếu không kênh nào phản hồi? Nếu không có thời gian chờ, quy trình làm việc này có thể vẫn bị tạm dừng cho đến hết thời gian tồn tại thực thi đã cấu hình.

Luôn cấu hình thời gian chờ lệnh gọi lại

Hãy thêm bảo vệ thời gian chờ vào xác minh song song từ phần trước. context.waitForCallback() chấp nhận một tùy chọn timeout giới hạn thời gian mỗi nhánh chờ trước khi ném ra một ngoại lệ. Bằng cách gói lệnh gọi song song trong một khối try/catch, bạn có thể triển khai logic dự phòng khi người dùng không phản hồi kịp thời.

// Enhanced: parallel verification with timeout and error handling
let verified;
try {
  verified = await context.parallel("human-verification", [
    (ctx) => ctx.waitForCallback("SendVerificationEmail",
      async (callbackId) => sendCustomerNotification(callbackId, 'email', tx),
      { timeout: { days: 1 } }  // Wait up to 1 day for email response
    ),
    (ctx) => ctx.waitForCallback("SendVerificationSMS",
      async (callbackId) => sendCustomerNotification(callbackId, 'sms', tx),
      { timeout: { days: 1 } }  // Wait up to 1 day for SMS response
    )
  ], {
    maxConcurrency: 2,
    completionConfig: {
      minSuccessful: 1
    }
  });
} catch (error) {
  const isTimeout = error.message?.includes("timeout");
  if (isTimeout) {
    context.logger.warn("Customer verification timeout", { error, txId: tx.id });
    // Fallback: escalate to fraud department
    return await context.step("sendToFraudDepartment", async () =>
      sendToFraudDepartment(tx, true)
    );
  }
  throw error; // Re-throw non-timeout errors
}

Lưu ý những gì đã thay đổi so với phần trước:

• timeout: { days: 1 }: Mỗi nhánh lệnh gọi lại hiện có thời gian chờ tối đa là 1 ngày. Nếu cả lệnh gọi lại email và SMS đều không đến trong khoảng thời gian đó, một ngoại lệ thời gian chờ sẽ được ném ra.
• try/catch với phát hiện thời gian chờ: Khối catch phân biệt giữa lỗi thời gian chờ và các ngoại lệ khác. Khi xảy ra thời gian chờ, quy trình làm việc triển khai logic dự phòng bằng cách chuyển giao dịch cho bộ phận gian lận, trong khi các lỗi không phải thời gian chờ được ném lại để được xử lý bởi cơ chế thử lại thực thi bền vững.

Nếu không có xử lý lỗi này, toàn bộ quá trình thực thi sẽ thất bại mà không được xử lý. Thời gian chờ cũng hoạt động với cấu hình minSuccessful: nếu một nhánh hết thời gian chờ nhưng nhánh kia thành công, hoạt động song song vẫn hoàn thành thành công vì chỉ cần một kết quả thành công.

Đối với các trường hợp sử dụng nâng cao nơi trình xử lý lệnh gọi lại thực hiện công việc dài, bạn cũng có thể cấu hình một heartbeatTimeout để phát hiện các lệnh gọi lại bị kẹt trước khi thời gian chờ chính hết hạn. Xem Hướng dẫn dành cho nhà phát triển Lambda để biết chi tiết.

Sử dụng thời gian chờ lệnh gọi lại cho các phê duyệt của con người, lệnh gọi lại API bên ngoài, xử lý không đồng bộ và tích hợp bên thứ ba.

Tổng hợp tất cả: triển khai phát hiện gian lận hoàn chỉnh

Bây giờ hãy xem tất cả các phương pháp hay nhất hoạt động cùng nhau như thế nào trong quy trình làm việc phát hiện gian lận hoàn chỉnh:

import { withDurableExecution } from "@aws/durable-execution-sdk-js";
import { BedrockAgentCoreClient, InvokeAgentRuntimeCommand } from "@aws-sdk/client-bedrock-agentcore";
const agentRuntimeArn = process.env.AGENT_RUNTIME_ARN;
const agentRegion = process.env.AGENT_REGION || 'us-east-1';
const client = new BedrockAgentCoreClient({ region: agentRegion });
export const handler = withDurableExecution(async (event, context) => {
  const tx = {
    id: event.id,
    amount: event.amount,
    location: event.location,
    vendor: event.vendor
  };
  // AI fraud assessment with error handling
  tx.score = await context.step("fraudCheck", async () => {
    try {
      const payloadJson = JSON.stringify({ input: { amount: tx.amount } });
      const command = new InvokeAgentRuntimeCommand({
        agentRuntimeArn: agentRuntimeArn,
        qualifier: 'DEFAULT',
        payload: Buffer.from(payloadJson, 'utf-8'),
        contentType: 'application/json',
        accept: 'application/json'
      });
      const response = await client.send(command);
      const responseText = await response.response.transformToString();
      const result = JSON.parse(responseText);
      return result?.output?.risk_score ?? 5;  // Default to high-risk if score unavailable
    } catch (error) {
      context.logger.error("Fraud check failed", { error, txId: tx.id });
      return 5;
    }
  });
  // Route based on AI decision
  if (tx.score < 3) {
    // Best Practice: Idempotent authorization
    return await context.step(`authorize-${tx.id}`, async () =>
    authorizeTransaction(tx, { idempotency_key: `tx-${tx.id}` })
    );
  }
  if (tx.score >= 5) {
    return await context.step(`sendToFraudDepartment-${tx.id}`, async () =>
      sendToFraudDepartment(tx)
    );
  }
  // Medium risk: need human verification
  await context.step(`suspend-${tx.id}`, async () => suspendTransaction(tx));
  // Best Practice: Concurrent operations with timeout configuration
  let verified;
  try {
    verified = await context.parallel("human-verification", [
      (ctx) => ctx.waitForCallback("SendVerificationEmail",
        async (callbackId) => sendCustomerNotification(callbackId, 'email', tx),
        { timeout: { days: 1 } }
      ),
      (ctx) => ctx.waitForCallback("SendVerificationSMS",
        async (callbackId) => sendCustomerNotification(callbackId, 'sms', tx),
        { timeout: { days: 1 } }
      )
    ], {
      maxConcurrency: 2,
      completionConfig: {
        minSuccessful: 1
      }
    });
  } catch (error) {
    const isTimeout = error.message?.includes("timeout");
    context.logger.warn(
      isTimeout ? "Customer verification timeout" : "Customer verification failed",
      { error, txId: tx.id }
    );
    return await context.step(`timeout-escalate-${tx.id}`, async () =>
      sendToFraudDepartment(tx, true)
    );
  }
  // Idempotent final step with idempotency key
  return await context.step(`finalize-${tx.id}`, async () => {
    const action = !verified.hasFailure && verified.successCount > 0
      ? "authorize"
      : "escalate";
    if (action === "authorize") {
      return authorizeTransaction(tx, true, { idempotency_key: `finalize-${tx.id}` });
    }
    return sendToFraudDepartment(tx, true);
  });
});

Lưu ý cách các phương pháp hay nhất hoạt động cùng nhau: context.parallel() gửi SMS và email đồng thời, tiếp tục khi một trong hai kênh phản hồi. Cả hai lệnh gọi lại đều cấu hình thời gian chờ 1 ngày với xử lý try/catch sẽ leo thang khi hết thời gian chờ. Tham số DurableExecutionName: tx-${transactionId} (được chỉ định tại thời điểm gọi, hiển thị trong ví dụ CLI sau) cung cấp tính năng loại bỏ trùng lặp cấp độ thực thi, trong khi các khóa bất biến trong các bước ủy quyền ngăn chặn các khoản phí trùng lặp ở lớp ứng dụng. Lời gọi không đồng bộ (InvocationType: 'Event') cho phép thời gian chờ 24 giờ.

Sau khi triển khai, hãy gọi hàm không đồng bộ với một giao dịch mẫu để xem nó hoạt động:

transactionId="123456789"
aws lambda invoke \
  --function-name "fraud-detection:$LATEST" \
  --invocation-type Event \
  --durable-execution-name "tx-${transactionId}" \
  --cli-binary-format raw-in-base64-out \
  --payload "{\"id\": \"${transactionId} \", \"amount\": 6500, \"location\": \"New York, NY\", \"vendor\": \"Amazon.com\"}" \
  --region us-east-2 \
  response.json

Sau khi gọi thành công, bạn có thể xem trạng thái thực thi trong chế độ xem các hoạt động bền vững của bảng điều khiển Lambda. Quá trình thực thi hiển thị trạng thái tạm dừng, chờ phản hồi của khách hàng:

Hình 2: Trạng thái thực thi bị tạm dừng

Lưu ý các bước fraudCheck và suspendTransaction hiển thị là thành công với kết quả đã được kiểm tra điểm. Hoạt động song song xác minh của con người cho thấy cả hai nhánh SMS và email đã bắt đầu. Dòng thời gian hiển thị hàm ở trạng thái tạm dừng. Mô phỏng phản hồi của khách hàng bằng cách gửi một lệnh gọi lại thành công thông qua bảng điều khiển, AWS Command Line Interface (AWS CLI) hoặc Lambda API:

aws lambda send-durable-execution-callback-success \
    --callback-id <CALLBACK_ID_FROM_EMAIL_OR_SMS> \
    --result '{"status":"approved","channel":"email"}' \
    --cli-binary-format raw-in-base64-out

Hình 3: Thực thi hoàn thành với sự chấp thuận của khách hàng

Sau khi nhận được sự chấp thuận của khách hàng, quá trình thực thi bền vững tiếp tục từ điểm kiểm tra của nó, ủy quyền giao dịch và hoàn thành. Quá trình thực thi kéo dài hàng giờ nhưng chỉ tiêu tốn vài giây thời gian tính toán.

Kết luận

Với các hàm bền vững, Lambda mở rộng vượt ra ngoài xử lý sự kiện đơn lẻ để cung cấp năng lượng cho các quy trình kinh doanh cốt lõi và các quy trình làm việc dài hạn, đồng thời giữ lại sự đơn giản trong vận hành, độ tin cậy và khả năng mở rộng đặc trưng của Lambda. Bạn có thể xây dựng các ứng dụng chạy trong nhiều ngày hoặc nhiều tháng, tồn tại sau các lỗi và tiếp tục từ nơi chúng đã dừng lại, tất cả trong mô hình lập trình hướng sự kiện quen thuộc.

Triển khai quy trình làm việc phát hiện gian lận từ kho lưu trữ GitHub của chúng tôi và thử nghiệm với các mẫu có sự can thiệp của con người trong tài khoản của riêng bạn. Để biết các khái niệm cốt lõi, hãy xem Giới thiệu về các hàm bền vững của AWS Lambda. Để có tài liệu toàn diện, hãy xem Hướng dẫn dành cho nhà phát triển Lambda. Duyệt qua Serverless Land để tìm các kiến trúc tham chiếu và khám phá nơi thực thi bền vững phù hợp với thiết kế của bạn.

Chia sẻ phản hồi, câu hỏi và trường hợp sử dụng của bạn trong các kho lưu trữ SDK hoặc trên re:Post.