標準服務最佳做法
注意：Cloud Service Mesh 1.6.8 以上版本會自動支援 Canonical 服務。
Canonical Services 可讓您瀏覽許多不同的設定。為享有最佳的 Cloud Service Mesh 服務資訊主頁體驗，請在設定服務時考量下列標準做法：
- 在整個網格中預留不重複的服務 [命名空間、名稱]。
- 每項標準服務定義一個軟體應用程式。
- 請勿在不同環境 (例如 prod/stage/dev) 中將標準服務分組。
- 如要查看多項服務的較高層級檢視畫面，請使用 Cloud Monitoring 資訊主頁。
- 規劃標準服務在實際工作環境中的長期使用壽命。
在整個網格中保留不重複的服務 [命名空間、名稱]
如果在一個叢集或區域中部署的 Canonical 服務，其 Kubernetes 命名空間和 Canonical 服務名稱與在另一個叢集或區域中部署的服務相同，Cloud Service Mesh 會假設這兩者是相同的邏輯服務。
這項行為與「相同性」的車隊原則一致，該原則指出命名空間應具有相同的含義，並在整個車隊中代表相同實體。
每個標準服務一個軟體應用程式
標準服務代表單一邏輯服務或微服務。這些群組旨在跨越同質二進位檔/工作負載，代表相同的軟體應用程式和業務功能。
雖然您可以定義標準服務，將概念上不同的多個微服務分組在一起，但服務資訊主頁不會提供完整的值。服務資訊主頁會顯示不相干的元件匯總，這些元件可能會個別執行，並且設定方式大不相同。因此，您可能難以瞭解整體的健康狀態、效能和設定。
以下做法不一定是錯誤做法，但如果發生下列情況，標準服務可能太大：
- 在單一標準服務中，不同工作負載之間會有網路流量。
- 標準服務包含在不同發布時程部署的多項工作負載。
- 貴機構內的不同團隊負責運作單一標準服務的不同部分。
請勿在不同環境中將標準服務分組
許多科技公司都會採用多個部署環境，確保軟體品質並降低風險。這些環境通常包括開發、測試、前置、實際工作環境或某些子集。
即使您在各個不同環境中部署相同的概念服務，將這些服務設為單一標準服務也是不當做法。這些服務不盡相同，對貴機構的營運關注程度或重點也不盡相同。
舉例來說，關鍵的實際工作環境服務發生故障時，可能會導致 3AM 頁面和搶修作業。如果「dev」部署作業在半夜失敗，您不會想通知任何人。同樣地，您也需要瞭解效能、容量和發布安全性。
從最簡單但最不嚴謹的方式，到最費力但最強大的方式，有三種方法可將服務分隔至不同的環境：
- 使用多個服務名稱分隔，例如
payments-prod和payments-test。 - 使用多個命名空間分隔，例如
billing-team和billing-team-test。 - 使用多個車隊 (每個環境一個) 進行分隔。
建議使用 Cloud Monitoring 自訂資訊主頁進行任意匯總
請使用 Cloud Monitoring 資訊主頁，一次建立多個邏輯服務的較高層級檢視畫面，而非人為地將標準服務擴大為較大的範圍，用於匯總資料。
標準服務應具備長效性
除了開發、探索和測試用途之外，標準服務應代表全球高階邏輯服務。這些服務變動緩慢，且通常會長期存在。這項長久性包括不會變更服務名稱。您可以變更這些名稱，但這會影響指標、服務等級目標和記錄。不過，您可以自由調整 Display name 欄位，不會造成中斷。
新的標準服務通常代表新軟體或更新的軟體，而移除的標準服務通常代表服務淘汰。您能否查看服務、企劃書和專案容量的歷來表現，取決於您是否在 Cloud Service Mesh 中維持該服務的單一概念，直到服務生命週期結束為止。
請注意，這與較低層級的資源 (例如 VM 執行個體、Kubernetes Pod/部署) 甚至整個叢集相反，這些資源通常會在更新和維護實際工作環境系統時出現和消失。