Kanonischer Dienst – Best Practices

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

Mit Kanonischen Diensten können Sie viele verschiedene Konfigurationen aufrufen. Optimale Nutzung mit Cloud Service Mesh Service-Dashboards: Berücksichtigen Sie bei der Einrichtung der Ihre Dienste:

  • Eindeutigen Dienst [Namespace, Name] im gesamten Mesh reservieren
  • Eine Softwareanwendung pro kanonischem Dienst definieren
    • Gruppieren Sie kanonische Dienste nicht umgebungsübergreifend (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 kanonischer Dienst, der in einem Cluster oder einer Region bereitgestellt wird, dieselbe Kubernetes-Umgebung hat Namespace und den Namen des kanonischen Dienstes, die in einem anderen Cluster bereitgestellt sind, oder Region geht, geht Cloud Service Mesh davon aus, 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önnen einen kanonischen Dienst zwar definieren, um mehrere konzeptionelle Mikrodienste zusammen verwenden, würden die Service Dashboards ihre vollständiger Wert.Das Service-Dashboard würde eine Aggregation unterschiedlicher Komponenten, die individuell leistungsfähig und unterschiedlich 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 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 Die Dienste sind nicht identisch und haben nicht dasselbe operative Niveau. oder Schwerpunkt auf Ihr Unternehmen legen.

So kann ein Fehler bei einem kritischen Produktionsdienst Feuergefechten. Sie möchten niemanden benachrichtigen, Bereitstellung schlägt fehl mitten in der Nacht. Dasselbe gilt für das Verständnis von Leistung, Kapazität und Releasesicherheit.

Von der einfachsten, aber am wenigsten strengen bis zur größten, aber kraftvollsten Es gibt drei Möglichkeiten, Dienste in 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. Ihr die bisherige Leistung Ihres Dienstes, Ihres Plans und Ihres Projekts sehen, sind alle davon abhängig, dass ein Dienst in einer Cloud Service Mesh für die Lebensdauer.

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