Kanonischer Dienst – Best Practices

Hinweis: Kanonische Dienste werden in Cloud Service Mesh Version 1.6.8 und höher automatisch unterstützt.

Mit Kanonischen Diensten können Sie viele verschiedene Konfigurationen aufrufen. Um die Dienste von Cloud Service Mesh-Dashboards optimal zu nutzen, sollten Sie beim Einrichten Ihrer Dienste die folgenden Standardverfahren befolgen:

  • Eindeutigen Dienst [Namespace, Name] im gesamten Mesh reservieren
  • Eine Softwareanwendung pro kanonischem Dienst definieren
    • Kanonischen Dienst nicht in Umgebungen gruppieren (z. B. prod/stage/dev).
    • Cloud Monitoring-Dashboards für übergeordnete Ansichten mehrerer Dienste verwenden
  • Kanonische Dienste für einen langlebigen Betrieb planen

Eindeutigen Dienst [Namespace, Name] im gesamten Mesh reservieren

Wenn ein in einem Cluster oder einer Region bereitgestellter kanonischer Dienst denselben Kubernetes-Namespace und kanonischen Dienstnamen hat wie ein in einem anderen Cluster oder einer anderen Region bereitgestellter Dienst, nimmt Cloud Service Mesh an, dass es sich um denselben logischen Dienst handelt.

Dieses Verhalten entspricht dem Flottenprinzip der "Gleichheit", das besagt, dass ein Namespace die gleiche Bedeutung haben und dieselbe Entität in der gesamten Flotte darstellen soll.

Eine Softwareanwendung pro kanonischem Dienst

Kanonische Dienste sollen einen einzelnen logischen Dienst oder Mikrodienst repräsentieren. Sie haben die Kontrolle über homogene Binärdateien/Arbeitslasten, die dieselbe Softwareanwendung und Geschäftsfunktion repräsentieren.

Sie könnten zwar einen kanonischen Dienst definieren, um mehrere konzeptionell unterschiedliche Microservices zusammenzufassen, aber die Service Dashboards würden nicht ihren vollen Wert liefern. Die Service Dashboards würden eine Aggregation von unterschiedlichen Komponenten anzeigen, die individuell sehr unterschiedlich funktionieren und konfiguriert sein können. Es wäre schwierig oder gar unmöglich, den Zustand, die Leistung und die Konfiguration des gesamten Systems zu verstehen.

Die folgenden Beispiele sind nicht unbedingt nicht empfehlenswert, aber der kanonische Dienst ist möglicherweise zu groß, wenn:

  • Es Netzwerk-Traffic zwischen verschiedenen Arbeitslasten innerhalb eines einzigen kanonischen Diensts gibt.
  • Ein kanonischer Dienst mehrere Arbeitslasten umfasst, die in unterschiedlichen Veröffentlichungszeitplänen bereitgestellt werden.
  • Verschiedene Teams innerhalb Ihres Unternehmens für die Ausführung verschiedener Teile eines kanonischen Diensts zuständig sind.

Kanonischen Dienst nicht in umgebungsübergreifend gruppieren

Viele Technologieunternehmen verwenden mehrere Bereitstellungsumgebungen, um die Qualität der Software zu erhöhen und das Risiko zu begrenzen. Diese Umgebungen enthalten meistens Entwicklungs-, Test-, Staging-, Produktions- oder Teilumgebungen.

Auch wenn Sie für verschiedene Umgebungen den gleichen konzeptionellen Dienst bereitstellen, ist es nicht empfehlenswert, sie als einen kanonischen Dienst zu erstellen. Diese Dienste sind nicht identisch und haben nicht denselben Grad an betrieblicher Bedeutung. Auch repräsentieren sie nicht denselben Stellenwert für Ihr Unternehmen.

Zum Beispiel kann der Ausfall eines kritischen Produktionsdienstes Warnmeldungen um 3 Uhr morgens und diverse Feuerwehreinsätze bedeuten. Sie möchten niemanden alarmieren müssen, nur weil das „dev.”-Deployment Mitten in der Nacht ausfällt. Dasselbe gilt für das Verständnis von Leistung, Kapazität und Releasesicherheit.

Es gibt drei Möglichkeiten, Dienste auf verschiedene Umgebungen aufzuteilen:

  1. Mithilfe verschiedener Dienstnamen, z. B. payments-prod und payments-test.
  2. Mithilfe verschiedener Namespaces, zum Beispiel billing-team und billing-team-test.
  3. Mithilfe mehrerer Flotten, pro Umgebung eine.

Benutzerdefinierte Cloud Monitoring-Dashboards für beliebige Aggregationen bevorzugen

Nutzen Sie die Cloud Monitoring-Dashboards, um übergeordnete Ansichten mehrerer logischer Dienste auf einmal zu erstellen, anstatt die kanonischen Dienste künstlich in größere Bereiche für aggregierte Daten aufzublähen.

Kanonische Dienste sollen langlebig sein

Außerhalb der Entwicklungs-, Erkundungs- und Testanwendungsfälle sollten kanonische Dienste globale, allgemeine logische Dienste repräsentieren. Diese Dienste ändern sich langsam und sind meist langlebig. Diese Langlebigkeit umfasst auch das Nicht-Ändern von Dienstnamen. Sie können die Namen zwar ändern, das wirkt sich aber auf Messwerte, SLOs und Logs aus. Sie können das Feld Display name jedoch problemlos individuell anpassen.

Ein neuer kanonischer Dienst repräsentiert häufig neue oder aktualisierte Software, während ein kanonischer Dienst, der verschwindet, häufig einen eingestellten Dienst repräsentiert. Die Möglichkeit, die bisherige Leistung Ihres Dienstes zu sehen, zu planen und die Kapazität zu projektieren, hängt davon ab, ob Sie ein einziges Konzept dieses Dienstes in Cloud Service Mesh für seine Lebensdauer beibehalten.

Beachten Sie, dass sich dies auf untergeordnete Ressourcen wie VM-Instanzen, Kubernetes-Pods/-Deployments und sogar auf ganze Cluster bezieht. Diese werden häufig im Rahmen der Aktualisierung und Wartung von Produktionssystemen veröffentlicht.

Nächste Schritte