Trong kỹ thuật phần mềm, các lỗi giao diện người dùng (UI) có thể làm người dùng khó chịu, nhưng những sai lệch tài chính sẽ giết chết doanh nghiệp và kéo theo những vụ kiện tụng. Việc xây dựng một kiến trúc microservices tài chính vững chắc cho Fintech hoặc Core Banking (Ngân hàng Lõi) là một trong những thử thách kiến trúc khó nhằn nhất mà bạn từng đối mặt. ...
Hầu hết các lập trình viên Go xây dựng microservices đều biết đến mẫu Choreography Saga: service A phát ra (emit) một sự kiện, service B phản ứng, service C phản ứng với B, và cứ tiếp tục như vậy. Nếu bước C thất bại, các services sẽ phát ra các sự kiện “bù trừ” (compensation) theo thứ tự ngược lại. Mẫu này hoạt động một cách mượt mà đối với các luồng đơn giản, nhưng lại phá vỡ tính hiệu quả khi số lượng bước tăng lên: việc debug một saga thất bại đòi hỏi phải lần theo dấu vết (tracing) các sự kiện qua năm topic của message broker, và việc triển khai logic bù trừ đòi hỏi mỗi service phải hiểu toàn bộ trạng thái của saga. ...
“Hãy đập đi viết lại toàn bộ bằng Microservices.” Câu nói này thường là điềm báo cho những dự án kỹ thuật thất bại trị giá hàng triệu đô la. Khi một ứng dụng di sản (legacy) như một hệ thống thương mại điện tử Magento khổng lồ đang gánh vác toàn bộ doanh thu tài chính của một công ty, việc thực hiện một cú chuyển đổi kiểu “Big Bang” (cắt cái rụp sang hệ thống mới) thực tế là một hành động tự sát. ...
Việc mở rộng quy mô (scale) một nền tảng thương mại điện tử vượt qua cột mốc 10.000+ đơn hàng mỗi ngày, với mỗi đơn chứa nhiều SKU trải dài qua nhiều kho hàng biến động là lúc mà các kiến trúc ngây thơ sẽ sụp đổ. Việc đập thêm tiền nâng cấp phần cứng không còn là viên đạn bạc khi hệ thống phải đối mặt với các giao dịch phân tán (distributed transactions), điều kiện tương tranh (race conditions), và tính nhất quán cuối (eventual consistency). ...
Trong bài viết trước, chúng ta đã khám phá cách việc từ bỏ kiến trúc nguyên khối (monolithic) để ưu tiên các ranh giới ngữ cảnh nghiêm ngặt của Thiết kế Hướng Domain (Domain-Driven Design - DDD) đã giúp một nền tảng thương mại điện tử có thể scale vượt mức 10.000+ đơn hàng mỗi ngày. Tuy nhiên, việc băm nát một database khổng lồ thành 20+ database Postgres hoàn toàn cách ly lại đẻ ra một vấn đề mới cực kỳ đáng sợ: Làm thế nào để chúng ta duy trì tính nhất quán dữ liệu giữa các service đã bị cắt đứt kết nối với nhau? ...
Khi chuyển đổi từ một nền tảng nguyên khối (monolith) sang một hệ thống microservice phân tán, câu hỏi khó nhất không phải là “Chúng ta viết code như thế nào?” — mà là “Làm sao để các mảnh ghép di động này nói chuyện với nhau một cách an toàn, và tại sao mỗi ranh giới lại được vẽ chính xác ở vị trí đó?” Bài viết này là mỏ neo kiến trúc cho toàn bộ series về composable commerce. Nó trình bày bản vẽ hệ thống tổng thể và giải thích lý do đằng sau mỗi ranh giới domain. Để tìm hiểu sâu về từng tầng cụ thể, mỗi phần đều có link dẫn đến bài viết chuyên đề trong series. ...