DE202022100357U1

DE202022100357U1 - Ein System zur Verkehrsabweisung für eine Hochleistungs-Gateway-Plattform mit phasenweiser Deaktivierung von Diensten

Info

Publication number: DE202022100357U1
Application number: DE202022100357.2U
Authority: DE
Original assignee: Individual
Current assignee: Bharti Pawan Kumar Prof Dr Amroha In; Bhuyan Hemanta Kumar Dr Kendrapada In; Brahma Biswajit Bhubaneswar In; Dhal Sunil Kumar Prof Dr Nayapalli In; Kamila Nilayam Kumar Bhubaneswar In; Majhi Santosh Kumar Dr Nayagarh In; Nukala Mahesh Guntur In; Pani Subhendu Kumar Prof Dr Kendrapara In
Priority date: 2022-01-22
Filing date: 2022-01-22
Publication date: 2022-03-08
Anticipated expiration: 2032-01-23

Abstract

Ein System zur Zurückweisung von Verkehr, das eine phasenweise, dienstweise Deaktivierung verwendet, wobei das System umfasst:
einen Gateway-Filter, der in einen Legacy-Gateway-Dienst eingeschlossen ist, wobei jede Anforderung abgefangen und durch den Gateway-Filter geleitet wird, bevor sie in ein Gateway-Dienstmodul gelangt;
eine kalenderbewusste Dienstschnittstelle, um die Namen der Dienste mit dem Datum der Außerbetriebnahme prozentual abzubilden, wobei die kalenderbewusste Dienstschnittstelle beginnt, einen Verkehr abzulehnen, wenn der Dienstname übereinstimmt und ein aktuelles Datum mit einem spezifizierten Datum in einer Konfigurationsdatei übereinstimmt oder größer als dieses ist; und
eine Filterlogik, die die Zurückweisung des Datenverkehrs in dem in der Konfigurationsdatei angegebenen Prozentsatz sicherstellt, um den robusten Deaktivierungsmechanismus für den spezifischen Dienst, der für die Deaktivierung in Frage kommt, zu gewährleisten.

Description

BEREICH DER ERFINDUNG
Die vorliegende Offenlegung bezieht sich auf ein System zur Zurückweisung von Verkehr für eine Hochleistungs-Gateway-Plattform, dass eine phasenweise Deaktivierung der einzelnen Dienste verwendet.
HINTERGRUND DER ERFINDUNG
Jede Plattform, die in früheren Tagen erstellt wurde, muss aufgrund veralteter Technologie, der Behebung von Sicherheitsproblemen oder weil die Plattform mit der Weiterentwicklung der Technologie oder der zugrundeliegenden Anwendungsprogrammsprache und/oder Frameworks nicht mehr relevant ist, außer Betrieb genommen werden. Das Gleiche gilt für Plattformen oder Anwendungen, die heute entwickelt werden und in einigen Jahren außer Betrieb genommen werden müssen.
Es gibt jedoch eine Reihe von Problemen, mit denen die Anwendungsleiter/-teams in der Regel konfrontiert werden, wenn sie sich der Herausforderung stellen, eine Middleware-Gateway-(Multi-Service-)Plattform stillzulegen. Wenn eine alte Plattform vollständig abgeschaltet werden soll und die Anruferquelle nicht identifizierbar ist, besteht definitiv ein hohes Risiko und viele Kunden sind davon betroffen. Die Plattform wird regelmäßig vom technischen Team überwacht, um die Quelle der Anrufe zu analysieren. Es gibt Situationen, in denen die Anrufe eines Kunden gestoppt wurden und in Zukunft nicht mehr gemäß der Service Level Kommunikation bearbeitet werden können. Da die Plattform noch in Betrieb ist, kann es vorkommen, dass die Kunden ihre Anrufe für einige Zeit unterbrechen und nach einigen Tagen den gleichen Service wieder aufnehmen, was von der Vereinbarung über die Service Level Kommunikation abweicht. Dies führt zu einem mehrmaligen Hin- und Herlaufen für die Außerbetriebnahme und Wiederaufnahme des Dienstes. Darüber hinaus sind viele technische Übungen und Anstrengungen erforderlich, um den Anruf auf der Ebene der Legacy-Serviceklasse abzulehnen oder abzuschalten. Bitte beachten Sie das Class Design Diagram als Referenz. Viel Koordination auf der Ebene des technischen Programms ist erforderlich, um die Termine festzulegen und die Änderungen für die Stilllegung des Dienstes an PROD weiterzugeben. Dies gilt es zu vermeiden.
In Anbetracht der vorangegangenen Diskussion wird deutlich, dass ein System zur Zurückweisung des Verkehrs unter Verwendung einer phasenweisen Deaktivierung der einzelnen Dienste erforderlich ist.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Offenlegung zielt darauf ab, ein System zur Verfügung zu stellen, dass eine phasenweise Deaktivierung von Diensten mit einem langsamen prozentualen Mechanismus zur Zurückweisung von Verkehr ermöglicht, um eine begrenzte Anzahl von betroffenen Kunden zu gewährleisten und den Explosionsradius der Auswirkungen auf den Kunden zu reduzieren.
In einer Ausführungsform wird ein System zur Zurückweisung von Datenverkehr offenbart, dass eine phasenweise Deaktivierung der einzelnen Dienste verwendet. Das System umfasst einen Gateway-Filter, der in einen Legacy-Gateway-Dienst eingewickelt ist, wobei jede Anforderung abgefangen und durch den Gateway-Filter geleitet wird, bevor sie in ein Gateway-Dienstmodul gelangt. Das System umfasst ferner eine kalenderbewusste Dienstschnittstelle, um die Namen der Dienste prozentual mit dem Datum der Außerbetriebnahme abzubilden, wobei die kalenderbewusste Dienstschnittstelle beginnt, einen Datenverkehr abzulehnen, wenn der Dienstname übereinstimmt und ein aktuelles Datum mit einem angegebenen Datum in einer Konfigurationsdatei übereinstimmt oder größer als dieses ist. Das System enthält ferner eine Filterlogik, um die prozentuale Zurückweisung des Datenverkehrs zu gewährleisten, die in der Konfigurationsdatei angegeben ist, um den robusten Inaktivierungsmechanismus für den spezifischen Dienst, der deaktiviert werden soll, sicherzustellen.
In einer anderen Ausführungsform umfasst das System eine Schnittstelle zur Steuerung des Verkehrs-Cache, um die prozentuale Ablehnung des Verkehrs für den jeweiligen Dienst zu steuern.
In einer anderen Ausführungsform umfasst der in der Konfigurationsdatei angegebene Prozentsatz 1 % Verkehrsverweigerung an einem ersten Datum, 10 % Verkehrsverweigerung an einem zweiten Datum und so weiter bis zu 100 % Verkehrsverweigerung, die belastbar ist.
In einer anderen Ausführungsform wird die gesamte Liste einer kalendergesteuerten Strategie zugeordnet. Wenn das Datum kommt, werden die neuen Dienste in die Liste der Dienstnamen aufgenommen, und der Verkehr für alle Dienste, deren Name mit den Namen der Dienstliste übereinstimmt, wird ab dem jeweiligen Datum abgewiesen.
In einer Ausführungsform wird der Ablehnungsprozess fortgesetzt, und am Ende der im Kalender angegebenen Daten werden automatisch alle Dienste in die Liste aufgenommen, und schließlich wird der gesamte Verkehr abgelehnt, wenn ein Gateway vollständig abgeschaltet werden muss.
In einer anderen Ausführungsform werden die Stilllegungsdaten einmalig allen Kunden der Beteiligten mitgeteilt, und die nach Datum geordneten Namen der Dienste werden in die Eigenschaftsdatei aufgenommen, die von jedem Kunden vor der einmaligen Weitergabe an PROD überprüft und abgezeichnet wird.
In einer anderen Ausführungsform ist eine Vielzahl von Clients mit dem Gateway-Dienst verbunden, in dem mehrere Dienste gehostet werden, und die Vielzahl der Clients kann die Konfigurationsdatei ändern und aktualisieren.
Ein Ziel der vorliegenden Offenlegung ist es, viele alte bestehende Legacy-Dienste stillzulegen, um die hochleistungsfähige Plattform sauber und fähig zu machen, jederzeit schnellere Kommunikation zu verarbeiten.
Ein weiteres Ziel der vorliegenden Offenlegung ist die Entwicklung einer dienstweisen langsamen Deaktivierung (inkrementelle Verkehrsverweigerung), die eine günstigere Situation für die Deaktivierung einzelner oder mehrerer Gateway-Dienste in einem anmutigen, belastbaren Verfahren darstellt.
Ein weiteres Ziel der vorliegenden Erfindung ist es, eine schnelle und kosteneffiziente Dienst-zu-Dienst-Deaktivierung in Phasen mit einem langsamen prozentualen Verkehrsabweisungsmechanismus zu liefern, um eine begrenzte (sehr wenige, wenn überhaupt) Anzahl von Kunden zu gewährleisten, die betroffen sind, und um den Explosionsradius des Kunden zu reduzieren.
Zur weiteren Verdeutlichung der Vorteile und Merkmale der vorliegenden Offenbarung wird eine genauere Beschreibung der Erfindung durch Bezugnahme auf bestimmte Ausführungsformen gegeben, die in den beigefügten Figuren dargestellt sind. Es wird davon ausgegangen, dass diese Figuren nur typische Ausführungsformen der Erfindung darstellen und daher nicht als Einschränkung des Umfangs der Erfindung zu betrachten sind. Die Erfindung wird mit zusätzlicher Spezifität und Detail mit den beigefügten Figuren beschrieben und erläutert werden.
Figurenliste
Diese und andere Merkmale, Aspekte und Vorteile der vorliegenden Offenbarung werden besser verstanden, wenn die folgende detaillierte Beschreibung unter Bezugnahme auf die beigefügten Figuren gelesen wird, in denen gleiche Zeichen gleiche Teile in den Figuren darstellen, wobei:

1 ein Blockdiagramm eines Verkehrsrückweisungssystems mit phasenweiser dienstweiser Deaktivierung in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt; und
2 die Architektur eines kalendergesteuerten langsamen Ablehnungs-Gateway-Filterdienst-Stilllegungssystems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.

Der Fachmann wird verstehen, dass die Elemente in den Figuren der Einfachheit halber dargestellt sind und nicht unbedingt maßstabsgetreu gezeichnet wurden. Die Flussdiagramme veranschaulichen beispielsweise das Verfahren anhand der wichtigsten Schritte, um das Verständnis der Aspekte der vorliegenden Offenbarung zu verbessern. Darüber hinaus kann es sein, dass eine oder mehrere Komponenten der Vorrichtung in den Figuren durch herkömmliche Symbole dargestellt sind, und dass die Figuren nur die spezifischen Details zeigen, die für das Verständnis der Ausführungsformen der vorliegenden Offenbarung relevant sind, um die Figuren nicht mit Details zu überfrachten, die für Fachleute, die mit der vorliegenden Beschreibung vertraut sind, leicht erkennbar sind.
DETAILLIERTE BESCHREIBUNG
Um das Verständnis der Erfindung zu fördern, wird nun auf die in den Figuren dargestellte Ausführungsform Bezug genommen und diese mit bestimmten Worten beschrieben. Es versteht sich jedoch von selbst, dass damit keine Einschränkung des Umfangs der Erfindung beabsichtigt ist, wobei solche Änderungen und weitere Modifikationen des dargestellten Systems und solche weiteren Anwendungen der darin dargestellten Grundsätze der Erfindung in Betracht gezogen werden, wie sie einem Fachmann auf dem Gebiet der Erfindung normalerweise einfallen würden.
Der Fachmann wird verstehen, dass die vorstehende allgemeine Beschreibung und die folgende detaillierte Beschreibung beispielhaft und erläuternd für die Erfindung sind und nicht als einschränkend angesehen werden.
Wenn in dieser Beschreibung von „einem Aspekt“, „einem anderen Aspekt“ oder ähnlichem die Rede ist, bedeutet dies, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die im Zusammenhang mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Offenbarung enthalten ist. Daher können sich die Ausdrücke „in einer Ausführungsform“, „in einer anderen Ausführungsform“ und ähnliche Ausdrücke in dieser Beschreibung alle auf dieselbe Ausführungsform beziehen, müssen es aber nicht.
Die Ausdrücke „umfasst“, „enthaltend“ oder andere Variationen davon sollen eine nicht ausschließliche Einbeziehung abdecken, so dass ein Verfahren oder eine Methode, die eine Liste von Schritten umfasst, nicht nur diese Schritte umfasst, sondern auch andere Schritte enthalten kann, die nicht ausdrücklich aufgeführt sind oder zu einem solchen Verfahren oder einer solchen Methode gehören. Ebenso schließen eine oder mehrere Vorrichtungen oder Teilsysteme oder Elemente oder Strukturen oder Komponenten, die mit „umfasst...a“ eingeleitet werden, nicht ohne weitere Einschränkungen die Existenz anderer Vorrichtungen oder anderer Teilsysteme oder anderer Elemente oder anderer Strukturen oder anderer Komponenten oder zusätzlicher Vorrichtungen oder zusätzlicher Teilsysteme oder zusätzlicher Elemente oder zusätzlicher Strukturen oder zusätzlicher Komponenten aus.
Sofern nicht anders definiert, haben alle hierin verwendeten technischen und wissenschaftlichen Begriffe die gleiche Bedeutung, wie sie von einem Fachmann auf dem Gebiet, zu dem diese Erfindung gehört, allgemein verstanden wird. Das System, die Methoden und die Beispiele, die hier angegeben werden, dienen nur der Veranschaulichung und sind nicht als Einschränkung gedacht.
Ausführungsformen der vorliegenden Offenbarung werden im Folgenden unter Bezugnahme auf die beigefügten Figuren im Detail beschrieben.
In 1 ist ein Blockdiagramm eines Verkehrsrückweisungssystems mit phasenweiser dienstweiser Deaktivierung in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung dargestellt. Das System 100 umfasst einen Gateway-Filter 102, der in einen Legacy-Gateway-Dienst 110 eingewickelt ist, wobei jede Anforderung abgefangen und durch den Gateway-Filter 102 geleitet wird, bevor sie in ein Gateway-Dienstmodul 104 gelangt.
In einer Ausführungsform wird eine kalenderbewusste Serviceschnittstelle 106 verwendet, um die Namen der Dienste prozentual mit dem Datum der Außerbetriebnahme abzubilden, wobei die kalenderbewusste Serviceschnittstelle 106 beginnt, einen Datenverkehr abzulehnen, wenn der Name des Dienstes übereinstimmt und ein aktuelles Datum mit einem angegebenen Datum in einer Konfigurationsdatei übereinstimmt oder größer als dieses ist.
In einer Ausführungsform ist eine Filterlogik 108 so konfiguriert, dass sie die in der Konfigurationsdatei angegebene prozentuale Zurückweisung des Datenverkehrs sicherstellt, um den robusten Deaktivierungsmechanismus für den spezifischen, zu deaktivierenden Dienst zu gewährleisten.
In einer anderen Ausführungsform umfasst das System eine Schnittstelle zur Steuerung des Verkehrsspeichers, um die prozentuale Ablehnung des Verkehrs für den jeweiligen Dienst zu steuern.
In einer anderen Ausführungsform umfasst der in der Konfigurationsdatei angegebene Prozentsatz 1 % Verkehrsverweigerung an einem ersten Datum, 10 % Verkehrsverweigerung an einem zweiten Datum und so weiter bis zu 100 % Verkehrsverweigerung, die belastbar ist.
In einer anderen Ausführungsform wird die gesamte Liste einer kalendergesteuerten Strategie zugeordnet. Wenn das Datum kommt, werden die neuen Dienste in die Liste der Dienstnamen aufgenommen, und der Verkehr für alle Dienste, deren Name mit den Namen der Dienstliste übereinstimmt, wird ab dem jeweiligen Datum abgewiesen.
In einer Ausführungsform wird der Ablehnungsprozess fortgesetzt, und am Ende der im Kalender angegebenen Daten werden automatisch alle Dienste in die Liste aufgenommen, und schließlich wird der gesamte Verkehr abgelehnt, wenn ein Gateway vollständig abgeschaltet werden muss.
In einer anderen Ausführungsform werden die Stilllegungsdaten allen Kunden der Beteiligten einmalig mitgeteilt, und die datumsbezogenen Dienstnamen werden in die Eigenschaftsdatei aufgenommen, die von jedem Kunden vor dem einmaligen Roll-out an PROD überprüft und abgezeichnet wird.
In einer anderen Ausführungsform ist eine Vielzahl von Clients mit dem Gateway-Dienst verbunden, in dem mehrere Dienste gehostet werden, und die Vielzahl der Clients kann die Konfigurationsdatei ändern und aktualisieren.
2 veranschaulicht die Architektur eines kalendergesteuerten, langsamen Ablehnungs-Gateway-Filterdienst-Stilllegungssystems gemäß einer Ausführungsform der vorliegenden Offenlegung: Ein API-Gateway 202 ist eine Schnittstelle zwischen einem Client und einer Sammlung von Backend-Diensten.
In einer Ausführungsform ist eine Route 53 204 so konfiguriert, dass sie automatische Anfragen über das Internet an eine Ressource, z. B. einen Webserver, sendet, um zu überprüfen, ob diese erreichbar, verfügbar und funktionsfähig ist.
In einer Ausführungsform fungiert ein Load Balancer 206 als Reverse Proxy und verteilt den Netzwerk- oder Anwendungsverkehr auf eine Reihe von Servern.
In einer Ausführungsform wird eine Gateway-Filterklasse 102 auf die alte Gateway-Dienstklasse 110 aufgesetzt. Es wird eine kalenderabhängige Serviceschnittstelle 106 eingeführt, die die Namen der Dienste mit dem Datum der Stilllegung in Prozent abbildet, d. h. an einem Datum wird 1 % des Datenverkehrs abgelehnt, am nächsten abgebildeten Datum werden 10 % des Datenverkehrs abgelehnt und so weiter bis zu einer 100%igen Ablehnung des Datenverkehrs.
In einer Ausführungsform wird in der Gateway-Filter-Wrapper-Klasse 102 jede Anfrage abgefangen und durch die Klasse geleitet, bevor sie in das Gateway-Dienstmodul 104 gelangt. Während sie durch die Wrapper-Klasse gefiltert wird, wird jeder Dienstname in der Anfrage mit den definierten Dienstnamenkarten abgeglichen, die von der kalenderabhängigen Dienstschnittstelle 106 bereitgestellt werden. Der Datenverkehr wird abgelehnt, wenn der Dienstname übereinstimmt und das aktuelle Datum mit dem in der Konfigurationsdatei angegebenen Datum übereinstimmt oder größer ist als dieses. Die Filterlogik 108 stellt sicher, dass der Datenverkehr zu dem in der Konfigurationsdatei angegebenen Prozentsatz zurückgewiesen wird. Diese langsame Zurückweisung des Datenverkehrs gewährleistet einen robusten Deaktivierungsmechanismus für den spezifischen Dienst, der zur Deaktivierung vorgesehen ist. Wenn das Datum kommt, werden die neuen Dienste in die Liste der Dienstnamen aufgenommen, und der Datenverkehr für alle Dienste, deren Namen mit den Namen der Dienstliste übereinstimmen, wird ab dem jeweiligen Datum abgelehnt.
In einer Ausführungsform wird dieser Prozess fortgesetzt, wenn ein Gateway vollständig abgeschaltet werden muss, und am Ende der im Kalender festgelegten Daten werden automatisch alle Dienste in die Liste aufgenommen, und schließlich wird der gesamte Datenverkehr abgewiesen. Auf diese Weise wird ein langsamer, stetiger und innovativer Prozess in Gang gesetzt, der mit seiner belastbaren Strategie (stetiger Prozentsatz der Verkehrsabweisung von 1 % bis 100 %) sehr stark auf die Kalenderdaten abgestimmt ist. Die Daten der Stilllegung werden allen Kunden der Beteiligten einmalig mitgeteilt, und die datumsbezogenen Dienstnamen werden in die Eigenschaftsdatei aufgenommen, die von jedem Kunden vor dem einmaligen Roll-out an PROD überprüft und abgezeichnet werden kann.
Hier sind die Vorteile für diese vorgeschlagene Lösung aufgeführt. Diese Praxis hilft sehr dabei, den Gateway-Verkehr stetig und belastbar mit reduziertem Sprengradius abzulehnen. einmalige Änderung zur Einführung der Gateway-Filter-Wrapper-Klasse 102 und der kalenderbewussten Programmzuordnung zu den Dienstnamen, Datum und Prozentsatz der Verkehrsablehnung. Einmalige Abmeldung für die Daten und die Servicenamen bei den Clients. Einmaliger Non-Prod- und PROD-Rollout, die in Non-Prod stillgelegten Dienste werden automatisch nach einer bestimmten Zeit (z.B. 30 Tage) in PROD stillgelegt. Das bedeutet, dass sich das Datum der Service-Stilllegung in Non-Prod und Prod um eine bestimmte Zeitspanne unterscheidet, z.B. 30 Tage in idealen Szenarien für eine große Unternehmensorganisation. Automatische Stilllegung von Services gemäß den Service Level Communication Agreements innerhalb interner und externer Kundenteams/Stakeholder. Die prozentuale Ablehnung des Datenverkehrs stellt sicher, dass der Kunde im Falle eines Problems in Echtzeit reagieren kann.
In der Figur des Klassenentwurfsdiagramms können Sie sehen, dass die Gateway-Filterklasse 102 eine kalenderabhängige Schnittstelle verwendet, die den Kalendertag auswertet und die in der Eigenschaftsdatei definierten Dienste einschließt. Die Diensteliste enthält alle Dienste, deren Verkehr abgelehnt wird. Im Laufe des Tages werden weitere Dienste in die Diensteliste aufgenommen (d. h., die CalendarAwareInterfacecomponent nimmt den Dienstnamen in die Liste auf, wenn das betreffende Datum im Kalender des Systems erscheint), und es werden mehr Dienstanfragen abgelehnt.
Wenn ein Kunde an einem beliebigen Tag schreit, kann eine genauere Analyse vorgenommen werden, an welchen Tagen das Problem bei den Kunden auftrat und welche Dienste an den genannten Tagen in den Dienstlisten aufgeführt sind. Um die Schreie zu reduzieren, könnte der Verkehr zum inaktiven Cluster 210 umgeleitet werden, wie in der Figur des Systemdiagramms dargestellt. Dadurch wird die Schrei-Strategie gestrafft und automatisiert, um die Strategie der automatischen Stilllegung zu gewährleisten.
In einer Ausführungsform sind mehrere Clients mit einem Gateway-Dienst verbunden, in dem mehrere Dienste gehostet werden. Alle Kunden, die den zu deaktivierenden Dienst in Anspruch nehmen, müssen mit diesem Modell kommuniziert werden, und auf der Grundlage der Eingaben der Kunden und ihrer Zustimmung muss die Konfigurationsdatei geändert und aktualisiert werden. Wenn zu Beginn der Kommunikation kein konkreter Zeitpunkt vereinbart werden konnte, kann ein vorläufiges Datum genannt werden, um mit dem Plan und dem Prozess fortzufahren; zu einem späteren Zeitpunkt können die Konfigurationseigenschaften ohne Einsatz geändert werden. Die Gateway-Anwendung wird die Konfiguration dynamisch laden, um die neuesten Eigenschaftswerte zu berücksichtigen.
In einer Ausführungsform ist ein aktiver Cluster 208 eine Datenausfallsicherheitsarchitektur, bei der Client-Arbeitslasten auf zwei oder mehr Knoten in einem Cluster verteilt werden, um Ihre Daten im Falle eines unerwarteten Komponentenausfalls sicher und verfügbar zu halten.
Der Client bereitet eine Konfigurationsdatei vor, die aus Service Name: Daten für 1 Prozent Traffic-Ablehnung: Datum für 1 Prozent Traffic-Ablehnung: Daten für 10 Prozent Traffic-Ablehnung: Datum für 10 Prozent Traffic-Ablehnung: Daten für 25 Prozent Traffic-Ablehnung: Datum für 25 Prozent Traffic-Ablehnung: Daten für 50 Prozent Traffic-Ablehnung: Datum für 50 Prozent Traffic-Ablehnung: Datum für 100 Prozent Traffic-Ablehnung formatierte Datei wird in den Anwendungseigenschaften gepflegt.
In einer Ausführungsform wird die Konfigurationsdatei geladen und die kalenderabhängige Schnittstelle sowie die Schnittstelle zur Cache-Verkehrskontrolle werden initialisiert. Das Datum der 1%igen Verkehrsabweisung beginnt an dem Datum, das in Datum für 1%ige Verkehrsabweisung für den jeweiligen Client und den jeweiligen Dienst angegeben ist. Das Datum für die Ablehnung von 10 % des Datenverkehrs beginnt an dem Datum, das in Datum für die Ablehnung von 10 % des Datenverkehrs für den jeweiligen Client und den jeweiligen Dienst angegeben ist. Das Datum für die Ablehnung von 25 % Traffic beginnt an dem Datum, das in Datum für die Ablehnung von 25 % Traffic für den jeweiligen Kunden und den jeweiligen Dienst angegeben ist. Das Datum der 50%igen Traffic-Ablehnung beginnt an dem Datum, das in Datum für 50%ige Traffic-Ablehnung für den jeweiligen Kunden und den jeweiligen Dienst angegeben ist. Das Datum der 100%igen Traffic-Ablehnung beginnt an dem Datum, das in Datum für 100%ige Traffic-Ablehnung für den jeweiligen Kunden und den jeweiligen Dienst angegeben ist.
Erfindungen und Leistungen:
Dies ist ein Konzept, das die Abschaltung von Legacy-Anwendungsdiensten aufgrund von veralteter Technologie und Sicherheitsproblemen erleichtern soll. Jede Plattform, die in früheren Zeiten gebaut und heute verwendet wird, muss aufgrund der folgenden Nachteile abgeschaltet werden.
Die Gateway-Anwendung kann nicht auf neue Umgebungen aufgerüstet werden. Alte Software hat viele Sicherheitsmängel. Support und Wartung der Anwendung sind teuer und aufgrund der Nichtverfügbarkeit von KMUs. Fehler oder Produktionsprobleme können nicht schnell behoben werden und es gibt keine einfachen Lösungsmöglichkeiten. Neuere technologische Methoden konnten von der Anwendung nicht übernommen werden.
Unsere Erfindung wird den Prozess der Anwendungsabschaltung vereinfachen. Eine Gateway-Anwendung ist von vielen Client-Anwendungen abhängig. Unser innovatives Design sorgt für eine reibungslose Beendigung der Client-Anwendungen, so dass die Gateway-Anwendung elastisch und mit weniger Client-Koordination außer Betrieb genommen werden kann.
Einzigartigkeit der Erfindung:
Die Erfindung ist eine zusätzliche Komponente, die in die Gateway-Anwendung integriert wird. Diese Komponente filtert die Anfrage und beginnt mit der (schrittweisen) Ablehnung der Anfrage ab einem mit dem Client Application Team vereinbarten Kalenderdatum. Diese Ablehnungen erstrecken sich über einen bestimmten Zeitraum von Tagen mit einem schrittweisen Prozentsatz des Datenverkehrs. Am Ende der Tage werden 100% des Datenverkehrs für den Dienst abgelehnt. Wenn dieser Datenverkehr ungenutzt ist, wird sich das Kundenanwendungsteam nicht beschweren, aber wenn es sich um wichtigen Datenverkehr handelt, muss das Kundenteam nach dem vereinbarten Plan arbeiten, um den jeweiligen abzuschaltenden Dienst zu erreichen.
In einer Ausführungsform, verschiedene beanspruchte Komponenten:

Hier sind die Bestandteile unserer Erfindung
- - Gateway-Dienstfilter für die Ablehnung von Datenverkehr.
- - Calendar Aware Service, um mit Gateway Service Traffic Filter Rejections abgeglichen zu werden.
- - Traffic Cache Control Aware Interface zur Kontrolle der prozentualen Ablehnung des Verkehrs für den jeweiligen Dienst.

In einer Ausführungsform umfasst das System mehrere Schritte:

Mehrere Clients sind mit einem Gateway-Dienst verbunden, in dem mehrere Dienste gehostet werden. Alle Clients und der Eigentümer des Dienstes müssen mit diesem Modell kommuniziert werden. Auf der Grundlage der Eingaben der Clients und ihrer Zustimmung ist die Konfigurationsdatei zu ändern und zu aktualisieren. Wenn zu Beginn der Kommunikation kein konkreter Zeitpunkt vereinbart werden konnte, kann ein vorläufiges Datum genannt werden, um mit dem Plan und dem Prozess fortzufahren. Zu einem späteren Zeitpunkt können die Konfigurationseigenschaften geändert werden, ohne dass eine Bereitstellung erfolgt. Die Gateway-Anwendung wird die Konfiguration dynamisch laden, um die neuesten Eigenschaftswerte zu berücksichtigen.

In einer Ausführungsform könnte der Schrei der Clients/Verbraucher für einen bestimmten Tag eingeschränkt werden, wobei der Verkehr gnädigerweise abgelehnt wird. Jeder Dienst kann bei Bedarf reaktiviert werden. Die Reaktivierung liefert auch die Details, von denen der Anruf ausgeht, und auf dieser Grundlage kann eine neue Kommunikation auf Dienstebene mit den Kundeneigentümern zum Zweck der Deaktivierung des Dienstes hergestellt werden. Diese Strategie der automatischen Außerbetriebnahme funktioniert gut und stellt sicher, dass der veraltete, alte und nicht wartbare Dienst nur bei Änderungen der Konfigurationseigenschaften automatisch außer Betrieb genommen wird, und zwar auf eine sehr robuste Weise. Bei jeder Änderung der Kommunikation auf Dienstebene und der Verpflichtungen könnte die Änderung der Eigenschaftsdatei in Github aufgenommen werden, und dann könnte die Cloud-Config-Strategie zur Steuerung der Stilllegung des Dienstes herangezogen werden.
Das entwickelte System ermöglicht eine langsame Deaktivierung von Diensten (inkrementelle Ablehnung von Datenverkehr), was eine günstigere Situation darstellt, in der wir in der Lage sind, einzelne oder mehrere Gateway-Dienste in einer anmutigen, belastbaren Methode zu deaktivieren. Ein allgemeineres Problem besteht darin, dass eine Plattform mehrere Dienste als Gateway/Proxy/Pass-Through-Middleware enthält, und wenn die Plattform oder ein einzelner Anwendungsdienst vollständig abgeschaltet werden muss, sind mehrere Clients davon betroffen. Um sicherzustellen, dass nur eine begrenzte Anzahl von Clients betroffen ist (wenn überhaupt) und um den Radius der Auswirkungen auf die Clients zu reduzieren, schlagen wir eine phasenweise Deaktivierung der einzelnen Dienste mit einem Mechanismus zur Ablehnung von langsamem Datenverkehr vor. Auf diese Weise wird der veraltete und/oder nicht mehr zu wartende Dienst mit einem anmutigen Ausfallsicherheitsmechanismus und ohne oder mit nur geringen Auswirkungen auf die Clients deaktiviert (geringe oder gar keine Auswirkungen).
Die Figuren und die vorangehende Beschreibung geben Beispiele für Ausführungsformen. Der Fachmann wird verstehen, dass eines oder mehrere der beschriebenen Elemente durchaus zu einem einzigen Funktionselement kombiniert werden können. Alternativ dazu können bestimmte Elemente in mehrere Funktionselemente aufgeteilt werden. Elemente aus einer Ausführungsform können einer anderen Ausführungsform hinzugefügt werden. Die Reihenfolge der hier beschriebenen Prozesse kann beispielsweise geändert werden und ist nicht auf die hier beschriebene Weise beschränkt. Darüber hinaus müssen die Aktionen eines Flussdiagramms nicht in der gezeigten Reihenfolge ausgeführt werden; auch müssen nicht unbedingt alle Aktionen durchgeführt werden. Auch können die Handlungen, die nicht von anderen Handlungen abhängig sind, parallel zu den anderen Handlungen ausgeführt werden. Der Umfang der Ausführungsformen ist durch diese spezifischen Beispiele keineswegs begrenzt. Zahlreiche Variationen sind möglich, unabhängig davon, ob sie in der Beschreibung explizit aufgeführt sind oder nicht, wie z. B. Unterschiede in der Struktur, den Abmessungen und der Verwendung von Materialien. Der Umfang der Ausführungsformen ist mindestens so groß wie in den folgenden Ansprüchen angegeben.
Vorteile, andere Vorzüge und Problemlösungen wurden oben im Hinblick auf bestimmte Ausführungsformen beschrieben. Die Vorteile, Vorzüge, Problemlösungen und Komponenten, die dazu führen können, dass ein Vorteil, ein Nutzen oder eine Lösung auftritt oder ausgeprägter wird, sind jedoch nicht als kritisches, erforderliches oder wesentliches Merkmal oder Komponente eines oder aller Ansprüche zu verstehen.
Bezugszeichenliste

100-: Ein System zur Unterdrückung des Datenverkehrs für eine Hochleistungs-Gateway-Plattform mit phasenweiser Deaktivierung einzelner Dienste
102: Gateway-Filter
104: Gateway-Dienstmodul
106: Kalenderabhängige Dienstschnittstelle
108: Filter-Logik
110: Älterer Gateway-Dienst
202: API-Gateway
204: Weiterleitung 53
206: Lastausgleicher
208: Aktive Cluster, Aktive Traffics
210: Aktive Cluster, Aktive Traffics

Claims

Ein System zur Zurückweisung von Verkehr, das eine phasenweise, dienstweise Deaktivierung verwendet, wobei das System umfasst: einen Gateway-Filter, der in einen Legacy-Gateway-Dienst eingeschlossen ist, wobei jede Anforderung abgefangen und durch den Gateway-Filter geleitet wird, bevor sie in ein Gateway-Dienstmodul gelangt; eine kalenderbewusste Dienstschnittstelle, um die Namen der Dienste mit dem Datum der Außerbetriebnahme prozentual abzubilden, wobei die kalenderbewusste Dienstschnittstelle beginnt, einen Verkehr abzulehnen, wenn der Dienstname übereinstimmt und ein aktuelles Datum mit einem spezifizierten Datum in einer Konfigurationsdatei übereinstimmt oder größer als dieses ist; und eine Filterlogik, die die Zurückweisung des Datenverkehrs in dem in der Konfigurationsdatei angegebenen Prozentsatz sicherstellt, um den robusten Deaktivierungsmechanismus für den spezifischen Dienst, der für die Deaktivierung in Frage kommt, zu gewährleisten.
System nach Anspruch 1, wobei das System eine Schnittstelle zur Steuerung des Verkehrs-Caches umfasst, um die prozentuale Zurückweisung des Verkehrs für den jeweiligen Dienst zu steuern.
System nach Anspruch 1, wobei der in der Konfigurationsdatei angegebene Prozentsatz 1 % Verkehrsabweisung an einem ersten Datum, 10 % Verkehrsabweisung an einem zweiten Datum und so weiter bis zu 100 % Verkehrsabweisung elastisch umfasst.
Das System nach Anspruch 1, wobei die gesamte Liste auf eine kalenderbewusste Strategie abgebildet wird, wobei wenn das Datum kommt, werden die neuen Dienste in die Liste der Dienstnamen aufgenommen, und der Verkehr für all jene Dienste, deren Name mit den Namen der Dienstliste übereinstimmt, wird ab den jeweiligen Daten abgewiesen.
System nach Anspruch 1 und 4, wobei der Ablehnungsprozess fortgesetzt wird und automatisch am Ende der im Kalender angegebenen Daten alle Dienste in die Liste aufgenommen werden und schließlich der gesamte Verkehr abgelehnt wird, wenn ein Gateway vollständig abgeschaltet werden muss.
System nach Anspruch 1, bei dem die Daten der Außerbetriebnahme allen Kunden der Beteiligten einmal mitgeteilt werden und die datumsbezogenen Namen der Dienste in die Eigenschaftsdatei aufgenommen werden, die von jedem Kunden vor der einmaligen Weitergabe an PROD überprüft und abgezeichnet wird.
System nach Anspruch 1, wobei mehrere Clients mit dem Gateway-Dienst verbunden sind, in dem mehrere Dienste gehostet werden, und die mehreren Clients die Konfigurationsdatei ändern und aktualisieren können.