T2 — Microservices và Serverless Computing - congsinhv/fluxion GitHub Wiki
Microservices và Serverless Computing trong Hệ Thống MDM
Issue: #11 — Nghiên cứu Microservices và Serverless Computing Tuần: 2 | 31/03 – 06/04/2026 Numbering chính thức: Mục 2.3 theo Master TOC (Chương 2)
2.3.1 Kiến Trúc Microservices
2.3.1.1 Định Nghĩa và Nguồn Gốc
Thuật ngữ Microservices Architecture được hệ thống hoá lần đầu bởi Martin Fowler và James Lewis trong bài viết nền tảng năm 2014 [1]. Theo hai tác giả, kiến trúc microservices mô tả cách thiết kế ứng dụng phần mềm dưới dạng một tập hợp các dịch vụ nhỏ, độc lập, có khả năng triển khai riêng lẻ (independently deployable services), mỗi dịch vụ chạy trong tiến trình riêng và giao tiếp qua cơ chế nhẹ — thường là HTTP/REST hoặc message queue [1].
Fowler và Lewis nhấn mạnh rằng không có định nghĩa chính xác, tuyệt đối, mà thay vào đó tồn tại một tập hợp các đặc điểm chung (common characteristics) mà hầu hết các triển khai microservices đều chia sẻ. Điều này phân biệt microservices với các kiến trúc service-oriented trước đó vốn phụ thuộc nặng vào Enterprise Service Bus (ESB) — một thành phần trung gian mang nhiều logic nghiệp vụ phức tạp [1].
Sam Newman, trong cuốn sách chuyên khảo Building Microservices (lần đầu 2015, tái bản 2021) [2], cung cấp định nghĩa thực hành hơn: microservices là các dịch vụ được mô hình hoá xung quanh domain nghiệp vụ (modeled around a business domain), có khả năng triển khai độc lập, và giao tiếp với nhau thông qua mạng. Newman đặc biệt nhấn mạnh vai trò của information hiding — che giấu chi tiết triển khai nội bộ để tránh sự phụ thuộc chặt chẽ (tight coupling) giữa các dịch vụ [2].
2.3.1.2 Các Đặc Điểm Cốt Lõi
Fowler và Lewis [1] xác định các đặc điểm phân biệt của microservices architecture:
1. Componentization via Services (Thành phần hoá qua dịch vụ) Thay vì xây dựng thành phần dưới dạng thư viện (libraries) được liên kết vào cùng một tiến trình, microservices tách biệt chức năng thành các dịch vụ độc lập có thể triển khai và thay thế riêng lẻ [1].
2. Organization around Business Capabilities (Tổ chức theo năng lực nghiệp vụ) Các nhóm phát triển được tổ chức quanh khả năng nghiệp vụ (business capability), không phải theo lớp công nghệ. Mỗi nhóm sở hữu toàn bộ ngăn xếp kỹ thuật của dịch vụ mình — nguyên tắc "you build it, you run it" [1].
3. Smart Endpoints and Dumb Pipes (Điểm đầu cuối thông minh, kênh truyền đơn giản) Logic nghiệp vụ nằm ở các dịch vụ (endpoints), không nằm ở tầng trung gian (middleware/ESB). Kênh truyền (message broker) chỉ vận chuyển thông điệp mà không xử lý logic nghiệp vụ [1].
4. Decentralized Governance (Quản trị phi tập trung) Mỗi dịch vụ tự do lựa chọn công nghệ phù hợp nhất với bài toán của mình (polyglot persistence, polyglot programming) [1].
5. Decentralized Data Management (Quản lý dữ liệu phi tập trung) Mỗi dịch vụ quản lý cơ sở dữ liệu riêng, tránh chia sẻ schema. Trong thực tế, nguyên tắc này thường được đánh đổi (trade-off) với sự đơn giản vận hành — đặc biệt ở quy mô nhỏ (MVP), một cơ sở dữ liệu dùng chung có thể được chấp nhận [2].
6. Design for Failure (Thiết kế cho thất bại) Các dịch vụ phải được thiết kế với giả định rằng bất kỳ dịch vụ phụ thuộc nào cũng có thể thất bại — circuit breaker, retry, và graceful degradation. Dead Letter Queue (DLQ) là cơ chế phổ biến để cách ly message thất bại sau nhiều lần thử lại, ngăn lỗi lan truyền lên toàn bộ pipeline [2].
7. Independently Deployable (Triển khai độc lập) Newman [2] coi đây là định nghĩa tối thiểu của microservices: nếu một dịch vụ không thể được triển khai độc lập mà không yêu cầu phối hợp với dịch vụ khác, thì đó không thực sự là microservice.
2.3.1.3 Nguyên Tắc Thiết Kế của Sam Newman
Newman [2] tổng hợp bảy nguyên tắc thực hành cho microservices:
| # | Nguyên tắc | Mô tả |
|---|---|---|
| 1 | Model Around Business Concepts | Ranh giới dịch vụ theo Bounded Context của DDD |
| 2 | Adopt a Culture of Automation | CI/CD, IaC, automated testing là bắt buộc |
| 3 | Hide Internal Implementation Details | API là hợp đồng; nội bộ là chi tiết ẩn |
| 4 | Decentralize All the Things | Quyết định và dữ liệu ở cấp dịch vụ |
| 5 | Deploy Independently | Mỗi dịch vụ có pipeline triển khai riêng |
| 6 | Isolate Failure | Lỗi ở một dịch vụ không cascade sang dịch vụ khác |
| 7 | Highly Observable | Logging, metrics, tracing phân tán là điều kiện bắt buộc |
2.3.2 So Sánh Monolith, Microservices, và Serverless
2.3.2.1 Kiến Trúc Monolith
Kiến trúc đơn khối (monolithic architecture) là mô hình truyền thống trong đó toàn bộ ứng dụng — UI, business logic, data access — được đóng gói và triển khai như một đơn vị duy nhất [3]. Ưu điểm chính của monolith là sự đơn giản trong phát triển ban đầu: không có độ trễ mạng giữa các thành phần, gỡ lỗi dễ hơn, và triển khai ban đầu đơn giản hơn.
Tuy nhiên, khi ứng dụng tăng trưởng về quy mô, monolith gặp giới hạn cơ bản: mọi thay đổi nhỏ đều yêu cầu triển khai lại toàn bộ; mở rộng quy mô chỉ có thể theo chiều ngang đồng đều; coupling chặt giữa các module làm tăng rủi ro thay đổi [1][3].
2.3.2.2 Kiến Trúc Serverless
Serverless computing là mô hình điện toán đám mây trong đó nhà cung cấp đám mây quản lý hoàn toàn hạ tầng — server, scaling, provisioning — và nhà phát triển chỉ viết và triển khai code. Mô hình tính phí theo lần thực thi (pay-per-execution) thay vì theo tài nguyên được cấp phát [4].
Serverless bao gồm hai nhánh chính:
- FaaS (Function-as-a-Service): Thực thi code theo sự kiện, không trạng thái, thời gian sống ngắn. AWS Lambda là triển khai phổ biến nhất.
- BaaS (Backend-as-a-Service): Các dịch vụ backend được quản lý sẵn như AWS Cognito (xác thực), AWS AppSync (GraphQL API), Amazon S3 (lưu trữ). Nhà phát triển tích hợp trực tiếp thay vì tự xây dựng.
2.3.2.3 Ma Trận So Sánh
| Chiều đánh giá | Monolith | Microservices | Serverless (FaaS) |
|---|---|---|---|
| Độ phức tạp ban đầu | Thấp | Cao | Trung bình |
| Triển khai độc lập | Không | Có | Có (theo function) |
| Mở rộng chọn lọc | Không | Có (theo service) | Có (tự động) |
| Quản lý hạ tầng | Cao | Cao | Rất thấp |
| Chi phí tải nhẹ | Cao (server luôn chạy) | Cao (container luôn chạy) | Rất thấp (pay-per-use) |
| Chi phí tải cao liên tục | Thấp/cố định | Trung bình | Có thể cao hơn EC2 |
| Độ trễ khởi động | Không đáng kể | Phụ thuộc container | Cold start: 100ms–3s+ |
| Thời gian thực thi tối đa | Không giới hạn | Không giới hạn | 15 phút (AWS Lambda) |
| Trạng thái (Stateful) | Dễ | Cần thiết kế | Không (stateless) |
| Vendor lock-in | Thấp | Trung bình | Cao |
| Phù hợp cho MDM commands | Không | Có | Có (event-driven) |
| Phù hợp cho Gateway dài hạn | Có | Có | Không (giới hạn 15 phút) |
Bảng 2.3.1: So sánh Monolith, Microservices, và Serverless
2.3.2.4 Kết Luận So Sánh Trong Bối Cảnh Fluxion
Hệ thống Fluxion áp dụng mô hình lai (hybrid): Serverless/FaaS (AWS Lambda) cho các tác vụ xử lý lệnh MDM ngắn hạn, event-driven; và Container (ECS Fargate) cho các dịch vụ Gateway cần duy trì kết nối lâu dài với APNS và DEP. Quyết định kiến trúc này được hỗ trợ bởi phân loại use case của Eismann et al. [7] và AWS Well-Architected Serverless Lens [13].
2.3.3 Serverless Computing: FaaS và BaaS
2.3.3.1 Function-as-a-Service (FaaS)
FaaS là tầng thực thi hàm theo sự kiện, không trạng thái, không cần quản lý server. Mỗi hàm (function) là một đơn vị triển khai độc lập, được kích hoạt bởi trigger (HTTP request, message queue event, schedule, v.v.) và kết thúc sau khi hoàn thành nhiệm vụ [4].
Đặc điểm kỹ thuật cốt lõi của FaaS:
- Stateless by design: Hàm không lưu trữ trạng thái giữa các lần gọi; trạng thái phải được externalize ra database hoặc cache
- Event-driven: Mỗi invocation là phản hồi với một sự kiện cụ thể
- Auto-scaling: Nhà cung cấp tự động mở rộng số lượng instance song song
- Pay-per-invocation: Chi phí tính theo số lần gọi và thời gian thực thi (GB-giây trên AWS Lambda)
Áp dụng trong Fluxion: Tất cả Lambda resolvers hoạt động theo mô hình FaaS — mỗi GraphQL request đến AppSync kích hoạt một Lambda invocation riêng, xử lý nghiệp vụ, và kết thúc.
2.3.3.2 Backend-as-a-Service (BaaS)
BaaS là lớp dịch vụ backend được quản lý hoàn toàn bởi nhà cung cấp đám mây, cung cấp sẵn các chức năng phổ biến mà không phải tự xây dựng [4]. Fluxion sử dụng các BaaS sau:
| BaaS Service | Vai trò trong Fluxion |
|---|---|
| AWS Cognito | Xác thực người dùng, phát hành JWT token |
| AWS AppSync | GraphQL API Gateway, xử lý subscription real-time |
| Amazon SNS | Pub/Sub fan-out từ action-trigger Lambda đến nhiều SQS queue |
| Amazon SQS | Queue bền vững với DLQ tích hợp sẵn |
| Amazon RDS PostgreSQL | Managed database — backup, patching, failover tự động |
Tỷ lệ BaaS/FaaS cao trong Fluxion phù hợp với bối cảnh dự án nghiên cứu cần đạt chức năng MDM đầy đủ với nguồn lực phát triển hạn chế.
2.3.4 Cloud-Native Applications: Định Nghĩa và Đặc Điểm
2.3.4.1 Định Nghĩa CNCF
Cloud Native Computing Foundation (CNCF) công bố định nghĩa chuẩn trong Cloud Native Definition v1.0 năm 2018 [5]:
"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable."
2.3.4.2 Nghiên Cứu Học Thuật: Kratzke và Quint (2017)
Kratzke và Quint [12] thực hiện nghiên cứu ánh xạ hệ thống (systematic mapping study) phân tích tài liệu học thuật về cloud-native applications, công bố trên Journal of Systems and Software (2017). Nghiên cứu xác định các đặc điểm cốt lõi:
1. Microservice Architecture: Ứng dụng phân rã thành tập hợp dịch vụ nhỏ, chạy trong tiến trình riêng, giao tiếp qua API nhẹ.
2. Containerization: Đóng gói ứng dụng và phụ thuộc vào container bất biến (immutable container) đảm bảo tính nhất quán từ phát triển đến production.
3. Dynamic Orchestration: Nền tảng tự động hoá quản lý container — phân phối tải, khởi động lại khi lỗi, mở rộng khi cần.
4. Resilience and Self-healing: Ứng dụng phục hồi tự động từ lỗi, không phụ thuộc sự can thiệp thủ công.
5. Observability: Logging, metrics, và distributed tracing là yêu cầu tối thiểu.
6. DevOps Culture: CI/CD, Infrastructure as Code, và văn hóa tự động hoá là điều kiện cần thiết.
2.3.4.3 Fluxion Trong Khung Cloud-Native
| Đặc điểm Cloud-Native | Biểu hiện trong Fluxion |
|---|---|
| Microservices | Lambda resolvers domain-specific, ECS Gateway services |
| Managed Containers | ECS Fargate cho Gateway (không cần quản lý OS/runtime) |
| Dynamic Orchestration | AWS tự động scale Lambda và Fargate tasks |
| Resilience | SQS DLQ, SNS retry, RDS Multi-AZ failover |
| Declarative APIs | GraphQL schema-first với AppSync |
| Observability | AWS CloudWatch Logs, X-Ray distributed tracing |
Điểm khác biệt: Fluxion không sử dụng service mesh (như Istio) vì độ phức tạp vận hành không phù hợp với quy mô dự án — áp dụng nguyên tắc KISS.
2.3.5 AWS Lambda: Mô Hình Thực Thi và Đặc Điểm Kỹ Thuật
2.3.5.1 Vòng Đời Execution Environment
AWS Lambda thực thi code theo mô hình ba giai đoạn [9]:
Giai đoạn 1 — Init Phase: AWS download function code, khởi tạo runtime environment, và thực thi initialization code bên ngoài handler (kết nối database, load config). Giai đoạn này tạo ra cold start latency — chỉ xảy ra khi tạo execution environment mới [6].
Giai đoạn 2 — Invoke Phase: Khi execution environment đã sẵn sàng, AWS gọi handler function với event payload. Đây là warm invocation — không có chi phí khởi tạo.
Giai đoạn 3 — Shutdown Phase: Sau khoảng thời gian không có request, AWS thu hồi execution environment. Request tiếp theo tạo cold start mới.
2.3.5.2 Cold Start: Nguyên Nhân và Tác Động
Lloyd et al. [6] điều tra toàn diện các yếu tố ảnh hưởng đến hiệu năng Lambda, công bố tại IEEE IC2E 2018. Cold start xảy ra khi nhà cung cấp đám mây cần tạo mới execution environment do không có environment sẵn có.
Các yếu tố ảnh hưởng chính [6]:
| Yếu tố | Tác động |
|---|---|
| Memory allocation | Bộ nhớ lớn hơn → CPU cao hơn → cold start ngắn hơn |
| Runtime language | Java/NET > Node.js/Python (JVM initialization) |
| Code package size | Package lớn → download lâu hơn |
| VPC configuration | Lambda trong VPC thêm 300–800ms |
Số liệu thực tế (2024–2025):
- Node.js/Python không VPC: 100–300ms
- Node.js/Python trong VPC: 300–800ms
- Java 11 (JVM): 1–4 giây
- Java với SnapStart: 200–600ms
Cold start ảnh hưởng dưới 1% invocations trong hầu hết workload production [6].
2.3.5.3 Concurrency Model
Lambda sử dụng mô hình concurrency theo chiều ngang: mỗi request đồng thời tạo một execution environment riêng biệt [10]:
- Unreserved concurrency: Chia sẻ từ pool 1,000 concurrent executions mặc định của account/region
- Reserved concurrency: Giới hạn tối đa đồng thời cho một function cụ thể
- Provisioned concurrency: Pre-warm environments — loại bỏ cold start nhưng phát sinh chi phí liên tục
Khi số lượng thiết bị MDM tăng lên, action-resolver Lambda scale tự động — lợi thế so với kiến trúc server truyền thống phải dự phòng tài nguyên cho tải đỉnh.
2.3.5.4 Giới Hạn Kỹ Thuật Lambda
| Thông số | Giới hạn |
|---|---|
| Thời gian thực thi tối đa | 900 giây (15 phút) |
| Bộ nhớ | 128 MB – 10,240 MB |
| Payload (synchronous) | 6 MB request / 6 MB response |
| Payload (asynchronous) | 256 KB |
| Concurrent executions (default) | 1,000/region/account |
Bảng 2.3.2: Giới hạn kỹ thuật của AWS Lambda [13]
Giới hạn 15 phút là yếu tố quyết định kiến trúc: các dịch vụ Gateway cần duy trì kết nối APNS liên tục không thể thực hiện bằng Lambda — lý do trực tiếp chọn ECS Fargate cho Gateway services.
2.3.6 Phân Tích Ưu/Nhược Điểm Serverless Cho MDM Command Processing
2.3.6.1 Đặc Điểm Workload
Workload xử lý lệnh MDM trong Fluxion:
- Event-driven: Lệnh kích hoạt khi admin gửi action qua dashboard
- Bursty: Tải đột biến khi admin cấu hình hàng loạt thiết bị
- Thời gian xử lý ngắn: Mỗi lệnh xử lý trong vài trăm ms đến vài giây
- Bất đồng bộ: Fire-and-forget qua SQS (không cần trả về kết quả ngay)
- Độc lập theo thiết bị: Lệnh cho thiết bị A không phụ thuộc thiết bị B
Đây là profile workload lý tưởng cho serverless/FaaS theo phân loại của Eismann et al. [7].
2.3.6.2 Nghiên Cứu Eismann et al. (2022)
Eismann et al. [7] đánh giá 89 use case serverless trên IEEE Transactions on Software Engineering (2022), phân loại theo 24 đặc điểm. Các use case phù hợp nhất với serverless:
- Event-driven data processing: Xử lý message — match với
ios-process-actionLambda - Web APIs và backends: HTTP-triggered functions — match với Lambda resolvers
- Scheduled tasks: Cron-based processing — match với maintenance jobs
Use case ít phù hợp với serverless: long-running stateful workflows (>15 phút), applications yêu cầu consistent low-latency, và workloads high-throughput liên tục.
2.3.6.3 Ưu Điểm
1. Auto-scaling tức thì Khi admin gửi lệnh MDM đồng thời cho 1,000 thiết bị, Lambda tự động tạo 1,000 execution environment song song. Kiến trúc truyền thống cần pre-provision server cho tải đỉnh, gây lãng phí khi tải thấp [6][13].
2. Chi phí phù hợp với tải thực tế MDM command processing là workload bursty — admin không gửi lệnh liên tục 24/7. Pay-per-invocation chỉ phát sinh chi phí khi có lệnh thực sự được xử lý. AWS Lambda cung cấp 1 triệu invocations miễn phí mỗi tháng [13].
3. Không cần quản lý hạ tầng Không cần lo OS patching, security updates, instance management, hay capacity planning. AWS Well-Architected Serverless Lens [13] nhấn mạnh nguyên tắc "Share Nothing" và "Assume No Hardware Affinity".
4. Tích hợp sự kiện native
Lambda tích hợp native với SQS, SNS, AppSync, EventBridge. Luồng Fluxion — action-resolver → SQS → action-trigger → SNS → SQS → ios-process-action — sử dụng hoàn toàn tích hợp native, không cần orchestration thủ công [13].
5. Cô lập lỗi theo function
Lỗi trong ios-process-action Lambda không ảnh hưởng đến action-resolver hay các Lambda resolver khác.
2.3.6.4 Nhược Điểm
1. Cold Start Latency
action-resolver Lambda được gọi đồng bộ từ AppSync — cold start tăng thời gian phản hồi GraphQL mutation. Giải pháp trong Fluxion: action-resolver chỉ validate và publish vào SQS rồi trả về ngay — toàn bộ xử lý nặng diễn ra bất đồng bộ, che giấu latency khỏi người dùng [6].
2. Giới Hạn 15 Phút MDM Gateway services — APNS connection server, DEP enrollment — yêu cầu kết nối liên tục và session state. Lambda không phù hợp → ECS Fargate được chọn.
3. Quản Lý Kết Nối Database Lambda stateless — mỗi invocation đồng thời mở kết nối PostgreSQL mới. Số lượng concurrent invocations cao vượt quá connection limit của RDS. AWS RDS Proxy giải quyết vấn đề này bằng cách pool kết nối giữa Lambda và RDS [13].
4. Vendor Lock-in Kiến trúc Fluxion phụ thuộc sâu vào hệ sinh thái AWS. Di chuyển sang nhà cung cấp khác đòi hỏi viết lại đáng kể — đánh đổi có chủ ý giữa tốc độ phát triển và tính di động [7].
5. Observability Phức Tạp Distributed tracing qua pipeline Lambda → SQS → Lambda → SNS → SQS → Lambda đòi hỏi correlation ID xuyên suốt và AWS X-Ray để theo dõi toàn bộ luồng [13].
2.3.6.5 Tổng Hợp
Serverless/FaaS là lựa chọn phù hợp cho xử lý lệnh MDM vì workload event-driven, bursty, stateless per-command, thời gian xử lý ngắn — khớp với profile use case phù hợp nhất với serverless theo Eismann et al. [7]. Các nhược điểm được giảm thiểu qua thiết kế kiến trúc: bất đồng bộ hoá qua SQS để che giấu cold start, ECS Fargate cho workload không phù hợp Lambda.
2.3.7 Container Orchestration: ECS Fargate Cho Long-Running Services
2.3.7.1 Tại Sao MDM Cần Long-Running Container
Trong hệ thống MDM, một số thành phần cần duy trì kết nối liên tục để nhận callback từ thiết bị — ví dụ: endpoint nhận kết quả thực thi lệnh từ thiết bị iOS [1]. Các thành phần này có đặc điểm không phù hợp với Lambda:
- Incoming connections liên tục: Phải lắng nghe callback từ device bất kỳ lúc nào — không theo trigger cụ thể
- Thời gian sống dài: Cần chạy liên tục 24/7 như một HTTP server
- Không phù hợp với mô hình invocation-per-request của Lambda: Lambda là outbound call, không phải inbound listener
2.3.7.2 AWS ECS và Fargate
Amazon ECS hỗ trợ hai launch type:
- EC2 launch type: Container chạy trên EC2 instances do người dùng quản lý
- Fargate launch type: Container chạy trên hạ tầng AWS quản lý hoàn toàn — không cần provisioning EC2 [14]
Fargate là serverless containers: linh hoạt của container (chạy bất kỳ runtime, bất kỳ thời gian dài) với sự đơn giản vận hành của serverless (không quản lý server). Chi phí theo vCPU và memory theo giây [14].
2.3.7.3 So Sánh Lambda và ECS Fargate
| Tiêu chí | AWS Lambda | ECS Fargate |
|---|---|---|
| Thời gian thực thi | Tối đa 15 phút | Không giới hạn |
| Trạng thái | Stateless | Stateful được phép |
| Mô hình tính phí | Per invocation + GB-giây | Per vCPU/GB-giây khi chạy |
| Kết nối liên tục | Không khả thi | Hỗ trợ đầy đủ |
| Quản lý OS | Không cần | Không cần (Fargate) |
| Auto-scaling | Tự động, tức thì | Cần cấu hình ECS Service Auto Scaling |
| Phù hợp cho | Event-driven, ngắn hạn | Long-running, stateful |
Bảng 2.3.3: So sánh AWS Lambda và ECS Fargate [14]
2.3.7.4 ECS Service Scheduler
ECS Service Scheduler đảm bảo số lượng task mong muốn (desired count) luôn chạy. Khi một task thất bại, scheduler tự động khởi động task mới. Cho Gateway services của Fluxion:
- Health check tích hợp: Phát hiện và thay thế task không phản hồi
- Multi-AZ deployment: Task phân phối qua nhiều Availability Zone cho high availability
- Rolling deployment: Cập nhật không gián đoạn khi deploy phiên bản mới
- Service discovery: Tích hợp với AWS Cloud Map hoặc ALB
2.3.7.5 Kết Hợp FaaS và Container Trong MDM
Trong hệ thống MDM, sự kết hợp FaaS (Lambda) và Container (ECS Fargate) cho phép tận dụng ưu điểm của cả hai: Lambda cho tác vụ gửi lệnh xuống thiết bị (short-lived, event-driven) và Container cho nhận callback từ thiết bị (long-running, incoming connections liên tục) [13][14].
Áp dụng trong Fluxion: Worker Lambda publish event vào SNS → OEM Lambda gửi MDM command qua APNS → thiết bị thực thi → gửi callback về ECS Fargate service → cập nhật device status vào PostgreSQL. Chi tiết luồng tích hợp tại T5 — Thiết kế Command Pipeline (Sequence Diagram).
2.3.8 Tổng Hợp: Ánh Xạ Lý Thuyết — Thực Tiễn Fluxion
| Khái niệm lý thuyết | Nguồn | Biểu hiện trong Fluxion |
|---|---|---|
| Componentization via Services | Fowler & Lewis [1] | Lambda resolver per domain |
| Smart Endpoints, Dumb Pipes | Fowler & Lewis [1] | SNS/SQS chỉ vận chuyển; logic ở Lambda |
| Independently Deployable | Newman [2] | Mỗi Lambda có pipeline deploy riêng |
| Isolate Failure | Newman [2] | SQS DLQ, Lambda error isolation |
| FaaS Event-driven | [4][6] | Lambda trigger từ AppSync, SQS, SNS |
| BaaS | [4][7] | Cognito, AppSync, SNS, SQS, RDS |
| Cold Start Mitigation | Lloyd et al. [6] | action-resolver async pattern (SQS buffer) |
| Suitable Serverless Use Cases | Eismann et al. [7] | Command processing: event-driven, bursty, short-lived |
| Cloud-native Resilience | Kratzke & Quint [12] | RDS Multi-AZ, SQS DLQ, Lambda retry |
| Serverless Design Principles | AWS [13] | Share Nothing, Speedy-Simple-Singular |
| Long-running Container | AWS [14] | ECS Fargate cho APNS Gateway, DEP Server |
Bảng 2.3.4: Ánh xạ lý thuyết — thực tiễn kiến trúc Fluxion
Tài Liệu Tham Khảo
[1] Fowler, M., & Lewis, J. (2014). Microservices: A Definition of This New Architectural Term. martinfowler.com. https://martinfowler.com/articles/microservices.html
[2] Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems, 2nd Edition. O'Reilly Media. https://samnewman.io/books/building_microservices_2nd_edition/
[3] Richardson, C. (2018). Microservices Patterns. Manning Publications. https://microservices.io/patterns/monolithic.html
[4] AWS. (2024). What is Serverless Computing? Amazon Web Services. https://aws.amazon.com/what-is/serverless-computing/
[5] CNCF. (2018). Cloud Native Definition v1.0. Cloud Native Computing Foundation. https://github.com/cncf/toc/blob/main/DEFINITION.md
[6] Lloyd, W., Ramesh, S., Chinthalapati, S., Ly, L., & Pallickara, S. (2018). Serverless Computing: An Investigation of Factors Influencing Microservice Performance. IEEE IC2E 2018, pp. 159–169. https://ieeexplore.ieee.org/document/8360324
[7] Eismann, S., Scheuner, J., van Eyk, E., et al. (2022). A Review of Serverless Use Cases and their Characteristics. IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3638–3658. https://arxiv.org/abs/2008.11110
[8] Newman, S. (2019). Monolith to Microservices. O'Reilly Media. https://www.oreilly.com/library/view/monolith-to-microservices/9781492047834/
[9] AWS. (2024). Understanding the Lambda execution environment lifecycle. AWS Lambda Developer Guide. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
[10] AWS. (2024). Understanding Lambda function scaling and concurrency. AWS Lambda Developer Guide. https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html
[11] AWS. (2024). Configuring provisioned concurrency. AWS Lambda Developer Guide. https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html
[12] Kratzke, N., & Quint, P.-C. (2017). Understanding cloud-native applications after 10 years of cloud computing: A systematic mapping study. Journal of Systems and Software, vol. 126, pp. 1–16. https://www.sciencedirect.com/science/article/abs/pii/S0164121217300018
[13] AWS. (2023). Serverless Applications Lens — AWS Well-Architected Framework. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html
[14] AWS. (2024). AWS Fargate or AWS Lambda? Decision Guide. https://docs.aws.amazon.com/decision-guides/latest/fargate-or-lambda/fargate-or-lambda.html