Microservice là gì? Bạn đã thật sự hiểu và sử dụng Microservice đúng cách chưa?
Nếu bạn từng tìm hiểu về phát triển hệ thống, DevOps hay điện toán đám mây, chắc hẳn đã không ít lần nghe đến cụm từ Microservice. Đây là kiến trúc được rất nhiều công ty công nghệ lớn như Netflix, Amazon hay Uber sử dụng để xây dựng những hệ thống có quy mô hàng triệu người dùng. Chính vì vậy, nhiều lập trình viên cũng mặc định rằng Microservice là "chuẩn mực" mà bất kỳ dự án nào cũng nên hướng tới.
Thế nhưng, càng phổ biến thì Microservice lại càng dễ bị hiểu sai.
Không ít người cho rằng chỉ cần tách backend thành nhiều project là đã trở thành Microservice. Có người lại nghĩ rằng chỉ cần mỗi module dùng một database riêng là đủ. Thậm chí có những dự án chỉ có vài nghìn người dùng nhưng vẫn cố gắng chia thành hàng chục service vì nghĩ rằng đó là cách làm chuyên nghiệp nhưng thực tế không đơn giản như vậy.
Microservice là gì?
Microservice là một kiến trúc phần mềm trong đó toàn bộ hệ thống được chia thành nhiều dịch vụ nhỏ, mỗi dịch vụ đảm nhiệm một nghiệp vụ cụ thể và có khả năng hoạt động độc lập với các dịch vụ còn lại.
Hãy tưởng tượng bạn đang xây dựng một website thương mại điện tử. Thay vì viết toàn bộ chức năng trong một backend duy nhất, bạn sẽ tách hệ thống thành nhiều service khác nhau. Một service chỉ chịu trách nhiệm đăng nhập và xác thực người dùng, một service quản lý sản phẩm, một service xử lý đơn hàng, một service thực hiện thanh toán và một service chuyên gửi email hoặc thông báo.
Mỗi service sẽ có source code riêng, quy trình triển khai riêng và có thể được phát triển độc lập mà không làm ảnh hưởng đến các service khác.
Điểm quan trọng nhất của Microservice không nằm ở việc chia nhỏ ứng dụng, mà nằm ở khả năng độc lập của từng service.
Điều mà rất nhiều người đang hiểu sai
Một trong những quan niệm sai lầm phổ biến nhất là nghĩ rằng chỉ cần tạo nhiều project backend là đã áp dụng Microservice.
Giả sử bạn chia hệ thống thành ba project gồm Auth, Product và Order. Tuy nhiên, cả ba project này đều kết nối vào cùng một database và thường xuyên truy cập dữ liệu của nhau. Mỗi khi thay đổi cấu trúc bảng dữ liệu, cả ba project đều phải sửa theo.
Đó chưa phải là Microservice đúng nghĩa.
Bản chất của Microservice là giảm sự phụ thuộc giữa các thành phần trong hệ thống. Mỗi service phải có khả năng phát triển, triển khai và mở rộng gần như độc lập. Nếu một service thay đổi mà kéo theo hàng loạt service khác phải sửa theo thì kiến trúc đó vẫn còn phụ thuộc rất chặt chẽ.
Nói cách khác, chia nhiều project không khó. Thiết kế để chúng thực sự độc lập mới là phần khó nhất.
Mỗi service có cần database riêng không?
Nếu tìm hiểu về Microservice, bạn sẽ thường xuyên bắt gặp một nguyên tắc rất quan trọng, đó là Database per Service.
Điều này có nghĩa là mỗi service nên sở hữu database của chính nó.
Ví dụ, Auth Service có thể quản lý toàn bộ dữ liệu người dùng trong auth_db, Product Service sử dụng product_db để lưu sản phẩm, còn Order Service quản lý đơn hàng trong order_db.
Tại sao lại phải phức tạp như vậy?
Hãy thử tưởng tượng Product Service cần lấy thông tin người dùng. Nếu Product Service truy cập trực tiếp vào database của Auth Service thì hai service đã bắt đầu phụ thuộc vào nhau. Chỉ cần Auth Service thay đổi cấu trúc bảng dữ liệu, Product Service cũng sẽ bị ảnh hưởng.
Thay vào đó, Product Service nên gọi API của Auth Service hoặc nhận dữ liệu thông qua các sự kiện đồng bộ. Nhờ vậy, Auth Service hoàn toàn có thể thay đổi cấu trúc database mà không làm hỏng các service khác.
Đây cũng là một trong những khác biệt lớn nhất giữa Microservice và Monolithic.
Các service giao tiếp với nhau như thế nào?
Khi mỗi service đều hoạt động độc lập, chắc hẳn sẽ có người đặt câu hỏi rằng làm sao chúng có thể trao đổi dữ liệu với nhau.
Câu trả lời là thông qua API hoặc Message Queue.
Trong những trường hợp cần phản hồi ngay lập tức, một service sẽ gọi trực tiếp API của service còn lại. Ví dụ, khi Order Service muốn kiểm tra thông tin khách hàng trước khi tạo đơn hàng, nó có thể gửi một request đến Auth Service để lấy dữ liệu cần thiết.
Ngược lại, với những công việc không cần xử lý ngay lập tức, các service thường giao tiếp bằng sự kiện. Khi một đơn hàng được tạo thành công, Order Service chỉ cần phát ra sự kiện OrderCreated. Notification Service sẽ nhận sự kiện đó để gửi email, Inventory Service sẽ nhận để cập nhật tồn kho, còn Reward Service sẽ cộng điểm thưởng cho khách hàng.
Các service không cần biết nhau tồn tại nhưng vẫn có thể phối hợp với nhau một cách hiệu quả.
Có phải mỗi request đều phải gọi Auth Service để xác thực?
Đây là hiểu lầm mà rất nhiều người mới tiếp cận Microservice gặp phải.
Nhiều người nghĩ rằng nếu hệ thống có Auth Service thì mỗi khi Product Service hoặc Order Service nhận request, chúng đều phải gọi sang Auth Service để kiểm tra người dùng đã đăng nhập hay chưa.
Nếu làm như vậy, hệ thống sẽ rất chậm. Chỉ cần Auth Service gặp sự cố thì gần như toàn bộ hệ thống cũng sẽ bị ảnh hưởng.
Thực tế, hầu hết hệ thống hiện đại đều sử dụng JWT.
Sau khi người dùng đăng nhập thành công, Auth Service sẽ phát hành Access Token. Các service khác chỉ cần tự xác thực chữ ký của JWT bằng secret hoặc public key đã được cấu hình từ trước. Nếu token hợp lệ, service sẽ đọc được thông tin như User ID, Role hoặc Permission mà không cần gửi thêm bất kỳ request nào đến Auth Service.
Nhờ đó, tốc độ xử lý nhanh hơn rất nhiều, đồng thời giảm đáng kể áp lực cho Auth Service.
Auth Service lúc này chủ yếu chỉ xử lý các nghiệp vụ như đăng nhập, refresh token hoặc logout.
Microservice có nhanh hơn Monolithic không?
Câu trả lời là không.
Đây là điều khiến nhiều người bất ngờ.
Trong kiến trúc Monolithic, các module chỉ cần gọi hàm trực tiếp với nhau và cùng sử dụng một database. Mọi thứ đều diễn ra trong cùng một ứng dụng nên độ trễ rất thấp.
Trong khi đó, ở Microservice, mỗi lần một service muốn giao tiếp với service khác, dữ liệu phải được gửi qua mạng bằng HTTP, gRPC hoặc Message Queue. Quá trình này phát sinh thêm chi phí về kết nối, mã hóa dữ liệu và truyền tải.
Nếu một request phải đi qua nhiều service liên tiếp, thời gian phản hồi chắc chắn sẽ cao hơn so với Monolithic.
Tuy nhiên, Microservice không được tạo ra để tăng tốc độ xử lý của từng request. Giá trị lớn nhất của nó nằm ở khả năng mở rộng hệ thống.
Giả sử Product Service đang chịu tải rất lớn trong khi các service khác vẫn hoạt động bình thường. Với Microservice, bạn chỉ cần tăng thêm máy chủ cho Product Service mà không cần triển khai lại toàn bộ hệ thống. Điều này giúp tiết kiệm tài nguyên và dễ dàng đáp ứng lượng người dùng tăng cao.
Khi nào nên sử dụng Microservice?
Microservice phát huy hiệu quả khi hệ thống đủ lớn và có nhiều nhóm phát triển cùng làm việc.
Nếu mỗi nhóm chịu trách nhiệm cho một nghiệp vụ riêng, việc tách thành các service độc lập sẽ giúp quá trình phát triển, kiểm thử và triển khai diễn ra nhanh chóng hơn. Mỗi service cũng có thể được mở rộng theo đúng nhu cầu thực tế thay vì phải scale toàn bộ hệ thống.
Ngược lại, nếu dự án chỉ có một hoặc hai lập trình viên, việc áp dụng Microservice quá sớm thường khiến mọi thứ trở nên phức tạp hơn mức cần thiết. Bạn sẽ phải quản lý Docker, API Gateway, Message Queue, Logging, Monitoring, CI/CD và rất nhiều thành phần khác chỉ để vận hành một hệ thống chưa thực sự lớn.
Trong nhiều trường hợp, một Modular Monolith được thiết kế tốt lại là lựa chọn hợp lý hơn. Khi hệ thống phát triển đến một quy mô nhất định, bạn hoàn toàn có thể tách từng module thành Microservice mà không cần viết lại toàn bộ ứng dụng.
Kết luận
Microservice không đơn thuần là việc chia backend thành nhiều project. Cốt lõi của kiến trúc này là xây dựng những dịch vụ có khả năng hoạt động độc lập, triển khai độc lập và mở rộng độc lập.
Đây là một kiến trúc rất mạnh, nhưng cũng đi kèm với không ít thách thức. Việc lựa chọn Microservice hay Monolithic không phụ thuộc vào việc cái nào hiện đại hơn, mà phụ thuộc vào quy mô hệ thống, đội ngũ phát triển và bài toán thực tế mà bạn đang giải quyết.
Hiểu đúng Microservice sẽ giúp bạn biết khi nào nên áp dụng nó, và quan trọng hơn, biết khi nào không nên. Đó mới là dấu hiệu của một kiến trúc sư phần mềm thực thụ.
