Vấn đề của Microservices

Vấn đề

Microservices có lẽ không cần phải giới thiệu thêm nhiều nữa, trong vài năm đổ lại đây nó đang nổi lên như một hiện tượng. Microservices là một kỹ thuật phát triển phần mềm, cấu trúc một ứng dụng như một tập hợp các dịch vụ được ghép lỏng lẻo. Trái ngược với Microservices là Monolithic, nơi tất cả thành phần của ứng dụng được đặt chung với nhau thành một thể thống nhất.

Vào thời của tôi hoặc cũng có thể là nhiều anh chị đi trước được tiếp xúc với Monolithic là chính. Nếu như bạn đọc chưa biết, trước kia tôi vốn là một lập trình viên PHP. PHP có rất nhiều Framework, chúng được tổ chức theo cách đặt tất cả logic xử lý ứng dụng vào trong đó. Một và chỉ một dự án là đủ. Sau khi sửa, tải nó lên Hosting là bản cập nhật có hiệu lực ngay lập tức.

Khi đi thực tập ở công ty trong vai trò JavaScript. Tôi được tham gia vào nhiều dự án thực tế và hết sức ngạc nhiên khi thấy ứng dụng lúc này không chỉ đơn thuần triển khai bằng một bước như trước nữa, mà đó là nơi có chứa những mảnh ghép rời rạc từ nhiều phần tạo nên hệ thống. Từng thành phần giao tiếp với nhau thông qua một cách nào đó như gọi API hoặc lắng nghe Message Queue. Khi tìm hiểu sâu hơn, tôi biết đây là một lối kiến trúc mang hơi hướng của Microservices

Microservices hiện đại. Điều đó đúng. Tôi đã thấm nhuần cái tư tưởng của Microservices là hãy biến hệ thống của bạn trở nên lỏng lẽo nhất có thể. Bất cứ thành phần nào cũng có thể tách ra, thay bằng thành phần khác. Mỗi mảnh ghép đảm nhiệm một nhiệm vụ duy nhất, nằm độc lập với nhau, khiến cho hệ thống trở nên minh bạch hơn bao giờ hết.

Sau này khi chuyển công ty, hầu hết là những doanh nghiệp còn non trẻ hay còn gọi là Startup. Kiểu kiến trúc này vẫn được ưa chuộng. Từ đó mình càng được tiếp xúc nhiều hơn. Mưa dần thấm lâu, trời sinh ra Microservices tại sao còn sinh ra Monolithic? Chẳng phải một kiến trúc rõ ràng như Microservices đã đánh bại Monolithic ngay bây giờ, ngay lúc này rồi sao? Microservices đang đánh bay đi sự lề mề, ục ịch của Monolithic.

Cho đến một ngày...

Đó là thời gian tôi bắt tay vào xây dựng cho mình một trang blog. Bạn nghĩ như thế nào nếu một anh thợ phụ đã có gạch và vữa trong tay, chuẩn bị xây ngôi nhà đầu tiên cho chính mình? Thứ duy nhất mà anh thiếu chắc hẳn là kinh nghiệm. Sau lần xây dựng trang blog theo lối kiến trúc Microservices, sau đó là quá trình đập đi xây lại theo phong cách Monolithic. Tôi như tự tay tát vào mặt mình về những tuyên bố hùng hồn ở trên, mới vỡ lẽ ra một sự thật rằng Microservices không phải là viên đạn bạc.

Trong bài viết này tôi sẽ trình bày lại với bạn đọc về quãng thời gian u tối do áp dụng Microservices vào dự án cá nhân của mình. Dĩ nhiên không có ý đánh đồng rằng Microservices là tệ. Nó chỉ tệ khi gây cản trở đến quá trình vận hành. Hy vọng qua bài viết này bạn đọc sẽ hình dung ra thông điệp mà tôi muốn truyền đạt và mong nhận được những lời khuyên thích đáng.

Từ Monolithic sang Microsevice

Để xây dựng ứng dụng theo kiến trúc Microsevice nói tóm gọn là tách biệt các thành phần xử lý logic thành các khối riêng biệt nếu có thể. Triển khai chúng bằng bất kỳ cách nào, bất kỳ ngôn ngữ nào, cho chúng giao tiếp với nhau thông qua một cách nào đó ví dụ như HTTP, gRPC, Webhook...

Hệ thống mà tôi xây dựng chia thành nhiều thành phần nhỏ. Trong đó có thể kể đến giao diện blog (page), trang quản trị (admincp), api, một service quản lý hình ảnh (image), một service xử lý tác vụ chạy ngầm (background) và một vài cái lặt vặt nữa không nhớ rõ lắm. Các thành phần chủ yếu giao tiếp với nhau thông qua REST API. Bạn biết không, sau khi làm xong tất cả mọi thứ, tôi đặt chúng vào trong cùng một máy chủ, trong các container của Docker. Bằng cách nào đó, nghe nó như Microsevice nhưng lại rất Monolithic.

Trong quá trình vận hành, ưu điểm lớn nhất nhìn thấy là sự minh bạch. Các thành phần được tách biệt với nhau rất dễ dàng để nhận biết hoặc thêm thắt tính năng. Nhưng khi làm đủ lâu, sự thật khủng khiếp mới dần hé lộ.

Thứ nhất là quá trình gỡ lỗi hết sức khó khăn. Các mấu nối giữa các hệ thống lỏng lẻo nhưng phụ thuộc vào nhau. Nếu trong quá trình gỡ lỗi, nghi ngờ chỗ nào, thành phần nào có khả năng lỗi nhất buộc chúng ta phải kết nối chúng lại với nhau để tái hiện lỗi. Hay nói cách khác là bạn cần phải chuẩn bị đầy đủ service, khởi động chúng cùng với nhau để bắt đầu. Lặp lại quy trình này liên tục giữa các service cho đến khi tìm thấy lỗi.

Thứ hai là vấn đề truy vết. Nhiều người sẽ nghĩ cách tốt nhất là ghi lại nhật ký (logs) hệ thống. Nhưng quản lý logs lại là công việc ở một phạm trù khác. Bạn cần quản lý được đống nhật ký đó và biết cách móc nối chúng lại với nhau để tìm cho mình được thông tin có giá trị. Nếu không tất cả chỉ giống như là viên thuốc giả dược. Cứ ghi lại tất cả những gì xảy ra nhưng lại không biết cách làm thế nào để phát hiện được chúng. Nếu sau này dữ liệu nhiều lên còn phát sinh thêm nhiều vấn đề khác như lưu trữ và rác.

Quản lý các service này không hề dễ dàng với nguồn nhân lực hạn chế. Nếu hệ thống có 2 services, không thành vấn đề. Nhưng sau đó nó mở rộng ra đến 3, 4, 5... thậm chí là đến hàng chục services thì câu chuyện lúc đó sẽ như thế nào? Hãy tưởng tượng công việc thường ngày bạn làm trên một dự án? Từ quản lý mã nguồn, tài liệu, phiên bản, các gói phụ thuộc... cho đến quá trình CI/CD, triển khai. Thì ngần ấy công việc được nhân lên tương ứng với số lượng dự án mà bạn đang có. Tin tôi đi, điều đó như là một cơn ác mộng vậy.

Một ý nữa là nó phức tạp hơn mức cần thiết. Tránh rơi vào cái bẫy mọi thứ nên hoàn hảo ngay từ đầu. Hãy thiết kế một hệ thống phù hợp với tình hình hiện tại chứ không phải là để chịu tải được hàng triệu người cùng lúc, trong khi thực tế chúng ta không có nổi 100 lượt xem hàng ngày. Hãy đối diện với sự thật và đừng gây thêm gánh nặng cho mình.

Từ Microsevice sang Monolithic

Với những lý do trên khiến tôi tiến tới đập đi xây lại blog của mình sau nhiều lần đắn đo suy nghĩ. Gộp tất cả những thứ đang có thành một khối thống nhất, như thể đó là Monolithic. Quả thật đây chính là điều đúng đắn nhất mà nên làm sớm hơn.

Monolithic tỏ ra hợp lý với cách vận hành cá nhân, mà theo tôi nghĩ nó cũng phù hợp với một đội nhỏ. Giờ đây tôi chỉ cần tập trung vào một dự án duy nhất. Dễ gỡ lỗi, dễ truy vết và không mất thêm thời gian để quản lý dự án theo cấp số nhân nữa. Vậy mới thấy Microservices không phải là viên đạn bạc và Monolithic là một giải pháp phù hợp hơn trong hoàn cảnh này.

Đập đi xây lại blog là một quá trình tốn nhiều thời gian. Nhiều người có thể nghĩ việc tổ chức theo Microservices trước đó là quãng thời gian vô ích, nhưng đối với tôi nó lại là một khoảng thời gian quý giá để rút ra được nhiều bài học. Một trong số đó là nhìn nhận ra những mặt tốt/xấu của Microservices.

Tóm lại là

Microservices là một kỹ thuật phát triển phần mềm hiện đại, nhưng không dành cho tất cả mọi người. Việc phát triển ứng dụng theo kiểu kiến trúc này đòi hỏi rất nhiều nỗ lực vận hành, kiểm soát hệ thống. Nếu không bạn chẳng thực sự biết điều gì đang xảy ra bên trong ứng dụng của mình cả. Nếu bạn chỉ có một mình hoặc một đội nhỏ, hãy thử cân nhắc sang Monolithic - truyền thống, đơn giản và dễ tiếp cận.

Bên cạnh đó tôi tin là vẫn có rất nhiều người biết cách vận hành hệ thống microservices của mình. Hãy chia sẻ lại câu chuyện của bạn xuống phần bình luận cho tôi và mọi người cùng biết nhé. Xin cảm ơn.