Bài viết nằm trong series Microservice: What, when and how?
1) Monolithic Architecture
Thời còn sinh viên, chúng ta đã 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 và phát triển trên duy nhất một project. Team chỉ có một mình hoặ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, team sẽ ngồi hì hục chia task và thực hiện implement tính năng, build lại project, chạy trên local và thấy cuộc đời vẫn màu hồng, chẳng có gì magic ở đây cả, mọi thứ vẫn thật perfect. Từ đó, chúng ta có một vài kết luận khi triển khai Monolithic Architecture như sau:
- Quá trình phát triển sản phẩm đơn giản, thay đổi code, build và deploy trên duy nhất một project. Không cần tốn nhiều công để set up môi trường.
- 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ế luôn có xu hướng vận động không ngừng, requirement thay đổi mỗi ngày. Từ đó dẫn đến việc team size tăng lên, có thêm người mới nhưng họ lại chưa có cái nhìn đủ sâu sắc về hệ thống. Hãy thử tưởng tượng rằng 50 developers (dự án siêu to khổng lồ) cùng phát triển trên một project duy nhất thì sẽ có vấn đề gì xảy ra. Đại loại sẽ là:
- Project code bằng Java nhưng không thể tuyển đủ Java developer. Căng rồi đây, khả năng 1 ông phải làm công việc của 2, 3 người.
- Về mặt business, phải đảm bảo tất cả các dev hiểu về hệ thống để có thể maintain/implement/fix bug nhanh chóng và chính xác. Tuy nhiên thực tế source code quá lớn và chi phí để làm những điều kể trên không hề nhỏ.
- Với source code lớn như vậy, việc conflict code diễn ra hàng ngày hoặc hàng giờ. 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 đâu có đơn giản và dễ dàng như vậy.
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 thức 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, 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 sẵn sàng (availability). Tuy nhiên, thực tế khi triển khai chúng ta luôn deploy nhiều instance (horizontal scale) và sẽ thực hiện deploy từng node một nên đây 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, khi triển khai sẽ có nhiều instance nên việc một node sập cũng không ảnh hưởng lớn, các node còn lại vẫn có thể xử lý được request (trừ khi nó đang xử lý business logic, với trường hợp này thì bất kì kiến trúc sẽ gặp khó khăn 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ữ nên 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 lại không làm điều đó vì đang sử dụng C#.
- Khi áp dụng horizontal scale (deploy multiple instance) sẽ phát sinh thêm 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. Lãng phí tài nguyên là tốn tiền rồi, không ai muốn như thế cả.
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. Giả sử chúng ta có 50 developers và 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, theo dõi/hủy đơn, chat với seller, review/comment sản phẩm... Áp dụng Microservice, ưu điểm đầu tiên đó là chia bài toán ban đầu 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 có thể chia như sau:
- Order service: 10 developers. Giải quyết phần order.
- Payment service: 10 developers. Giải quyết phần thanh toán.
- Inventory service: 10 developers. Giải quyết phần kiểm tra lượng hàng còn lại xem có tạo được order không.
- Một vài service nữa tùy thuộc theo cách phân chia bài toán...
Sau một khoảng thời gian, một vài anh em thuộc team Order service theo bồ bỏ cuộc chơi (việc thường xuyên xảy). Team phải tuyển thêm người, 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 team để biết hiểu được hệ thống hoạt động như thế nào, implement/refactor ra sao. Từ đó rút ngắn thời gian training, giảm cost của dự án, thêm một vấn đề được giải quyết.
Ok, vậy là 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 mà Microservice đem lại, chúng ta có thể tìm kiếm hàng loạt trên google, mình sẽ chỉ điểm qua một vài sự khác biệt lớn ở phần tiếp theo. Nhâm nhi li trà và tiếp tục thôi.
4) Monolithic vs Microservice
Mục đích chính của phần này là tổng kết lại sự khác biệt, 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 đ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, các bài toán chúng ta phải xử lý khi làm việc với Microservice thật sự rất phức tạp. Ý 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é.