Xây dựng hệ thống cấu hình đa đối tượng thuê với các mẫu lưu trữ được gắn thẻ

Tác giả: Koshal Agrawal, Ishita Gupta, and Vijit Vashishtha
Ngày phát hành: 08 APR 2026
Chuyên mục: Advanced (300), Amazon Cognito, Amazon DynamoDB, Amazon EventBridge, AWS Lambda, AWS Systems Manager, Financial Services, Industries, Technical How-to

Trong các kiến trúc microservices hiện đại, quản lý cấu hình vẫn là một trong những mối quan tâm vận hành thách thức nhất. Hai khoảng trống xuất hiện khi các tổ chức mở rộng quy mô: xử lý siêu dữ liệu đối tượng thuê thay đổi nhanh hơn mức TTL của cache cho phép, và mở rộng quy mô dịch vụ siêu dữ liệu mà không tạo ra nút thắt cổ chai về hiệu suất.

Các chiến lược caching truyền thống buộc phải đánh đổi khó chịu: hoặc chấp nhận ngữ cảnh đối tượng thuê cũ (có nguy cơ cô lập dữ liệu hoặc cờ tính năng không chính xác), hoặc triển khai vô hiệu hóa cache mạnh mẽ làm giảm hiệu suất và tăng tải cho dịch vụ siêu dữ liệu của bạn. Khi số lượng đối tượng thuê tăng lên hàng trăm hoặc hàng nghìn, bản thân dịch vụ siêu dữ liệu này trở thành một thách thức về mở rộng quy mô, đặc biệt khi các loại cấu hình khác nhau có các mẫu truy cập rất khác nhau.

Thách thức càng tăng lên khi bạn cần hỗ trợ các backend lưu trữ khác nhau cho các loại cấu hình khác nhau. Một số yêu cầu các mẫu truy cập tần suất cao phù hợp với Amazon DynamoDB, trong khi những loại khác hưởng lợi từ tổ chức phân cấp và tính năng lập phiên bản tích hợp của AWS Systems Manager Parameter Store. Các giải pháp truyền thống thường đẩy các nhóm kỹ thuật vào thế khó: hoặc xây dựng nhiều dịch vụ cấu hình (tăng chi phí vận hành), hoặc đánh đổi hiệu suất bằng cách sử dụng một backend lưu trữ duy nhất không được tối ưu hóa cho mọi trường hợp sử dụng.

Trong bài đăng này, chúng tôi trình bày cách bạn có thể xây dựng một dịch vụ cấu hình đa đối tượng thuê, có khả năng mở rộng bằng cách sử dụng mẫu lưu trữ được gắn thẻ (tagged storage pattern), một phương pháp kiến trúc sử dụng tiền tố khóa (như tenant_config_ hoặc param_config_) để tự động định tuyến các yêu cầu cấu hình đến dịch vụ lưu trữ AWS phù hợp nhất. Mẫu này duy trì sự cô lập đối tượng thuê nghiêm ngặt và hỗ trợ cập nhật cấu hình theo thời gian thực, không gián đoạn thông qua kiến trúc hướng sự kiện, giảm thiểu vấn đề dữ liệu cache cũ.

Những gì bạn sẽ học:

Triển khai mô hình dữ liệu đa đối tượng thuê với DynamoDB và Parameter Store
Sử dụng mẫu Strategy để chuyển đổi backend lưu trữ linh hoạt
Xây dựng sự cô lập đối tượng thuê thông qua các claim của JSON Web Token (JWT)
Tạo cơ chế tự động làm mới hướng sự kiện với Amazon EventBridge và AWS Lambda
Triển khai cập nhật cấu hình không gián đoạn với gRPC (một giao thức giao tiếp hiệu suất cao) streaming
Giải quyết vấn đề TTL của cache cho siêu dữ liệu đối tượng thuê thay đổi nhanh chóng

Cuối bài đăng này, bạn sẽ hiểu cách kiến trúc một dịch vụ cấu hình xử lý các yêu cầu đa đối tượng thuê phức tạp trong khi tối ưu hóa cả hiệu suất và sự đơn giản trong vận hành.

Tổng quan giải pháp

Kiến trúc sử dụng bốn dịch vụ AWS được điều phối thông qua một dịch vụ gRPC dựa trên NestJS để tạo ra một hệ thống quản lý cấu hình đáng tin cậy, hướng sự kiện. Trước tiên, hãy hiểu kiến trúc tổng thể trước khi đi sâu vào chi tiết triển khai của từng thành phần.

Các thành phần kiến trúc

Sơ đồ sau đây cho thấy kiến trúc end-to-end của Dịch vụ Cấu hình Đa đối tượng thuê được triển khai trên AWS, từ cách các yêu cầu của client đi vào hệ thống đến cách dữ liệu cấu hình được truy xuất từ backend lưu trữ phù hợp.

Hình 1: Kiến trúc Dịch vụ Cấu hình Đa đối tượng thuê

Các ứng dụng client xác thực qua Amazon Cognito và đi qua AWS WAF trước khi đến Amazon API Gateway. Lưu lượng truy cập sau đó được định tuyến qua VPC Link đến Application Load Balancer, phân phối các yêu cầu trên hai microservices cốt lõi chạy trên Amazon Elastic Container Service (Amazon ECS) trên AWS Fargate trong các subnet riêng tư:

Order Service— xử lý các yêu cầu REST đến và ủy quyền tra cứu cấu hình cho Config Service qua gRPC
Config Service— cung cấp API gRPC và sử dụng Config Strategy Factory để tự động chọn backend lưu trữ phù hợp (DynamoDB hoặc Parameter Store) dựa trên yêu cầu

Dịch vụ khám phá được quản lý bởi AWS Cloud Map, trong khi Amazon CloudWatch tập trung nhật ký và số liệu trên các dịch vụ.

Hệ thống được tổ chức thành bốn lớp liên kết với nhau, mỗi lớp giải quyết một khía cạnh cụ thể của thách thức quản lý cấu hình:

1. Lớp lưu trữ – chiến lược đa backend

Lớp lưu trữ sử dụng một cách chiến lược hai dịch vụ AWS bổ sung, mỗi dịch vụ được tối ưu hóa cho các mẫu và yêu cầu truy cập cấu hình khác nhau.

Amazon DynamoDB: Lưu trữ các cấu hình dành riêng cho đối tượng thuê. Đây là các cài đặt duy nhất cho mỗi khách hàng, chẳng hạn như tùy chọn cổng thanh toán hoặc cờ tính năng. Với độ trễ một chữ số mili giây, DynamoDB xử lý các thao tác đọc tần suất cao một cách hiệu quả. Lược đồ sử dụng các khóa tổng hợp (TENANT#{tenantId} làm khóa phân vùng, CONFIG#{configType} làm khóa sắp xếp) để truy vấn hiệu quả theo phạm vi đối tượng thuê và cô lập đa đối tượng thuê tích hợp ở cấp độ mô hình dữ liệu.
AWS Systems Manager Parameter Store: quản lý các tham số được chia sẻ. Đây là các giá trị cấu hình được sử dụng trên nhiều dịch vụ hoặc đối tượng thuê, chẳng hạn như các API endpoint, chuỗi kết nối cơ sở dữ liệu và cài đặt dành riêng cho Region. Không giống như các cấu hình dành riêng cho đối tượng thuê thay đổi thường xuyên, các tham số này tương đối tĩnh nhưng hưởng lợi từ tổ chức phân cấp. Cấu trúc đường dẫn (/config-service/{tenantId}/{service}/{parameter}) cho phép các hoạt động truy xuất hàng loạt, giảm số lượng lệnh gọi API cần thiết trong quá trình khởi tạo dịch vụ từ hàng chục xuống chỉ một yêu cầu.

2. Lớp dịch vụ – gRPC với mẫu chiến lược

Một microservice dựa trên NestJS triển khai logic truy xuất cấu hình bằng gRPC để giao tiếp hiệu suất cao, an toàn về kiểu. Lựa chọn này giảm đáng kể băng thông mạng và cải thiện thời gian phản hồi cho giao tiếp giữa các dịch vụ mà không yêu cầu tương thích với trình duyệt web.

Cốt lõi là một triển khai mẫu Strategy xác định backend lưu trữ tối ưu dựa trên tiền tố khóa cấu hình. Mẫu này đơn giản hóa việc thêm các backend lưu trữ mới (như Amazon Simple Storage Service (Amazon S3) cho các tệp cấu hình lớn) mà không cần sửa đổi logic dịch vụ cốt lõi.

3. Lớp xác thực – Amazon Cognito

Luồng xác thực người dùng thông qua Amazon Cognito với các thuộc tính tùy chỉnh:

custom:tenantId (bất biến) – Định danh đối tượng thuê được nhúng trong JWT
custom:role (có thể thay đổi) – Vai trò người dùng để ủy quyền

Thiết kế bảo mật quan trọng: Dịch vụ không bao giờ chấp nhận tenantId từ các tham số yêu cầu. Thay vào đó, nó trích xuất ngữ cảnh đối tượng thuê từ các token JWT đã được xác thực, đảm bảo các yêu cầu không thể truy cập dữ liệu của các đối tượng thuê khác ngay cả khi chúng cố gắng thao túng tải trọng yêu cầu.

4. Lớp làm mới theo sự kiện

Các bản cập nhật cấu hình truyền thống đặt ra một tình huống khó xử: làm thế nào để bạn giữ các dịch vụ đồng bộ mà không ảnh hưởng đến hiệu suất hoặc gây ra thời gian ngừng hoạt động?

Các phương pháp thăm dò liên tục kiểm tra các thay đổi, tạo ra các lệnh gọi API không cần thiết tốn tiền ngay cả khi không có gì thay đổi. Chúng cũng gây ra sự chậm trễ. Các dịch vụ không thấy các bản cập nhật cho đến chu kỳ thăm dò tiếp theo, có thể là vài giây hoặc vài phút sau.

Các phương pháp khởi động lại dịch vụ gây ra thời gian ngừng hoạt động, làm mất các kết nối đang hoạt động và làm gián đoạn các phiên người dùng. Đối với các ứng dụng SaaS phục vụ khách hàng 24/7, các bản cập nhật dựa trên khởi động lại là không thể chấp nhận được.

Lớp làm mới theo sự kiện giải quyết cả hai vấn đề bằng cách triển khai kiến trúc phản ứng trong đó Amazon EventBridge giám sát Parameter Store để tìm các thay đổi và kích hoạt AWS Lambda để cập nhật cache cục bộ của dịch vụ. Điều này đạt được các bản cập nhật cấu hình trong vòng vài giây trong khi người dùng không gặp phải sự gián đoạn nào.

Triển khai kỹ thuật

Các phần sau đây trình bày chi tiết việc triển khai, bắt đầu với mô hình dữ liệu, đóng vai trò là xương sống cho việc cô lập đối tượng thuê và truy vấn hiệu quả.

A. Mô hình dữ liệu đa đối tượng thuê

Nền tảng của sự cô lập đối tượng thuê bắt đầu với mô hình dữ liệu. Sử dụng cấu trúc khóa tổng hợp của DynamoDB, chúng tôi đạt được cả sự cô lập đối tượng thuê và truy vấn hiệu quả mà không yêu cầu các bảng riêng biệt cho mỗi đối tượng thuê.

Thiết kế lược đồ DynamoDB:

Ví dụ sau đây cho thấy một cấu hình dành riêng cho đối tượng thuê được lưu trữ trong DynamoDB, minh họa cách các khóa tổng hợp cho phép cả sự cô lập và truy cập hiệu quả:

			
{
  "pk": "TENANT#acme-corp",
  "sk": "CONFIG#payment-gateway",
  "config": {
    "providers": [
      {
        "name": "Stripe",
        "apiEndpoint": "https://api.stripe.com",
        "retryPolicy": "exponential"
      }
    ]
  },
  "isActive": true,
  "version": 2,
  "createdAt": "2024-01-15T10:30:00Z",
  "updatedAt": "2024-02-20T14:45:00Z"
}

		

Các quyết định về lược đồ khóa:

Mẫu khóa phân vùng: TENANT#{tenantId} đảm bảo dữ liệu đối tượng thuê được đặt cùng vị trí, cho phép truy vấn hiệu quả theo phạm vi đối tượng thuê trong khi vẫn duy trì sự tách biệt logic.
Mẫu khóa sắp xếp: CONFIG#{configType} cho phép truy vấn các loại cấu hình cụ thể trong dữ liệu của đối tượng thuê. Tiền tố CONFIG# cho phép mở rộng trong tương lai với các loại thực thể khác (ví dụ: METADATA#, AUDIT#).
Xóa mềm: Cờ boolean isActive hỗ trợ xóa mềm, duy trì nhật ký kiểm tra trong khi loại trừ các cấu hình không hoạt động khỏi các truy vấn.
Lập phiên bản: Trường version theo dõi các thay đổi cấu hình, hỗ trợ khả năng khôi phục và lịch sử thay đổi.

Tổ chức Parameter Store:

Các tham số tuân theo cấu trúc phân cấp phản ánh mô hình đa đối tượng thuê. Ví dụ này minh họa cấu trúc đường dẫn:

			
/config-service/
├── acme-corp/
│   ├── api/
│   │   ├── api-key
│   │   └── endpoint
│   └── database/
│       └── connection-string
└── globex-inc/
    ├── api/
    │   ├── api-key
    │   └── endpoint
    └── database/
        └── connection-string

		

Cấu trúc này mang lại một số lợi ích:

Truy xuất hàng loạt bằng cách sử dụng tiền tố đường dẫn (API GetParametersByPath)
Quyền sở hữu và kiểm soát truy cập rõ ràng thông qua các chính sách AWS Identity and Access Management (AWS IAM)
Tách biệt môi trường (dev/staging/prod) ở cấp độ đường dẫn
Tự động lập phiên bản tham số và theo dõi thay đổi

Nâng cao: Ngữ cảnh đối tượng thuê đa chiều
Đối với các tổ chức có nhiều dịch vụ yêu cầu các phạm vi cấu hình khác nhau, hãy cân nhắc giới thiệu một chiều thứ hai trong khóa phân vùng:

			
PK = "TENANT#acme-corp|SERVICE#order-service"
SK = "CONFIG#payment-gateway"

Cách tiếp cận đa chiều này cho phép cô lập cấp độ dịch vụ, trong đó Order service chỉ thấy các cấu hình API thanh toán trong khi Reporting service không có quyền truy cập vào cài đặt cổng thanh toán. Nó cũng cung cấp các truy vấn hiệu quả theo phạm vi dịch vụ, truy xuất cấu hình cho một dịch vụ cụ thể với PK = TENANT#acme-corp|SERVICE#order-service và SK bắt đầu bằng CONFIG#. Chiều thứ hai có thể đại diện cho các đơn vị kinh doanh, khu vực địa lý hoặc một ranh giới logic phù hợp với các yêu cầu kiểm soát truy cập, làm cho mẫu này đặc biệt có giá trị khi cần kiểm soát truy cập chi tiết hơn ngoài sự cô lập cấp độ đối tượng thuê. Để biết hướng dẫn chi tiết về các mẫu mô hình DynamoDB đa đối tượng thuê, hãy xem amazon-dynamodb-data-modeling-for-multi-tenancy-part-2.

B. Mẫu chiến lược cho tính linh hoạt lưu trữ

Hệ thống quyết định backend lưu trữ nào sẽ sử dụng cho mỗi yêu cầu cấu hình. Mẫu Strategy là một phương pháp thiết kế cho phép một chương trình chọn các hành vi khác nhau trong thời gian chạy dựa trên ngữ cảnh. Hãy nghĩ về nó như một bộ điều khiển giao thông kiểm tra từng yêu cầu và hướng nó đến dịch vụ thích hợp.

Tại sao nên sử dụng mẫu chiến lược?

Nếu không có mẫu Strategy, việc xử lý nhiều backend lưu trữ sẽ yêu cầu logic điều kiện phức tạp trong toàn bộ cơ sở mã. Siêu dữ liệu đối tượng thuê khác nhau có các mẫu truy cập rất khác nhau. Định tuyến đến các backend được tối ưu hóa giúp giảm thiểu cả việc tăng chi phí DynamoDB (đối với các cấu hình ít thay đổi) và việc điều tiết Parameter Store (đối với các thao tác đọc tần suất cao), giải quyết khoảng cách về khả năng mở rộng. Một triển khai đơn giản có thể trông như thế này và đáng để dừng lại để hiểu tại sao cách tiếp cận này lại thất bại.

			
// Without Strategy Pattern - complex and hard to maintain
async getConfig(key: string, tenantId: string) {
  if (key.startsWith('tenant_config_')) {
    // DynamoDB logic here
    const pk = `TENANT#${tenantId}`;
    const sk = `CONFIG#${key.slice(14)}`;
    return await this.dynamoDB.query({...});
  } else if (key.startsWith('param_config_')) {
    // Parameter Store logic here
    const path = `/config-service/${tenantId}/${key.slice(13)}`;
    return await this.ssm.getParameter({...});
  }
  // More conditions as backends are added...
}

		

Mỗi khi bạn thêm một backend lưu trữ mới, chẳng hạn như AWS Secrets Manager hoặc Amazon S3, bạn buộc phải quay lại hàm này và thêm một else if khác. Logic lưu trữ trở nên gắn chặt với lớp dịch vụ của bạn, khiến việc kiểm tra từng backend một cách độc lập trở nên khó khăn hơn và gần như không thể hoán đổi một backend mà không có nguy cơ gây ra lỗi ở nơi khác.

Chiến lược triển khai

Mẫu Strategy đóng gói logic dành riêng cho lưu trữ vào các lớp chiến lược riêng biệt, có thể hoán đổi cho nhau. Mã này minh họa cách factory kiểm tra các khóa và chọn các chiến lược:

			
@Injectable()
export class ConfigStrategyFactory {
  private keyStrategyMap = new Map<string, ConfigStrategy>([
    ['tenant_config_', this.dynamoDBConfigStrategy],
    ['param_config_', this.ssmConfigStrategy],
  ]);
  getStrategy(key: string): ConfigStrategy {
    for (const [prefix, strategy] of this.keyStrategyMap.entries()) {
      if (key.startsWith(prefix)) {
        return strategy;
      }
    }
    throw new ValidationException(`Invalid key format: ${key}`);
  }
}

		

Ánh xạ tiền tố khóa:

tenant_config_* → Định tuyến đến Amazon DynamoDB cho các mẫu truy cập tần suất cao, dành riêng cho đối tượng thuê
param_config_* → Định tuyến đến AWS Systems Manager Parameter Store cho các tham số phân cấp, được chia sẻ

Với cách tiếp cận này, việc thêm một backend lưu trữ mới chỉ yêu cầu:

Tạo một lớp chiến lược mới triển khai giao diện ConfigStrategy
Thêm một dòng vào keyStrategyMap với tiền tố và chiến lược mới
Không thay đổi các chiến lược hiện có hoặc mã gọi

Thiết kế này giúp bảo vệ các khoản đầu tư công nghệ. Khi các yêu cầu phát triển và các dịch vụ AWS mới trở nên phù hợp, hệ thống sẽ thích ứng mà không cần viết lại lớn.

Chiến lược caching đa lớp

Các cấu hình khác nhau hưởng lợi từ các cách tiếp cận caching khác nhau. Mẫu này triển khai các chiến lược caching khác nhau được tối ưu hóa cho các mẫu truy cập và yêu cầu kinh doanh của từng loại cấu hình:

Cấu hình đối tượng thuê tần suất cao (được truy cập hàng nghìn lần mỗi phút) sử dụng caching cấp ứng dụng với các giá trị Time-To-Live (TTL) ngắn. Điều này giảm đáng kể các truy vấn cơ sở dữ liệu trong khi vẫn duy trì dữ liệu tương đối mới.
Các tham số được chia sẻ (được truy cập thường xuyên nhưng hiếm khi thay đổi) sử dụng caching trong bộ nhớ với vô hiệu hóa theo sự kiện. Cache chỉ làm mới khi EventBridge phát hiện một thay đổi thực tế, giảm thiểu các lệnh gọi API không cần thiết.

Các cân nhắc về bảo mật cache

Việc triển khai sử dụng một Map trong bộ nhớ được chia sẻ với các khóa có tiền tố đối tượng thuê (tenantId:serviceName:configKey). Các giá trị được cache là siêu dữ liệu cấu hình (API endpoint, cờ tính năng, ngưỡng), không phải dữ liệu nhạy cảm như thông tin xác thực hoặc PII. Các giá trị nhạy cảm vẫn nằm trong Parameter Store với mã hóa SecureString và được truy xuất theo yêu cầu, không được cache. Ngay cả trong các trường hợp đặc biệt, các kiểm soát truy cập hạ nguồn (xác thực JWT, khóa tổng hợp DynamoDB) đóng vai trò là ranh giới thực thi cuối cùng.

Đối với các nhóm xử lý các tải trọng cấu hình nhạy cảm hơn, hãy cân nhắc Amazon ElastiCache (Redis OSS) hoặc Valkey với cô lập tiền tố khóa và mã hóa khi lưu trữ/truyền tải, mặc dù điều này làm tăng độ trễ mạng 1-3ms so với truy cập trong bộ nhớ dưới mili giây.

C. Xác thực và cô lập đối tượng thuê

Sự cô lập đối tượng thuê được thực thi ở nhiều lớp, bắt đầu bằng xác thực dựa trên JWT và các guard ủy quyền tùy chỉnh.

Luồng xác thực JWT của Cognito:

Client xác thực với Cognito và nhận token JWT
Yêu cầu bao gồm JWT trong tiêu đề Authorization: Bearer {token}
CognitoJwtGuard xác thực chữ ký token với endpoint JSON Web Key Sets (JWKS) của Cognito
Guard trích xuất claim custom:tenantId và đính kèm vào ngữ cảnh yêu cầu
TenantAccessGuard xác minh người dùng có quyền truy cập vào đối tượng thuê được yêu cầu
Lớp dịch vụ sử dụng tenantId đã được xác thực cho các hoạt động dữ liệu

Việc triển khai này minh họa cách tiếp cận an toàn để trích xuất ngữ cảnh đối tượng thuê:

			
async retrieveConfig(req: RetrieveConfigRequest): Promise<RetrieveConfigResponse> {
  // tenantId is extracted from validated JWT token, never from request parameters
  const tenantId = (req as any).tenantId;
  if (!tenantId) {
    throw new UnauthorizedException('Tenant ID not found in authentication context');
  }
  const strategy = this.strategyFactory.getStrategy(req.key);
  const data = await strategy.getConfig(req.serviceName, req.key, tenantId);
  return { data };
}

		

Tại sao phương pháp này giúp ngăn chặn truy cập trái phép:

Hãy xem xét điều gì xảy ra nếu một người dùng trái phép cố gắng truy cập cấu hình của đối tượng thuê khác:

Người dùng xác thực là Đối tượng thuê A và nhận JWT với custom:tenantId: "tenant-a"
Người dùng cố gắng thao túng yêu cầu để truy cập dữ liệu của Đối tượng thuê B
Dịch vụ trích xuất tenantId từ JWT (vẫn là “tenant-a”), bỏ qua các tham số yêu cầu
Truy vấn sử dụng ID đối tượng thuê của JWT, vì vậy người dùng chỉ thấy dữ liệu của Đối tượng thuê A

Nâng cao: Cô lập thông tin xác thực cấp độ hạ tầng

Thiết kế hiện tại thực thi sự cô lập đối tượng thuê ở lớp ứng dụng thông qua trích xuất JWT và khóa tổng hợp DynamoDB. Tác vụ ECS sử dụng một vai trò thực thi IAM được chia sẻ, nghĩa là các yêu cầu của đối tượng thuê hoạt động dưới cùng một thông tin xác thực AWS. Mặc dù cách tiếp cận này đủ cho hầu hết các ứng dụng đa đối tượng thuê, các nhóm có yêu cầu tuân thủ nghiêm ngặt hơn (HIPAA, PCI-DSS, FedRAMP) có thể cần cô lập cấp độ hạ tầng.

Để tăng cường cô lập, hãy cân nhắc triển khai mẫu Token Vending Machine (TVM) với AWS Security Token Service (STS) để cấp thông tin xác thực IAM tạm thời, theo phạm vi đối tượng thuê. Điều này cung cấp sự cô lập cấp độ hạ tầng với nhật ký kiểm tra AWS CloudTrail cho mỗi đối tượng thuê và nguyên tắc thực thi quyền tối thiểu. Tuy nhiên, TVM làm tăng độ phức tạp vận hành (caching thông tin xác thực, chi phí API STS, logic làm mới token) và độ trễ (50-100ms cho mỗi hoạt động).

Hãy xem xét đây là bước tiếp theo khi các kiểm toán viên tuân thủ yêu cầu tách biệt cấp độ hạ tầng thay vì một yêu cầu cơ bản.

Thiết kế này giúp ngăn chặn các nỗ lực truy cập chéo đối tượng thuê ở cấp độ hạ tầng, giải quyết một vấn đề bảo mật phổ biến.

D. Cơ chế tự động làm mới không gián đoạn

Các bản cập nhật cấu hình trong các hệ thống sản xuất đặt ra một thách thức vận hành kinh điển. Cách tiếp cận hướng sự kiện này giải quyết hoàn toàn sự đánh đổi TTL của cache, các cấu hình cập nhật theo thời gian thực mà không cần thăm dò hoặc cửa sổ dữ liệu cũ.

Luồng tích hợp EventBridge:

			
1. Parameter Store Change
         ↓
2. EventBridge Rule (matches /config-service/* changes)
         ↓
3. Lambda Function (extracts tenantId from path)
         ↓
4. Service Discovery (AWS Cloud Map queries for healthy instances)
         ↓
5. gRPC Refresh Call (direct service-to-service invocation)
         ↓
6. In-Memory Cache Update (zero-downtime)
         ↓
7. Updated Configuration Active (no connection drops)

		

Lợi ích chính:

Không gián đoạn: Không yêu cầu khởi động lại dịch vụ. Các kết nối vẫn hoạt động
Cập nhật phản ứng: Chỉ kích hoạt khi có thay đổi xảy ra (không thăm dò lãng phí)
Hiệu quả chi phí: Giảm thiểu các lệnh gọi API SSM thông qua caching và làm mới theo sự kiện
Nhật ký kiểm tra: EventBridge cung cấp lịch sử thay đổi và giám sát hoàn chỉnh

Khi nào nên sử dụng mẫu này?

Mẫu lưu trữ được gắn thẻ không áp dụng phổ biến. Giống như hầu hết các cách tiếp cận kiến trúc, nó có các trường hợp sử dụng lý tưởng mà lợi ích vượt trội đáng kể so với độ phức tạp triển khai. Hãy cân nhắc mẫu này khi ứng dụng của bạn phù hợp với các đặc điểm sau:

SaaS đa đối tượng thuê yêu cầu cô lập đối tượng thuê nghiêm ngặt và tuân thủ quy định sẽ hưởng lợi đáng kể. Sự cô lập cấp độ hạ tầng của mẫu thông qua các claim JWT và thiết kế mô hình dữ liệu cung cấp các cam kết bảo mật mà sự cô lập cấp độ ứng dụng không thể sánh bằng.
Kiến trúc microservices với các yêu cầu cấu hình phức tạp trên hàng chục dịch vụ tìm thấy giá trị trong quản lý tập trung và định tuyến lưu trữ linh hoạt.
Các tổ chức quản lý cấu hình trên nhiều backend lưu trữ và môi trường (dev, staging, production, DR) đánh giá cao tổ chức phân cấp và kiểm soát truy cập dựa trên đường dẫn mà Parameter Store cung cấp, kết hợp với hiệu suất của DynamoDB cho truy cập tần suất cao.
Các ứng dụng thông lượng cao (1000+ yêu cầu/giây) cần thời gian phản hồi dưới mili giây sử dụng DynamoDB Accelerator (DAX) để caching trong bộ nhớ. Mặc dù DynamoDB cung cấp độ trễ một chữ số mili giây tuyệt vời, DAX mang lại độ trễ đọc micro giây, thường nhanh hơn 5-10 lần đối với dữ liệu được cache. Điều này tạo ra sự khác biệt đáng kể ở quy mô lớn.
Các nhóm ưu tiên sự đơn giản trong vận hành đánh giá cao cơ chế làm mới theo sự kiện giúp tránh phối hợp triển khai thủ công.

Bắt đầu

Bạn đã sẵn sàng triển khai Mẫu Lưu trữ Được gắn thẻ trong tổ chức của mình chưa?

Bắt đầu với một dự án thí điểm tập trung vào một microservice duy nhất và dần dần mở rộng mẫu trên toàn kiến trúc của bạn. Thiết kế mô-đun có nghĩa là bạn có thể nhận ra lợi ích một cách tăng dần trong khi xây dựng niềm tin vào cách tiếp cận.

Các bước triển khai:

Thiết kế mô hình dữ liệu của bạn: Xác định lược đồ DynamoDB và hệ thống phân cấp Parameter Store
Thiết lập Amazon Cognito: Cấu hình user pool với các thuộc tính đối tượng thuê tùy chỉnh
Xây dựng lớp dịch vụ: Triển khai mẫu Strategy để định tuyến lưu trữ
Thêm làm mới theo sự kiện: Cấu hình các quy tắc EventBridge và hàm Lambda
Kiểm tra cô lập đối tượng thuê: Xác minh xác thực JWT và ngăn chặn truy cập chéo đối tượng thuê
Triển khai và giám sát: Thiết lập các bảng điều khiển CloudWatch và quy trình vận hành

Bạn có thể tìm thấy mã hoàn chỉnh cho giải pháp này, bao gồm các mẫu AWS CloudFormation, tập lệnh triển khai và kiểm thử, trong GitHub – Configuration Management Service.

Để tránh phát sinh chi phí liên tục, hãy xóa các tài nguyên bạn đã tạo trong quá trình hướng dẫn này. Để biết hướng dẫn dọn dẹp chi tiết bao gồm các lệnh từng bước và các bước xác minh, hãy xem Infrastructure Cleanup Guide.

Kết luận

Xây dựng một dịch vụ cấu hình đa đối tượng thuê đòi hỏi phải xem xét cẩn thận các mẫu lưu trữ, ranh giới bảo mật và yêu cầu vận hành. Mẫu lưu trữ được gắn thẻ được trình bày trong bài đăng này cung cấp một nền tảng linh hoạt, có khả năng mở rộng để giải quyết những thách thức này thông qua:

Định tuyến lưu trữ thông minh: Mẫu Strategy cung cấp lựa chọn backend tối ưu cho mỗi loại cấu hình, cho phép DynamoDB cho các cài đặt dành riêng cho đối tượng thuê và SSM Parameter Store cho các tham số được chia sẻ.
Cập nhật không gián đoạn: Kiến trúc hướng sự kiện thông qua EventBridge và Lambda tránh khởi động lại dịch vụ và chi phí thăm dò để các cấu hình làm mới ngay lập tức khi có thay đổi.
Cô lập đối tượng thuê mạnh mẽ: Xác thực dựa trên JWT với các claim tùy chỉnh đảm bảo các ranh giới đối tượng thuê được thực thi ở cấp độ hạ tầng, không phải logic ứng dụng, giúp ngăn chặn các nỗ lực truy cập chéo đối tượng thuê.
Đơn giản trong vận hành: Caching trong bộ nhớ, kết hợp với làm mới theo sự kiện, có thể giảm chi phí API trong khi vẫn duy trì thời gian phản hồi micro giây.
Hiệu quả chi phí: Thanh toán theo yêu cầu, caching mạnh mẽ và các phiên bản Spot giúp giữ chi phí vận hành ở mức tối thiểu ngay cả ở quy mô lớn.

Tài nguyên bổ sung

Về tác giả

Koshal Agrawal

Koshal Agrawal làm việc tại Professional Services GCC, giúp các tổ chức xây dựng và cung cấp các giải pháp cloud-native trên AWS. Anh đam mê kiến trúc đám mây và các công cụ dành cho nhà phát triển — và thích biến các vấn đề kỹ thuật phức tạp thành các giải pháp sạch, sẵn sàng cho sản xuất.

Ishita Gupta

Ishita Gupta làm việc tại Professional Services GCC, nơi cô đã giúp các doanh nghiệp xây dựng và cung cấp các ứng dụng cloud-native. Với chuyên môn trải rộng cả phát triển frontend và backend, cô đam mê xây dựng các giải pháp sáng tạo và đưa các ứng dụng vào cuộc sống thông qua mã.

Vijit Vashishtha

Vijit Vashishtha làm việc tại Professional Services GCC, lãnh đạo và thực hiện các sáng kiến kiến trúc và kỹ thuật backend cho các nền tảng doanh nghiệp chạy khối lượng công việc sản xuất. Anh tập trung vào việc xây dựng các hệ thống đáng tin cậy, chịu lỗi, có khả năng mở rộng hiệu quả trong khi vẫn duy trì sự xuất sắc trong vận hành và kỷ luật chi phí.