Chúng ta đã nghe rất nhiều về Microservice, từ sự kì diệu của nó cho đến những lợi ích mà nó đem lại khi so sánh với mô hình Monolithic. Tuy nhiên chúng ta đôi khi lại bỏ qua những bất tiện và khó khăn khi triển khai Microservice và đặc biệt là làm cách nào, làm như thế nào để giải quyết nó. Với lý do đó, mình sẽ viết một series liên quan đến Microservice với các chủ đề dưới đây:
Microservice 001: Monolithic và sự hình thành của Microservice
Microservice 002: Bài toán và cách triển khai Microservice P1
Microservice 003: Bài toán và cách triển khai Microservice P2
Microservice 004: Một vài vấn đề cần xử lý trong mô hình Microservice
Microservice 005: Giao tiếp giữa các service trong Microservice P1
Microservice 006: Giao tiếp giữa các service trong Microservice P2
Microservice 007: Giao tiếp giữa các service trong Microservice P3
Microservice 008: Distributed transaction với Saga pattern P1
Microservice 009: Distributed transaction với Saga pattern P2
Hiện tại nếu search trên google thì các bạn sẽ tìm được rất nhiều các bài viết liên quan đến chủ đề này rồi. Tuy nhiên mình nghĩ với series này các bạn sẽ thấy một góc nhìn khác gần gũi hơn và có hệ thống. Hãy góp ý, chỉnh sửa và bổ sung nhé. Thank you all.
1. Monolithic Architecture
Khi học trên ghế nhà trường, chúng ta đã rất quen thuộc với việc phát triển sản phẩm với mô hình Monolithic, nói nôm na là toàn bộ code được đóng gói phát triển trên duy nhất một project. Team cũng chỉ có một mình hoặc cùng lắm là có thêm vài chị em bạn dì nữa. Mỗi khi giảng viên có thêm một yêu cầu nào đó, team sẽ ngồi hì hục chia task và thực hiện thêm mới tính năng, build lại toàn bộ project và thấy cuộc đời vẫn màu hồng, cũng không có gì gọi là phức tạp lắm, mọi thứ vẫn thật perfect. Và chúng ta sẽ có một vài kết luận như sau:
- Quá trình phát triển sản phẩm đơn giản, cập nhất code, build và deploy trên duy nhất một project.
- Phát triển trên một ngôn ngữ cụ thể nên chỉ cần nắm sâu và chắc ngôn ngữ đó là giải quyết được hầu hết các vấn đề.
2. Real life
Cuộc đời lại không màu hồng như khi ta còn cắp sách tới trường. Các dự án thực tế thì luôn có xu hướng thay đổi liên tục, requirement luôn được thêm mới, từ đó dẫn đến việc team size tăng lên, thêm người mới vào nhưng họ lại chưa có cái nhìn đủ sâu sắc về hệ thống. Và hãy thử tưởng tượng rằng 100 developers (dự án siêu to khổng lồ) cùng phát triển trên một project duy nhất thì có vấn đề gì:
- Project code bằng Java nhưng không thể tuyển đủ Java developer.
- Đảm bảo tất cả các developer phải hiểu về hệ thống để có thể maintain/implement/fix bug, tuy nhiên thực tế source code quá lớn và chi phí (time, cost...) để làm những điều kể trên không hề nhỏ.
- Với source code lớn như vậy thì việc conflict code diễn ra hàng ngày hoặc hàng giờ. Và thời gian thay vì để implement thì chúng ta sẽ ngồi resolve confict. Có bạn sẽ nói rằng mỗi ông một task, cố gắng chia task để khi implement không gặp conflict, nhưng chắc chắn là cuộc đời lại không màu hồng như thế.
Sơ sơ qua thì đã có vài hạn chế khi triển khai Monolithic Architecture nhưng chủ yếu là về mặt con người và cách hoạt động. Chúng ta sẽ tiếp tục bàn đến khó khăn về mặt technical sau đây:
- Khi update code (thêm hoặc xóa chức năng), chúng ta phải thực hiện việc deploy lại toàn bộ hệ thống dẫn tới giảm tính availability. Tuy nhiên theo quan điểm của mình, thực tế khi triển khai chúng ta luôn deploy từ 2 nodes trở lên và sẽ thực hiện deploy từng node một nên nó không phải vấn đề không thể giải quyết.
- Khi server có vấn đề thì toàn bộ hệ thống sẽ sập. Một lần nữa, thực tế triển khai chúng ta sẽ deploy nhiều nodes nên việc một node sập cũng sẽ không ảnh hưởng lớn (trừ khi nó đang xử lý business logic, với trường hợp này thì kiến trúc nào cũng sẽ gặp khó khăn nhất định không chỉ riêng Monolithic). Nếu đảm bảo code đủ tốt thì sẽ không cần quá lo lắng về vấn đề này.
- Vì toàn bộ hệ thống sử dụng chung một ngôn ngữ (Java, C#, Python, Ruby...) nên chúng ta sẽ phụ thuộc toàn bộ vào ngôn ngữ đó. Sẽ xảy ra trường hợp là tính năng này nếu implement với Golang sẽ rất mạnh nhưng ta không thể làm điều đó vì đang sử dụng C#.
- Khi áp dụng scale (deploy multiple nodes) như mình đề cập ở trên thì sẽ có thêm một vấn đề đó là có những thành phần không bắt buộc phải scale nhưng vì áp dụng Monolithic nên phải scale toàn bộ hệ thống dẫn đến việc lãng phí tài nguyên.
3. Mircoservice Architecture
Từ những vấn đề kể trên mà Microservice Architecture ra đời nhằm giải quyết vấn đề cơ bản đầu tiên đó là team size lớn (tất nhiên với các tính năng phức tạp thì mới dẫn đến việc team có nhiều member). Giả sử chúng ta có bài toán E-commerce khổng lồ bao gồm rất nhiều các chức năng từ đặt hàng, kiểm tra kho hàng, thanh toán (nhiều cổng thanh toán khác nhau...), theo dõi đơn hàng, hủy đơn hàng, chat với hệ thống, chat với người bán, review, comment sản phẩm... Áp dụng Microservice Architecture, việc đơn giản nhất mà kiến trúc này muốn nói đến đó là chia nhỏ bài toán thành những bài toán nhỏ hơn để dễ dàng hơn trong việc quản lý, phát triển sản phẩm (cụ thể, có những cách nào để chia bài toán thì mình sẽ đề cập đến trong các bài sau). Với tư tưởng giải quyết đó, chúng ta đã chia được từ bài toán E-commerce với 50 developers ra thành các bài toán nhỏ hơn với team size nhỏ hơn, ví dụ:
- Order service: 10 developers. Giải quyết phần order của khách hàng.
- Payment service: 10 developers. Giải quyết phần thanh toán order của khách hàng.
- Inventory service: 10 developers. Giải quyết phần kiểm tra tồn kho xem order của khách có thể thực hiện được hay không.
- Và một vài service nữa tùy thuộc theo cách phân chia bài toán.
Tiếp tục, team Order service mất đi một vài nhân tố (việc thường xuyên xảy), một số anh em theo vợ bỏ cuộc chơi. Team phải tuyển thêm một vài bạn developer, các bạn mới chỉ cần nắm sơ bộ tổng quan về hệ thống, tiếp theo đó là đọc source code, tài liệu của Order service team để biết được việc mình cần làm là gì. Như vậy giảm thiểu rất nhiều thời gian training và đọc hiểu tài liệu, rút ngắn ít nhiều cost của dự án. Ai mà chả thích điều đó cơ chứ. Vậy là thêm một vấn đề được giải quyết.
Ok, vậy là một vài vấn đề liên quan đến con người và cách tổ chức đã được giải quyết. Tuy nhiên không thể thiếu được những ưu điểm về mặt technical đem lại, phần này rất dễ để tìm kiếm tuy nhiên mình sẽ liệt kê ở phần tiếp theo để chúng ta có một góc nhìn đầy đủ nhất.
4. Monolithic vs Microservice
Nhiệm vụ chính của phần này là tổng kết lại sự khác biệt cũng như thuận lợi, khó khăn của cả hai kiến trúc Monolithic và Microservice.
4.1 Monolithic Architecture
Ưu điểm
- Đơn ngôn ngữ nên phát triển đơn giản, source code tập trung. Có rất nhiều framework hỗ trợ.
- Việc debug và test dễ dàng hơn so với Microservice vì chỉ trên một IDE, một project.
- Performance tốt hơn nếu được triển khai đúng đắn (code xịn). Lý do: giao tiếp giữa các service trong Mircoservice sẽ có độ trễ nhất định (bài sau).
- Yêu cầu về infrastructure không có gì phức tạp vì chỉ có duy nhất một service.
Nhược điểm
- Theo thời gian, source code sẽ phình lên nhanh chóng (requirement change, refactor, fix bug...) dẫn đến việc người mới mất nhiều thời gian hơn để hiểu.
- Không tận dụng được lợi thế của các ngôn ngữ khác, tốn chi phí để thay đổi ngôn ngữ nếu dự án quá lớn.
- Deployment sẽ tốn nhiều cost, source code lớn, thời gian deploy dài.
- Scale up đơn giản nhưng tốn chi phí cho những phần không cần scale trong hệ thống.
4.2 Microservice Architecture
Ưu điểm
- Vì chia thành các bài toán nhỏ hơn nên source code cũng nhỏ hơn, dễ dàng thay đổi cập nhật. Vòng đời phát triển sản phẩm nhanh hơn.
- Deployment nhanh hơn, độc lập với các service. Các team sẽ phát triển nhanh hơn và ít phụ thuộc vào nhau.
- Các issue nếu xảy ra trong 1 service thì sẽ có ít ảnh hưởng hơn tới các service còn lại. Các service còn lại vẫn hoạt đồng bình thường (tuy nhiên không đảm bảo hệ thống hoạt động đúng đắn, phải có các giải pháp để xử lý những vấn đề này).
- Tận dụng được điểm mạnh đa ngôn ngữ để áp dụng cho từng service một cách phù hợp.
Nhược điểm
- Rất phức tạp để thiết kế và triển khai.
- Performance chậm hơn do việc communicate giữa các service.
- Yêu cầu kiến thức về domain, business tốt để phân chia thành các service nhỏ sao cho phù hợp. Yêu cầu kĩ năng và kinh nghiệm của team phải cực tốt.
- Vấn đề liên quan đến vận hành và xử lý, nếu một hoặc một vài service down thì sẽ giải quyết như thế nào.
- Yêu cầu infrastructure rất phức tạp. Không chỉ quản lý các service trong Microservice mà phải quản lý cả các hệ thống messaging (liên quan đến việc giao tiếp giữa các service).
5. Khi nào nên sử dụng kiến trúc nào
Đúc kết lại thì có vẻ như đây là phần quan trọng nhất. Chúng ta có thể dựa trên một vài điều kiện dưới đây để quyết định xem nên áp dụng mô hình nào.
5.1 Monolithic Architecture
- Yêu cầu của bài toán nhỏ, khả năng mở rộng trong tương lai ít, đối tượng người dùng không nhiều.
- Team size nhỏ, kinh nghiệm và kiến thức chưa nhiều.
- Yêu cầu phát triển thần tốc, càng nhanh càng tốt.
5.2 Microservice Architecture
- Team size lớn và rất lớn, đủ nguồn nhân lực có kiến thức và kinh nghiệm để phát triển.
- Bài toán lớn, khả năng mở rộng và phát triển mạnh mẽ, đối tượng người dùng là rất nhiều hoặc có tiềm năng phát triển cực lớn trong tương lai.
5.3 Kết luận
No silver bullet, sẽ không có mô hình nào có thể giải quyết triệt để được những hạn chế của mô hình kia. Nó sẽ tùy thuộc và cơ cấu tổ chức, bài toán cũng như kinh nghiệm của team để lựa chọn kiến trúc cho phù hợp. Chúng ta nói về Microservice rất nhiều, nhưng trào lưu thực tế hiện nay, các nhà phát triển lại đang quay trở lại với mô hình Monolithic vì những ưu điểm của nó và những nhược điểm của Microservice. Ý kiến của bạn về vấn đề này như thế nào, hãy để lại bình luận phía dưới nhé.