Để thực hiện migrate sang microservice, thì phương pháp Domain Driven Design được sử dụng. Tuy nhiên được cải biên thành DDD Incremental Design. Phương pháp này thực chất là SA và Domain expert cùng ngồi lại với nhau để xác định Bounded Context, hiểu đơn giản là bóc tách 1 phần chức năng của hệ thống cũ và tạo ra 1 logical border quanh nó. Thật sự thì đọc giải thích trên Google về các khái niệm domain và bounded context rất khó hiểu.
Link phần 1 đây nhé các bạn : https://topdev.vn/blog/migrate-tu-he-thong-monolithic-sang-microservice/
- Từ hệ thống cũ phân tích nghiệp vụ, bóc ra một chức năng business cụ thể (ví dụ như order, payment)
- Tạo 1 border bao quanh business logic và data đó, những module khác muốn truy cập thì phải qua interface
Khái niệm Big Ball of Mud
Legacy system đang theo kiến trúc monolithic, giống như một quả bóng bùn khổng lồ (gigantic ball of mud), anti-pattern. Business logic được code theo kiểu xâu chuỗi theo kiểu hàm A gọi hàm B, B lại gọi cho C qua rất nhiều level function call. Không hề có một biên giới rõ ràng giữa data và chức năng. Đó là 1 challenging khi migrate sang microservice.
Việc xác định Bounded Context trong hệ thống đòi hỏi cần có Domain Expert, những người hiểu rất sâu sắc business của hệ thống, biết được các module liên hệ qua lại như thế nào, dependency ra sao.
Domain Expert cần mô tả được hệ thống có bao nhiêu module, quan hệ giữa các module như thế nào
Ví dụ minh họa đơn giản
Những module như Order có nhiều quan hệ với module khác thì việc migrate sang microservices sẽ phức tạp hơn nhiều so với các module độc lập như Product.
Từ các module trên sẽ bóc nhỏ thành các Bounded Context
Build model và interface
Sau khi Bounded Context được xác định, bước tiếp sẽ tạo interface. Phần lớn trường hợp thì interface được thiết kế thành Rest API. Ngoài ra thì có thể sử dụng Queue, event streams.
Các module bên ngoài sẽ được modify để access bounded context thông qua interface. Do đó mỗi khi bóc tách module thành microservice, thì những phần còn lại của hệ thống mono sẽ được sửa đổi để gọi chúng qua interface thay vì function call như trước. Quá trình bóc tách sửa chữa cứ được làm từ từ từng bước một cho đến khi toàn bộ hệ thống migrate xong. Tức là hệ thống mới và cũ vẫn cùng tồn tại (co-exist) cho đến khi hoàn thành migration. Gọi là mô hình Strangler pattern, hiểu nhanh là mô hình dây leo tầm gửi, dây leo (microservice bám quanh) cây chủ (monolithic) cắn từng miếng của cây chủ để lớn dần. cây chủ ngày càng nhỏ dần rồi chết khô
Chốt hạ là sao cho 2 hệ thống mono và microservice có thể chạy đồng thời mà ko ảnh hưởng gì đến business, user sử dụng vẫn ko cảm thấy khác biệt gì, là một challenging thứ 2. Vì quá trình migration sẽ được tính bằng năm.
Ví dụ Order Service được tách ra thành service độc lập từ monolithic ban đầu. Xác định dc bounded context Order từ monolithic tách ra thành Order microservice, phần code đang gọi legacy order qua function call được modified để switch sang gọi bằng API (order API)
Migrate data
Bước cuối cùng là làm sao break down DB monolithic ra thành db riêng own by service.
Challenging ở đây là làm sao migrate data từ mono db sang microservice db. Vì data là tài sản của tổ chức, không phải của ứng dụng, data lên tới hàng triệu record với hàng trăm bảng quan hệ chằng chịt.
Việc break down và migrate data như thế nào, đón đọc bài sau.
TechTalk via Giaosucan
