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. 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
    • Kanonische Dienste 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ö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.

Angefangen bei der einfachsten, aber am wenigsten strengen bis zur höchsten Leistung, 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