Duy trì và ghi lại các điểm cuối API của nhiều ứng dụng trong kiến ​​trúc microservice

Tôi nghĩ rằng một trong những điểm đau đớn nhất khi làm việc với microservice là đảm bảo rằng các API được ghi chép tốt và các API không thay đổi hành vi của chúng mà không ảnh hưởng đến các ứng dụng tiếp theo. Vấn đề này trở nên khuếch đại khi bạn có nhiều dịch vụ phụ thuộc lẫn nhau. Có lẽ tại thời điểm đó bạn làm microservice sai, nhưng tôi lạc đề.

Giả sử chúng tôi đã thừa hưởng 20 dịch vụ siêu nhỏ thuộc sở hữu của các nhóm khác nhau và không có tài liệu rõ ràng về ứng dụng nào sử dụng điểm cuối API của ứng dụng khác. Có một cách quy định tài liệu này? Lúc đầu, tôi nghĩ đến việc phân tích các điểm cuối của từng ứng dụng và thêm chúng vào bảng cơ sở dữ liệu, sau đó tạo mối quan hệ FK giữa mỗi ứng dụng và tuyến đường của ứng dụng trên một bảng nhiều-nhiều (hầu hết tất cả đều là các ứng dụng rails). Nhưng tôi không chắc đây là một cách tốt để xử lý việc này hay tôi đang phát minh lại bánh xe ở đây.

Nhìn lại, đây có thể là một cách không tồi để ghi lại tương tác ứng dụng nếu bạn đang bắt đầu với microservice từ đầu. Điều này sẽ chỉ thực thi rằng một nguồn sự thật duy nhất được duy trì thông qua việc sử dụng cơ sở dữ liệu và mọi thay đổi đối với các điểm cuối sẽ được thực hiện trong ứng dụng cùng với thay đổi trong cơ sở dữ liệu. Suy nghĩ?

Một phần lớn lợi ích của "kiến trúc microservice" là bạn không ghi lại tất cả các mối quan hệ đó. Mỗi dịch vụ là sản phẩm riêng của mình. Và mỗi chủ sở hữu dịch vụ chịu trách nhiệm cho hoạt động dịch vụ của họ như một sản phẩm độc lập. Điều đó có thể bao gồm những thứ như:

• Xuất bản tài liệu "tiếp thị", tài liệu người dùng và nhật ký thay đổi (bao gồm cả khấu hao )
• Cung cấp một cách để khách hàng / người tiêu dùng yêu cầu các tính năng / báo cáo lỗi
• Duy trì SLA
• Thực hiện cập nhật tương thích ngược nhất có thể và phá vỡ các thay đổi
• Biết và xem tin tức cho các dịch vụ họ tiêu thụ trực tiếp
• Cắt tỉa phụ thuộc khi có thể
• Khấu hao toàn bộ dịch vụ khi nó trở nên không liên quan hoặc quá tốn kém để duy trì

Và như thế.

Trên hết, tôi nhấn mạnh, là một trong những lợi ích cốt lõi của microservice, cơ hội cho chủ sở hữu dịch vụ thực sự tập trung và chuyên môn hóa vào "một điều" dịch vụ của họ.

Về việc mỗi chủ sở hữu sản phẩm hoặc dịch vụ nên ghi lại các phụ thuộc của riêng họ - điều đó sẽ xảy ra "một cách tự nhiên" khi chúng được thêm vào cấu hình của trình biên dịch của bạn (hoặc tập lệnh xây dựng). Nếu bạn cần biết ServiceA phụ thuộc vào điều gì , ServiceA/Configuration.xml(hoặc bất cứ điều gì ) sẽ cho bạn biết. Thông thường tôi cũng mong muốn mỗi chủ sở hữu dịch vụ lập sơ đồ phụ thuộc ngay lập tức của riêng họ - nhưng không phụ thuộc vào phụ thuộc và v.v. Và, với thông tin đã có sẵn trong mã, tôi không nhất thiết mong đợi những sơ đồ đó sẽ được duy trì trong tương lai.

^{Nếu bạn thực sự muốn có một bức tranh toàn cầu, hãy quét các tập lệnh cấu hình / xây dựng. Những gì bạn làm với đầu ra đó, cách bạn lưu trữ nó và vv, phụ thuộc hoàn toàn vào quyết định mà dữ liệu sẽ giúp bạn đưa ra.}

Tôi nghĩ rằng một ý tưởng tốt là tạo ra một sơ đồ tích hợp và đưa nó vào kho lưu trữ của bạn. Chọn một số công cụ miễn phí (như draw.io) có thể xuất sơ đồ trong tệp XML hoặc JSON và cam kết tệp này trong kho lưu trữ của bạn. Nếu bạn sử dụng Github hoặc Gitlab, hãy tạo hình ảnh từ sơ đồ này và đưa vào Wiki hoặc thậm chí trong tệp README.md, vì vậy hình ảnh sẽ hiển thị mỗi khi nhà phát triển trực quan hóa kho lưu trữ từ trình duyệt.

Chiến lược tương tự có thể được sử dụng cho cơ sở dữ liệu.

Về tài liệu tài nguyên API, Swagger là một lựa chọn tốt.

Vấn đề này trở nên khuếch đại khi bạn có nhiều dịch vụ phụ thuộc lẫn nhau. Có lẽ tại thời điểm đó bạn làm microservice sai, nhưng tôi lạc đề.

Đây là một vấn đề, chắc chắn.