實施api狀態端點的最佳做法是什麼？

Question

假設我有100個API，每個API與6個數據庫對話。我正在考慮兩種方法來構建狀態端點。消費者不需要訪問所有100個apis來執行其業務需求，他們可以根據需要訪問1個或2個apis。

1）每個API都有它自己的/狀態端點，並且該端點將檢查它使用的所有6個數據庫的連通性，並且如果一個失敗，它將返回不健康的，否則健康的。在這種情況下，API消費者只訪問他們使用的狀態端點。在這種情況下，誰消費特定的API將訪問其狀態端點來檢查健康狀況。

2）在這種情況下，消費者只能訪問1個端點，其中包含所有100個apis的狀態，這是基於6個數據庫中的任何一個是否已關閉以及api是否已關閉，因此如果api啓動並且數據庫處於關閉狀態，對於該特定api狀態不健康，並且如果數據庫啓動並且api已啓動，則api已啓動且健康，則消費者可以從該單個端點獲取所有api的個人狀態或狀態（如果需要）。每個API都有自己的內部/狀態端點，無論其依賴的6個數據庫的狀態如何，它都會恢復正常。我將爲所有6個數據庫添加6個不同的狀態端點，並且它將檢查連接並且如果連接不健康則返回健康狀態。

這兩個最好的方法是什麼？

我真的很感激你的所有輸入。

Answer 1

不要做。如果他們發現30個正在工作的集羣微服務的健康狀況很好，只會因某些依賴項（在本例中爲數據庫）的健康狀況變爲紅色而變爲紅色，就會讓系統管理員發瘋。有你知道的數據庫健康監測工具。系統管理員需要把注意力放在發生了什麼事情上，而不是什麼事情很好。理想情況下，微服務不應該關心依賴關係的健康狀況。如果可以，請將事務保存在隊列中，然後讓服務再次嘗試（再次...）。在任何情況下，如果你有實時分析（你應該！）設置適當的聚合日誌記錄，那麼sysops將會看到微服務和數據庫（以及任何其他）之間的實時連接問題。另外理想情況下，微服務應該從數據持久性角度更加孤立。 100個微服務直接與6個數據庫作鬥爭？