Giới thiệu về Microservices (Phần 3) Những ưu nhược điểm của Microservices

Để có thể đơn giản hóa mọi sự phức tạp với Microservices chúng ta cần phải hiểu rõ về ưu điểm cũng như nhược điểm của Microservices để áp dụng với những trường hợp cụ thể.

Ưu điểm của Microservices

Thứ nhất, giúp đơn giản hóa hệ thống. Với tổng số chức năng không đổi, kiến trúc Microservices chia nhỏ hệ thống ra làm nhiều dịch vụ nhỏ lẽ dể dàng quản lý và triển khai từng phần so với kiến trúc nguyên khối. Mỗi dịch vụ thì được định nghĩa để giao tiếp với các dịch vụ khác thông qua RPC (Remote Procedure Call) hay message-driven API. Kiến trúc Microservices thúc đẩy việc phân tách rạch ròi các dịch vụ nhỏ, việc khó có thể làm nếu xây dựng ứng dụng bằng kiến trúc một khối. Trên hết với mỗi dịch vụ nhỏ, chúng ta sẽ có thời gian phát triển nhanh hơn, dễ nắm bắt cũng như bảo trì hơn.

Thứ hai, kiến trúc này cho phép việc mỗi dịch vụ được phát triển độc lập bởi những team khác nhau. Cũng như cho phép developer có thể tự do chọn lựa technology stack cho mỗi dịch vụ mình phát triển. Dĩ nhiên tự do lựa chọn nhưng không phải là tạo ra một mớ hỗn độn về technology, điều này thì chằng có một dự án hay sản phẩm nào mong muốn cả. Tuy nhiên, sự tự do này có nghĩa là các developer không còn phải bắt buộc phải sử dụng các công nghệ lỗi thời có thể đã tồn tại vào lúc bắt đầu dự án. Khi viết một dịch vụ mới, họ có tùy chọn của việc sử dụng công nghệ bắt kịp với xu thế. Hơn nữa, vì dịch vụ là tương đối nhỏ, việc viết lại một dịch vụ cũ dựa trên nền tảng công nghệ mới hơn là hoàn toàn khả thi.

Thứ ba, kiến trúc Microservices cho phép mỗi dịch vụ có thể được triển khai một cách độc lập. Cùng với đó thì việc triển khai hệ thống theo kiểu continuous deployment là hoàn toàn có thể.

Cuối cùng, kiến trúc Microservices cho phép mỗi dịch vụ có thể thực hiện việc scale một cách độc lập. Bạn có thể scale dễ dàng bằng cách tăng số instance phục vụ cho mỗi dịch vụ lên và phân tải bằng load balancer. Ngoài ra bạn cũng có thể tối ưu chi phí vận hành dịch vụ bằng cách triển khai mỗi dịch vụ lên server có resource thích hơp. Ví dụ về việc này tôi đã nêu ra trong bài Điạ ngục kiến trúc một khối.

Nhược điểm của Microservices

Nhược điểm đầu tiên của Microservices cũng chính từ tên gọi của nó. Microservice nhấn mạnh kích thước nhỏ gọn của dịch vụ. Một số lập trình đề xuất dịch vụ siêu nhỏ cỡ dưới 100 dòng code. Nhưng làm sao để chia nhỏ, và chia làm sao để khi chia quá nhiều sẽ dẫn đến manh mún, vụn vặt, khó kiểm soát.

Nhược điểm thứ hai của Microservices đến từ đặc điểm hệ thống phân tán (distributed system). Lập trình viên cần phải lựa chọn phát triển mỗi dịch vụ nhỏ giao tiếp với các dịch vụ khác bằng cách nào messaging hay là RPC. Hơn thế nữa, họ phải xử lý sự cố khi kết nối chậm, lỗi khi thông điệp không gửi được hoặc thông điệp gửi đến nhiều đích đến vào các thời điểm khác nhau.

Thứ ba, phải đảm bảo giao dịch phân tán (distributed transaction) cập nhật dữ liệu đúng đắn (all or none) vào nhiều dịch vụ nhỏ khác nhau khó hơn rất nhiều, đôi khi là không thể so với đảm bảo giao dịch cập nhật vào nhiều bảng trong một cơ sở dữ liệu trung tâm. Theo nguyên tắc CAP (CAP theorem) thì giao dịch phân tán sẽ không thể thỏa mãn cả 3 điều kiện: consistency (dữ liệu ở điểm khác nhau trong mạng phải giống nhau), availablity (yêu cầu gửi đi phải có phúc đáp), partition tolerance (hệ thống vẫn hoạt động được ngay cả khi mạng bị lỗi). Những công nghệ cơ sở dữ liệu phi quan hệ (NoSQL) hay môi giới thông điệp (message broker) tốt nhất hiện nay cũng chưa vượt qua nguyên tắc CAP.

Thứ tư, testing một dịch vụ trong kiến trúc microservices đôi khi yêu cầu phải chạy cả các dịch vụ nhỏ khác mà nó phụ thuộc. Do đó khi phân rã ứng dụng một khối thành microservices cần luôn kiểm tra mức độ ràng buộc giữa các dịch vụ. Nếu các dịch vụ nhỏ thiết kế phục thuộc vào nhau theo chuỗi. A gọi B, B gọi C, C gọi D. Nếu một mắt xích có giao tiếp API thay đổi, liệu các mắt xích khác có phải thay đổi theo không? Nếu có thì việc bảo trì, kiểm thử sẽ phức tạp tương tự ứng dụng một khối. Thiết kế dịch vụ tốt sẽ giảm tối đa ảnh hưởng lan truyền đến các dịch vụ khác.

Cuối cùng, triển khai dịch vụ microservices nếu làm thủ công theo cách đã làm với ứng dụng một khối phức tạp hơn rất nhiều. Ứng dụng một khối bổ sung các server mới giống hệt nhau đằng sau load balancer. Trong khi ở kiến trúc microservices, các dịch vụ nhỏ nằm trên nhiều máy ảo hay Docker container khác nhau, hoặc một dịch vụ có nhiều thực thể phân tán ra nhiều. Theo Adrian Crockcroft, Hailo có 160 dịch vụ, NetFlix có hơn 600 dịch vụ. Với cloud, các máy ảo, docker container có thể linh động bật tắt, dịch chuyển. Vậy cần thiết phải có một cơ chế phát hiện dịch vụ (service discovery mechanism) để cập nhật tự động địa chỉ IP và cổng, mô tả, phiên bản của mỗi dịch vụ.

Ngoài ra, chúng ta cũng đã từng nói về việc Microservices có những nét tương đồng với SOA, vậy hãy cùng so sánh một chút giữa hai kiến trúc này.

Lời kết

Kiến trúc một khối sẽ hữu hiệu đối với ứng dụng đơn giản, ít chức năng. Nó bộc lộ nhiều nhược điểm khi ứng dụng phát triển lớn nhiều chức năng. Kiến trúc microservices chia nhỏ kiến trúc một khối ra các dịch vụ nhỏ. Microservices sẽ hiệu quả, phù hợp cho những ứng dụng phức tạp, liên tục phát triển nếu được thiết kế đúng và tận dụng các công nghệ quản lý, vận hành tự động.

Hy vong qua series này, các bạn đã có một cái nhìn tổng quát và hiểu về kiến trúc Microservices, cũng như dựa vào ưu nhược điểm của nó mà có thể áp dụng với những trường hợp cụ thể trong thực tế.

Hẹn gặp lại các bạn trong những bài viết tiếp theo.

Bài viết có tham khảo và sử dụng tài nguyên từ các nguồn:

https://www.nginx.com/blog/introduction-to-microservices/

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.html