Kiến trúc Microservices hiện là chủ để được cộng đồng SA và developer vô cùng quan tâm. Có thể dễ dàng tìm được các bài báo, bài thuyết trình, blog bàn về chủ đề này tuy nhiên không phải ai cũng hiểu và có cái nhìn chính xác về loại hình kiến trúc hiện đại trên. Bài viết dưới đây sẽ mang đến cho độc giả cái nhìn khách quan về các ưu, nhược điểm của Microservices từ đó tìm ra phương pháp áp dụng khoa học và hiệu quả cho công việc, dự án của mình.
Bắt đầu với câu hỏi: “Liệu có thể xây dựng và duy trì ứng dụng dễ dàng hơn khi chúng được chia thành các ứng dụng nhỏ kết nối với nhau?” kiến trúc Microservices đã được ra đời.
Ưu điểm
Đầu tiên, microservices giúp giảm thiểu quá trình phức tạp hóa, rối rắm hóa trong các hệ thống lớn. Với tổng số chức năng không đổi, kiến trúc microservices chia nhỏ hệ thống cồng kềnh 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 monolithic.
Trong microservice, các dịch vụ giao tiếp với nhau thông qua Remote Procedure Call (RPC) hay Message-driven API. Ngoài ra, kiến trúc microservices thúc đẩy việc phân tách rạch ròi modules/services (loose coupling – high cohension), việc khó có thể làm nếu xây dựng theo kiến trúc monolithic.
Và quan trọng hơn cả, 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 mỗi service được phát triển độc lập bởi những team khác nhau, cho phép developer có thể tự do lựa chọn công nghệ cho mỗi dịch vụ mình phát triển. Sự tự do này không phải là tạo ra một mớ công nghệ hổ lốn, mà 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òn tồn tại do các nguyên nhân lịch sử của dự án. Khi đó, khi bắt tay vào viết một service mới, họ có cơ hội sử dụng công nghệ và môi trường tối ưu nhất với chức năng của service đấy.
Hơn nữa, một số service có thể outsourcing mà vẫn đảm bảo việc bảo mật của hệ thống cũng như mã nguồn phần còn lại của hệ thống. Các service có thể bật tắt để AB testing, được pháp triển, nâng cấp từng phần tùy theo mức độ quan trọng và ưu tiên của service.
Thứ ba, microservices cho phép mỗi service được đóng gói và triển khai độc lập với nhau. (VD: Mỗi service có thể được đóng gói vào một docker container độc lập, giúp giảm tối đa thời gian deploy). Bên cạnh đó, microservices rất phù hợp để áp dụng continuous deployment.
Thứ tư, microservices cho phép mỗi service có thể được scale một cách độc lập với nhau. Việc scale có thể được thực hiện dễ dàng bằng cách tăng số instance cho mỗi service rồi phân tải bằng load balancer. Ngoài ra, chúng ta còn có thể triển khai mỗi service lên server có resource thích hợp để tối ưu hóa chi phí vận hành (việc mà không thể làm được trong kiến trúc monolithic).
Khuyết điểm
Nhược điểm đầu tiên của Microservices cũng chính từ tên gọi của nó. Microservice khuyến khích làm nhỏ gọn các service. Một số lập trình đề xuất các service nên 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 tính phân tán (distributed). Kiến trúc sư cần phải đánh giá phương thức giao tiếp của các service trong hệ thống: message queue hay RPC. Hơn thế nữa, các developer phải handle các trường hợp kết nối chậm, lỗi khi message không gửi được hoặc message gửi đến nhiều đích đến vào các thời điểm khác nhau. Ngoài ra, tính toàn vẹn, nhất quán của dữ liệu trong hệ thống phân tán. Theo 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);
  • Availability (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ột/nhiều thành phần bị lỗi).
Những Message broker tốt nhất hiện nay cũng chưa đáp ứng được CAP.
Thứ ba, testing một service trong kiến trúc microservices đôi khi yêu cầu phải chạy cả các services 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 service. Nếu các serivce phụ thuộc dây chuyền vào nhau. A gọi B, B gọi C, C gọi D. Nếu một mắt xích nào đó thay đổi API interface, liệu các mắt xích khác có phải thay đổi theo không? Nếu có thì việc maintaining và testing sẽ phức tạp. Thiết kế tốt sẽ giảm tối đa ảnh hưởng domino đến các service khác trong ứng dụng.
Cuối cùng, việc triển khai microservices phức tạp hơn rất nhiều nếu làm thủ công theo cách đã làm với ứng dụng monolithic. 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ế service discovery để 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ụ,…
Nguyễn Đức Minh Quân
Quản lý giải pháp ITS – FPT IS FTS
Tin liên quan: