Microservices Anti-pattern là tập hợp các pattern sai anh em nên tránh khi làm việc với microservices. Đây đều là những kinh nghiệm xương máu, nhiều project đã fail vì vấp phải các anti pattern này

Mời anh em lướt qua 4 Microservices Anti pattern để dày thêm kinh nghiệm khi làm việc với microservices nhé. Tất cả đều có ví dụ, làm sao để tránh khỏi các anti pattern. Mong rằng bài viết này sẽ hữu ích với các anh em làm TechLead cũng như Solution Architect.

Cùng bắt đầu ngay thôi nào!

1. No well defined services – Không định nghĩa tốt services

Đầu tiên no well defined services là services không được định nghĩa kĩ càng ngay từ ban đầu. Để hiểu hơn về pattern này, đầu tiên anh em cần xem lại step by step khi mình thiết kế microservices

Ở bước số 3, map the components, anh em cần định nghĩa được services sẽ mapping ở đâu với ai (services sẽ làm những gì).

Bước này cực kì quan trọng vì nó quyết định hệ thống chúng ta design sẽ hoạt động như thế nào khi chạy lâu dài (long run). Một khi đã định nghĩa mapping và các components trong đó, sẽ rất khó để thay đổi. Đơn cử như roles và permission trong hệ thống, một khi đã định nghĩa, sẽ rất là khó thay đổi sau khi anh em development.

Chính vì vậy, để tránh khỏi anti-pattern này, anh em cần định nghĩa services có gì bên trong (inside), bên ngoài services có gì (outside). Nếu không thể giới hạn (scoped) được logic sẽ viết trong microservices, khả năng cao services anh em thiết kế ra sẽ luôn được bổ sung logic.

Lúc mà logic cứ được add thêm vào liên tục, lúc đó bản thân services sẽ không còn là micro services nữa mà chuyển thành mini-monolith. Lúc này logic trong services trở nên mất kiểm soát (uncontrollably). Hậu quả là nếu nhiều services cùng tiến triển theo chiều hướng xấu đó thì bể luôn cả hệ thống microservices

2. No well defined API – Không định nghĩa tốt API

Kế tiếp với anti pattern số 2 khi làm việc với microservices là không định nghĩa API rõ ràng.

Đầu tiên API ở đây chỉ đơn giản là cách thức giao tiếp, còn RestAPI hay gRPC hay GraphQL thì tuỳ thuộc techstack của anh em nhé.

Nhắc tới API thì không còn gì quan trọng hơn API khi làm việc với microservices. Client làm việc với microservices như thế nào, các microservices giao tiếp với nhau ra sau, tất cả đều thông qua API. Vậy sẽ ra sao nếu API không được định nghĩa rõ ràng?

Nếu API không được định nghĩa rõ ràng, không dễ dàng sử dụng, ngay lúc đó anh em có 1 API chết. Mà đã là API chết thì viết tốn công vô ích, có khi lại còn bị chửi. Vậy làm sao để định nghĩa được một API tốt?

Có một vài nguyên tắc anh em có thể tham khảo để tránh gặp phải anti pattern không design tốt API

• API MUST be consistent (nó phải nhất quán), tránh mập mờ về việc mà API làm
• API MUST be versioned (nó phải được đánh phiên bản), tránh chuyện có thay đổi dẫn tới chết tới chết lui hoặc nhầm lẫn giữa các phiên bản với nhau
• API MUST be part of design (nó phải là một phần nằm trong thiết kế của microservices)

Dưới đây là một số API best practice anh em có thể tham khảo

3. Quên không làm cross cutting trước

Trong quá trình thiết kế và implement microservices, hẳn anh em không còn lạ gì một số tác vụ cần thiết nên được implement. Đơn cử như những tác vụ mà system nào cũng nên implement ví dụ như

• Logging
• Caching
• User management
• Authentication & Authorization
• …

Nếu hệ thống có user, tất nhiên anh em sẽ phải làm user management, phải thực hiện authen, autho cho hệ thống. Đây đều là những tác vụ cơ bản (cross cutting)

Anti pattern ở đây là một số anh em khi implement microservices sẽ bay thẳng vào code logic của services đó mà quên mất các cross cutting. Thực chất các tác vụ này là cần thiết để làm và nên làm ngay từ ban đầu.

Hơn nữa các services tiếp theo chắc chắn sẽ sử dụng các cross cutting này, services nào chả dùng logging và caching (kỹ thuật cơ bản). Một số services khi đã làm xong anh em sẽ làm biếng quay lại để sửa code trong đó.

4. Mở rộng ranh giới services (expanding services boundaries)

Thường ngay từ lúc thiết kế, ông SA (solution architect) đã define rõ ràng ranh giới của các services, tức là services đó nên làm gì, sẽ làm gì và làm tới đâu.

Việc anh em mở rộng ranh giới của microservices sẽ dần tới services đó trở nên kém hiệu quả (inefficient) và trở nên quá tải (bloated).

Để tranh khỏi Microservices Anti pattern này, anh em đừng ngại ngùng khi scope của 1 microservices đã hết thì cứ triển thêm cái mới, miễn là không ảnh hưởng tới việc các services cần làm gì. Một khi đã mở rộng microservices, sẽ cực kì khó khăn cho anh em có thể kiểm soát số lượng microservices của mình.

5. Tham khảo thêm về Microservices Anti pattern

• Top 6 nguyên lý thiết kế microservices cho lập trình viên có kinh nghiệm
• Identify microservice boundaries – Azure Architecture Center
• How to Decompose Monolith into Microservices

Anh em nếu muốn tìm hiểu sâu hơn về Microservices có thể vào ghé Udefree để lựa cho mình các khoa học miễn phí cũng như trả phí

Cảm ơn anh em đã đọc bài – Thank you for your read – Happy coding!