- "Monolith > apps > services > microservices"
- Thứ nhất, đây không phải quy tắc mà chỉ là quan điểm của tôi. Những người từng xây dựng hệ thống phân tán quy mô lớn đều biết rằng thực tế không vận hành đúng y như vậy, và phải thích nghi
- Thứ hai, các giai đoạn rất quan trọng
- Nếu là công ty 5-50 người thì cứ dùng Monolith
- Nếu là công ty 10.000 người thì có lẽ sẽ có đủ mọi thứ ở trên. Nhưng nếu nói về những gì tôi nghĩ khác trước đây thì...
Trước hết là định nghĩa
- monolith - xyz.com
- apps - abc.xyz.com
- services - hỗ trợ app/monolith, hạ tầng cốt lõi, các chức năng tuân thủ cốt lõi, có thể không do đội app viết ra (được đội hạ tầng vận hành)
- microservices - vài trăm dòng code, phần lớn chỉ dùng một lần, lẽ ra có thể/nên là thư viện hoặc SDK
Why ? : Về cơ bản là vì "Speed & Risk"
- #1 Toàn bộ đội phát triển cùng làm trong một ứng dụng lớn duy nhất (hãy tưởng tượng toàn bộ site là một app Rails) sẽ dễ hơn
- #2 Khi tăng trưởng, hệ thống phân tán mà bạn sớm muộn cũng sẽ có vốn dĩ đã khó suy luận, ngay cả khi không có hàng trăm microservice vốn tự mang rủi ro
- #3 Nếu đi hoàn toàn theo hướng micro thì bạn sẽ phải đưa vào các khái niệm mới để xử lý sự mở rộng thiếu kiểm soát
- #4 Dịch vụ hạ tầng tự chế (bespoke) hoặc microservice là khái niệm cực đoan của nợ kỹ thuật. Code cũng là nợ, nhưng service là phiên bản cực đoan hơn của nó. Hãy nghĩ về điều đó có nghĩa là gì. Hãy biến nó thành điểm đòn bẩy
- Các kỹ sư hệ thống phân tán ghét sự trùng lặp, nên nếu có gì đó được làm ở nhiều nơi thì họ sẽ nghĩ: "hãy tách cái này ra và làm thành một microservice"
- Về lý thuyết thì đúng, và đến khoảng mười hay hai mươi cái thì vẫn ổn. Nhưng nếu vượt quá vài chục, hoặc được dùng vượt ra ngoài một công ty lớn, thì đó không còn là vấn đề kỹ thuật mà là vấn đề tổ chức
- Điều tôi nói có thể nghe giống một kiểu nhị nguyên sai lầm, nhưng trên thực tế microservice vừa có các thách thức kỹ thuật, vừa có nhiều vấn đề tổ chức hơn
Điều tôi lo ngại là
- #1 (trừ khi được dẫn dắt bởi một CEO xuất thân IT theo cách khá đặc biệt) hạ tầng luôn bị đẩy xuống thấp trong thứ tự ưu tiên
- #2 Nếu có quá nhiều service thì thường sẽ phát sinh vấn đề về quyền sở hữu và ranh giới
- #3 Người ta lại đưa thêm nhiều công cụ hơn để xử lý vô số microservice
- #4 Quan trọng nhất là từng microservice lẽ ra nên là thư viện hoặc SDK lại tạo thêm rủi ro cho production
Nhìn chung, điều tôi khuyến nghị là
- #1 Giữ Monolith càng lâu càng tốt nếu có thể
- #2 Hãy bắt đầu service từ những gì hạ tầng cần, đừng bắt đầu từ phía phát triển ứng dụng
- #3 Nếu phải tách Mono ra, hãy phân rã thành các app lớn chứ không phải các service nhỏ
- #4 Hãy coi mỗi app mới như một bức tường ảo bên trong công ty
- #5 Nếu có thể, hãy ưu tiên thư viện thay vì microservice
13 bình luận
Phần cuối nói về những lo ngại và các khuyến nghị khiến tôi khá đồng cảm.
Thực ra quy mô công ty hay quy mô dịch vụ đều có cùng bối cảnh như vậy, và sẽ đến lúc buộc phải tách nhỏ ra, nên tôi cảm thấy cần có một sự phán đoán thật xuất sắc để chuẩn bị trước cho thời điểm đó.
Chẳng phải điều đó nên phụ thuộc vào quy mô hệ thống chứ không phải quy mô công ty sao? Hay là mình đã hiểu sai về MSA?
Tôi trước hết đồng ý với ý kiến ở phần bình luận bên trên rằng
có lẽ vấn đề không nằm ở microservice mà là ở việc mở rộng dịch vụ một cách thiếu kiểm soát?
và có vẻ như khi công ty càng lớn thì những nhược điểm vốn có của monolith như vấn đề triển khai + quản lý nhánh càng bộc lộ quá rõ, nên cần phải lựa chọn thật tốt sự đánh đổi giữa chi phí và năng suất.
Bài viết hay quá. Cảm ơn bạn.
Có vẻ khá giống với tranh luận về tầm quan trọng của design pattern nhỉ?
Design pattern là các mẫu code được đúc kết ra trong quá trình giải quyết nhiều vấn đề khác nhau mà....
Dù sao thì cũng phải tùy tình huống, được vận dụng và áp dụng theo nhu cầu cần thiết mà.....
Nhưng cũng có những người thường xem design pattern như đáp án mẫu, cho rằng nó là thứ bắt buộc và quá sa đà vào nó...
Dạo này với cả MSA cũng có vẻ tương tự, ngày càng có nhiều người kiểu cứ mặc định là phải MSA....
Nghe như kiểu tranh luận con gà có trước hay quả trứng có trước vậy.
Có lẽ vấn đề không phải ở microservices, mà là ở việc mở rộng dịch vụ một cách thiếu kiểm soát thì đúng hơn?
Tôi nghĩ điều quan trọng là phải có sự cân bằng phù hợp.
Khi chuyển sang microservice, rất có thể sẽ dẫn đến việc tính năng mới = một microservice mới,
nên có lẽ việc quản lý sẽ ngày càng trở nên khó khăn hơn.
Điều này làm tôi nhớ đến bài viết
Goodbye Microservicestừng được đăng trên blog kỹ thuật của Segment.Dù Segment cũng xử lý lượng dữ liệu rất lớn theo thời gian thực vì là một CDP, họ vẫn đã chuyển từ kiến trúc Microservices sang Monolith và tổng hợp lý do trên blog. Tôi nghĩ bài đó cũng có nhiều điểm giao thoa với bài này :)
https://segment.com/blog/goodbye-microservices/
Nhìn chung khá trùng với suy nghĩ của tôi.
Công ty chúng tôi có 5 lập trình viên, nên tôi nghĩ hiện tại vẫn đúng khi theo hướng monolith (Ruby on Rails).
Giống như bài viết trên, nếu sau này trở thành một dự án có từ 50 người trở lên cùng phát triển đồng thời, lúc đó có lẽ chúng tôi sẽ làm monolith thứ hai.
Nếu là công ty có 5-50 người thì cứ dùng Monolith thôi << ý này là nói tổng số nhân sự chứ không phải số lượng lập trình viên đúng không?
Có vẻ là đang nói về quy mô công ty~
Nếu có thể thì hãy giữ kiến trúc monolith càng lâu càng tốt < hoàn toàn đồng cảm. Khi tách ra, chi phí vận hành và bảo trì tăng lên rất nhiều.
Tôi nghĩ đây là một bài viết như một phản ứng ngược trước việc MSA đang dần bị giáo điều hóa, và ở khía cạnh đó, nó có ý nghĩa nhất định.