Thời gian gần đây, đi liền với sự nổi dậy của cloud computing, microservice cũng đang dần trở thành một từ khóa hot. Bài viết này sẽ giới thiệu tổng quan về microservice một cách đơn giản, dễ hiểu cho bà con gần xa.

Micro là rất nhỏ, service là dịch vụ, vậy microservice nghĩa là… dịch vụ vô cùng nhỏ. Nói đơn giản, microservice là một kiếu kiến trúc phần mềm. Các module trong phần mềm này được chia thành các service rất nhỏ (microservice).

Có vẻ phức tạp ha? Ủa mà vậy thì liên quan gì đến cái bồn cầu nhỉ?? Đọc hết bài rồi sẽ hiểu ngay thôi!

Từ cái bồn cầu và kiến trúc monolith

Ngành phần mềm “vay mượn” khá nhiều ý tưởng từ ngành kiến trúc (những từ như architecture, pattern đều là mượn từ ngành kiến trúc cả). Do vậy, để hiểu về microservice, ta hãy xem cách dân kiến trúc xây dựng nó.

Bạn thấy gì khi nhìn vào hình dưới? Dĩ nhiên là… thấy một cái bồn cầu. Sai rồi, bạn còn thấy một cái bồn rửa mặt và một cái bồn tắm nữa, tổng cộng là ba cái bồn.

Nói đơn giản, trong bức hình không chỉ đơn thuần là cái bồn cầu mà còn là phòng tắm, với bồn tắm bồn cầu bồn rửa mặt. Đây là kiến trúc mà chúng ta thường dùng để xây dựng phần mềm – kiến trúc monolith (một khối). Toàn bộ các module (view, business, database, report) đều được gom chung vào một project lớn. Khi deploy, mấy anh IT sẽ ném khối code này lên server và config để nó chạy.

Kiến trúc này hoạt động khá tốt vì nó đơn giản, dễ code. Tuy nhiên, khi phần mềm trở nên lớn và phức tạp thì nó lại dần bộc lộ nhược điểm. Do các module dính với nhau thành … một cục, khi muốn nâng cấp một module, ta phải deploy lại toàn bộ code; khi muốn phục vụ nhiều người dùng, ta phải nâng cấp server.

Ví dụ như trong hình, giả sử mình lấy vợ, muốn mở rộng cái bồn tắm để … hai người tắm chung :”>, mình phải đập cả phòng tắm để mở rộng nó. Trong thời gian đó, cả bồn tắm lẫn bồn rửa mặt đều không thể hoạt động.

Cho đến phần mềm và microservice

Chúng ta hãy chuyển qua ngắm một cái bồn cầu khác (trong kí túc xá của mình) được xây dựng theo kiến trúc microservice. Thoạt nhìn, cái bồn cầu này có vẻ cũ và bẩn hơn cái trên. Tuy nhiên, nó đã tuân theo kiến trúc microservice một cách hoàn mĩ.

Toàn bộ hệ thống được chia làm ba module riêng biệt: bồn rửa mặt, toilet, phòng tắm. Nếu muốn nâng cấp toliet, mình chỉ đập cái cũ, mua cái mới về lắp, không ảnh hưởng tới module khác (bồn rửa mặt hay phòng tắm).

Kiến trúc microservice cũng tương tự vậy. Thay vì gom tất cả module thành một khối (monolith), ta tách các module thành những service siêu nhỏ. Mỗi service sẽ được đặt trên một server riêng (Có thể dùng server cloud như AWS hoặc Azure), giao tiếp với nhau thông qua mạng (Gửi nhận message qua giao thức HTTP hoặc sử dụng MessageQueue)..

Ủa mà tại sao phải làm như vậy nhỉ? Đọc tiếp tiếp đoạn dưới nhé!

Microservice – Lợi và hại

Không phải vô duyên vô cớ mà người ta nghĩ ra kiến trúc microservice. Hiện nay, các ứng dụng rất lớn và liên tục được update. Với kiến trúc monolith, việc gom toàn bộ ứng dụng vào một cục làm việc nâng cấp trở nên khó khăn và mất thời gian.

Để giải quyết, lập trình viên bắt đầu tách dần ứng dụng lớn ra thành các service nhỏ. Mỗi service quản lý một cơ sở dữ liệu riêng, nằm trên một server riêng, tách biệt hoàn toàn với nhau. Kiến trúc microservice ra đời từ đó.

Kiến trúc này có những ưu điểm sau:

• Dễ nâng cấp và scale, đây là điều quan trọng nhất. Giả sử bạn làm một trang web bán hàng. Tới cuối năm, cần xuất nhiều hóa đơn, chỉ việc nâng cấp server cho service order và report là xong. Với cloud computing, việc nâng cấp server vô cùng dễ dàng chỉ với vài cú click chuột. Điều này rất khó thực hiện với monolith.
• Do tách biệt nên nếu một service bị lỗi, toàn bộ hệ thống vẫn hoạt động bình thường. Với monolith, một module bị lỗi có thể sẽ kéo theo toàn bộ hệ thống… tiêu đời.
• Với monolith, các module sử dụng chung 1 ngôn ngữ/framework. Với microservice, các service nằm tách biệt nhau, bạn có thể thoải mái sử dụng ngôn ngữ lập trình riêng, database riêng. VD service xử lý ảnh có thể viết bằng C++, service tổng hợp data có thể viết bằng Python.

Tất nhiên là không có bữa trưa nào miễn phí, microserivce cũng đi kèm một số khuyết điểm.

• Các module giao tiếp qua mạng nên có thể tốc độ không cao bằng monolith. Ngoài ra, mỗi module phải tự giải quyết các vấn đề về bảo mật, transaction, lỗi kết nối, quản lý log files.
• Mỗi service sử dụng một database riêng, việc đảm bảo tính đồng nhất trong dữ liệu sẽ trở nên phức tạp.
• Sử dụng nhiều service nên việc theo dõi, quản lý các service này sẽ phức tạp hơn. Do vậy, một số tool/công nghệ ra đời để phục vụ cho việc này (Docker, Ansible, Salt, Octopus, …).
• Cần một đội ngũ có khả năng và trình độ: Software Architect để phân tách module, Techinical Leader để setup workflow, IT/DevOps để setup CI/CD , deploy lên cloud…. Thử tuyển 1 team 4 dev PHP intern thì tới mùa quýt năm sau cũng chưa triển khai được microservice nhé.

Con đường phía trước

Kiến trúc Microservice đã được nhiều công ty lớn áp dụng như Amazon, Netflix, chứng tỏ rằng nó hiệu quả, giải quyết được vấn đề. Tuy nhiên, điều đó không có nghĩa chúng ta nên mù quáng, cắm đầu làm theo các công ty lớn.

Một số lời khuyên bổ ích mình rút ra được là: Để đơn giản, trước hết hãy tập trung phát triển ứng dụng dạng monolith, với nhiều module riêng biệt trước. Khi vai trò của các module đã rõ ràng, ta có thể dần tách cách module này ra thành các service riêng.

Bác Martin Fowler, một cây đa cây đề ngành phần mềm, một người có khá nhiều bài viết kinh điển về Microservice, cũng không dám khẳng định là microservice sẽ hoàn toàn thay thế được monolith trong tương lai. Do vậy, sau khi đọc xong bài viết này, các bạn đừng lên công ty và đề nghị cả team đập hết project hiện tại, thiết kế lại theo hướng microservice để theo kịp xu thế nhé!

Bài viết liên quan: Tổng quan về ABP FRAMEWORK. Cách build 1 webapplication dựa trên ABP FRAMEWORK

Demo: Demo Microservice Solution ABP Framework

Nguồn: Phạm Huy Hoàng - Tôi đi code dạo.