Microservices vs Kiến trúc nguyên khối [đã đóng]

Tôi đã đọc một số bài viết về microservices và tôi hơi bị tò mò. Có vẻ như đó là một khái niệm thú vị. Nhưng tôi tự hỏi, lợi và bất lợi khi sử dụng microservices so với kiến ​​trúc nguyên khối là gì và ngược lại.

Khi microservices phù hợp hơn và tốt hơn nên đi đâu với kiến ​​trúc nguyên khối.

Mặc dù tôi còn khá mới đối với thế giới microservices, nhưng tôi sẽ cố gắng trả lời câu hỏi của bạn đầy đủ nhất có thể.

Khi bạn sử dụng kiến ​​trúc microservices, bạn sẽ tăng khả năng tách và tách các mối quan tâm. Vì bạn đang chia nhỏ ứng dụng của mình.

Điều này dẫn đến việc cơ sở mã của bạn sẽ dễ quản lý hơn (mỗi ứng dụng độc lập với các ứng dụng khác để duy trì và chạy). Do đó, nếu bạn làm đúng , việc thêm các tính năng mới vào ứng dụng của bạn sẽ dễ dàng hơn trong tương lai . Trong khi với một kiến ​​trúc nguyên khối, nó có thể trở thành một điều rất khó thực hiện nếu ứng dụng của bạn lớn (và bạn có thể giả định rằng nó sẽ xảy ra vào một thời điểm nào đó).

Việc triển khai ứng dụng cũng dễ dàng hơn , vì bạn đang xây dựng các microservices độc lập riêng biệt và triển khai chúng trên các máy chủ riêng biệt. Điều này có nghĩa là bạn có thể xây dựng và triển khai các dịch vụ bất cứ khi nào bạn muốn mà không cần phải xây dựng lại phần còn lại của ứng dụng.

Vì các dịch vụ khác nhau có quy mô nhỏ và được triển khai riêng biệt, nên rõ ràng là dễ dàng mở rộng quy mô chúng hơn, với lợi thế là bạn có thể mở rộng các dịch vụ cụ thể của ứng dụng ứng dụng đang tải quá mức).

Tuy nhiên, đối với các ứng dụng không có ý định trở nên quá lớn để quản lý trong tương lai. Tốt hơn là giữ nó ở kiến ​​trúc nguyên khối. Vì kiến ​​trúc microservices có một số khó khăn nghiêm trọng liên quan. Tôi đã nói rằng việc triển khai microservices dễ dàng hơn, nhưng điều này chỉ đúng khi so sánh với các khối lớn. Sử dụng microservices, bạn có thêm sự phức tạp khi phân phối các dịch vụ đến các máy chủ khác nhau ở các vị trí khác nhau và bạn cần tìm cách quản lý tất cả những điều đó. Xây dựng microservices sẽ giúp bạn về lâu dài nếu ứng dụng của bạn lớn, nhưng đối với các ứng dụng nhỏ hơn, việc duy trì nguyên khối sẽ dễ dàng hơn.

Đây là một câu hỏi rất quan trọng vì một số người bị thu hút bởi tất cả những lời bàn tán xung quanh microservices và có những sự cân bằng cần cân nhắc. Vậy, những lợi ích và thách thức của microservices (khi so sánh với mô hình nguyên khối) là gì?

Những lợi ích

• Khả năng triển khai : nhanh nhẹn hơn để triển khai các phiên bản mới của dịch vụ do chu kỳ xây dựng + kiểm tra + triển khai ngắn hơn. Ngoài ra, hãy linh hoạt để sử dụng các cấu hình bảo mật, nhân rộng, tính bền bỉ và giám sát dành riêng cho dịch vụ.
• Độ tin cậy : một lỗi microservice ảnh hưởng đến riêng microservice đó và người tiêu dùng của nó, trong khi trong mô hình nguyên khối, lỗi dịch vụ có thể ảnh hưởng đến toàn bộ nguyên khối.
• Tính khả dụng : triển khai phiên bản mới của một microservice cần ít thời gian ngừng hoạt động, trong khi việc triển khai phiên bản mới của một dịch vụ trong nguyên khối yêu cầu khởi động lại toàn bộ nguyên khối thường chậm hơn.
• Khả năng mở rộng : mỗi microservice có thể được mở rộng một cách độc lập bằng cách sử dụng các nhóm, cụm, lưới. Các đặc điểm triển khai làm cho microservices trở nên phù hợp tuyệt vời với tính đàn hồi của đám mây.
• Khả năng sửa đổi : linh hoạt hơn để sử dụng các khung mới, thư viện, nguồn dữ liệu và các tài nguyên khác. Ngoài ra, các microservices được ghép nối lỏng lẻo, các thành phần mô-đun chỉ có thể truy cập thông qua các hợp đồng của chúng và do đó ít có nguy cơ biến thành một quả bóng bùn lớn.
• Quản lý : nỗ lực phát triển ứng dụng được chia cho các nhóm nhỏ hơn và hoạt động độc lập hơn.
• Quyền tự chủ về thiết kế : nhóm có quyền tự do sử dụng các công nghệ, khuôn khổ và mẫu khác nhau để thiết kế và triển khai từng dịch vụ vi mô, đồng thời có thể thay đổi và triển khai lại từng dịch vụ vi mô một cách độc lập

Thách thức

• Khả năng triển khai : có nhiều đơn vị triển khai hơn, do đó, có nhiều công việc phức tạp hơn, tập lệnh, khu vực chuyển giao và tệp cấu hình để giám sát việc triển khai. (Vì lý do đó, phân phối liên tục và DevOps rất được mong đợi cho các dự án microservice.)
• Hiệu suất : các dịch vụ có nhiều khả năng cần giao tiếp qua mạng hơn, trong khi các dịch vụ trong nguyên khối có thể được hưởng lợi từ các cuộc gọi nội hạt. (Vì lý do đó, thiết kế nên tránh các microservices "chát".)
• Khả năng sửa đổi: các thay đổi đối với hợp đồng có nhiều khả năng ảnh hưởng đến người tiêu dùng được triển khai ở nơi khác, trong khi ở mô hình nguyên khối, người tiêu dùng có nhiều khả năng ở trong nguyên khối và sẽ được triển khai ngay sau khi hoàn thành dịch vụ. Ngoài ra, các cơ chế để cải thiện quyền tự chủ, chẳng hạn như tính nhất quán cuối cùng và các cuộc gọi không đồng bộ, làm tăng thêm độ phức tạp cho các dịch vụ nhỏ.
• Khả năng kiểm tra: các bài kiểm tra tích hợp khó thiết lập và chạy hơn vì chúng có thể kéo dài các microservices khác nhau trên các môi trường thời gian chạy khác nhau.
• Quản lý : nỗ lực quản lý các hoạt động tăng lên vì có nhiều thành phần thời gian chạy hơn, tệp nhật ký và tương tác điểm-điểm cần giám sát.
• Sử dụng bộ nhớ : một số lớp và thư viện thường được sao chép trong mỗi gói microservice và diện tích bộ nhớ tổng thể tăng lên.
• Quyền tự chủ về thời gian chạy : trong nguyên khối, logic kinh doanh tổng thể được gắn kết với nhau. Với microservices, logic được trải rộng trên các microservices. Vì vậy, tất cả những điều khác đều bình đẳng, có nhiều khả năng một microservice sẽ tương tác với các microservices khác qua mạng - sự tương tác đó làm giảm quyền tự chủ. Nếu sự tương tác giữa các microservices liên quan đến việc thay đổi dữ liệu, thì nhu cầu về ranh giới giao dịch sẽ ảnh hưởng đến quyền tự chủ hơn nữa. Tin tốt là để tránh các vấn đề về quyền tự chủ trong thời gian chạy, chúng tôi có thể sử dụng các kỹ thuật như tính nhất quán cuối cùng, kiến ​​trúc hướng sự kiện, CQRS, bộ nhớ cache (sao chép dữ liệu) và điều chỉnh các microservices với ngữ cảnh bị ràng buộc DDD. Những kỹ thuật này không có sẵn cho microservices, nhưng hầu như đã được đề xuất bởi hầu hết mọi tác giả mà tôi đã đọc.

Một khi chúng ta hiểu được những đánh đổi này , có một điều nữa chúng ta cần biết để trả lời câu hỏi khác: cái nào tốt hơn, microservices hay monolith? Chúng ta cần biết các yêu cầu phi chức năng (yêu cầu thuộc tính chất lượng) của ứng dụng. Ví dụ, một khi bạn hiểu tầm quan trọng của hiệu suất so với khả năng mở rộng, bạn có thể cân nhắc sự cân bằng và đưa ra quyết định thiết kế có kiến ​​thức.

@Luxo là đúng. Tôi chỉ muốn đưa ra một sự thay đổi nhỏ và mang lại quan điểm tổ chức của nó. Không chỉ microservices cho phép tách các ứng dụng mà còn có thể hữu ích ở cấp độ tổ chức. Ví dụ, tổ chức sẽ có thể chia thành nhiều nhóm trong đó mỗi nhóm có thể phát triển trên một tập hợp các dịch vụ nhỏ mà nhóm có thể cung cấp.

Ví dụ: trong các cửa hàng lớn hơn như Amazon, bạn có thể có nhóm cá nhân hóa, nhóm thương mại điện tử, nhóm dịch vụ cơ sở hạ tầng, v.v. Nếu bạn muốn tham gia vào dịch vụ vi mô, Amazon là một ví dụ rất tốt về điều đó. Jeff Bezos quy định các nhóm phải giao tiếp với các dịch vụ của nhóm khác nếu họ cần quyền truy cập vào một chức năng được chia sẻ. Xem ở đây để biết mô tả ngắn gọn.

Ngoài ra, các kỹ sư từ Etsy và Netflix cũng đã có một cuộc tranh luận nhỏ trở lại thời kỳ microservices vs monolith trên Twitter. Cuộc tranh luận ít kỹ thuật hơn một chút nhưng cũng có thể cung cấp một số hiểu biết sâu sắc.