Giải thích thuật ngữ Microservice theo cách siêu bựa phần 2



Bài này tiếp tục giải thích các thuật ngữ mới của kiến trúc Microservice theo cách không thể “bựa” hơn.


Eventual Consistency

Đây là khái niệm được sử dụng nhiều trong các hệ phân tán distributed system. Thuật ngữ này được giải thích theo cách khá hàn lâm trên Wikipedia như sau

Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.[1] Eventual consistency, also called optimistic replication,[2] is widely deployed in distributed systems, and has origins in early mobile computing projects.[3] A system that has achieved eventual consistency is often said to have converged, or achieved replica convergence.[4]Eventual consistency is a weak guarantee – most stronger models, like linearizability are trivially eventually consistent, but a system that is merely eventually consistent does not usually fulfill these stronger constraints


Thật sự thì cách giải thích hàn lâm như trên là rất khó hiểu. Cho nên mình sẽ giải thích theo cách “nông dân” như sau
Hãy xem một scenario đơn giản của Kiến trúc Microservice như sau
Hoàng Kiều gọi API đến endpoint để order em Ngọc Trinh
Service Order thực hiện process Order của Hoàng Kiều (1 record order bao gồm order Id, customer…) được update vào database Order.
Service Order process xong send request sang Service Payment để thực hiện trả tiền


Event consistency
Mọi thứ sẽ hoạt động bình thường nếu như các service không có trục trặc gì. Tuy nhiên đối với hệ thống phân tán như Microservice, việc các service gặp vấn đề là điều ko tránh khỏi. Điều gì xảy ra nếu như service Payment bị lỗi? Điều này dẫn tới hệ thống sẽ có 1 Order nhưng không có Payment tương ứng. Anh Kiều được chén e Ngọc Trinh miễn phí, ăn bánh không phải trả tiền. Như vậy data trong hệ thống sẽ không nhất quán (Inconsistency)

Để xử lý vấn đề này, Microservice đã sử dụng những mô hình như Retry, Circuit Breaker and Compensation Transaction, mục tiêu là sẽ rollback lại những thay đổi data trong hệ thống về trạng thái trước đó.


Ví dụ trong trường hợp trên, tại thời điểm bản ghi Order được tạo, nhưng Payment không được tạo Dữ liệu là inconsistency. Tuy nhiên sau khi hệ thống detect được lỗi, sẽ rollback lại data (Bản ghi Order sẽ bị xóa đi) dữ liệu sẽ trở lại đồng nhất. Kiến trúc Microservice chấp nhận dữ liệu inconsistency tại một thời điểm nào đó, nhưng sau đó sẽ consistency trở lại. Cái này gọi là Eventual Consistency
CAP theorem
Thanh niên bây giờ cái gì cũng thích gọi là NGON, BỔ, RẺ. Nhưng thực tế cái gì NGON, BỔ thì sẽ không RẺ (Đi massage cao cấp toàn hàng tuyển thì phải chấp nhận Bo $$ nhiều). Cái gì NGON, RẺ thì sẽ không BỔ (Nhìn vấn đề vệ sinh an toàn thực phẩm ở Việt Nam thì biết)
Nguyên tắc CAP này cũng như vậy
CAP theorem
Nguyên tắc này được Eric Brewer đề xuất vào năm 2000, là chữ viết tắt của 3 từ ConsistencyAvailability and Partition Tolerance – or CAP:
Consistency: Dữ liệu phải đảm bảo đồng nhất (Ăn bánh thì phải giả tiền)
Availability: Yêu cầu request thì phải có phản hồi (Khách hàng call thì phải nghe máy)
Partition tolerance: Hệ thống vẫn hoạt động được ngay cả khi mạng bị lỗi
Kiến trúc phân tán Microservice chỉ có thể thỏa mãn 2 trong 3 điều kiện trên, không bao giờ được cả 3(Không có chuyện Ngon, Bổ, Rẻ), Khi làm các dự án về Microservice, mình thường chọn Availability và Partition tolerance, còn đối với Consistency thì chọn lựa giải pháp Eventually Consistency như trên

ACID & BASE theorem

Vâng những nguyên tắc toàn hóa chất, chị em nào hay đánh ghen sẽ hiểu rõ thuật ngữ này. ACID là nguyên tắc dùng trong các hệ thống database truyền thống. ACID (viết tắt của Atomicity, Consistency, Isolation, Durability)
Acid database
Atomicity: Tất cả cùng được update hoặc không có gì. Một transaction fail thì tất cả sẽ fail hết. Đại loại sống thì cùng sống, chết thì cùng chết.
Consistency: Đảm bảo rằng một giao dịch không bao giờ được thông qua cơ sở dữ liệu của bạn trong tình trạng dở dang. Tính chất này, hoặc là tạo ra toàn bộ trạng thái mới hoặc rollback tất cả các xử lý để về trạng thái ban đầu, nhưng không bao giờ thông qua cơ sở dữ liệu trong trạng thái dở dang. Đã có Order thì phải có Payment không thì không Order gì hết. Chơi hoặc Nghỉ không nửa vời.
Isolation Giữ giao dịch tách rời nhau cho đến khi chúng đã hoàn tất. Tính chất này đảm bảo rằng hai hoặc nhiều giao dịch không bao giờ được trộn lẫn với nhau, tạo ra dữ liệu không chính xác và không phù hợp.
Durability: Khi một giao dịch đã được thực hiện, nó sẽ vẫn như vậy, ngay cả trong trường hợp bị mất điện, tai nạn hoặc lỗi. Khi Hoàng Kiều đã Order Payment xong thì Ngọc Trinh dù có đang đèn đỏ cũng phải phục vụ nhiệt tình
ACID được sử dụng trong hệ thống đơn khối, tuy nhiên khi chuyển sang Microservice, một nguyên tắc khác trái ngược được sử dụng đó là BASE
Basically Available: Mọi request data đều sẽ có response. Tuy nhiên response có thể thất bại trong việc lấy dữ liệu.Tương tự như bạn gọi điện đến Help Desk của ngân hàng yêu cầu thông tin, lần nào gọi hệ thống cũng trả lời tuy nhiên sẽ có lúc nhân viên bận nên chỉ nghe thông báo các đường dây đều bận, xin gọi lại sau
Soft state: Trạng thái của hệ thống có thể thay đổi theo thời gian do vấn đề Eventual Consistency như trên. Tại một thời điểm có Order nhưng không có Payment, nhưng sau đó thì sẽ không có Order lẫn Payment
Eventual consistency: Như đã giải thích ở trên
(Còn tiếp)

Powered by Blogger.