基於Spring Cloud微服務叢集的服務治理思考

就目前瞭解的情況來看，公司的服務提供方是較為混亂的。可能也是因為剛進公司對大多數服務都不是很瞭解的原因。至少目前來說還是一頭霧水。

個人覺得在以下方面可以加強：

• 每一個服務提供方的功能範圍需要明確，且能夠從某種意義上與其它的服務提供方區分開來，形成文件來描述系統劃分的原則與依據，協助使用者清晰的理解各個提供方的功能，簡化呼叫。同時在後續的服務開發過程中嚴格按照這些原則來將新增加的服務劃分到正確的系統中去，避免系統之間的邊界在發展過程中越來越模糊與混亂。

• 對於當前微服務叢集中所提供的服務清單，應該能夠通過系統能夠看到完整的系統名稱、包含提供的服務內容的描述資訊、該系統提供的服務清單及其描述資訊等。目前通過EurekaServer、Actuator及Swagger可以完成這些功能，但就多數應用來說，目前有一些不盡如人意的地方：一是各個系統的名稱、描述資訊等較為混亂，無法從這些資訊上得到這個系統是做什麼用途的。各個應用在定義名稱、版本、描述資訊時都很隨意。同時，在使用Swagger來描述各個介面時，其描述資訊也寫的比較混亂。二是通過Swagger來檢視各個服務提供方的服務資訊非常不友好，無法在某一個介面中檢視及搜尋、定位叢集所提供的所有服務介面，而只能先通過EurekaServer定位到某一個提供方後再去訪問該提供方的SwaggerUI中檢視其提供的介面資訊。

  可以通過以下方式來進行改進 ：

  • 嚴格規範每一個提供方的應用名稱、描述資訊的定義。
  • 通過使用Actuator、Erueka、Swagger已有的介面來做一個介面，將這些應用及其介面資訊統一收集，並提供搜尋定位等功能來輔助使用。

• 提供呼叫鏈路的監控，每一個呼叫可能會同時呼叫多個提供者提供的服務，而提供者提供的服務本身又可能會呼叫其它提供者提供的服務，這些服務呼叫者之間的關係，如果有一個呼叫鏈路圖能夠看清楚每一個呼叫請求所使用的服務，那麼在後續分析問題、進行某些修改的影響分析等都會非常有用。可以考慮引用sleuth來對呼叫鏈路進行監控與分析。