Chia tỷ lệ nguyên khối so với quy mô microservice

Một trong những đối số phổ biến để sử dụng microservice là khả năng mở rộng tốt hơn. Nhưng tôi tự hỏi liệu lập luận này có thực sự hợp lệ hay không.

Hãy nói rằng chúng tôi đã có một ứng dụng bao gồm 10 microservice với 9 trong số đó có hai trường hợp (để dự phòng) và một trong số đó có 4 trường hợp để xử lý tải (khả năng mở rộng). Đối số pro-microservice sau đó là bạn có thể mở rộng quy mô miroservice này một cách độc lập khỏi các dịch vụ khác.

Tuy nhiên, giả sử tất cả 10 microservice là các mô-đun trong một khối đơn và một số trường hợp (ví dụ 22 như tổng từ trên) của khối nguyên khối này đã được triển khai. Hệ thống sẽ có thể xử lý tải cho một phần quan trọng, bởi vì có đủ trường hợp để làm như vậy. Nếu các trường hợp chứa logic chương trình không cần thiết, nhược điểm duy nhất là, nhị phân và dung lượng RAM cần thiết sẽ lớn hơn một chút. Nhưng một lần nữa, sự khác biệt không nên quá lớn trong hầu hết các trường hợp - ít nhất là không so với phần còn lại của ngăn xếp (nghĩ về Spring Boot). Mặt trái của một khối nguyên khối sẽ là một hệ thống đơn giản hơn mà không có (hầu hết) các ngụy biện của một hệ thống phân tán.

Tui bỏ lỡ điều gì vậy?

Quan điểm của microservice là không giảm tải bộ xử lý. Trong thực tế, do chi phí truyền thông và lặp lại các chức năng từng là mã tiện ích toàn cầu, nó thường làm tăng tải bộ xử lý lên một chút.

Mục đích của bãi bỏ một khối nhiều hơn nữa để có thể duy trì, triển khai và điều hành một hệ thống phức tạp các chức năng ở tất cả . Khi hệ thống của bạn đạt đến một kích thước nhất định, biên dịch, thử nghiệm, triển khai, v.v., một khối nguyên khối trở nên quá đắt để có thể khả thi trong khi duy trì thời gian hoạt động tốt. Với microservice, bạn có thể nâng cấp, khởi động lại hoặc khôi phục hệ thống từng phần.

Đừng nhầm lẫn, chúng tôi không viết microservice bởi vì đó vốn dĩ là một giải pháp tốt hơn để kết nối mọi thứ một cách lỏng lẻo trên các giao diện từ xa. Trong thực tế, việc mất loại mạnh và kiểm tra tính nhất quán mà một khối nguyên khối có thể cung cấp thường là một nhược điểm lớn. Chúng tôi làm điều đó bởi vì chúng tôi phải làm vì sự phức tạp đã giúp chúng tôi trở nên tốt hơn và đang làm cho tình huống dưới mức tối ưu.

Bạn chủ yếu là chính xác. Nếu bạn có các dịch vụ nhanh được tải như nhau, bạn cũng có thể cài đặt tất cả chúng trên tất cả các hộp. Nó không phải là "tốt đẹp" như có một hộp cho mỗi dịch vụ, nhưng nó tiết kiệm tiền.

Tuy nhiên. Ngay khi bạn mất cân bằng, giả sử dịch vụ 5 chiếm 100% số lõi trong 2 phút, bạn muốn chuyển dịch vụ đó sang hộp riêng để nó không chặn tất cả các dịch vụ khác nếu nó chạy.

Nếu cuộc gọi đến dịch vụ hết 5 lần do tải, chỉ một số chức năng của ứng dụng của bạn sẽ thất bại thay vì tất cả.

Bây giờ bạn có thể làm điều tương tự với một khối nguyên khối được mô đun hóa tốt. Cài đặt tất cả các dịch vụ, nhưng chỉ định tuyến 5 dịch vụ lưu lượng đến một trong số chúng. Trong khi không định tuyến dịch vụ 5 lưu lượng đến các hộp khác.

Nhưng thông thường, nguyên khối bởi bản chất của chúng không phải là một bộ sưu tập các dịch vụ lỏng lẻo được cài đặt trên cùng một hộp. Sẽ có các cuộc gọi bộ nhớ giữa các mô-đun sẽ gây ra lỗi cho ứng dụng.

Điểm của các dịch vụ vi mô là 1) phân tách mối quan tâm và 2) phân phối tải. Về cơ bản, điều này giải phóng chúng tôi để tạo ra dịch vụ hộp đen tốt nhất có thể với các công nghệ dành riêng cho nhiệm vụ đó. Các dịch vụ của chúng tôi có thể là polyglot - được viết bằng các ngôn ngữ lập trình khác nhau trên các ngăn xếp khác nhau. Các nhóm khác nhau có thể làm việc trên mỗi dịch vụ mà không có kiến ​​thức về cách những người khác làm việc ngoài hợp đồng api của họ. Điều này, nói chung, cho phép cơ sở mã đơn giản hơn nhiều cho mỗi dịch vụ, dễ gỡ lỗi, hiểu và điều chỉnh hiệu năng hơn.