Während sich die Cloud-native-Technologie weiterentwickelt und verwandte Technologien zunehmend in den Produktionsabläufen von Unternehmen eingesetzt werden, gibt es zwei unumkehrbare Trends:
1. Die Zahl der Microservices nimmt zu. Es stellt sich heraus, dass riesige Einzeldienste ständig in Microservices zerlegt werden. Dies erleichtert zwar die Wiederverwendung von Funktionen und eine effiziente Iteration, bringt aber auch viele Herausforderungen für Betrieb und Wartung mit sich:
Kostenproblem: Wie soll der Lebenszyklus von Diensten und grundlegenden Ressourcenabhängigkeiten funktionieren? Wie kann die Existenz verwaister Ressourcen verhindert und Ressourcenverschwendung vermieden werden? Wie kann die Ressourcennutzung verbessert werden?
Effizienzproblem: Wie lassen sich einheitliche Dienste schnell und effizient bereitstellen? Servicesortierung und Chargenaufbau
Verantwortungszuweisung: Wie findet man angesichts einer enormen Zunahme an Dienstleistungen und Ressourcen die verantwortliche Person und das Team, zu dem sie gehört? (Wie findet man die richtige Person, die sich um ein Problem kümmert und es weiterverfolgt? Wie kann man die Kosten dem richtigen Team zuordnen?)
Hinweis: Dieser Artikel konzentriert sich hauptsächlich auf die Infrastrukturverwaltung sowie den Betrieb und die Wartung von Diensten und Dienstabhängigkeiten und konzentriert sich nicht auf das Upstream- und Downstream-Abhängigkeitsmanagement. Upstream- und Downstream-Abhängigkeiten können durch Service Governance (Abhängigkeitstopologie) usw. gelöst werden.
2. Dienste werden immer komplexer und stützen sich auf eine vielfältigere Infrastruktur (z. B. selbst erstellte Computerräume, Cloud-Computerräume, hybride Computerräume usw.) und auf immer mehr Middleware (z. B. selbst erstellte Systeme). (innerhalb von Unternehmen, großen Cloud-Anbietern usw.), Diensten usw.), müssen Benutzer die Unterschiede in diesen Infrastrukturen wahrnehmen?
Wenn man davon ausgeht, dass die Nutzungskosten für den Benutzer steigen werden, wie werden die Standards dies regeln?
Wie können diese zugrunde liegenden Unterschiede maskiert werden, wenn sie nicht wahrgenommen werden?
Lösungen
Um die beiden oben genannten Probleme zu lösen, müssen wir zunächst herausfinden, was die Ursache der oben genannten Probleme ist.
Problem 1: Informationsfragmentierung, Redundanz und fehlende Informationsaktualisierungen
Beispiel 1:
Derzeit konzentriert sich Didi intern auf die Rechenressourcen eines Dienstes (elastische Cloud-Ressourcen) sowie auf betriebs- und wartungsbezogene Attribute wie Beobachtung und Alarmierung der entsprechenden Service-Baumknoten. Die oben genannten Attribute sind alle über die Service-Baumknoten-ns miteinander verbunden. Speicherressourcen sind not Es gibt keine entsprechenden Zuordnungsmetainformationen (existiert nur in der Codekonfiguration). Es gibt keinen klaren Überblick über die vollständigen Abhängigkeiten, die den Betrieb eines Dienstes als Ganzes ermöglichen. Wenn Sie die vollständigen Abhängigkeiten verstehen möchten, muss der SRE die relevanten Betriebs- und Wartungsattribute sortieren und der Serviceleiter den Code überprüfen um die zugrunde liegenden Middleware-Abhängigkeiten zu klären.
Lösung: Abstraktion und Zuordnung von Rechenressourcen, Speicherressourcen und einigen Teilbetriebs- und Wartungskonfigurationen als Ganzes entsprechend der Servicedimension, sodass der Service eine Gesamtperspektive hat. Gleichzeitig kann das Ganze im Vergleich zu einem einzelnen Service verbessert werden Verwalten Sie den Lebenszyklus und vermeiden Sie verwaiste Ressourcen. Vermeiden Sie Ressourcenverschwendung. Sehen Sie sich das Anwendungsbeispiel in der Abbildung an, um alle IaaS-Ressourcen und PaaS-Ressourcen zu sehen, von denen eine Anwendung abhängt.
Gleichzeitig können durch die Beobachtung der Gesamtressourcennutzung des Dienstes Probleme einer geringen Ressourcenauslastung oder unzureichender Ressourcen rechtzeitig erkannt und entsprechende Maßnahmen zur Optimierung ergriffen werden.
Abstraktion der Anwendungszusammensetzung
Anwendungsbeispiele
Ansicht der Anwendungsressourcen-Governance
Beispiel 2:
Bei Szenarios für Website-Erstellung und Einheitenbereitstellung handelt es sich um den Prozess des manuellen Aussortierens von Serviceressourcen (Rechnerressourcen, Speicherressourcen, Betriebs- und Wartungskonfiguration usw., eine Reihe von Daten), der anschließenden stapelweisen Bereitstellung nacheinander und der abschließenden Zusammenstellung der Ressourcen Eins nach dem anderen nimmt einen großen Teil der Zeit in Anspruch. Da oft so viele Personen beteiligt sind (die Pünktlichkeit der Lieferung kann nicht garantiert werden und die Koordination der Arbeitskräfte ist besonders schwierig), ist es zeitaufwändig und mühsam. Wenn in diesem Prozess Probleme wie Auslassungen auftreten, führt dies erstens zu Nacharbeiten, erneuter Lieferung und Montage und zweitens führt die Abnahmephase zu einer Reihe unvorhersehbarer Probleme (die Zeit für Fehlerbehebung und Reparatur ist unkontrollierbar).
Lösung: Basierend auf der Gesamtabstraktion und Verknüpfung der oben genannten Dienste kann der Arbeitsaufwand für die manuelle Sortierung reduziert und anschließend eine einheitliche Bereitstellung durchgeführt werden. Neue Umgebungskonfigurationen können sogar automatisch generiert und die Umgebung automatisch bereitgestellt werden. Dadurch werden manuelles Kämmen, Auslassungen und manuelle Eingriffe erheblich reduziert.
Vergleich alter und neuer Liefermodelle
Beispiel 3:
Jede abhängige Ressource (Elastic Cloud, RDS usw.) verfügt über einen eigenen Satz von Verwaltungskontrollen und Metainformationen, die getrennt und nicht synchronisiert sind. Elastic Cloud und RDS haben beispielsweise ihre eigene verantwortliche Person und ihr eigenes Kostenzuordnungsteam. Die große Redundanz der Daten erschwert die Aktualisierung der Daten: Wenn sich Informationen ändern, müssen die relevanten Informationen aller Ressourcenplattformen gleichzeitig aktualisiert werden, und jede Ressource weist keine Korrelation auf (es ist äußerst schwierig, Korrelationsaktualisierungen zu erreichen). .
Bei Datenänderungen fehlt ein Aktualisierungsmechanismus. Beispielsweise ist der für den Dienst verantwortliche Student zurückgetreten, der Verantwortliche für die entsprechende Ressourcenplattform hat sich jedoch nicht geändert oder ist aus diesem Grund versetzt worden. Mit der Zeit werden diese Service-Metainformationen zu schmutzigen Daten. Wenn sie verwendet werden müssen, können wir die Personal- und Organisationszugehörigkeit nur manuell anhand verschiedener Daten wie früherer Personal- und Organisationsinformationen erraten.
Lösung: Basierend auf den oben genannten Problemen ist es zunächst erforderlich, die redundanten Daten jedes Systems in einer einheitlichen Kopie zu rationalisieren, sie in die Serviceebene zusammenzuführen und die Redundanz zu reduzieren. Zweitens: Richten Sie einen Datenzirkulationsmechanismus ein, um abnormale Daten regelmäßig zu überwachen und eine Reihe von Zirkulationsprozessen auszulösen, um sicherzustellen, dass die Daten rechtzeitig aktualisiert werden können.
Zusammenfassungsmanagement für Ressourceneigentümer
Problem 2: Mangel an höherdimensionaler Abstraktion
Die von Kubernetes herbeigeführte Revolution der Cloud-nativen Technologie liegt in der Standardisierung und Abstraktion der Infrastrukturschicht, aber diese Abstraktionsebene ist noch zu weit von der geschäftlichen Forschung und Entwicklung sowie dem Betrieb und der Wartung entfernt. Das typischste Beispiel ist, dass es in Kubernetes bis heute kein Konzept für „Anwendung“ gibt. Es bietet feinkörnigere „Workload“-Grundelemente wie Deployment oder DaemonSet. In der tatsächlichen Umgebung besteht eine Anwendung häufig aus einer Reihe unabhängiger Komponenten, z. B. einem Bestelldienst, der aus einem „Java-Anwendungscontainer“ und einer „Datenbankinstanz“ besteht, oder einem „Deployment + StatefulSet + HPA + Service + Ingress“. Microservice-Anwendungen.
SREs in den Bereichen Forschung, Entwicklung und Betrieb in Unternehmen waren gezwungen, über Nacht zu „Container-Experten“ zu werden, während sie verschiedene Konzepte im Bereich „Infrastruktur als Code (Infrastruktur als Code)“ lernten, die nicht ihr Anliegen sein sollten (z. B. Deklarationen, API, Controller usw.). ), während er sich darüber beschwert, dass Kubernetes zu kompliziert und das Design zu seltsam sei. Daher müssen wir eine standardisierte Methode bereitstellen, der jeder folgen kann, um Abstraktionen auf höherer Ebene der Anwendungsschicht zu definieren, und die „Trennung von Belangen“ als Kernidee dieses Definitionsmodells betrachten.
Insbesondere standardisiert OAM Anwendungsdefinitionsspezifikationen auf der Grundlage des Kubernetes API-Ressourcenmodells, das betont, dass eine moderne Anwendung eine Sammlung mehrerer Komponenten und keine einfache Arbeitslast oder ein K8s-Operator ist. Daher sind im Kontext von OAM ein Java-Container, die Datenbank, von der er abhängt, und die verschiedenen Cloud-Dienste, die er verwenden muss, allesamt Komponenten einer „Bestelldienst“-Anwendung. Darüber hinaus betrachtet OAM die für diese Anwendung erforderliche „Betriebs- und Wartungsstrategie“ als Teil einer Anwendung, beispielsweise die für diesen Java-Container erforderliche HPA (horizontale automatische Erweiterungsstrategie).
Beispiel für ein Service-OAM-Modell
Dieses plattformunabhängige Anwendungsdefinitionsparadigma ermöglicht es Anwendungsentwicklern, ihre Anwendungen nur durch OAM-Spezifikationen zu beschreiben, und die Anwendungen können auf jedem Kubernetes-Cluster oder jeder serverlosen Anwendungsplattform oder sogar Edge-Umgebung ausgeführt werden, ohne dass die Anwendungsbeschreibung geändert werden muss. Alle Änderungen.
Mit der Abstraktionsfähigkeit des OAM-Modells kapselt der Basisdienstanbieter (Plattformteam) hauptsächlich Basisdienste, die internen Benutzern bereitgestellt werden, basierend auf selbst erstellten Diensten, Cloud-Diensten und Cloud-Anbieterdiensten von Drittanbietern: wie interne elastische Cloud, RDS , Redis usw. , um die Unterschiede zwischen verschiedenen Cloud-Anbietern und verschiedenen Plattformen abzuschirmen. Für die Unternehmensforschung und -entwicklung (Endbenutzer) konzentriert es sich auf das Design von Geschäftslogik und bietet externe Dienste durch Orchestrierung von Elastic Cloud, RDS und anderen Infrastrukturen, wodurch die Lernkosten für die Plattformrelevanz gesenkt werden.
Plattform-F&E- und Unternehmens-F&E-Perspektiven
interne Praxis
Geschäftsabstraktion
Basierend auf der Analyse der oben genannten Probleme haben wir relevante Praktiken in der Branche untersucht. KubeVela ist eine Open-Source-Cloud-native Anwendungsorchestrierungs-Engine, die das Open Application Model (OAM)-Modell verwendet, um die Bereitstellung und den Betrieb von Anwendungen zu beschreiben und zu verwalten.
OAM ist ein offener Standard für Cloud-native Anwendungen, der eine einheitliche Möglichkeit zur Beschreibung und Verwaltung der Portabilität, Skalierbarkeit und Beobachtbarkeit von Anwendungen bieten soll. Das OAM-Modell bietet eine deklarative Möglichkeit, die Komponenten, Abhängigkeiten und Konfigurationen einer Anwendung zu beschreiben. Es entkoppelt Anwendungen von der zugrunde liegenden Infrastruktur, sodass sich Entwickler mehr auf die Anwendung selbst konzentrieren können, anstatt sich um die zugrunde liegende Laufzeitumgebung zu kümmern. Diese Abstraktion erhöht die Entwicklerproduktivität und vereinfacht die Anwendungsentwicklung und -bereitstellung.
OAM-Modell
Zusammenfassend lässt sich sagen, dass die Modelle KubeVela und OAM eine Möglichkeit bieten, die Anwendungsentwicklung und -verwaltung zu vereinfachen. Wie in der Abbildung oben gezeigt, handelt es sich um eine grobe Komponente einer Anwendung, die möglicherweise etwas abstrakt ist. Lassen Sie uns bestimmte Dienste innerhalb des Unternehmens nutzen als Beispiel:
Beispiele für die Anwendung von OAM
Nehmen Sie als Beispiel die Service-LocalPII-Anwendung, die aus den folgenden Komponenten besteht:
Servicekomponente: umfasst einen elastischen Cloud-Cluster-Cluster (Workload) und drei Merkmale ( Bereitstellungsmodul , das für die Codeaktualisierung verantwortlich ist , CutLog- Protokollschnitt für die Protokollbereinigung und Beobachtungsstrategie );
RDS-Komponente: Enthält RDS-Instanz (Workload), einschließlich Instanzinformationen, Geschäftstyp, Paketinformationen und Verbindungsinformationen (VIP+Port, Benutzername, Passwort);
S3-Komponente: Wie die RDS-Komponente enthält der S3-Bucket (Workload) den Bucket-Namen, den Bucket-Berechtigungstyp und Verbindungsinformationen;
BizConfig-Komponente: Enthält eine Reihe von Yaml-Konfigurationen und Verbindungsinformationen von RDS-Komponenten und S3-Komponenten. Sie wird letztendlich vom SDK genutzt und verwendet, um die Konfiguration der Dienstumgebung zu generieren.
Auf dieser Grundlage können wir die Dienstabhängigkeitstopologie abstrahieren und dann die Wartung von Metainformationen wie Diensten und Ressourcen in die Anwendungsdimension integrieren, wodurch Datenfragmentierung und -redundanz verringert und damit verbundene Informationsänderungsprozesse (Rücktritt, Live-Wasserübergabedienste) erhöht werden. und Lösen von Cloud-Problemen. Problem mit der Informationsaktualisierung.
Serviceressourcentopologie
Trennung von Bedenken
Das Geschäftsmodul wird auf Basis von KubeVela- und OAM-Modellen abstrahiert. Gleichzeitig steigt mit der Implementierung von Cloud-native-Technologie im Unternehmen auch die Komplexität von Infrastruktur und Basisdiensten. Am Beispiel des Basisdienstes RDS: die aktuelle Form von Das Unternehmen hat beim Aufbau von RDS, Diensten, die auf K8S-Dienstdefinitionen basieren, und RDS-Diensten verschiedener Cloud-Anbieter, wenn die zugrunde liegenden Details im Zusammenhang mit der geschäftlichen Forschung und Entwicklung nicht abgeschirmt sind, dann muss jede geschäftliche Forschung und Entwicklung die Unterschiede jedes Produkts und der Technik verstehen Details von K8S, was zu hohen Lernkosten führt. Steigend, während viele Standards und Spezifikationen nicht garantiert werden können.
Daher ist es notwendig, die Belange der Geschäftsentwicklung und der Plattformentwicklung zu trennen und die zugrunde liegenden Funktionen ohne geschäftliche Eingriffe zu iterieren und direkt von der App zu nutzen.
Plattformingenieur: Konzentrieren Sie sich auf die Abstraktion und Definition grundlegender Dienste und schützen Sie gleichzeitig die Unterschiede in der zugrunde liegenden Infrastruktur von Unternehmen der oberen Schicht, um die Lernkosten für Forschung und Entwicklung von Unternehmen der oberen Schicht zu senken.
Business R&D Engineer: Konzentrieren Sie sich auf die Geschäftslogik, orchestrieren Sie die zugrunde liegenden Basisdienste nach Bedarf und müssen Sie nicht auf Unterschiede in der zugrunde liegenden Infrastruktur achten.
Service-Separation of Concerns
Die Gesamtbereitstellung einer Anwendung ist wie folgt: Der Plattformanbieter, die Forschung und Entwicklung sowie die SRE konzentrieren sich alle auf ihre jeweiligen Verantwortlichkeiten und Anliegen, um sicherzustellen, dass der Dienst als Ganzes normal und effizient funktioniert.
Plattformanbieter: Die Infrastruktur sowie die Betriebs- und Wartungsplattform stellen Komponentendefinitionen und Komponentendienste bereit
Forschung und Entwicklung: Nutzen Sie das Anwendungszentrum, um die Servicearchitektur zu orchestrieren und die für das Geschäft erforderlichen Komponenten zu organisieren
SRE: Orchestrieren Sie Servicebetriebsfunktionen und -funktionen über das Anwendungscenter
RD + SRE: Gemeinsame Unterschiede in der Konfigurationsumgebung
Lieferzentrum: Stellt die Serviceumgebung bereit, einschließlich Ressourcen sowie Betriebs- und Wartungsmerkmale usw.
Neues Modell der Servicebereitstellung
Tatsächliche Produktimplementierung
Basierend auf der obigen Analyse und dem Gesamtdesign können wir es grob in vier Hauptfunktionsprodukte unterteilen.
Komponentenmarkt
Der Komponentenmarkt bietet hauptsächlich die Produktdefinition und -registrierung für verschiedene Basisdienste innerhalb des Unternehmens. Komponentenführer wie RDS, Kedis und Fusion definieren beispielsweise ihre eigenen Servicefunktionen auf dem Komponentenmarkt und sind für die Wartung der Komponentenfunktionen und die zugrunde liegende Multi verantwortlich -Cloud-Anpassung. Durch Pluggable Die Methode stellt dem Anwendungszentrum Funktionen zur Verfügung, und das F&E-Personal des Unternehmens ordnet Ressourcen und stellt Funktionen im Anwendungszentrum gemäß seinen eigenen Serviceanforderungen zusammen und stellt so externe Dienste bereit.
Komponentenmarkt
Anwendungszentrum
Application Center ist eine Plattform zur Verwaltung des Anwendungslebenszyklus, die Ressourcenabhängigkeiten sowie Betriebs- und Wartungseinrichtungen mit Diensten verknüpft. Es bietet eine vollständige Beschreibung von Anwendungen und schnelle Bereitstellungsfunktionen, erleichtert die Ressourcenverwaltung und verbessert die Bereitstellungseffizienz.
Zunächst wird der Kostenstellen-Organisationsbaum als Grundlage für die Bestimmung der Servicekostenzuordnung und der damit verbundenen Übertragungsfunktionen integriert. Zu den Anwendungsattributen gehören die für die Anwendung verantwortliche Person, das verantwortliche Team und die Kostenstelle, zu der sie gehören. Richten Sie Aktualisierungs- und Übertragungsmechanismen für die Zuweisung der Anwendungsverantwortung und der Kostenzuordnung ein und streben Sie danach, Dienstleistungen für Personen, Zuordnung zu Teams und Kosten bereitzustellen Abteilungen.
Application Center-Homepage
Application Center – Grundlegende Informationen
Zweitens bietet es Funktionen zur Orchestrierung von Servicekomponenten. F&E-Mitarbeiter in Unternehmen können erforderliche Ressourcenkomponenten gemäß ihren eigenen Serviceanforderungen zusammenstellen, um Servicefunktionen zu erreichen. Durch das Umgebungsmanagement des Anwendungszentrums können Servicecluster als Ganzes bereitgestellt und Servicecluster repliziert werden durchgeführt werden.
Orchestrierung von Application Center-Komponenten
Anwendungszentrum-Umweltmanagement
Cloud-native Betriebs- und Wartungsplattform
Reorganisieren Sie die Betriebs- und Wartungsverwaltungs- und Kontrollfunktionen (Bereitstellung/elastische Cloud/Beobachtung) mit der Anwendung (Servicemodul) als Zentrum und kombinieren Sie das Anwendungscenter mit dem Anwendungscenter, um die Beziehung zwischen der Anwendung (Servicemodul) zu binden und aufrechtzuerhalten. und Ressourcen zur Lösung von Lebenszyklusmanagement- und anderen Problemen.
Cloud-native Betriebs- und Wartungsplattform
Website-Erstellungszentrum
Das Website-Building-Center ist eine Bereitstellungsplattform für komplette Unternehmenswebsites, die auf der Grundlage des Application Centers erstellt wurde. Die Bereitstellungsfunktion basiert auf dem Application Center. Es bietet außerdem Linkverwaltung, Prozessverwaltung und andere Funktionen im Bereitstellungsprozess, um die Bereitstellungseffizienz zu verbessern der gesamten Website.
Website-Erstellungszentrum
Implementierung der Geschäftslinie
Internationale Geschäfte
Unter Berücksichtigung der Geschäftsmerkmale des internationalen Geschäfts, die eine häufigere Bereitstellung im Computerraum und eine höhere Liefereffizienz erfordern, arbeiten wir mit der internationalen Geschäftsarchitektur zusammen, um die Metainformationsintegration, die allgemeine Dienstabstraktion und das internationale Geschäfts-CaC (Konfiguration) zu lösen Anwendungszentrum. Das heißt, Code) Technologieimplementierung (differenzierte Konfigurationen von Computerräumen werden automatisch generiert), um die Servicebereitstellungseffizienz des gesamten Computerraums insgesamt zu verbessern. Derzeit bietet die Internationalisierung zwei große Vorteile:
Durch das Application Center Hosting (automatische Generierung der Ressourcentopologie und automatische Anwendung von Serviceressourcen) wird die manuelle Sortierung und Bereitstellungsbeteiligung reduziert. Durch die Implementierung der CaC-Technologie wird die Beteiligung der Geschäftsentwicklung an Konfigurationsänderungen und Online-Prozessen reduziert. Durch die Bereitstellung im gesamten Computerraum können weitere Einsparungen erzielt werden mehr als 30 % der menschlichen Investitionen.
Das Anwendungszentrum verwaltet den Ressourcenlebenszyklus als Ganzes und bietet Funktionen wie Kostenzuordnung und -übertragung, wodurch die früheren Probleme verwaister Ressourcen und der Unfähigkeit, Schnittstellen zu finden, gelöst werden, eine anwendungsdimensionale Kostenbeobachtung bereitgestellt wird und ein wichtiger Ausgangspunkt für nachfolgende Zwecke bereitgestellt wird Kostenmanagement.
Inländisches Geschäft
Die inländische Wirtschaftsförderung wird in diesem Jahr Projektmöglichkeiten wie den Bau inländischer multiaktiver Computerräume sowie Kostensenkung und Effizienzsteigerung nutzen:
Nutzen Sie die Funktionen des Anwendungszentrums und des Website-Erstellungszentrums, um die Effizienz des Aufbaus von Rechenressourcen in multiaktiven Computerräumen und die Konsistenz der Bereitstellung der Website-Erstellung zu verbessern.
Nutzen Sie die vom Anwendungszentrum bereitgestellten Wartungs- und Transferfunktionen von Anwendungsleitern, zugewiesenen Teams und zugeordneten Kostenstellen, um die Kostenberechnung zu fördern und den Teams Verantwortlichkeiten zuzuweisen, um Kostensenkungsprojekte voranzutreiben.
Cloud Native Night Talk
Wie verwenden Sie KubeVela in tatsächlichen Projekten? Welche Herausforderungen und Best Practices wurden festgestellt? Hinterlassen Sie gerne eine Nachricht im Kommentarbereich. Wenn Sie weiter mit uns kommunizieren möchten, können Sie auch direkt eine private Nachricht an das Backend senden.
Der Autor wählt eine der aussagekräftigsten Nachrichten aus und sendet ein auf Didi zugeschnittenes multifunktionales Cross-Pack. Der Preis wird am 14. September um 21 Uhr ausgelost.
