Xử lý thông báo lỗi từ các dịch vụ khác trong Kiến trúc dịch vụ vi mô

Công ty chúng tôi chạy các ứng dụng trên kiến ​​trúc Micro Service bao gồm hàng ngàn dịch vụ. Tôi đang làm việc trên một ứng dụng phụ trợ "X" nói về hơn 50 dịch vụ. Dịch vụ Frontend gọi dịch vụ của tôi là "X" để thực hiện các yêu cầu trên các dịch vụ khác.

Vấn đề :

Front end muốn hiển thị thông báo thân thiện với người dùng khi có lỗi trên các dịch vụ khác.

1. Các dịch vụ khác không trả lại tin nhắn thân thiện với người dùng. Tôi không thể yêu cầu thay đổi bởi các đội khác vì có một số.
2. Không có mã lỗi đồng ý như vậy. Các dịch vụ khác trả về một thông báo lỗi chuỗi. Hiện tại, nó được chuyển trở lại UI. Đôi khi các thông báo lỗi là một tham chiếu con trỏ (mã xấu: /)

Giải pháp có thể :

Kiểm tra chuỗi thông báo lỗi và có ánh xạ trong dịch vụ của tôi tới tin nhắn thân thiện với người dùng. Nhưng mọi thứ có thể bị phá vỡ nếu dịch vụ callee thay đổi thông báo lỗi của họ. Dự phòng thông báo lỗi mặc định khi không tìm thấy ánh xạ lỗi tùy chỉnh.

Bất kỳ ý tưởng hơn về giải pháp mở rộng và bền vững? Cảm ơn!

Khước từ

Công ty chúng tôi chạy các ứng dụng trên kiến ​​trúc Micro Service bao gồm hàng ngàn dịch vụ. Tôi đang làm việc trên một ứng dụng phụ trợ "X" nói về hơn 50 dịch vụ. Dịch vụ Frontend gọi dịch vụ của tôi là "X" để thực hiện các yêu cầu trên các dịch vụ khác.

Trước hết, hàng ngàn dịch vụ ngẫu nhiên không biến kiến ​​trúc thành microservice như kiến ​​trúc. Vẫn cần một ý nghĩa nhất định về "toàn bộ" và một chút sắp xếp giữa các dịch vụ. Hướng dẫn hoặc quy tắc của ngón tay cái.

Bối cảnh các phụ trợ trong 'toàn bộ'

Tôi giả sử, phụ trợ của bạn không phải là cổng cũng không phải proxy . Tôi đoán nó có kinh doanh riêng và bối cảnh giới hạn được xác định rõ. Vì vậy, liên quan đến các dịch vụ khác, phụ trợ là một mặt tiền .

Là một mặt tiền, ẩn chi tiết triển khai (ví dụ, tích hợp với các dịch vụ từ xa) là một trong những trách nhiệm của nó. Đối với giao diện người dùng (và do đó, người dùng cuối), người đối thoại đáng tin cậy duy nhất là Xvà không có chi tiết triển khai nào sẽ tiếp cận các lớp bên ngoài. Bất cứ điều gì xảy ra dưới mui xe, đó không phải là việc của người dùng.

Điều đó không có nghĩa là chúng tôi không thể nói với người dùng rằng đã xảy ra sự cố. Chúng tôi có thể, nhưng chúng tôi làm nó trừu tượng hóa những chi tiết này. Chúng tôi sẽ không cho cảm giác về một cái gì đó từ xa đang thất bại. Phải ngược lại, một cái gì đó trong Xthất bại và đó là nó.

Vì chúng ta đang nói về hàng ngàn tích hợp có thể (+50 atm), số lượng lỗi có thể và khác nhau là rất đáng kể. Nếu chúng ta ánh xạ từng cái một vào một thông điệp tùy chỉnh, người dùng cuối sẽ bị choáng ngợp bởi rất nhiều thông tin (và không được văn bản hóa). Nếu chúng tôi ánh xạ tất cả các lỗi thành một tập hợp nhỏ các lỗi tùy chỉnh, chúng tôi sẽ thiên vị thông tin, khiến chúng tôi khó theo dõi vấn đề và giải quyết nó.

Theo tôi, thông báo lỗi sẽ cung cấp cho người dùng với ý nghĩa rằng chúng ta có thể làm gì đó để sửa đổi vấn đề.

Tuy nhiên, nếu người dùng cuối vẫn muốn biết những gì đang diễn ra dưới mui xe, có nhiều cách khác hữu ích hơn cho toàn bộ tổ chức.

Trách nhiệm giải trình

1. Các dịch vụ khác không trả lại tin nhắn thân thiện với người dùng. Tôi không thể yêu cầu thay đổi bởi các đội khác vì có một số. Không có mã lỗi nào được thống nhất như vậy.

2. Các dịch vụ khác trả về một thông báo lỗi chuỗi. Hiện tại, nó được chuyển trở lại UI. Đôi khi các thông báo lỗi là một tham chiếu con trỏ (mã xấu: /)

Là nhà phát triển, trách nhiệm của bạn là đưa ra những lập luận này cho các bên liên quan. Đó là vấn đề trách nhiệm. Theo tôi, có một sự rò rỉ về lãnh đạo kỹ thuật và đó là một vấn đề thực sự khi nói đến các hệ thống phân tán.

Không có hình dung kỹ thuật. Nếu có, các dịch vụ sẽ được triển khai theo quy tắc ngón tay cái để làm cho hệ thống có thể mở rộng và dễ dàng tích hợp giữa các dịch vụ. Ngay bây giờ có vẻ như các dịch vụ xuất hiện một cách điên cuồng, không có ý thức đóng góp cho "toàn bộ".

Nếu tôi được yêu cầu làm những gì bạn được yêu cầu (và đôi khi tôi đã được), tôi sẽ tranh luận liệu việc biến tình trạng hỗn loạn hiện tại thành tin nhắn thân thiện với người dùng có nằm ngoài phạm vi hay không X.

Ít nhất, "giơ tay", phơi bày mối quan tâm của bạn, phơi bày những lựa chọn thay thế của bạn và để bất cứ ai có trách nhiệm giải quyết.

Làm cho giải pháp của bạn có giá trị cho công ty

Kiểm tra chuỗi thông báo lỗi và có ánh xạ trong dịch vụ của tôi tới tin nhắn thân thiện với người dùng. Nhưng mọi thứ có thể bị phá vỡ nếu dịch vụ callee thay đổi thông báo lỗi của họ. Dự phòng thông báo lỗi mặc định khi không tìm thấy ánh xạ lỗi tùy chỉnh.

Bạn đúng rồi. Đó là một giải pháp yếu. Nó dễ vỡ và không hiệu quả trong thời gian dài.

Tôi cũng nghĩ rằng nó gây ra sự ghép đôi vì những thay đổi trong các chuỗi này có thể buộc bạn phải khúc xạ ánh xạ. Không phải là một cải tiến lớn.

Bất kỳ ý tưởng về một giải pháp mở rộng và bền vững?

Báo cáo . Xử lý các lỗi, cung cấp mã / vé / id cho họ và báo cáo. Sau đó, cho phép front-end trực quan hóa báo cáo. Chẳng hạn, chia sẻ một liên kết đến dịch vụ báo cáo .

Lỗi. <Một thông báo lỗi rất thân thiện với người dùng và rất mặc định>. Theo liên kết để biết thêm thông tin

Bằng cách này, bạn có thể tích hợp nhiều dịch vụ mà bạn cần. Và bạn giải phóng bản thân khỏi chi phí xử lý và dịch các chuỗi ngẫu nhiên thành các chuỗi ngẫu nhiên mới, nhưng thân thiện với người dùng.

Dịch vụ báo cáo có thể được sử dụng lại cho các dịch vụ còn lại để nếu bạn có ID tương quan, bạn có thể cho phép người dùng có cái nhìn toàn cảnh về các lỗi và nguyên nhân. Trong các kiến ​​trúc phân tán, khả năng truy tìm nguồn gốc khá quan trọng.

Sau đó, các dịch vụ báo cáo có thể được tăng cường với nhiều ánh xạ như bạn cần phải cung cấp hướng dẫn có thể đọc được và hữu ích về những việc cần làm nếu lỗi X xảy ra . Nếu chuỗi thay đổi ở đây không có vấn đề gì cả. Những gì chúng tôi có (cửa hàng) là trạng thái cuối cùng của báo cáo.

Dịch vụ báo cáo sẽ mở ra cơ hội bình thường hóa các lỗi trong tổ chức vì dịch vụ sẽ hiển thị API công khai (do đó là hợp đồng).

Không có phép lạ trong trường hợp của bạn. Các giải pháp có thể có vẻ như giải pháp mà bạn đã đề xuất.

Kiểm tra chuỗi thông báo lỗi và có ánh xạ trong dịch vụ của tôi tới tin nhắn thân thiện với người dùng. Nhưng mọi thứ có thể bị phá vỡ nếu dịch vụ callee thay đổi thông báo lỗi của họ. Dự phòng thông báo lỗi mặc định khi không tìm thấy ánh xạ lỗi tùy chỉnh.

API có thể thay đổi thông báo lỗi nếu API cũng trả lại một số loại mã lỗi, mà người tiêu dùng API có thể sử dụng để theo dõi lỗi và ánh xạ cho một thông báo khác (như bạn đang cố gắng thực hiện, nhưng với thông báo).

Chỉ đảm bảo ghi nhật ký thông báo rằng API đã trả về trước khi thực hiện lỗi dự phòng. Có thể bạn có thể thêm thông báo API theo một số loại developerMessagelỗi tùy chỉnh, giúp xác định sự cố mà không cần sử dụng nhật ký (chỉ đảm bảo rằng API của họ không ném bất kỳ thông báo nào có thông tin hợp lý).

Nếu bạn có một số kênh liên lạc với nhóm đang thực hiện dịch vụ này, hãy giải thích vấn đề của bạn và yêu cầu họ giúp đỡ, bởi vì đó có thể là vấn đề tương tự đối với nhóm khác đang cố gắng sử dụng API của họ.