Personal project · học kỹ thuật, không phải học nghiệp vụ

Một shop online nhỏ, dựng bằng 2 frontend, 2 backend stack, 2 database

Nghiệp vụ được giữ đơn giản: đăng ký, xem sản phẩm, thêm vào giỏ, đặt hàng, nhận thông báo. Phần đáng học nằm ở cách các mảnh ghép nói chuyện với nhau: REST, gRPC, GraphQL Federation, event qua message broker, cache, log có correlation ID, trace OpenTelemetry, test nhiều tầng và CI.

Java 21 · Spring Boot 3.3 .NET 10 · ASP.NET Core React 19 Angular 21 MySQL · MongoDB · Redis Nginx · Apollo Router · OTel · Seq

5backend service

3frontend (shell + 2 remote)

4kiểu giao tiếp: REST, gRPC, GraphQL, event

2cloud adapter cho messaging và cache

9/9phase local đã xong

0resource cloud đã tạo

Sơ đồ hoạt hình

Một request đi qua những đâu?

Chọn một kịch bản rồi bấm Phát hoặc Tiếp. Đường xanh đậm là bước đang chạy, đường nét đứt là dữ liệu trả về. Nét gạch ngắn trên sơ đồ là gRPC, nét chấm là GraphQL.

Kịch bản

1 / 1HTTP

Bản đồ kiến thức

Dự án này dạy được gì

Mỗi ô là một nhóm kỹ thuật. Bấm vào để mở phần giải thích kèm code thật ở tab Kỹ thuật.

Kiến trúc microservice

Chia theo năng lực nghiệp vụ, mỗi service một database, polyglot Java + .NET.

Java & Spring

Spring Security + JWT, filter chain, @Transactional và cái bẫy self-invocation, Flyway.

.NET & MongoDB

Kestrel 2 cổng, repository, update nguyên tử với FindOneAndUpdate, seed dữ liệu.

Giao tiếp giữa service

gRPC + Protobuf, event OrderCreated qua SNS/SQS hoặc Service Bus, GraphQL Federation, Nginx gateway.

Micro-frontend

Webpack Module Federation, hợp đồng mount/unmount cho React và Angular, cấu hình lúc chạy.

Cache, log, trace, test

Redis cache-aside, correlation ID + Seq, OpenTelemetry agent, Testcontainers, Playwright, Docker.

Lộ trình

Dự án đã đi qua những chặng nào

Phase 1Scaffold

Cấu trúc repo, docker-compose, thư mục /contracts

Phase 2identity-service

Java, đăng ký/đăng nhập, cấp JWT

Phase 3product-service

.NET + MongoDB, catalog, seed

Phase 4cart-service

.NET, gọi gRPC sang product

Phase 5order-service

Checkout, gRPC, phát OrderCreated

Phase 6notification-service

Nhận OrderCreated, ghi thông báo

Phase 7Micro-frontend

Shell + React remote + Angular remote

Phase 8Logging

Seq + correlation ID ở cả 5 service

Phase 9End-to-end

Playwright chạy hết luồng mua hàng

ThêmDocker hóa 9 service

Mỗi service một Dockerfile multi-stage

ThêmRedis + Gateway + GraphQL

Cache 2 cloud, Nginx, Apollo Federation

ThêmOTel + CI

Trace qua agent, GitHub Actions

Tiếp theoDeploy Azure → AWS

Đã duyệt thiết kế, chưa tạo resource

18 chủ đề · code trích nguyên văn từ repo

Học kỹ thuật qua chính code của dự án

Mỗi chủ đề có 4 phần: vấn đề cần giải, cách dự án làm, đoạn code thật, và những điều nên nhớ hoặc bẫy đã gặp. Cuối mỗi chủ đề có vài câu hỏi phỏng vấn hay gặp.

Nhảy tới chủ đề

Microservice, polyglot và database-per-service

Kiến trúcBounded contextDatabase per service

Vấn đề. Muốn tập triển khai lên cloud thì phải có thứ gì đủ "thật" để triển khai: nhiều service, nhiều ngôn ngữ, nhiều kiểu database. Một app monolith một file jar thì không dạy được bao nhiêu về DevOps.

Cách dự án làm. Cắt shop thành 5 service theo năng lực nghiệp vụ. Mỗi service sở hữu dữ liệu của riêng nó, không service nào đọc thẳng database của service khác. Muốn lấy dữ liệu thì phải hỏi qua API (REST, gRPC) hoặc nghe event.

Service	Stack	Database	Việc chính
identity	Java 21, Spring Security	MySQL `identity_db`	Đăng ký, đăng nhập, cấp JWT
product	.NET 10	MongoDB `product_db`	Catalog, tồn kho
cart	.NET 10	MongoDB `cart_db`	Giỏ hàng, hỏi giá qua gRPC
order	Java 21	MySQL `order_db`	Checkout, lịch sử đơn, phát event
notification	Java 21	MySQL `notification_db`	Nghe OrderCreated, lưu thông báo

Hình dung: mỗi service giống một phòng ban có tủ hồ sơ khóa riêng. Phòng Kho không mở tủ của phòng Kế toán; muốn biết gì thì gọi điện hỏi (API) hoặc đọc thông báo nội bộ (event).

Chọn database theo hình dạng dữ liệu: user, đơn hàng, thông báo là dữ liệu quan hệ, cần ràng buộc (MySQL). Sản phẩm và giỏ hàng là document linh hoạt (MongoDB).

Nên nhớ

Database-per-service giúp mỗi service deploy, đổi schema độc lập.
Đổi lại, không còn JOIN qua service; phải ghép dữ liệu bằng API hoặc GraphQL Federation (phần 9).
Polyglot ở đây là để học; ở công ty thật thường chọn 1–2 stack để giảm chi phí vận hành.

Đánh đổi

Không có transaction chung giữa các service: checkout phải tự bù trừ khi lỗi (phần 4).
Debug khó hơn: cần correlation ID và trace (phần 15, 16).

Câu hỏi phỏng vấn

Khi nào không nên dùng microservice? Khi team nhỏ, domain chưa rõ ranh giới, hoặc chưa có CI/CD và observability. Lúc đó monolith chia module tốt thường rẻ hơn.

Database-per-service thì báo cáo tổng hợp làm sao? Dùng API composition, GraphQL Federation, hoặc đẩy event sang một kho đọc riêng (CQRS / data warehouse).

Spring Security: đăng ký, đăng nhập và cấp JWT

Spring Boot 3.3.4jjwt 0.12.6BCryptHS256

Vấn đề. 4 service khác cần biết "ai đang gọi" mà không phải tự làm đăng nhập. Nếu mỗi request đều phải hỏi lại identity-service thì nó thành nút cổ chai.

Cách dự án làm. identity-service là nơi duy nhất kiểm tra mật khẩu. Đúng mật khẩu thì nó ký một JWT bằng HS256 với secret chung JWT_SECRET. Các service khác chỉ cần cùng secret là tự kiểm tra được token, không cần gọi lại identity (stateless).

Angular loginPOST /api/auth/loginqua gateway AuthServiceBCrypt.matches JwtServicesub=userId, exp=24h Shell lưu tokenlocalStorage

Spring Security được cấu hình stateless: tắt CSRF (vì không dùng cookie session), không tạo HttpSession, mở /api/auth/** cho mọi người, còn lại phải có token. Hai filter tự viết được chèn vào chuỗi filter theo thứ tự: correlation ID trước, JWT sau.

Nên nhớ

Không bao giờ lưu mật khẩu thô; BCrypt tự thêm salt và chậm có chủ đích.
Sai email hay sai mật khẩu đều trả cùng một lỗi, để kẻ tấn công không dò được email nào tồn tại.
Kiểm tra độ dài secret ngay lúc khởi động: lỗi cấu hình lộ ra sớm thay vì lúc có người đăng nhập.

Giới hạn của HS256

Mọi service giữ cùng secret, nên service nào cũng có thể ký token giả. RS256 (khóa bí mật chỉ ở identity, khóa công khai ở nơi khác) an toàn hơn.
JWT không thu hồi được trước khi hết hạn (ở đây là 24 giờ).

Câu hỏi phỏng vấn

Vì sao tắt CSRF lại an toàn ở đây? CSRF lợi dụng việc trình duyệt tự gửi cookie. Token ở header Authorization không tự gửi, nên kẻ tấn công không lợi dụng được.

Lưu JWT ở localStorage có rủi ro gì? Nếu trang dính XSS thì script đọc được token. Cookie HttpOnly chống được việc đọc nhưng lại cần chống CSRF. Mỗi cách có đánh đổi.

Kiểm tra JWT ở hai stack: filter Java và AddJwtBearer .NET

OncePerRequestFilterSecurityContextAddJwtBearer

Vấn đề. Token do Java ký phải được cả Java lẫn .NET đọc được. JWT là chuẩn mở nên chỉ cần cùng thuật toán và cùng secret.

Java (order, notification). Một filter đọc header Authorization: Bearer ..., xác minh chữ ký, rồi đặt userId vào SecurityContextHolder. Token sai thì xóa context, Spring Security sẽ trả 401 ở bước sau.

.NET (cart). Middleware có sẵn làm hết việc trên. Chỉ cần khai báo cách kiểm tra.

Bẫy đã gặp

.NET mặc định đổi tên claim sub thành một URI dài kiểu .../nameidentifier. Phải đặt MapInboundClaims = false thì FindFirst("sub") mới thấy.

Nên nhớ

product-service không kiểm tra JWT: xem catalog là công khai, đúng như ngoài đời.
Ở cloud, secret đến từ Key Vault / Secrets Manager, không nằm trong code.

Câu hỏi phỏng vấn

401 và 403 khác nhau thế nào? 401: chưa xác thực được bạn là ai (thiếu hoặc sai token). 403: biết bạn là ai nhưng bạn không có quyền.

Checkout qua nhiều service: điều phối, bù trừ và bẫy @Transactional

OrchestrationCompensationSpring AOP proxy

Vấn đề. Đặt hàng chạm tới 3 service và 2 database. Không có transaction nào trải qua cả MySQL của order lẫn MongoDB của product. Nếu giữ hàng được món 1 mà món 2 hết hàng thì phải trả lại món 1.

Cách dự án làm. order-service đóng vai nhạc trưởng (orchestrator) và chạy theo thứ tự:

1. GetCartgRPC → cart 2. ReserveStock từng móngRPC → product 3. Lưu Order@Transactional, MySQL 4. ClearCartgRPC → cart 5. Phát OrderCreatedSNS / Service Bus 6. Xóa cacheRedis

Phía product, "giữ hàng" là một lệnh update nguyên tử của MongoDB: chỉ trừ kho nếu còn đủ hàng. Hai người cùng mua món cuối cùng thì chỉ một người thành công, không cần lock.

Bẫy self-invocation

@Transactional chạy nhờ proxy Spring bọc quanh bean. Gọi this.persist() từ trong cùng class sẽ đi vòng qua proxy nên không có transaction.
Cách sửa trong dự án: tách việc lưu sang bean riêng OrderPersistenceService.

Nên nhớ

Đây là dạng saga đơn giản, kiểu orchestration. Bù trừ là best-effort: nếu product sập đúng lúc trả hàng thì chỉ ghi log cảnh báo.
Test e2e kiểm tra đúng việc này: lỗi 409 hết hàng thì món còn hàng được trả lại kho.
Mã lỗi rõ ràng: giỏ rỗng 400, hết hàng 409.

Câu hỏi phỏng vấn

Saga orchestration và choreography khác nhau thế nào? Orchestration có một service điều phối gọi từng bước (như ở đây). Choreography không có nhạc trưởng: mỗi service nghe event rồi tự làm phần mình và phát event tiếp.

Nếu phát event lỗi sau khi đã lưu đơn thì sao? Đơn đã lưu nhưng không ai được báo. Cách chuẩn là Outbox pattern: ghi event vào bảng outbox trong cùng transaction rồi có tiến trình khác gửi đi. Dự án chưa làm phần này.

Flyway: schema database đi theo code

FlywayJPA validateMySQL 8.4

Vấn đề. Lên cloud thì không ai tạo bảng bằng tay. Database phải tự có đúng schema khi service khởi động lần đầu.

Cách dự án làm. Mỗi service Java có thư mục db/migration với file đánh số V1__...sql. Lúc khởi động, Flyway chạy những file chưa chạy và ghi lại vào bảng lịch sử. Hibernate đặt ddl-auto: validate: chỉ kiểm tra entity khớp schema, không tự sửa bảng.

Nên nhớ

Migration đã chạy thì không sửa nữa; muốn đổi thì thêm V2, V3.
user_id không có foreign key sang bảng users vì users nằm ở database khác (database-per-service).
notification có ràng buộc UNIQUE (order_id) để chặn ghi trùng (phần 8).

Việc phải làm trước khi deploy

User/password MySQL đang cố định root/root123 trong application.yml. Azure MySQL không cho dùng tên root, nên Step 0 phải chuyển sang biến môi trường.

ASP.NET Core + MongoDB: repository, index, seed

.NET 10MongoDB.Driver 3.11Kestrel

Vấn đề. Catalog sản phẩm cần đọc nhanh, phân trang, lọc theo danh mục, và SKU không được trùng.

Cách dự án làm. Class Product được map sang document bằng attribute BSON. Giá tiền lưu kiểu Decimal128 chứ không phải double để không lệch số lẻ. Lúc khởi động, app tạo unique index cho Sku rồi seed 12 sản phẩm nếu collection còn trống.

Một tiến trình .NET nghe 2 cổng: 8082 cho REST (HTTP/1.1) và 8083 cho gRPC (HTTP/2). Chi tiết này sẽ thành vấn đề khi lên Azure Container Apps (xem tab DevOps, mục gRPC A1/A2).

Nên nhớ

Bắt lỗi trùng khóa ở database (unique index) chắc hơn kiểm tra trước rồi mới ghi, vì 2 request song song có thể cùng qua bước kiểm tra.
Seeder chỉ chạy khi collection trống, nên chạy lại nhiều lần vẫn an toàn (idempotent).

Một app, ba API

Cùng một service phục vụ REST cho frontend, gRPC cho service khác, GraphQL cho router. Logic nằm ở tầng service, các API chỉ là lớp vỏ.

gRPC + Protobuf: hợp đồng chung cho Java và .NET

proto3HTTP/2CodegenMetadata

Vấn đề. Service gọi service rất nhiều lần mỗi checkout. Cần nhanh, có kiểu dữ liệu chặt, và một service Java phải gọi được service .NET mà không ai viết tay client.

Cách dự án làm. Hợp đồng viết một lần trong /contracts/*.proto. Lúc build, .NET (Grpc.Tools) và Java (protobuf-maven-plugin) đều sinh code từ cùng file đó. REST chỉ dành cho frontend; gRPC chỉ dùng giữa các service.

contracts/product.protoGrpc.Tools ProductLookupBaseserver ở product protocProductLookupBlockingStubclient ở order

Server (.NET) chỉ cần override method được sinh ra

Client (Java) gắn correlation ID vào metadata cho từng lời gọi

Nên nhớ

Số thứ tự field (= 1, = 2) là thứ được gửi đi, không phải tên. Đừng đổi số của field đã dùng.
Lỗi gRPC (StatusRuntimeException, RpcException) được đổi thành exception nghiệp vụ, để tầng trên không phụ thuộc thư viện gRPC.
Địa chỉ lấy từ biến môi trường, nên lên cloud chỉ cần đổi env.

Bẫy

gRPC cần HTTP/2. Đó là lý do product và cart tách cổng gRPC riêng, và cũng là câu hỏi mở khi lên Container Apps.
plaintext chỉ ổn trong mạng nội bộ.

Câu hỏi phỏng vấn

Khi nào chọn gRPC thay vì REST? Gọi nội bộ giữa service, cần hiệu năng, cần hợp đồng chặt, hoặc cần streaming. REST hợp hơn cho API công khai và cho trình duyệt.

Thêm field mới vào message có làm hỏng client cũ không? Không, nếu dùng số field mới. Client cũ bỏ qua field nó không biết.

Event-driven: OrderCreated qua SNS/SQS hoặc Azure Service Bus

Pub/Sub@ProfileAt-least-onceIdempotentDLQ

Vấn đề. Đặt hàng xong thì phải báo cho khách. Nhưng nếu notification-service đang sập thì việc đặt hàng không được hỏng theo. Và đổi từ AWS sang Azure không được bắt viết lại code nghiệp vụ.

Cách dự án làm. order-service chỉ phát một sự thật đã xảy ra: OrderCreated (thì quá khứ). Nó không biết ai nghe. Code nghiệp vụ chỉ thấy interface IEventPublisher; hai bản cài đặt AWS và Azure được chọn qua biến SPRING_PROFILES_ACTIVE.

order-serviceIEventPublisherpublish SNS topicecommerce-eventsfan-out SQS queuenotification-order-created@SqsListener notification-serviceIEventConsumer

Phía nhận: xử lý trùng vì broker giao "ít nhất một lần"

Chạy local thì không cần tài khoản AWS: LocalStack giả lập SNS và SQS, script khởi tạo tạo topic, queue và subscription.

Nên nhớ

Topic + subscription cho phép thêm người nghe mới mà không sửa order-service. Kế hoạch Azure thêm Function ghi hóa đơn làm subscription thứ hai.
Idempotent 2 lớp: kiểm tra trong code và UNIQUE(order_id) trong database.
Dead-letter là cấu hình của hạ tầng (giao tối đa 3 lần), không nằm trong code Java.

Bẫy đã gặp

Script .sh checkout trên Windows bị đổi sang CRLF thì LocalStack chạy lỗi mà không báo, và mọi checkout không phát được event. Sửa bằng .gitattributes ép LF.
Mỗi profile phải tắt auto-config của cloud kia, nếu không Spring cố kết nối cả hai.

Câu hỏi phỏng vấn

Queue và topic khác nhau thế nào? Queue: mỗi message tới một người nhận. Topic: mỗi subscription nhận một bản sao (fan-out). Vì vậy Azure Queue Storage không hợp ở đây: nó không có topic.

Exactly-once có tồn tại không? Trên thực tế hệ thống thường đạt at-least-once cộng với consumer idempotent.

GraphQL Federation: một query, dữ liệu từ 4 service ở 2 stack

Apollo Router 1.57HotChocolate 16Netflix DGS 9@key

Vấn đề. Màn hình "đơn hàng của tôi" muốn hiện cả số tồn kho hiện tại của từng sản phẩm. Đơn hàng nằm ở order (Java/MySQL), tồn kho nằm ở product (.NET/MongoDB). Không thể JOIN.

Cách dự án làm. 4 service mở thêm /graphql (subgraph). Mỗi subgraph khai báo kiểu nó sở hữu, và có thể nhắc tới kiểu của service khác chỉ bằng khóa id. Apollo Router ghép tất cả thành một schema (supergraph) và tự tách query, gọi đúng service, rồi ghép kết quả.

Clientorders { items { product { stockQuantity } } } Apollo Router :40001 orders subgraphtrả productId2 products subgraphresolve Product theo id

Nên nhớ

Thêm GraphQL không đổi gì REST hay gRPC đang có; chỉ thêm vào.
Router chuyển tiếp header Authorization, nên subgraph vẫn tự kiểm tra quyền.

Bảo mật theo field

/graphql phải mở không cần token để Rover đọc schema. Vì vậy từng resolver (me, cart, orders) tự kiểm tra auth.
Resolver User của identity trả null nếu id không phải của chính người gọi, để không xem trộm được người khác.

Nginx API gateway: một cổng vào, CORS ở một chỗ

Reverse proxyCORSenvsubst template

Vấn đề. Lúc đầu frontend phải biết 4–5 địa chỉ backend, và service nào cũng phải tự cấu hình CORS.

Cách dự án làm. Mọi request REST đi qua Nginx ở :8080, được chia theo tiền tố đường dẫn. CORS chỉ cấu hình ở đây. Các service phía sau không có cấu hình CORS nào. Địa chỉ upstream đến từ biến môi trường: image Nginx chính thức tự thay ${...} trong file template lúc khởi động.

Nên nhớ

Preflight OPTIONS được trả 204 ngay tại gateway, không làm phiền service.
Cùng một image chạy được ở local, Azure, AWS: chỉ đổi biến upstream và origin.

Phải sửa khi lên Azure

proxy_set_header Host $host chuyển tiếp host công khai. Container Apps định tuyến nội bộ theo Host, nên request sẽ đi lạc. Step 0 sẽ bỏ dòng này.
Gateway cũng phải gọi được identity qua HTTPS, vì identity chạy trên App Service.

Redis cache-aside, đổi được Azure ↔ AWS bằng một biến

Cache-asideTTLAdapter patternBest-effort

Vấn đề. Catalog được đọc rất nhiều mà ít đổi. Nhưng nếu Redis sập thì shop vẫn phải bán được.

Cách dự án làm. Code nghiệp vụ chỉ biết interface ICacheService (.NET) / CacheService (Java). Có 2 adapter, Azure Cache for Redis và Amazon ElastiCache. Cả hai nói cùng giao thức Redis, chỉ khác cách kết nối. Mọi thao tác cache đều bọc try/catch: lỗi thì ghi cảnh báo và đọc thẳng database.

GetByIdAsync1. hỏi Redisproduct:{id}2. miss MongoDB3. ghi lại TTL Redis

Nên nhớ

Item cache bị xóa khi sửa, xóa, giữ hàng, trả hàng. List cache chỉ dùng TTL ngắn 60 giây vì khó biết trang nào bị ảnh hưởng.
Java chọn adapter bằng @ConditionalOnProperty; messaging thì dùng @Profile. Hai cách đều đạt mục tiêu "đổi cloud bằng cấu hình".

Bẫy

Update đi đường khác (như gRPC ReserveStock) mà quên xóa cache thì trang sản phẩm hiện tồn kho cũ tới hết TTL.
identity và cart cố ý không cache: dữ liệu thay đổi liên tục, cache không có lợi.

Micro-frontend với Webpack Module Federation

Webpack 5remoteEntry.jsRuntime remote

Vấn đề. Hai đội (giả định) viết hai framework khác nhau, React và Angular, nhưng người dùng phải thấy một website duy nhất, một thanh menu, một lần đăng nhập.

Cách dự án làm. Shell là app chủ (host), không dùng framework, chỉ lo định tuyến và phiên đăng nhập. Mỗi remote build riêng ra một file remoteEntry.js công khai module ./App. Lúc người dùng vào /products, shell mới tải script của React remote.

Trình duyệt mở /products Shell đọc config.jsreactRemoteUrlthêm <script> remoteEntry.js:3011import("reactRemote/App") mount(el, props)

Điểm hay nhất: địa chỉ remote không đóng cứng lúc build. Shell dùng "promise remote": đọc URL từ window.__APP_CONFIG__ trong trình duyệt rồi tự chèn thẻ script.

Nên nhớ

shared + singleton đảm bảo chỉ có một bản React trên trang.
Remote phải trả header CORS, vì shell ở origin khác tải remoteEntry.js. Trên Azure việc này chuyển sang staticwebapp.config.json.

Bẫy đã gặp (Angular)

Angular build ra script dạng module có import.meta. Shell chèn nó như script thường, nên trình duyệt báo "Loading script failed" mà không nói là lỗi cú pháp. Sửa bằng output.scriptType = 'text/javascript'.

Hợp đồng mount / unmount cho React và Angular

React 19 createRootAngular 21 createApplicationRace condition

Vấn đề. React và Angular không chia sẻ được cây component. Shell cần một cách chung để "gắn app vào div này" và "gỡ ra sạch sẽ".

Cách dự án làm. Mỗi remote xuất đúng 2 hàm: mount(el, props) và unmount(el). Props mang theo đường dẫn hiện tại, hàm navigate của shell và kho đăng nhập auth. Remote không gọi nhau trực tiếp; muốn chuyển trang thì gọi navigate của shell.

Bẫy race condition khi chuyển trang nhanh

Tải remote là thao tác bất đồng bộ. Nếu người dùng bấm sang trang B trong lúc trang A đang tải, A có thể tải xong sau và chồng lên B. Shell đánh số mỗi lần render và kiểm tra lại sau mỗi await.

Nên nhớ

Hợp đồng nhỏ và rõ thì thay framework của một remote không ảnh hưởng phần còn lại.
State: React dùng Redux Toolkit, Angular dùng NgRx. Thứ dùng chung chỉ có auth store của shell, giao tiếp bằng CustomEvent.

Bẫy Redux

createAsyncThunk làm mất field status của lỗi HTTP khi serialize. Dùng rejectWithValue để giữ status, nhờ đó biết 401 thì về trang đăng nhập, 409 thì báo hết hàng.

Build một lần, chạy ở mọi nơi: config.js lúc chạy

12-factor configdocker-entrypoint.dwindow.__APP_CONFIG__

Vấn đề. Nếu URL backend được build cứng vào bundle thì môi trường nào cũng phải build lại. Như vậy image đã test ở CI không phải image chạy trên cloud.

Cách dự án làm. Shell tải /config.js trước bundle chính. Trong Docker, file này được sinh từ biến môi trường mỗi lần container khởi động, và Nginx được cấu hình không cache nó.

Nên nhớ

${VAR:?msg} làm container dừng ngay nếu thiếu biến, thay vì chạy với cấu hình hỏng.
Remote đọc config lúc gọi hàm, không phải lúc import, nên test chỉ cần gán window.__APP_CONFIG__ trong file setup.

Khi lên Azure

Frontend chạy trên Static Web Apps (không có container), nên config.js sẽ được sinh lúc deploy thay vì lúc container khởi động.

Correlation ID và structured log với Seq

X-Correlation-IdMDCSerilogLogback appender

Vấn đề. Một lần checkout sinh log ở 4 service. Khi có lỗi, làm sao gom đúng các dòng log của lần đó?

Cách dự án làm. Request đầu tiên được gắn một ID (lấy từ header nếu có, không thì sinh UUID). ID này được đẩy vào ngữ cảnh log, rồi đi tiếp theo mọi đường: HTTP header, gRPC metadata, thuộc tính của message SNS/SQS/Service Bus. Trong Seq chỉ cần lọc CorrelationId = '...'.

orderheader → MDCgRPC metadata cart, productinterceptor → LogContext message attributenotification→ MDC Seq :5341lọc theo 1 ID

Nên nhớ

Structured log là log dạng field (JSON), không phải chuỗi. Nhờ vậy mới lọc được theo CorrelationId.
Java không có thư viện Seq cho Logback trên Maven Central, nên dự án tự viết SeqAppender gửi định dạng CLEF, bọc trong AsyncAppender để không chặn request.

Bẫy

Quên MDC.remove thì ID của request trước dính sang request sau trên cùng thread.
Gateway Nginx chưa cho header X-Correlation-Id trong CORS, nên trình duyệt không gửi được ID qua gateway.

OpenTelemetry: trace mà không sửa code

Java agent 2.31.NET auto-instrumentation 1.16OTLPCollector

Vấn đề. Log cho biết "chuyện gì xảy ra". Trace cho biết "mỗi bước tốn bao lâu, gọi tới đâu". Muốn có trace mà không phải sửa code cả 5 service.

Cách dự án làm. Agent được gắn ở Dockerfile. Java dùng -javaagent, .NET dùng CLR profiler và startup hook. Mọi service gửi dữ liệu theo chuẩn OTLP tới một OTel Collector. Collector là chỗ duy nhất biết dữ liệu đi đâu: local thì in ra console, Azure thì gửi Application Insights, AWS thì gửi X-Ray và CloudWatch.

Nên nhớ

Đổi cloud chỉ là đổi file cấu hình collector; app không biết mình đang gửi trace tới đâu.
Seq + correlation ID và OTel trace là hai hệ riêng, chạy song song.

Bẫy đã gặp (.NET)

UseSerilog(...) mặc định thay toàn bộ ILoggerFactory và bỏ luôn logger provider của OTel. Kết quả: 2 service .NET gửi trace nhưng không gửi log tới collector. Log của chúng vẫn tới Seq.

Test nhiều tầng: unit, integration, frontend, end-to-end

JUnit 5 + MockitoxUnit + MoqTestcontainersJest / VitestPlaywright 1.62

Vấn đề. Có 3 ngôn ngữ, 9 app và một luồng mua hàng đi qua 5 service. Cần biết thay đổi nào làm hỏng cái gì, càng sớm càng tốt.

Tầng	Công cụ	Kiểm tra gì	Trong CI?
Unit	JUnit 5 + Mockito, xUnit + Moq + FluentAssertions	Logic một class, phụ thuộc giả lập	Có
Integration	Testcontainers (MySQL, MongoDB, LocalStack), WebApplicationFactory, MockMvc	Service + database/broker thật chạy trong container	Có
Frontend	Jest + React Testing Library, Vitest + Angular TestBed	Component, router của shell	Có
E2E backend	`e2e-checkout-flow.sh` (curl + jq)	Luồng thật qua 5 service, lỗi 400/409, event, log trong Seq	Không
E2E trình duyệt	Playwright	Đăng ký → mua → đơn hàng → trang thông báo	Không

Unit test: checkout với giỏ rỗng thì không được làm gì thêm

Integration test: MySQL thật trong container

E2E trình duyệt: luồng mua hàng hoàn chỉnh

Nên nhớ

Testcontainers tránh tình huống "test với H2 thì qua, chạy MySQL thật thì lỗi".
Hệ thống bất đồng bộ (event) phải test bằng cách chờ có giới hạn (toPass, timeout(10_000)), không phải sleep cố định.
Test router của shell mô phỏng đúng race condition ở phần 13.

Chưa làm

2 script e2e chưa vào CI vì phần dọn tiến trình dùng lệnh riêng của Windows (netstat, taskkill).

Docker multi-stage và docker-compose

Multi-stage buildhealthcheckdepends_onprofiles

Vấn đề. Image deploy lên cloud nên nhỏ, không chứa SDK hay Maven, và phải chính là image đã chạy ở local và CI.

Cách dự án làm. Mỗi Dockerfile có 2 giai đoạn: giai đoạn build có SDK (Maven/JDK, .NET SDK, Node), giai đoạn chạy chỉ có runtime (JRE, ASP.NET runtime, Nginx). Build context là gốc repo để image copy được /contracts và sinh code gRPC.

Nên nhớ

Copy file dependency (pom.xml, .csproj, package-lock.json) trước code: đổi code không làm tải lại dependency.
Port được bind vào 127.0.0.1 để không lộ ra mạng LAN.

Vì sao CI phải build image

Thêm thư mục code mới mà quên COPY trong Dockerfile thì mvn/dotnet ở máy vẫn chạy, chỉ image là hỏng. Job docker compose build trong CI bắt được lỗi này (đã từng xảy ra với thư mục GraphQL).

Từ máy cá nhân lên cloud · Azure trước, AWS sau

Kế hoạch DevOps, tách riêng từng cloud

Phần đầu là nền chung cho cả hai cloud: CI đang chạy và nguyên tắc "một image, nhiều môi trường". Sau đó chọn Azure hoặc AWS để đọc kế hoạch riêng của cloud đó, từ sơ đồ, pipeline, từng bước dựng, tới chi phí.

XongChạy local

docker compose, 9 app + hạ tầng

XongCI

GitHub Actions: test 8 app + build image

Đã duyệtAzure

Thiết kế 30/09, thứ tự bước 01/10, chưa tạo resource

Chưa bắt đầuAWS

Mới có ánh xạ dịch vụ, làm sau Azure

Nền chung · dùng cho cả hai cloud

CI: phần đã chạy thật trên GitHub Actions

Mỗi lần push lên main hoặc mở PR, .github/workflows/ci.yml chạy 3 chặng dưới đây. Đây là nửa "CI" và đã xong. Nửa "CD" (đưa lên cloud) khác nhau theo từng cloud, nằm trong phần Azure và AWS bên dưới.

PushCó

push main / PRconcurrency: hủy run cũpermissions: contents read

Test song songCó

java × 3 · mvn testdotnet × 2 · dotnet testfrontend × 3 · jest / ng test

Build imageCó

docker compose buildbắt Dockerfile thiếu COPY

CDTheo cloud

Azure → deploy-azure.ymlAWS → deploy-aws.yml

Sẵn sàng. CI hiện dừng ở chặng "Build image" và chưa push image nào.

Nguyên tắc 1

Một image, nhiều môi trường

Image build một lần, chạy ở local, Azure hay AWS đều giống nhau. Chỉ biến môi trường là khác. File deploy/env-contract.md liệt kê mọi biến mà từng container đọc; mỗi cloud tự điền giá trị của nó.

order-service · cùng image, khác biến

SPRING_PROFILES_ACTIVE
  local: aws-sns   (LocalStack)
  azure: azure-servicebus
  aws:   aws-sns   (SNS thật, bỏ *_ENDPOINT)
CACHE_PROVIDER
  azure: azure     aws: aws

Nguyên tắc 2

Code không biết mình chạy trên cloud nào

Messaging nằm sau IEventPublisher / IEventConsumer, có sẵn cả adapter Azure và AWS.
Cache nằm sau ICacheService / CacheService, có sẵn cả 2 adapter.
Trace và log đi qua OTel Collector; mỗi cloud chỉ đổi file cấu hình exporter.
Vì vậy phần lớn việc deploy là dựng hạ tầng và điền biến, gần như không sửa code nghiệp vụ.

Microsoft Azure

Kế hoạch Azure

Nguồn: docs/superpowers/specs/2026-09-29-azure-deployment-design.md và deploy/azure/README.md. Kiến trúc được duyệt 30/09/2026, thứ tự bước chốt 01/10/2026. Chưa tạo resource nào.

IaCBicep

Region đề xuấtsoutheastasia

CDdeploy-azure.yml

Chạy cả tháng~50–70 USD

Sơ đồ

Ứng dụng nằm trên Azure như thế nào

Đọc từ trên xuống: người dùng vào từ Internet, chỉ chạm được các ô ở tầng "công khai". Mọi service còn lại nằm trong mạng nội bộ của Container Apps Environment.

Internet

Trình duyệt người dùng

HTTPS

Công khai

swa-shellStatic Web Appsswa-react-remoteStatic Web Appsswa-angular-remoteStatic Web Apps gatewayContainer App · Nginxgraphql-gatewayContainer App · Apollo Router

nội bộ · gRPC + HTTP

cae-ecommerce · nội bộ

product-serviceContainer Appcart-serviceContainer Apporder-serviceContainer Appnotification-serviceContainer Appotel-collectorContainer App

Ngoài CAE

app-identityApp Service · gateway gọi qua HTTPSfunc-receiptAzure Functions

kết nối dữ liệu

Dữ liệu và sự kiện

mysql-ecomMySQL Flexible · 3 DBcosmos-ecomCosmos DB Mongo · 2 DBredis-ecomCache for Redissb-ecomService Bus · topicstecomBlob · receipts

trace + log

Giám sát

appi-ecommerceApplication Insightslog-ecommerceLog Analytics

Dùng chung, bao quanh mọi thứ rg-ecommerce-devResource Group · xóa là xóa hết acrecomContainer Registry · 8 image kv-ecomKey Vault · bí mật id-ecommerceManaged Identity · kéo image, đọc secret GitHub OIDCCI đăng nhập không cần mật khẩu

Local → Azure

Mỗi mảnh ở local thành gì trên Azure

CD pipeline Azure · kế hoạch

Từ image đã build tới app chạy trên Azure

Phần nối tiếp CI ở trên, sẽ nằm trong .github/workflows/deploy-azure.yml (Step 9). Khung nét đứt là chưa có.

CI xanhCó

test + build image

Đăng nhậpKế hoạch

azure/login + OIDCfederated credential

Push imageKế hoạch

8 image → acrecomtag = commit SHA

DeployKế hoạch

Container Apps: revision mớiApp Service: app-identityStatic Web Apps × 3

Smoke testKế hoạch

GET /api/productsmua thử 1 đơn

Sẵn sàng.

11 bước dựng Azure

Thứ tự dựng, và vì sao theo thứ tự đó

Chọn một bước. Bản đồ resource sáng dần lên: ô viền xanh là tạo ở bước đang chọn, ô rõ nét là đã có từ trước, ô mờ là chưa tạo. Database đi trước backend vì backend kết nối database ngay khi khởi động (Flyway tạo bảng lúc đó).

Khái niệm riêng của Azure

Những thứ học được khi làm trên Azure

Bí mật

Key Vault + Managed Identity + OIDC

kv-ecom giữ JWT secret, mật khẩu DB, connection string.
id-ecommerce là danh tính của app: kéo image từ ACR và đọc Key Vault mà không cần mật khẩu.
GitHub Actions xin token ngắn hạn từ Azure qua OIDC, repo không lưu secret dài hạn. Cần quyền Owner để gán role.

Compute

3 kiểu chạy app trong một dự án

Container Apps: phần lớn backend. Gói Consumption, scale về 0, có revision.
App Service: chỉ identity (REST, 1 cổng), để học App Service và deployment slot.
Static Web Apps: 3 frontend, gói Free. Ngoại lệ duy nhất của quy tắc "cùng image".
AKS bị loại khỏi phần lõi: khoảng 70+ USD/tháng và phức tạp.

Mạng

Chỉ 2 Container App công khai

Trong cae-ecommerce chỉ gateway và graphql-gateway nhận traffic từ Internet. Container Apps định tuyến nội bộ theo header Host, nên Nginx phải thôi chuyển tiếp Host công khai (Step 0).

IaC

Bicep, có công tắc bật/tắt

Bicep đi kèm Azure CLI nên không cần cài Terraform. Phần chỉ để demo (slot, Application Gateway, tên miền, AKS) là tham số, mặc định tắt.

Messaging

Service Bus topic, không dùng Queue Storage

Topic ecommerce-events có 2 subscription: notification-order-created (MaxDeliveryCount = 3) và order-receipt cho Function. Queue Storage không có topic nên không fan-out được. Gói Basic cũng không có topic, nên phải dùng Standard.

Giám sát

Application Insights qua collector

otel-collector dùng exporter azuremonitor với APPLICATIONINSIGHTS_CONNECTION_STRING. App Insights lưu dữ liệu trong log-ecommerce. Java gửi cả trace lẫn log; .NET chỉ gửi trace.

Câu hỏi còn mở · riêng Azure

gRPC cần cổng thứ hai: A1 hay A2?

product (8082 REST + 8083 gRPC) và cart (8084 + 8085) nghe 2 cổng, nhưng một Container App chỉ có một cổng HTTP ingress chính. Phải kiểm tra trước khi deploy.

A1 · additionalPortMappings Ưu tiên

Khai báo thêm cổng gRPC cho Container App. Không sửa code. Cần kiểm tra gRPC nội bộ qua cổng phụ có chạy không, và có bắt buộc VNet riêng không.

order:8083productcổng chính 8082 + cổng phụ 8083

A2 · Một cổng HTTP/2 Dự phòng

Kestrel phục vụ cả REST và gRPC trên một cổng với Http1AndHttp2. Phải sửa nhỏ code và cấu hình của 2 service .NET, kể cả ở local.

order:8082productREST + gRPC chung 1 cổng

Mô phỏng · Azure

Blue-green bằng Container Apps revision

Mỗi lần deploy tạo một revision mới. Ở chế độ nhiều revision, bạn chia traffic dần sang bản mới; có lỗi thì kéo về 0%. Cách này miễn phí. Deployment slot của App Service cũng làm được blue-green nhưng cần gói Standard S1, khoảng 70 USD/tháng.

Traffic sang revision mới

Chi phí Azure nếu chạy cả tháng

Cái gì tốn tiền, cái gì miễn phí

Dịch vụ	Gói	USD / tháng	Ghi chú
Azure Cache for Redis	Basic C0	~16	Khoản lớn nhất trong phần lõi
MySQL Flexible Server	Burstable B1ms	~15	1 server, 3 database
Service Bus	Standard	~10	Gói Basic không có topic
Container Registry	Basic	~5	8 image
Cosmos DB for MongoDB	Serverless	~1–5	Trả theo lượng dùng
Container Apps	Consumption	~0–20	Scale về 0 khi không có traffic
Static Web Apps, Functions, revision, GitHub Actions	Free	0	Miễn phí hoặc gần như miễn phí
App Service slot · Application Gateway · AKS	S1 · v2 · cluster	~70 · >100 · ~70+	Chỉ để demo, mặc định tắt

Dọn dẹp: xóa rg-ecommerce-dev là xóa hết. Key Vault bị soft-delete, phải purge nếu muốn dùng lại tên.

Trước khi bắt đầu Azure

Checklist khởi động

Chuẩn bị máy và tài khoản

Azure subscription (Free Trial, Azure for Students hoặc Pay-as-you-go), quyền Owner.
winget install Microsoft.AzureCLI và winget install GitHub.cli
az login, gh auth login, rồi az account show

Câu hỏi cần trả lời

Mục đích: link demo chạy liên tục, tạo → demo → xóa, hay cả hai (đề xuất: cả hai).
Region (đề xuất southeastasia).
Kết quả kiểm tra gRPC A1 / A2.
Đánh dấu spec là Approved, viết implementation plan, rồi làm Step 0.

Amazon Web Services

Kế hoạch AWS

Nguồn: deploy/aws/README.md, deploy/env-contract.md, docs/otel-cloud-deployment.md. Repo mới có ánh xạ dịch vụ, chưa có thiết kế chi tiết, tên resource hay công cụ IaC. Sẽ làm sau khi Azure xong.

Lưu ý Phần "9 bước dựng" bên dưới là thứ tự đề xuất để học, dựng theo ánh xạ đã có. Nó chưa có trong repo; khi làm thật sẽ chốt lại trong một spec riêng.

IaCchưa chọn

ComputeECS on Fargate

CDdeploy-aws.yml

Chi phíchưa ước tính

Sơ đồ

Ứng dụng nằm trên AWS như thế nào

Khác Azure ở chỗ: cả 11 container (kể cả 3 frontend) đều chạy trên ECS Fargate, và OTel Collector chạy như sidecar trong từng task thay vì là một app riêng. Ô có dấu * là phần đề xuất, chưa ghi trong repo.

Internet

Trình duyệt người dùng

HTTPS

Công khai

Application Load Balancer *định tuyến tới gateway và 3 frontend

vào VPC

ECS cluster · Fargate

shellNginx · config.js từ envreact-remoteNginxangular-remoteNginx gatewayNginxgraphql-gatewayApollo Router

ECS · subnet riêng tư *

identity+ otel sidecarproduct+ otel sidecarcart+ otel sidecarorder+ otel sidecarnotification+ otel sidecar

kết nối dữ liệu

Dữ liệu và sự kiện

RDS for MySQL3 DBDocumentDB2 DBElastiCache for RediscacheSNS ecommerce-eventstopicSQS notification-order-created+ DLQ, maxReceiveCount 3

trace + log từ sidecar

Giám sát

AWS X-RaytraceCloudWatch Logs/ecommerce/otel-logs

Dùng chung, bao quanh mọi thứ VPC + security group *mạng và tường lửa Amazon ECRkho image Secrets Managerbí mật IAM task roleX-Ray + CloudWatch, không có key tĩnh GitHub OIDC *CI assume IAM role

Local → AWS

Mỗi mảnh ở local thành gì trên AWS

Local đã giả lập AWS sẵn: LocalStack đóng vai SNS và SQS, profile mặc định của Spring là aws-sns. Lên AWS thật chủ yếu là bỏ các biến *_ENDPOINT trỏ về LocalStack.

CD pipeline AWS · đề xuất

Từ image đã build tới app chạy trên AWS

Sẽ nằm trong .github/workflows/deploy-aws.yml. Ý tưởng giống Azure; khác ở chỗ AWS deploy bằng cách đăng ký một task definition revision mới rồi cập nhật ECS service.

CI xanhCó

test + build image

Đăng nhậpĐề xuất

configure-aws-credentialsOIDC → assume IAM role

Push imageĐề xuất

ECR login8+ image → ECR

DeployĐề xuất

task definition mớiupdate ECS servicechờ service ổn định

Smoke testĐề xuất

GET /api/products qua ALB

Sẵn sàng.

9 bước dựng AWS · đề xuất để học

Thứ tự dựng trên AWS

Cùng logic với Azure: nền tảng → dữ liệu → messaging → compute → nối dây → frontend → CI/CD. Điểm khác lớn là AWS bắt bạn tự lo mạng (VPC, subnet, security group) ngay từ bước đầu.

Khái niệm riêng của AWS

Những thứ học được khi làm trên AWS

Quyền

IAM role thay cho access key

Task execution role: quyền để ECS kéo image từ ECR và đọc secret lúc khởi động task.
Task role: quyền của chính app khi chạy, ví dụ AWSXRayDaemonWriteAccess và ghi CloudWatch Logs.
Ở local, app dùng AWS_ACCESS_KEY_ID=test cho LocalStack. Trên AWS thật không đặt key nào: SDK tự lấy quyền từ task role.

Giám sát

Collector làm sidecar

Mỗi task definition có 2 container: app và otel-collector. Chúng chung mạng nên app gửi tới http://localhost:4317. Collector dùng awsxray cho trace và awscloudwatchlogs cho log (log group /ecommerce/otel-logs).

Messaging

SNS fan-out, SQS giữ hàng đợi

SNS là topic phát đi; mỗi người nghe có một SQS queue riêng subscribe vào. Queue notification-order-created có RedrivePolicy maxReceiveCount = 3: nhận lỗi 3 lần thì message sang dead-letter queue. LocalStack hiện chưa cấu hình DLQ này.

Mạng

VPC, subnet, security group

Azure Container Apps lo mạng giùm bạn. Trên ECS bạn tự chọn subnet công khai hay riêng tư cho từng service, và mở cổng bằng security group. gRPC 2 cổng không còn là vấn đề: một task definition khai báo được nhiều container port.

Service discovery

Service gọi nhau bằng tên

order cần địa chỉ static://cart-service:8085. Ở compose, Docker DNS lo việc này. Trên ECS cần Service Connect hoặc Cloud Map để mỗi service có tên DNS nội bộ.

IaC

Chưa chọn công cụ

Ba lựa chọn phổ biến: CloudFormation (gốc của AWS), CDK (viết hạ tầng bằng TypeScript, Java, C#...) hoặc Terraform (dùng được cho nhiều cloud). Repo mới dự định thư mục deploy/aws/infra/, chưa quyết định.

Mô phỏng · AWS

Deploy an toàn trên ECS

ECS mặc định dùng rolling update: thay dần task cũ bằng task mới, giữ số task khỏe tối thiểu theo minimumHealthyPercent. Muốn blue-green thật (chạy song song 2 bản rồi chuyển traffic ở load balancer) thì dùng CodeDeploy hoặc tính năng blue/green của ECS. Kéo thanh trượt để xem rolling update thay task.

Phần task đã chạy bản mới

Chi phí AWS

Repo chưa ước tính, nhưng đây là chỗ tốn tiền

Dịch vụ	Tính tiền theo	Ghi chú
ECS Fargate	vCPU và RAM mỗi giây task chạy	11 container chạy suốt ngày đêm là khoản lớn
RDS, DocumentDB, ElastiCache	Giờ chạy của instance	Tính tiền kể cả khi không có traffic
Application Load Balancer	Giờ chạy + lượng xử lý	Tính tiền kể cả khi không có traffic
NAT Gateway	Giờ chạy + GB đi qua	Cần nếu task ở subnet riêng tư phải ra Internet; hay bị quên
SNS, SQS, ECR, Secrets Manager, CloudWatch	Theo lượng dùng	Rất nhỏ với dự án học tập

Cách giữ chi phí gần 0 giống Azure: dựng bằng IaC, demo, rồi xóa cả stack.

Trước khi bắt đầu AWS

Việc cần quyết định

Chuẩn bị

Tài khoản AWS, bật MFA cho root, tạo user hoặc IAM Identity Center để dùng hằng ngày.
Cài AWS CLI, aws configure sso hoặc aws configure.
Đặt budget alert trong AWS Budgets trước khi tạo resource đầu tiên.

Câu hỏi cần trả lời

Chọn IaC: CloudFormation, CDK hay Terraform.
Region.
Frontend giữ trên ECS như kế hoạch, hay chuyển sang S3 + CloudFront cho rẻ hơn.
Viết spec AWS riêng như đã làm cho Azure, rồi mới làm.