HomeOur Team
Kiến trúc Monolithic và Microservices
Solutions
Kiến trúc Monolithic và Microservices
manh.nguyen
manh.nguyen
October 27, 2020
4 min

Khi phát triển một ứng dụng phía máy chủ, bạn có thể thiết kế theo “Monolithic” hoặc “Microservices”. Chúng ta cùng tìm hiểu những ưu và nhược điểm của 2 kiến trúc này nhé.

Kiến trúc Monolithic

Kiến trúc Monolithic là mẫu thiết kế đơn giản, được sử dụng nhiều nhất lập trình web hiện nay. Ứng dụng được đóng gói và triển khai như một khối duy nhất.

Ưu điểm :

  • Đơn giản để phát triển
  • Đơn giản để kiểm tra
  • Đơn giản để triển khai: Bạn chỉ cần coppy ứng dụng đã đóng gói vào 1 máy chủ
  • Dễ scale vì chúng ta có thể có nhiều instance cho load banlancer.

Nhược điểm:

  • Cách tiếp cận đơn giản này có một giới hạn về kích thước và độ phức tạp.
  • Ứng dụng quá lớn và phức tạp sẽ khó để nâng cấp và phát triển.
  • Kích thước của ứng dụng lớn có thể làm chậm thời gian khởi động.
  • Bạn phải triển khai lại toàn bộ ứng dụng trên mỗi bản cập nhật.
  • Việc triển khai liên tục rất khó.
  • Các ứng dụng nguyên khối cũng có thể khó mở rộng quy mô khi các mô-đun khác nhau có các yêu cầu về tài nguyên xung đột.
  • Một vấn đề khác với các ứng dụng nguyên khối là độ tin cậy. Lỗi trong bất kỳ mô-đun nào (ví dụ: rò rỉ bộ nhớ) có thể làm hỏng toàn bộ quá trình. Hơn nữa, vì tất cả các phiên bản của ứng dụng đều giống nhau, lỗi đó sẽ ảnh hưởng đến tính khả dụng của toàn bộ ứng dụng.
  • Các ứng dụng nguyên khối có một rào cản đối với việc áp dụng công nghệ mới. Vì những thay đổi trong khuôn khổ hoặc ngôn ngữ sẽ ảnh hưởng đến toàn bộ ứng dụng nên nó cực kỳ tốn kém cả về thời gian và chi phí.

Kiến trúc microservice (Mocroservice architecture)

Nhưng năm gần đây, loại kiến trúc này đang dần trở nên phổ biến nhờ khả năng mudule hóa và khả năng mở rộng. Kiến trúc Microservices chia ứng dụng của bạn thành một tập hợp các service nhỏ, được kết nối với nhau thay vì xây dựng một dứng dụng nguyên khối duy nhất. Mỗi microservice chứa một logic nghiệp vụ khác nhau.

Ưu điểm:

  • Các component có kết nối lỏng lẻo dẫn đến dễ cách ly, dễ test và khởi động nhanh.
  • Vòng đời phát triển nhanh hơn. Tính năng mới được phát triển nhanh hơn và tính năng cũ được cấu trúc lại dễ hơn.
  • Các service có thể deploy độc lập nên ứng dụng dễ đọc, dễ tạo các bản vá hơn.
  • Những issue, ví dụ liên quan đến memry leak một trong các service, bị cô lập và có thể không làm sập ứng dụng.
  • Việc áp dụng các công nghệ mới dễ hơn. Các component có thể được nâng cấp độc lập với nhau.
  • Các mô hình scale phức tạp và hiệu quả hơn có thể được thiết lập. Các service quan trọng có thể scale hiệu quả hơn. Các component riêng sẽ khởi động nhanh hơn và cải thiện thời gian khởi động của cả hệ thống.
  • Các team tham gia sẽ ít phụ thuộc lẫn nhau. Kiến trúc này rất thích hợp cho các đội Agile.

Nhược điểm:

  • Phức tạp hơn về mặt tổng thể vì các component khác nhau có các stack công nghệ khác nhau nên buộc team phải tập trung đầu tư thời gian để theo kịp công nghệ.
  • Khó thực hiện test end-to-end và integration test vì có nhiều stack công nghệ khác nhau.
  • Deploy toàn bộ ứng dụng phức tạp hơn vì có nhiều container và nền tảng ảo hóa liên quan.
  • Ứng dụng được scale hiệu quả hơn nhưng thiết lập nâng cấp sẽ phức tạp hơn vì nó sẽ yêu cầu nâng cao nhiều tính năng như truy tìm dịch vụ (service discovery), định tuyến DNS,…
  • Yêu cầu một team-size lớn để maintain ứng dụng vì có nhiều component và công nghệ khác nhau.
  • Các thành viên trong team chia sẻ các skill khác nhau dựa trên component họ làm nên sẽ tạo ra sự khó khăn khi thay thế và chia sẻ kiến thức.
  • Stack công nghệ phức tạp và khó để học hơn.
  • Thời gian phát triển ban đầu là chậm nên thời gian để có thể làm marketing lâu hơn.
  • Yêu cầu cơ sở hạ tầng phức tạp. Thông thường sẽ yêu cầu nhiều container (Docker) và nhiều máy JVM để chạy.

Khi nào sử dụng ?

Kiến trúc một khối:

  • Phạm vi ứng dụng là nhỏ và được xác định rõ. Bạn chắc chắn ứng dụng sẽ không phát triển mạnh về các tính năng. Ví dụ: blog, web mua sắm trực tuyến đơn giản, ứng dụng CRUD đơn giản…
  • Team-size nhỏ, thường ít hơn 8 người.
  • Mặt bằng kỹ năng của các thành viên trong team thường không cao.
  • Thời gian để có thể marketing là quan trọng.
  • Bạn không muốn mất thời gian cho cơ sở hạ tầng, monitoring,…
  • Khi người dùng thường nhỏ và ít nên bạn không mong đợi họ sẽ mở rộng. Ví dụ các ứng dụng doanh nghiệp nhắm đến mục tiêu là một nhóm người cụ thể…

Kiến trúc microservice

  • Ứng dụng có phạm vi lớn và bạn xác định các tính năng sẽ được phát triển rất mạnh theo thời gian. Ví dụ: cửa hàng thương mại điện tử trực tuyến, dịch vụ truyền thông xã hội, dịch vụ truyền phát video với số lượng người dùng lơn, dịch vụ cung cấp API,…
  • Team-size lớn, có đủ thành viên để phát triển các component riêng lẻ một cách hiệu quả.
  • Mặt bằng kỹ năng của team tốt và các thành viên tự tin về các mẫu thiết kế microservice nâng cao.
  • Thời gian để đem đi marketing không quan trọng. Kiến trúc microservice sẽ mất nhiều thời gian hơn để hoạt động được.
  • Bạn sẵn sàng chi nhiều hơn cho cơ sở hạ tầng, giám sát,… để nâng cao chất lượng sản phẩm.
  • Tiềm năng về người dùng lớn và bạn kỳ vọng số lượng người dùng sẽ phát triển. Ví dụ một phương tiện truyền thông xã hội nhắm mục tiêu là người dùng trên toàn thế giới.

Tags

#architect#monolithic#microservices#102020
manh.nguyen

manh.nguyen

Developer

Related Posts

Sign In with Apple - Backend (Java)
Sign In with Apple - Backend (Java)
October 29, 2020
3 min
© 2021, All Rights Reserved.

Quick Links

HomeOur Team

Social Media