Làm thế nào để bạn thiết kế phần mềm cập nhật một số dịch vụ siêu nhỏ, nếu một trong số chúng bị lỗi?

Có một mẫu thiết kế hoặc thực hành nào tôi có thể sử dụng để trợ giúp với các dịch vụ bị hỏng hoặc đi xuống, trong khi các dịch vụ khác ổn định không?

Điều gì sẽ xảy ra nếu tôi có ba dịch vụ siêu nhỏ và hai trong số đó là tốt và một trong số đó chết ngay giữa POST? Hai sẽ nhận được POST và một sẽ không. Tôi không nghĩ mình có thể thực hiện giao dịch vì tôi đang chuyển yêu cầu của mình đến một dịch vụ.

Làm thế nào để tôi thiết kế cho điều đó? Tôi không muốn dữ liệu mồ côi trong các cơ sở dữ liệu khác nhau.

— johnny
nguồn

Đó không phải là một vấn đề đơn giản để giải quyết. Tôi đã thấy nó được triển khai như là hàng đợi cho các dịch vụ (tính nhất quán cuối cùng), vì rất có thể, việc bạn không kiểm soát (các) dịch vụ và áp dụng các trình quản lý giao dịch hoặc khả năng giao dịch là một cách tốt nhất, và có lẽ không phải là ý kiến hay trong môi trường SOA. Tôi hầu như đã thấy điều này xung quanh việc đẩy di động, nơi bạn có thể có hoặc không có kết nối với điểm đến của mình.

— Mike

axit trên microservice là một điều khó khăn để bẻ khóa, một tùy chọn khác có thể là một loại xe buýt, sử dụng redis xuất bản / đăng ký hoặc thiết kế hàng đợi và đăng một lần từ kênh gửi đến, sau đó dịch vụ đăng ký hoặc proxy dịch vụ của bạn đẩy đến mục tiêu và báo cáo thành công sự thất bại. Bạn sẽ cần theo dõi các thất bại và cũng có một luồng cho nó. Bạn cũng có thể gặp thất bại khi giao dịch không hợp lệ trên một dịch vụ nhưng hợp lệ đối với hai dịch vụ khác nhưng đó chỉ là một luồng thất bại khác mà bạn cần giải quyết.

— Tim Cederquist

Sẽ không sử dụng cái gì đó như "trình quản lý hàng đợi", đó là những gì tôi đoán Redis sẽ gây ra tắc nghẽn? Hoặc ít nhất là có tiềm năng cao quá? Tôi biết không có cách nào khác hơn bạn mô tả.

— johnny

Tùy thuộc vào khối lượng luồng dữ liệu, tôi đã triển khai trình quản lý hàng đợi, thử lại việc truyền cho đến khi báo cáo thành công hoặc nó gửi thông báo không thành công và gửi thông báo SMS về việc ngừng hoạt động. Tôi đoán nó cũng sẽ phụ thuộc một chút vào cửa sổ mất điện dự kiến (bao lâu).

— htm11h

Đây có phải là cái gì đó giống như rabbitmq không?

— johnny

Câu trả lời:

Một số tùy chọn.

Sử dụng kênh liên lạc liên tục

Thay vì HTTP, thả các tin nhắn trong hàng đợi có tính sẵn sàng cao và liên tục. Ví dụ: Kafka. Miễn là máy chủ mục tiêu có sẵn tại một số điểm, nó sẽ nhận được thông báo.

Bạn có sự đánh đổi ngay bây giờ để cung cấp và quản trị một hệ thống con phức tạp (hàng đợi). Vì vậy, hãy chắc chắn rằng bạn phân tích xem điều này có đáng không.

Backoff và thử lại

Yêu cầu người gọi giữ yêu cầu thất bại (có thể vẫn tồn tại trên đĩa) và thử lại định kỳ. Trong trường hợp này, điều quan trọng là phải phân biệt giữa yêu cầu của bạn gây ra sự cố so với dịch vụ bị ngừng hoạt động. Cái trước có lẽ là do lỗi và nên được ghi lại ... thử lại có thể sẽ không tạo ra sự khác biệt cho đến khi sửa lỗi được thực hiện.

Phát hiện và bồi thường

Một tác vụ định kỳ kiểm tra các điều kiện nhất quán giữa các dịch vụ micros. Ví dụ, thất bại ghi lại tất cả các cách truy vấn API trực tiếp khi cần thiết. Nếu nó phát hiện ra một vấn đề (ví dụ như có một đơn đặt hàng nhưng vận chuyển không bao giờ nhận được danh sách đóng gói) thì hãy thực hiện các bước bồi thường. Những bước đó có thể là tạo một vé hỗ trợ cho việc sửa lỗi thủ công hoặc gửi email cho ai đó hoặc bất cứ điều gì.

Xem xét lựa chọn thay thế thiết kế

Một trường hợp như thế này có thể yêu cầu một cổng API để quản lý các cuộc gọi đến các dịch vụ siêu nhỏ bị ảnh hưởng. Bằng cách đó bạn kiểm soát chiến thuật nào được sử dụng để giảm thiểu vấn đề này. Bạn có thể không muốn tạo gánh nặng cho khách hàng với những chi tiết triển khai đó. Xem mô hình ngắt mạch .

Bởi vì microservice là độc lập, sẽ luôn tồn tại một số trường hợp thất bại có thể dẫn đến sự không nhất quán. Bạn phải chuẩn bị để thực hiện sửa lỗi thủ công khi những phát sinh đó.

Nếu bạn yêu cầu sự nhất quán mạnh mẽ, thì microservice sẽ không phù hợp. Nếu vẫn cần khả năng mở rộng, bạn có thể muốn xem xét sharding nơi dữ liệu có liên quan có thể được đồng nằm trên mảnh tương tự cho đảm bảo tính nhất quán. Bạn vẫn có thể mở rộng IO bằng cách thêm phân đoạn.

Nếu bạn cần sự nhất quán mạnh mẽ và không gặp vấn đề về khả năng mở rộng, thì chỉ cần sử dụng các dịch vụ nguyên khối. Sử dụng các thư viện làm ranh giới trong ứng dụng của bạn để phân tách mối quan tâm.

— Kasey Nói
nguồn

Đây có phải là những gì RabbitMQ dành cho?

— johnny

RabbitMQ có phải là câu trả lời cho câu hỏi của bạn không? Không. Nó có thể là một phần của giải pháp đáp ứng nhu cầu của bạn, nhưng nó sẽ không giải quyết vấn đề của bạn một mình.

— Kasey speakman

Chỉ cần một lưu ý. Tôi nghĩ rằng RabbitMQ không duy trì các tin nhắn. Nó được tiêu thụ và loại bỏ khỏi hàng đợi, vì vậy KHÔNG. Nếu bạn cần kiên trì và thử lại, RabbitMQ sẽ không giúp đỡ.

— Laiv

Tôi nghĩ những gì bạn mô tả là vấn đề đồng thuận: bạn không muốn cam kết trừ khi mỗi người tham gia giao dịch phân tán nói rằng hoạt động đã thành công. Giải pháp đơn giản cho vấn đề này là Cam kết hai pha. Về cơ bản, nó thực hiện giao dịch trong mỗi hệ thống cho đến khi mỗi báo cáo trở lại rằng việc dàn dựng đã thành công (Giai đoạn 1). Nếu mọi người tham gia giao dịch trả lại thành công, mỗi người được yêu cầu cam kết; thay vào đó, nếu bất kỳ lỗi nào trong số chúng trả về thất bại, việc khôi phục được đưa ra (Giai đoạn 2). Có một nếp nhăn dẫn đến giải pháp Ba pha phức tạp hơn. Bạn có thể đọc một mô tả tốt hơn về mỗi ở đây:

http://the-apers-trail.org/blog/consallel-prot Protocol-two-phase-commit /

http://the-apers-trail.org/blog/consallel-prot Protocol-three-phase-commit /

— iarejenius
nguồn