Microservices

Trong Phần 3: Làm Chủ Qdrant Hybrid Search - Giải Bài Toán Semantic và Hard Filters, chúng ta đã xây dựng thành công một engine tìm kiếm Hybrid mạnh mẽ, kết hợp giữa Dense Semantic và Sparse Lexical Search. Tuy nhiên, một hệ thống tìm kiếm e-commerce thực chiến không chỉ đơn thuần là việc lấy ra các văn bản tĩnh từ cơ sở dữ liệu vector. Ví dụ, người dùng hỏi: “Tôi muốn mua tủ lạnh Samsung Inverter 400L có sẵn tại chi nhánh Quận 1 và đang được áp dụng khuyến mãi.” Nếu chỉ dựa vào Vector Database, chúng ta sẽ gặp hai lỗi nghiêm trạng: ...

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. ...

Làn sóng truyền thông xung quanh Trí tuệ Nhân tạo (AI) trong thương mại điện tử (TMĐT) đang cực kỳ rầm rộ. Mọi nền tảng SaaS đều hứa hẹn các tính năng “tự động hóa cá nhân hóa bằng AI chỉ với một click”, khiến các doanh nghiệp đang vận hành hệ thống Magento (Adobe Commerce) truyền thống cảm thấy lo lắng. Đứng trước sự lựa chọn giữa một dự án di chuyển nền tảng (replatforming) tốn kém hàng triệu đô la hoặc bị tụt lại phía sau trong cuộc đua AI, nhiều nhà lãnh đạo công nghệ thường mắc phải một sai lầm chí mạng: cố gắng ép các tác vụ tính toán AI chạy trực tiếp bên trong lõi nguyên khối (monolithic core) của Magento. ...

Hệ thống tìm kiếm là trái tim của mọi nền tảng thương mại điện tử (TMĐT). Nếu khách hàng không thể tìm thấy sản phẩm, họ không thể mua nó. Tuy nhiên, hành vi tìm kiếm của người dùng hiện nay đã phát triển mạnh mẽ: từ việc gõ các từ khóa ngắn, cộc lốc (ví dụ: “giày chạy bộ nam”) sang việc đưa ra các truy vấn phức tạp, hướng tới mục tiêu cụ thể (ví dụ: “tìm cho tôi một đôi giày chạy địa hình chống nước cho nam, size 42, dưới 2 triệu, giao hàng trước ngày mai”). Trước những ý đồ đa diện này, các công cụ tìm kiếm truyền thống bắt đầu bộc lộ giới hạn. ...

Hãy nói thẳng với nhau: Magento không phải là một nền tảng tồi. Đối với hàng ngàn doanh nghiệp, nó là công cụ hoàn hảo. Nó có một hệ sinh thái plugin lâu đời, một cộng đồng developer đông đảo, và một hồ sơ theo dõi đã được chứng minh qua vô số dự án thương mại điện tử enterprise. Nhưng nó có một cái trần nhà (ceiling). Và khi bạn đụng trần, bạn sẽ cảm nhận được sự đau đớn ở khắp mọi nơi — trong hệ thống deploy, trong thời gian chạy query database, trong khả năng các team có thể tự vận chuyển (ship) tính năng một cách độc lập, và cuối cùng là trong khả năng phục vụ khách hàng ổn định ở quy mô lớn. ...

“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. ...

“Tại sao lại cần tới 21 services? Như thế chẳng phải là overkill (giết gà dùng đao mổ trâu) sao?” Đây là câu hỏi phổ biến nhất mà tôi nhận được khi thảo luận về kiến trúc microservice viết bằng Golang mà chúng tôi đã xây dựng để xử lý khối lượng scale khổng lồ. Câu trả lời ngắn gọn là: Không, bởi vì Định luật Conway là có thật. ...