Câu trả lời cho câu hỏi ở #1 là câu trả lời mà @qloved cung cấp rồi.
Cơ mà, cậu đang hiểu sai về microservice rồi.
Theo em hiểu thì micro services là mô hình triển khai hệ thống cho phía server (gọi chung là backend) lúc này backend không còn là một máy chủ vật lý nữa mà là nhiều server, mỗi server sẽ có một database riêng.
Tớ không nghĩ đó là cách giải thích tốt cho micro service, dù nó không sai. Để phân biệt microservice với monolithic, cậu cần phải phân biệt nó dựa trên cách triển khai của business functionality, thay vì chỉ triển khai trên 1 ứng dụng, cậu chia nhỏ nó thành cách service, mỗi service có trách nhiệm riêng về business functionality.
Cậu có thể thấy ở ví dụ của cậu, cậu đang cố chia các layer của 1 ứng dụng monolithic thành 1 service. Điều đó không đúng, vì:
- Database, S3, CDN, cloud… không có bất cứ business functionality nào gắn với nó.
Cậu hoàn toàn có thể có 1 ứng dụng monolithic dùng tất cả các thành phần đó.
Sử dụng cloud cũng không phải là dấu hiệu cho microservice. Cậu hoàn toàn có thể có 1 ứng dụng monolithic được deploy trên nhiều instance rải rác khắp thế giới.
- Một khi business logic của cậu chỉ ở 1 app, đó không phải là microservice.
Để tớ lấy 1 ví dụ đơn giản cho microservice. Cậu biết E-commerce domain (cậu chỉ có thể chia microservice trên từng domain) có thể được chia thành các microservice như thế này:
- Order service: quản lý order life cycle.
- Shipping service: quản lý shipping life cycle.
- Item/product service: quản lý các item/item variant/product.
- Inventory service: quản lý inventory cho từng item.
- Campaign service: quản lý campaign.
- Shopper service: quản lý người mua.
- Merchant service: quản lý người bán.
- Etc…
Cậu có thể thấy, tất cả các service đều có nhiệm vụ rõ ràng và không trùng lặp về business. Các service cũng có dữ liệu riêng, được lưu vào DB riêng, và có thể hoạt động độc lập với service khác. Khi 1 merchant (người bán) muốn tạo 1 sản phẩm, cậu sẽ cần gọi merchant service, Item/Product service, Inventory service để lần lượt lấy thông tin người bán, tạo item và tạo inventory cho item đó.
Mỗi server giao tiếp với nhau bằng REST API hoặc grpc.
Còn nhiều giao thức khác để giao tiếp giữa các server đó 
Tớ để cho cậu tự tìm hiểu thêm nha!
Sẽ có 1 cái gì đó là nơi quản lý tất cả server này: gateway, eureka (spring boot), … để giao tiếp với hệ thống khác hoặc cung cấp API cho app và web.
API Gateway và Eureka (service discovery) không phải là nơi quản lý các server (với “quản lý” được hiểu là cậu có thể xem được performance của từng instance, tăng, giảm số lượng instance, hardware của từng service).
API Gateway là entry point của toàn bộ hệ thống, nơi nhận request từ bên ngoài hệ thống, gọi tới các downstream API để lấy dữ liệu và tích hợp với nhau trước khi trả về client. Security cũng được cài đặt chính ở đây.
Eureka là service discovery framework, thứ giúp các instance cùng thuộc 1 service nhận ra nhau. Eureka thường dùng để làm mid-tier server load balancer cho 1 service cụ thể, không phải để quản lý instance thuộc service đó.
Hi vọng câu trả lời trên giúp cậu.
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?