DE102018210537A1 - Mikrodienste-Architektur - Google Patents

Mikrodienste-Architektur Download PDF

Info

Publication number
DE102018210537A1
DE102018210537A1 DE102018210537.5A DE102018210537A DE102018210537A1 DE 102018210537 A1 DE102018210537 A1 DE 102018210537A1 DE 102018210537 A DE102018210537 A DE 102018210537A DE 102018210537 A1 DE102018210537 A1 DE 102018210537A1
Authority
DE
Germany
Prior art keywords
service
micro
accelerator
registry
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018210537.5A
Other languages
English (en)
Inventor
Vadim Sukhomlinov
Kshitij Doshi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102018210537A1 publication Critical patent/DE102018210537A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)
  • Multi Processors (AREA)

Abstract

Eine Rechenvorrichtung, die umfasst: eine Hardware-Rechenplattform; und Logik zum Arbeiten auf der Hardware-Rechenplattform, die zu Folgendem ausgelegt ist: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen soll, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.

Description

  • Gebiet der Offenbarung
  • Diese Offenbarung bezieht sich im Allgemeinen auf das Gebiet der Cloud-Datenverarbeitung und insbesondere, wenn auch nicht ausschließlich, auf ein System und ein Verfahren für eine Mikrodienste-Architektur.
  • Hintergrund
  • Moderne Datenverarbeitungspraktiken haben sich von einer hardwarespezifischen Datenverarbeitung hin zu der Idee „das Netz ist die Vorrichtung“ entwickelt. Ein modernes Netz kann ein Datenzentrum umfassen, das eine große Anzahl generischer Hardwareservervorrichtungen hostet, die beispielsweise in einem Serverrack enthalten sind und durch einen Hypervisor gesteuert werden. Jede Hardwarevorrichtung kann einen oder mehrere Instanzen einer virtuellen Vorrichtung wie beispielsweise einen Arbeitslastserver oder einen virtuellen Desktop betreiben.
  • Figurenliste
  • Die vorliegende Offenbarung wird am besten verstanden, wenn die folgende genaue Beschreibung mit den begleitenden Figuren gelesen wird. Es ist zu unterstreichen, dass gemäß der üblichen Vorgehensweise in der Industrie verschiedene Merkmale nicht notwendigerweise maßstabsgetreu sind und nur Veranschaulichungszwecken dienen. Wenn eine Skala gezeigt wird, bietet sie explizit oder implizit nur ein veranschaulichendes Beispiel. In anderen Ausführungsformen können die Abmessungen der verschiedenen Merkmale der Klarheit der Darstellung halber beliebig vergrößert oder verkleinert sein.
    • 1 ist eine Netzebenen-Darstellung eines Cloud-Dienstanbieters (CSP) gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 2 ist ein Blockdiagramm eines Datenzentrums gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 3 zeigt ein Blockdiagramm von Komponenten einer Rechenplattform gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 4 ist ein Blockdiagramm einer Mikrodienste-Architektur gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 5 ist ein Ablaufdiagramm eines Verfahrens zum Registrieren und Verwenden von Mikrodiensten gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 6 ist ein Blockdiagramm einer anfänglichen Einrichtung einer Mikrodienste-Instanz gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 7 ist eine Darstellung eines Betriebs von Mikrodiensten gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung, die als Erweiterung des Blockdiagramms von 6 angesehen werden kann.
    • 8 ist ein Blockdiagramm einer Nachrichtendienstverkettung gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 9 ist ein Blockdiagramm zur Diensterkennung gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
    • 10 ist ein Blockdiagramm, das eine Nachrichtenweiterleitung gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung zeigt.
    • 11 ist ein Blockdiagramm einer Lastausgleichs-Engine gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
  • Ausführungsformen der Offenbarung
  • Die folgende Offenbarung stellt viele verschiedene Ausführungsformen oder Beispiele zum Implementieren verschiedener Merkmale der vorliegenden Offenbarung bereit. Bestimmte Beispiele von Komponenten und Anordnungen sind unten beschrieben, um die vorliegende Offenbarung zu vereinfachen. Diese sind natürlich nur Beispiele und sind nicht als Einschränkung gedacht. Ferner kann die vorliegende Offenbarung Bezugsziffern und/oder -buchstaben in den verschiedenen Beispielen wiederholen. Diese Wiederholung dient dem Zweck der Vereinfachung und der Klarheit und schreibt an sich keine Beziehung zwischen den verschiedenen erörterten Ausführungsformen und/oder Anordnungen vor. Verschiedene Ausführungsformen können verschiedene Vorteile aufweisen und ein bestimmter Vorteil ist nicht notwendigerweise in allen Ausführungsformen erforderlich.
  • In einem modernen Datenzentrum können Funktionen, die früher von einem dedizierten Logikelement durchgeführt wurden, nun sinnvoller als logische Funktionen betrachtet werden. Um nur ein erläuterndes Beispiel zu geben: in einem Netzfunktionsvirtualisierungs-Kontext (NFC-Kontext) kann eine Etappe in der Dienstkette vertiefte Paketinspektion (DPI) bereitstellen. Andere Mikrodienste (uSVCs) können als nicht beschränkende Beispiele Verschlüsselung, Entschlüsselung, Kompression, Dekompression, IP-Sicherheit (IPsec), Kontofunktionen und Leistungstracker umfassen.
  • In einer Legacy-Netzumgebung wurde die beispielhafte DPI-Funktion vielleicht von einer dedizierten DPI-Hardwareanwendung durchgeführt, deren Hardware-Eingangsports mit einer vorherigen Etappe in der Dienstkette verbunden waren und deren Hardware-Ausgangsports mit der nächsten Etappe in der Dienstkette verbunden waren.
  • Solche fest codierten Netzfunktionen wurden in vielen Fällen durch Datenzentren ersetzt, in denen eine Funktion wie DPI auf viele verschiedene Weisen bereitgestellt werden kann. Zum Beispiel kann die DPI-Funktion mit Software, die in einer virtuellen Maschine (VM), die eine virtuelle Diensteinrichtung bildet, durchgeführt werden, deren Instanzen auf Nachfrage hervorgebracht werden können. Allerdings kann in einigen Einsätzen selbst das Bereitstellen von virtuellen Maschinen auf Nachfrage nicht ausreichen. Da Datenzentren sehr groß werden und das Verkehrsvolumen steigt, werden Latenz und Bandbreite zunehmend wichtig und Datenzentrumsbetreiber wollen es vielleicht vermeiden, dass Dienstfunktionen zu einem Flaschenhals für das Leistungsvermögen werden. Somit können in vielen Datenzentren durch weiteres Spezialisieren bestimmter Funktionen zusätzliche Flexibilität und Geschwindigkeit geboten werden.
  • Zum Beispiel kann ein Datenzentrum, anstatt VM-DPI-Anwendungen auf Nachfrage bereitzustellen, einen Betriebsmittelpool mit einer Reihe von Instanzen eines spezialisierten Betriebsmittels bereitstellen, die weitgehend optimiert worden sind. Der Vorteil eines Betriebsmittelpools besteht darin, dass weitgehend optimierte Betriebsmittel von vielen verschiedenen Knoten gemeinsam genutzt werden können. Betriebsmittelpools können Elemente wie Rechenknoten, Speicher (flüchtig oder nichtflüchtig), Datenspeicher, anwendungsspezifische integrierte Schaltungen (ASICs), Ein-Chip-Systeme (SoCs) oder feldprogrammierbare Gate-Arrays (FPGAs) als nicht beschränkende Beispiele umfassen. Solche Betriebsmittel können einem Rechenknoten (der als ein „zusammengesetzter Knoten“ betrachtet wird) auf Nachfrage zugeteilt werden, um den Bedarf des Datenzentrums zu decken. Somit könnte ein Betriebsmittelpool eine Anzahl von im Voraus bereitgestellten Einrichtungen, die für bestimmte Aufgaben optimiert sind, oder eine Bandbreite von hochfähigen Betriebsmitteln, die in solch einem Knoten versammelt sein können, umfassen. Solche Betriebsmittel können zum Hosten verschiedener Arten von Beschleunigern in einem Datenzentrum nützlich sein.
  • Ein Beispiel eines Betriebsmittelpools kann ein FPGA-Pool sein. Dieser kann ein Pool von FPGAs sein, der dazu ausgelegt und programmiert sein kann, auf Nachfrage eine bestimmte Funktion mit Hardware- oder nahezu Hardware-Geschwindigkeiten bereitzustellen. Somit kann ein FPGA-Pool vorteilhafterweise eine ähnliche Flexibilität bieten, wie sie mit Softwarebetriebsmitteln verfügbar ist, aber mit Geschwindigkeiten, die denen von reinen Hardwarebetriebsmitteln ähnlich sind. Um zu dem Beispiel einer DPI-Anwendung zurückzukehren, kann somit eine FPGA aus einem FPGA-Pool der DPI-Funktion zugeteilt werden und dazu ausgelegt sein, DPI mit sehr hohen Geschwindigkeiten bereitzustellen.
  • In Fällen, in denen sogar noch größere Geschwindigkeiten benötigt werden, können auch echte Hardwarebetriebsmittel bereitgestellt werden. Diese können zum Beispiel ASICS sein, die programmiert sind, um bestimmte Funktionen mit Geschwindigkeiten bereitzustellen, die viel höher sind als die, die in Software verwirklicht werden können.
  • Ein Systemprogrammierer, der DPI bereitstellt, kann zu Zeiten des Entwurfs wissen, welche Betriebsmittel zur Verfügung stehen und die Software dementsprechend programmieren. Zum Beispiel kann der Systemdesigner dann, wenn er weiß, dass ein FPGA-Pool in dem Datenzentrum verfügbar ist, seine Software so programmieren, dass sie verfügbare FPGA-Instanzen erkennt (beispielsweise über einen Orchestrator), und fordern, dass die eine oder die mehreren Instanzen einer FPGA mit der DPI-Funktion programmiert werden, und dann eine tatsächliche DPI-Verarbeitung an die bereitgestellte FPGA abgeben. Die flexible Natur des Datenzentrums macht es jedoch möglich, an diesem System ferner Verbesserungen vorzunehmen, und zwar selbst in Fällen, in denen der Designer zu Zeiten des Entwurfs nicht wissen kann, welche Betriebsmittel letztlich in dem Datenzentrum zur Verfügung stehen werden.
  • Man betrachte beispielsweise einen Fall, in dem der Systemprogrammierer zu Zeiten des Entwurfs weiß, dass seine Software eine DPI-Funktion bereitstellen soll und dass es bevorzugt ist, DPI unter allen Umständen mit größtmöglicher Geschwindigkeit bereitzustellen, aber sich nicht der speziellen Betriebsmittel, die die DPI-Funktion ausführen werden, bewusst ist (und sich derer nicht bewusst sein muss).
  • Es ist möglich, dass für ein Datenzentrum, verschiedene Systembetriebsmittel wie beispielsweise GPU-Anordnungen, Mehrkern-CPUs, Hardwarebeschleuniger, FPGAs, virtuelle Einrichtungen und viele andere verfügbar sind. Jedes von ihnen kann die erwünschte Funktion durchführen oder eine Rolle bei ihrer Durchführung spielen und es ist vorteilhaft, dass Systemsoftware dazu in der Lage ist, ein „am besten verfügbares“ Betriebsmittel zu verwenden, anstelle auf ein spezielles Betriebsmittel angewiesen zu sein.
  • In einigen Fällen können Hardware- und Plattformspezialisierung detektiert werden und auf niedriger Ebene in dem Softwarestapels genutzt werden. Allerdings kann dies auf Kosten der Portabilität und Wartbarkeit von Treibern in der darunter liegenden Hardware gehen. Da es notwendig ist, dass eine Anwendung mit der Anwesenheit oder Abwesenheit von Beschleunigern oder anderen Betriebsmitteln selbstständig umgehen kann, kann der Systemprogrammierer sich in den Details dazu, wie eine Aufgabe umgesetzt wird (z. B. welche Betriebsmittel die Aufgabe ausführen) verlieren, anstelle sich auf die Aufgabe selbst zu konzentrieren.
  • Die vorliegende Offenbarung stellt ein System und ein Verfahren bereit, um dieses Problem durch Bereitstellen sogenannter „Mikrodienste“ zu lösen. Mikrodienste beziehen sich auf einen Rahmen zum Partitionieren von Funktionalität auf eine weitgehend konfigurierbare und skalierbare Weise, bei der eine erwünschte Funktion problemlos in einem Wrapper verpackt werden kann, ohne dass sich der Systemprogrammierer zu Zeiten des Entwurfs darüber bewusst sein muss, wie oder auf welchen Betriebsmitteln die Funktion ausgeführt werden wird.
  • Das hierin offenbarte System und Verfahren beziehen sich auch auf die Skalierbarkeit von Hardware- und Softwareimplementierungen für Instanzen von Mikrodiensten. Hierin wird ein Rahmen zum Implementieren der Erkennung eines Mikrodienstes und dessen Fähigkeiten beschrieben. Portabilität und Wartbarkeit werden verbessert, weil der Rahmen an die Fähigkeiten angepasst werden kann, die in der Zukunft verfügbar sein werden, auch über verschiedene Anbieter hinweg. Der Rahmen kann zudem die Latenz durch Bereitstellen weitgehend optimierter Dienstverkettungen wesentlich verringern.
  • Beispielsweise optimiert das hierin offenbarte System Betriebsabläufe über verteilte Systeme hinweg, die aus verschiedenen Komponenten niedriger Ebene aufgebaut sind, auf die über „Hüllfunktionen“ zugegriffen wird, statt sie individuell zu adressieren. Die Nutzbarkeit der Mikrodienste wird ferner durch Automatisieren und Rationalisieren von Flüssen aktiver Nachrichten als Ketten von Mikrodienstaufrufen mit niedriger Latenz erhöht. Dies kann den Bedarf an einer Anforderungs-/Antwortinteraktion vermeiden, die in vielen Fällen zu einem wesentlichen Mehraufwand führt.
  • Beispielsweise wird der Hostsoftware eine Mikrodienste-Anwendungsprogrammierschnittstelle (API) offengelegt. Der Designer der Hostsoftware muss die Implementierungsdetails der Dienste hinter der Mikrodienste-API nicht verstehen oder sie berücksichtigen. Vielmehr bietet die Mikrodienste-API standardisierte Aufrufe verschiedener Fähigkeiten, einschließlich Typen und Formate von Eingaben und Ausgaben. Die Mikrodienste-API stellt dann den Funktionsaufruf für einen Mikrodienste-Treiber bereit, der (möglicherweise in Verbindung mit einem Orchestrator) Instanzen der verschiedenen Mikrodienste in verschiedenen Formen wie beispielsweise Hardwarebeschleunigern, FPGAs, Betriebsmittel-Pools, CPUs, GPUs oder lokaler Software erkennen und/oder zuteilen kann.
  • Wenn Instanzen eines Mikrodienstes oder eines mikrodienstfähigen Betriebsmittels online gehen, können sie sich bei einer Diensterkennungsfunktion (SDF) registrieren. Die SDF kann dann einen Katalog verfügbarer Mikrodienste pflegen, der Zuordnungen zum Übersetzen der Standard-Mikrodienste-API-Aufrufe in einen API-Aufruf, der von einer bestimmten Instanz des Mikrodienstes verwendbar ist, umfasst. Diese Architektur ermöglicht die Spezialisierung bestimmter Architekturfähigkeiten wie beispielsweise „Bump-in-the Wire“-Beschleunigung, FPGA-Funktionssätze, die von Verarbeitungskernen aufgerufen werden, oder zweckoptimierte Prozessoren mit hoch spezialisierter Software. Diese können nach Bedarf transparent in das Datenzentrum integriert werden.
  • Wenn der Mikrodienste-Treiber eine Anforderung bezüglich eines neuen Mikrodienstes empfängt, kann er die SDF abfragen und die Verfügbarkeit von Mikrodienstinstanzen identifizieren. Es ist zu beachten, dass dies nicht nur die Verfügbarkeit aktuell laufender Mikrodienstinstanzen umfasst, sondern auch die Verfügbarkeit von Betriebsmitteln, die vorgesehen sein können, um einen Mikrodienst bereitzustellen. Zum Beispiel kann eine FPGA verfügbar sein, aber noch nicht dazu programmiert sein, einen Mikrodienst bereitzustellen. Der SDF-Katalog kann Konfigurationsinformationen wie beispielsweise eine Gatterkonfiguration zum Programmieren einer FPGA zum Bereitstellen des erwünschten Mikrodienstes umfassen. Der Mikrodienste-Treiber kann dann die SDF abfragen, um zu bestimmen, dass eine FPGA verfügbar ist, um die Mikrodienstfunktion auszuführen, und kann von dem Katalog die angemessene Zuordnung für die Funktion wie etwa die Gatterkonfiguration für die FPGA empfangen. Der Mikrodienste-Treiber kann dann die FPGA mit der Gatterkonfiguration programmieren und, sobald die FPGA programmiert ist, kann der Mikrodiensttreiber beginnen, Aufrufe über die standardisierte Mikrodienste-API, die den bestimmten Schnittstellen für diese FPGA-Instanz zugeordnet ist, an die FPGA weiterzuleiten.
  • Ähnliche Vorgehensweisen können beispielsweise zum Bereitstellen virtueller Maschinen oder virtueller Instanzen, Software, die auf einer CPU oder GPU laufen soll, oder zum Zuteilen eines Hardwarebeschleunigers oder einer ASIC-Instanz zu dem Mikrodienst, so dass es für diesen Mikrodienst verwendet werden kann, verwendet werden.
  • Dieser Rahmen kann beim Abstrahieren von Details eines Instanzaufrufs Vorteile gegenüber anderen Lösungen wie beispielsweise der Verwendung von Middleware bieten. Solche Middleware kann Latenz oder Mehraufwand einbringen sowie die Portabilität der Lösung verhindern, und in einigen Fällen sogar das vollständige Verwirklichen der Hardwarefähigkeiten verhindern. Im Gegensatz dazu werden gemäß der Mikrodienste-Architektur der vorliegenden Offenbarung Mikrodienste erkannt und dynamisch in Strömen bereitgestellt, und zwar mit der Möglichkeit, die Hardware und/oder Softwarefähigkeiten der Mikrodienstinstanz vollständig zu verwenden. Der Mikrodienste-Treiber behandelt die Übersetzung generischer Funktionsaufrufe auf der Mikrodienste-API-Ebene in spezifische und optimierte Dienstaufrufe für die Mikrodienstinstanzen.
  • Somit wird die Aufgabenlogik von verschiedenen Implementierungen einer Funktion von den Implementierungsdetails getrennt gehalten. Dies ermöglicht es, Aufgaben unabhängig davon zu lassen, wo und wie die Funktion tatsächlich ausgeführt wird. Wie unten beschrieben kann dies auch den Ablauf von Verarbeitungsdienstketten automatisieren, weil mehrere Mikrodienstinstanzen verschiedener Typen bereitgestellt und in einer Dienstkette miteinander verkettet werden können, ohne dass jede Mikrodienstinstanz Ergebnisse zurück an eine VM oder einen Server übermitteln muss. In einigen Fällen kann dies viel Verkehrsaufkommen, das in Anforderungs-Antwort-Rahmen erforderlich ist, vermeiden. Somit ist das Bereitstellen von Mikrodiensten anpassbar und weitgehend optimiert und neue Mikrodienste und Mikrodienstinstanzen können als Beschleunigerfunktionen über das Datenzentrum verbreitet werden.
  • Ein System und ein Verfahren für eine Mikrodienste-Architektur sind unter genauerer Bezugnahme auf die beigefügten Figuren beschrieben. Es sollte beachtet werden, dass über die Figuren hinweg bestimmte Bezugszeichen wiederholt sein können, um anzugeben, dass eine bestimmte Vorrichtung oder ein bestimmter Block über die Figuren hinweg gänzlich oder im Wesentlichen konsistent ist. Dies ist allerdings nicht dazu gedacht, eine bestimmte Beziehung zwischen den offenbarten verschiedenen Ausführungsformen zu implizieren. In gewissen Beispielen kann eine Art Element durch eine bestimmte Bezugsziffer („Objekt 10“) bezeichnet werden, wohingegen individuelle Ausprägungen oder Beispiele der Art durch eine mit einem Bindestrich versehene Ziffer („erstes spezifisches Objekt 10-1“ und „zweites spezifisches Objekt 10-2“) bezeichnet werden können.
  • 1 ist eine Netzebenen-Darstellung eines Netzes 100 eines Cloud-Dienstanbieters (CSP) 102 gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung. Der CSP 102 kann als nicht beschränkendes Beispiel ein traditionelles Unternehmensdatenzentrum, eine „private Cloud“ eines Unternehmens oder eine „öffentliche Cloud“ sein, die Dienste wie Infrastruktur als ein Dienst (laaS), Plattform als ein Dienst (PaaS) oder Software als ein Dienst (SaaS) bereitstellt.
  • Der CSP 102 kann eine Anzahl von Arbeitslastclustern 118 bereitstellen, die Cluster individueller Server, Bladeserver, einen rackmontierter Server oder jeder anderen geeigneten Servertopologie sein. In diesem erläuternden Beispiel sind zwei Arbeitslastcluster 118-1 und 118-2 gezeigt, die jeweils rackmontierte Server 146 in einem Gehäuse 148 bereitstellen.
  • Jeder Server 146 kann ein eigenständiges Betriebssystem hosten und eine Serverfunktion bereitstellen oder die Server können virtualisiert sein; in letzterem Fall können sie von einem Manager für virtuelle Maschinen (VMM), Hypervisor und/oder Orchestrator gesteuert werden und können einen oder mehrere virtuelle Maschinen, virtuelle Server oder virtuelle Anwendungen hosten. Diese Serverracks können sich gemeinsam in einem einzigen Datenzentrum befinden oder können in verschiedenen geografischen Datenzentren platziert sein. In Abhängigkeit von den Vertragsvereinbarungen können einige Server 146 spezifisch bestimmten Unternehmenskunden oder Mietern gewidmet sein, während andere gemeinsam genutzt werden.
  • Die verschiedenen Vorrichtungen in den Datenzentren können miteinander über eine Vermittlungs-Fabric 170 verbunden sein, die eine oder mehrere Routing- und/oder Vermittlungs-Vorrichtungen mit hoher Geschwindigkeit umfassen kann. Die Vermittlungs-Fabric 170 kann sowohl „Nord-Süd“-Verkehr (z. B. Verkehr zu und von dem Weitbereichsnetz (WAN) wie beispielsweise dem Internet) und „Ost-West“-Verkehr (z. B. Verkehr über das Datenzentrum hinweg) bereitstellen. Historisch gesehen war Nord-Süd-Verkehr für den Hauptteil des Netzverkehrs verantwortlich, doch da Webdienste komplexer und verteilter geworden sind, ist das Volumen des Ost-West-Verkehrs gestiegen. In vielen Datenzentren ist Ost-West-Verkehr für den Großteil des Verkehrs verantwortlich.
  • Ferner kann, da die Fähigkeit jedes Servers 146 wächst, das Verkehrsvolumen weiter wachsen. Zum Beispiel kann jeder Server 146 mehrere Prozessorsteckplätze bereitstellen, wobei jeder Steckplatz einen Prozessor, der vier bis acht Kerne aufweist zusammen mit ausreichend Speicher für die Kerne aufnimmt. Somit kann jeder Server eine Anzahl von VMs hosten, von denen jede ihren eigenen Verkehr erzeugt.
  • Um das große Verkehrsvolumen in einem Datenzentrum aufzufangen, kann eine äußerst fähige Vermittlungs-Fabric 170 bereitgestellt werden. Die Vermittlungs-Fabric 170 ist in diesem Beispiel als ein „flaches“ Netz gezeigt, in dem jeder Server 146 eine direkte Verbindung zu einem Switch oben auf dem Rack (ToR-Switch) 120 aufweisen kann (z. B. eine „Stern“-Konfiguration) und jeder ToR-Switch 120 mit einem Kernswitch 130 gekoppelt sein kann. Diese zweistufige Netzarchitektur ist nur als erläuterndes Beispiel gezeigt. In anderen Beispielen können andere Architekturen verwendet werden, wie beispielsweise dreistufige Stern- oder Blatt-Grat-Topologien (auch „Dicker-Baum-Topologien genannt), die auf der „Clos“-Architektur basieren, Nabe-und-Speiche-Topologien, Gittertopologien, Ringtopologien oder 3-D-Gittertopologien als nicht beschränkende Beispiele.
  • Die Fabric selbst kann durch jede geeignete Zwischenverbindung bereitgestellt werden. Zum Beispiel kann jeder Server 146 eine Fabric-Schnittstelle wie beispielsweise ein Host-Fabric-Interface (HFI) von Intel, eine Netzschnittstellenkarte (NIC) oder eine andere Hostschnittstelle umfassen. Die Hostschnittstelle selbst kann mit einem oder mehreren Prozessoren über eine Zwischenverbindung oder einen Bus wie beispielsweise PCI, PCIe oder ähnliche gekoppelt werden oder in einigen Fällen kann dieser Zwischenverbindungsbus als Teil der Fabric 170 betrachtet werden.
  • Die Zwischenverbindungstechnologie kann durch eine einzige Zwischenverbindung oder eine hybride Zwischenverbindung bereitgestellt werden, wenn z. B. PCIe eine chipinterne Kommunikation bereitstellt, 1-GB- oder 10-GB-Kupfer-Ethernet relativ kurze Verbindungen zu einem ToR-Switch 120 bereitstellt und eine optische Verkabelung im Vergleich dazu längere Verbindungen zu dem Kernswitch 130 bereitstellt. Zwischenverbindungstechnologien umfassen als nicht beschränkende Beispiele Intel® OmniPath™, TrueScale™, Ultra Path Interconnect (UPI) (früher QPI oder KTI genannt), STL, Faserkanal, Ethernet, Faserkanal über Ethernet (FCoE), InfiniBand, PCIe oder Glasfaser, um nur ein paar zu nennen. Einige von diesen werden für bestimmte Einsätze oder Funktionen geeigneter sein als andere und ein Auswählen einer passenden Fabric für die momentane Anwendung ist eine gewöhnliche Übung für Fachleute.
  • Es ist zu beachten, dass, obwohl hierin beispielhaft Premium-Fabrics wie OmniPath™ bereitgestellt sind, die Fabric 170 im Allgemeinen eine beliebige geeignete Zwischenverbindung oder eine beliebiger geeigneter Bus für die bestimmte Anwendung sein kann. Dies könnte in einigen Fällen Alt-Zwischenverbindungen wie lokale Umgebungsnetze (LANs), Token-Ringnetze, synchrone optische Netze (SONET), asynchrone Transfermodusnetze (ATM), drahtlose Netze wie WiFi und Bluetooth, Zwischenverbindungen „einfacher alter Telefonsysteme“ (POTS-Zwischenverbindungen) oder dergleichen umfassen. Es wird ebenso ausdrücklich erwartet, dass in Zukunft neue Netztechnologien hervorgebracht werden, um einige der hierin aufgelisteten zu ergänzen oder zu ersetzen, und jede dieser zukünftigen Netztopologien und -technologien kann die Fabric 170 sein oder einen Teil davon bilden.
  • In bestimmten Ausführungsformen kann die Fabric 170 Kommunikationsdienste auf verschiedenen „Schichten“ bereitstellen, wie sie ursprünglich in dem siebenschichtigen OSI-Netzmodell umrissen sind. Nach heutiger Praxis wird das OSI-Modell nicht streng eingehalten. Im Allgemeinen werden die Schichten 1 und 2 oft die „Ethernet“-Schicht genannt (obwohl in großen Datenzentren Ethernet oft durch neuere Technologien ersetzt wurde). Die Schichten 3 und 4 werden oft als die Übertragungssteuerungsprotokoll-/Internetprotokoll-Schicht (TCP/IP-Schicht) genannt (die ferner in TCP- und IP-Schicht unterteilt werden kann). Die Schichten 5-7 können als „Anwendungsschicht“ bezeichnet werden. Diese Schichtdefinitionen sind als nützlicher Rahmen dargelegt, sollen aber nicht als Einschränkung dienen.
  • 2 ist ein Blockdiagramm eines Datenzentrums 200 gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung. Das Datenzentrum 200 kann in verschiedenen Ausführungsformen das gleiche Datenzentrum wie das Datenzentrum 100 von 1 oder ein anderes Datenzentrum sein. Zusätzliche Ansichten sind in 2 bereitgestellt, um verschiedene Aspekte des Datenzentrums 200 zu veranschaulichen.
  • Das Datenzentrum 200 kann durch einen Orchestrator 260 gesteuert werden. Der Orchestrator 260 kann beispielsweise ein softwaredefiniertes Netz (SDN), eine Netzfunktionsvirtualisierung (NFV), ein Management virtueller Maschinen und ähnliche Dienste in dem Datenzentrum 200 bereitstellen. Der Orchestrator 260 kann eine eigenständige Einrichtung mit einem oder mehreren eigenen Prozessoren, einem Speicher, einem Datenspeicher und einer Fabric-Schnittstelle sein. In einem weiteren Beispiel kann der Orchestrator 260 selbst eine virtuelle Maschine oder virtuelle Einrichtung sein. Der Orchestrator 260 kann eine globale Sicht auf das Datenzentrum 200 haben und die Fähigkeit haben, mehrere Dienste zu verwalten und zu konfigurieren, also beispielsweise Kunden, Domänen, Dienste, Dienstketten, virtuelle Maschinen, virtuelle Switches und Arbeitslastserver dynamisch zuteilen, um gegenwärtige Anforderungen zu erfüllen.
  • In diesem Beispiel ist eine Fabric 270 bereitgestellt, um verschiedene Aspekte des Datenzentrums 200 zu verbinden. Die Fabric 270 kann die gleiche wie die Fabric 170 von 1 sein oder kann eine andere Fabric sein. Wie oben kann die Fabric 270 durch irgendeine geeignete Verbindungstechnologie bereitgestellt sein. In diesem Beispiel wird Intel® OmniPath™ als veranschaulichendes und nicht einschränkendes Beispiel verwendet.
  • Wie dargestellt umfasst das Datenzentrum 200 eine Anzahl von Logikelementen, die mehrere Knoten bilden. Es sollte klar sein, dass jeder Knoten von einem physischen Server, einer Gruppe von Servern oder anderer Hardware bereitgestellt werden kann. Jeder Server kann entsprechend seiner Anwendung eine oder mehrere virtuelle Maschinen ausführen.
  • Der Knoten 0 208 ist ein Verarbeitungsknoten, der einen Prozessorsockel 0 und einen Prozessorsockel 1 umfasst. Die Prozessoren können beispielsweise Xeon™-Prozessoren von Intel mit mehreren Kernen, etwa 4 oder 8 Kernen, sein. Der Knoten 0 208 kann zum Bereitstellen von Netz- oder Arbeitslastfunktionen ausgelegt sein, beispielsweise durch Hosten mehrerer virtueller Maschinen oder virtueller Einrichtungen.
  • Eine bordinterne Kommunikation zwischen dem Prozessorsockel 0 und dem Prozessorsockel 1 kann durch eine bordinterne Uplinkverbindung 278 bereitgestellt werden. Diese kann eine sehr kurze Verbindung mit hoher Geschwindigkeit zwischen den beiden Prozessorsockeln bereitstellen, so dass virtuelle Maschinen, die auf dem Knoten 0 208 laufen, miteinander mit sehr hohen Geschwindigkeiten kommunizieren. Um diese Kommunikation zu erleichtern, kann ein virtueller Switch (vSwitch) auf dem Knoten 0 208 bereitgestellt sein, der als Teil des Fabric 270 betrachtet werden kann.
  • Der Knoten 0 208 ist über eine Fabric-Schnittstelle 272 mit der Fabric 270 verbunden. Die Fabric-Schnittstelle 272 kann wie oben beschrieben eine beliebige geeignete Fabric-Schnittstelle sein und kann in diesem speziellen Anschauungsbeispiel eine lntel®-HFI zum Anschluss an einen lntel®-OmniPath™-Fabric sein. In einigen Beispielen kann die Kommunikation mit der Fabric 270 getunnelt werden, beispielsweise durch Bereitstellen von UPI-Tunnelung über OmniPath™.
  • Da das Datenzentrum 200 viele Funktionen, die in früheren Generationen an Bord bereitgestellt wurden, in einer verteilten Art und Weise bereitstellen kann, kann eine äußerst fähige Fabric-Schnittstelle 272 bereitgestellt werden. Die Fabric-Schnittstelle 272 kann mit Geschwindigkeiten von mehreren Gigabits pro Sekunde arbeiten und kann in einigen Fällen eng mit dem Knoten 0 208 gekoppelt sein. Beispielsweise ist die Logik für die Fabric-Schnittstelle 272 in einigen Ausführungsformen direkt in die Prozessoren eines Ein—Chip-Systems integriert. Dies sorgt für eine Kommunikation mit sehr hoher Geschwindigkeit zwischen der Fabric-Schnittstelle 272 und den Prozessorsockeln, ohne dass zwischengeschaltete Busvorrichtungen benötigt werden, die zusätzliche Latenz in die Fabric einführen können. Dies soll jedoch nicht implizieren, dass Ausführungsformen, bei denen die Fabric-Schnittstelle 272 über einen herkömmlichen Bus bereitgestellt wird, ausgeschlossen werden sollen. Vielmehr wird explizit erwartet, dass in einigen Beispielen die Fabric-Schnittstelle 272 auf einem Bus bereitgestellt werden kann, beispielsweise einem PCIe-Bus, der eine serialisierte Version von PCI ist, die höhere Geschwindigkeiten als die herkömmliche PCI bereitstellt. Im Datenzentrum 200 können verschiedene Knoten verschiedene Arten von Fabric-Schnittstellen 272 bereitstellen, beispielsweise integrierte Fabric-Schnittstellen und Plug-in-Fabric-Schnittstellen. Es sollte auch beachtet werden, dass bestimmte Blöcke in einem Ein-Chip-System als Blöcke geistigen Eigentums (IP-Blöcke) bereitgestellt sein können, die als eine modulare Einheit in einer integrierten Schaltung „abgelegt“ werden können. Somit kann die Fabric-Schnittstelle 272 in einigen Fällen von einem solchen IP-Block abgeleitet sein.
  • Es ist zu beachten, dass der Knoten 0 208 unter dem Motto „das Netz ist die Vorrichtung“ einen begrenzten oder gar keinen integrierten Speicher oder Datenspeicher bereitstellen kann. Vielmehr kann sich der Knoten 0 208 hauptsächlich auf verteilte Dienste wie einen Speicherserver und einen Netzspeicherserver verlassen. An Bord kann der Knoten 0 208 nur ausreichend Speicher und Datenspeicher bereitstellen, um die Vorrichtung hochzufahren und mit der Fabric 270 kommunizieren zu lassen. Diese Art von verteilter Architektur ist wegen der sehr hohen Geschwindigkeiten von heutigen Datenzentren möglich und kann vorteilhaft sein, weil es nicht nötig ist, übermäßig viele Betriebsmittel für jeden Knoten bereitzustellen. Vielmehr kann ein großer Pool von Hochgeschwindigkeitsspeicher oder spezialisiertem Speicher dynamisch unter einer Anzahl von Knoten bereitgestellt werden, so dass jeder Knoten Zugriff auf einen großen Betriebsmittelpool hat, aber diese Betriebsmittel nicht ungenutzt bleiben, wenn dieser bestimmte Knoten sie nicht benötigt.
  • In diesem Beispiel stellen ein Speicherserver 204 des Knotens 1 und ein Datenspeicherserver 210 des Knotens 2 die Betriebsspeicher- und Datenspeicherfähigkeiten des Knotens 0 208 bereit. Beispielsweise kann der Speicherserverknoten 1 204 einen direkten Fernspeicherzugriff (RDMA) bereitstellen, wodurch der Knoten 0 208 auf die Speicherbetriebsmittel auf dem Knoten 1 204 über die Fabric 270 in einer DMA-Weise zugreifen kann, ähnlich wie er auf seinen eigenen integrierten Speicher zugreifen würde. Der Speicher, der von dem Speicherserver 204 bereitgestellt wird, kann ein herkömmlicher Speicher sein, beispielsweise ein dynamischer Direktzugriffsspeicher (DRAM) mit doppelter Datenrate vom Typ 3 (DDR3), der flüchtig ist, oder ein exotischerer Typ von Speicher wie etwa ein persistenter schneller Speicher (PFM) wie 3D Crosspoint™ (3DXP) von Intel®, der mit DRAM-ähnlichen Geschwindigkeiten arbeitet, jedoch nichtflüchtig ist.
  • In ähnlicher Weise kann ein Datenspeicherserverknoten 2 210 bereitgestellt sein, anstatt eine bordinterne Festplatte für den Knoten 0 208 bereitzustellen. Der Datenspeicherserver 210 kann eine vernetzte Gruppe von Platten (NBOD), PFM, eine redundante Anordnung unabhängiger Platten (RAID), eine redundante Anordnung unabhängiger Knoten (RAIN), einen netzangebundenen Speicher (NAS), einen optischen Speicher, Bandlaufwerke oder andere nichtflüchtige Speicherlösungen bereitstellen.
  • Somit kann der Knoten 0 208 beim Ausführen seiner zugewiesenen Funktion auf den Speicher von dem Speicherserver 204 zugreifen und Ergebnisse auf dem Datenspeicher speichern, der durch den Datenspeicherserver 210 bereitgestellt wird. Jede dieser Vorrichtungen ist über eine Fabric-Schnittstelle 272 mit der Fabric 270 gekoppelt, die eine schnelle Kommunikation bereitstellt, die diese Technologien möglich macht.
  • Zur weiteren Veranschaulichung ist auch der Knoten 3 206 dargestellt. Der Knoten 3 206 enthält auch eine Fabric-Schnittstelle 272 zusammen mit zwei Prozessorsockeln, die intern durch einen Uplink verbunden sind. Anders als der Knoten 0 208 enthält der Knoten 3 206 jedoch seinen eigenen bordinternen Speicher 222 und Datenspeicher 250. Somit kann der Knoten 3 206 dazu ausgelegt sein, seine Funktionen primär an Bord auszuführen und nicht auf den Speicherserver 204 und den Datenspeicherserver 210 zurückzugreifen. Unter entsprechenden Umständen kann der Knoten 3 206 jedoch seinen eigenen integrierten Speicher 222 und Datenspeicher 250 ähnlich wie der Knoten 0 208 mit verteilten Betriebsmitteln ergänzen.
  • Die Grundbausteine der verschiedenen hierin offenbarten Komponenten können als „Logikelemente“ bezeichnet werden. Logikelemente können umfassen: Hardware (einschließlich beispielsweise eines softwareprogrammierbaren Prozessors, einer ASIC oder einer FPGA), externe Hardware (digital, analog oder gemischtes Signal), Software, Erwiderungs-Software, Dienste, Treiber, Schnittstellen, Komponenten, Module, Algorithmen, Sensoren, Komponenten, Firmware, Mikrocode, programmierbare Logik oder Objekte, die koordiniert werden können, um eine logische Operation zu erreichen. Darüber hinaus sind einige logische Elemente von einem konkreten nichtflüchtigen computerlesbaren Medium bereitgestellt, auf dem ausführbare Befehle gespeichert sind, um einem Prozessor zu befehlen, eine bestimmte Aufgabe auszuführen. Ein solches nichttransitorisches Medium könnte beispielsweise eine Festplatte, einen Festkörperspeicher oder eine Festkörperplatte, einen Nur-Lese-Speicher (ROM), einen persistenten schnellen Speicher (PFM) (z. B. 3D-Crosspoint™ von Intel®), externen Speicher, eine redundante Anordnung unabhängiger Platten (RAID), eine redundante Anordnung unabhängiger Knoten (RAIN), netzangebundenen Speicher (NAS), optischen Speicher, ein Bandlaufwerk, ein Sicherungssystem, einen Cloud-Speicher oder eine beliebige Kombination der zuvor genannten als nicht einschränkendes Beispiel umfassen. Solch ein Medium könnte auch Befehle enthalten, die in eine FPGA programmiert sind oder in Hardware auf einer ASIC oder einem Prozessor codiert sind.
  • 3 zeigt ein Blockdiagramm von Komponenten einer Rechenplattform 302A gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung. In der dargestellten Ausführungsform sind die Plattformen 302A, 302B und 302C zusammen mit einer Datenzentrums-Managementplattform 306 und einer Datenanalyse-Engine 304 über das Netz 308 miteinander verbunden. In anderen Ausführungsformen kann ein Computersystem eine beliebige geeignete Anzahl von Plattformen (d. h. eine oder mehrere) umfassen. In einigen Ausführungsformen kann (z. B. dann, wenn ein Computersystem nur eine einzelne Plattform umfasst) die Gesamtheit oder ein Teil der Systemmanagementplattform 306 in einer Plattform 302 enthalten sein. Eine Plattform 302 kann eine Plattformlogik 310 mit einer oder mehreren zentralen Verarbeitungseinheiten (CPUs) 312, Speichern 314 (die eine beliebige Anzahl unterschiedlicher Module enthalten können), Chipsätzen 316, Kommunikationsschnittstellen 318 und jeder anderen geeigneten Hardware und/oder Software zum Ausführen eines Hypervisors 320 oder eines anderen Betriebssystems, das auf einer Plattform 302 laufenden Anwendungen zugeordnete Arbeitslasten ausführen kann, umfassen. In einigen Ausführungsformen kann eine Plattform 302 als eine Hostplattform für ein oder mehrere Gastsysteme 322, die diese Anwendungen aufrufen, fungieren. Die Plattform 302A kann irgendeine geeignete Computerumgebung darstellen, wie beispielsweise eine Hochleistungsrechenumgebung, ein Datenzentrum, eine Kommunikationsdienstanbieter-Infrastruktur (z. B. ein oder mehrere Teile eines entwickelten Paketkerns), eine speicherinterne Rechenumgebung, ein Rechensystem eines Fahrzeugs (z. B. eines Automobils oder eines Flugzeugs), eine Umgebung des Internets der Dinge, ein industrielles Steuersystem, eine andere Rechenumgebung oder eine Kombination davon.
  • In verschiedenen Ausführungsformen der vorliegenden Offenbarung werden eine akkumulierte Belastung und/oder Belastungsraten, die von mehreren Hardwarebetriebsmitteln (z. B. Kernen und Unkernen (Uncores)) akkumuliert werden, überwacht und Entitäten (z. B. die Systemmanagementplattform 306, der Hypervisor 320 oder andere Betriebssysteme) der Computerplattform 302A können der Plattformlogik 310 Hardwarebetriebsmittel gemäß den Belastungsinformationen zuteilen, um Arbeitslasten durchzuführen. In einigen Ausführungsformen können Selbstdiagnosefähigkeiten mit der Belastungsüberwachung kombiniert werden, um den Funktionszustand der Hardwarebetriebsmittel genauer zu bestimmen. Jede Plattform 302 kann eine Plattformlogik 310 umfassen. Die Plattformlogik 310 umfasst neben anderer Logik, die eine Funktionalität der Plattform 302 ermöglicht, eine oder mehrere CPUs 312, einen Speicher 314, einen oder mehrere Chipsätze 316 und Kommunikationsschnittstellen 328. Obwohl drei Plattformen dargestellt sind, kann die Computerplattform 302A mit einer beliebigen geeigneten Anzahl von Plattformen verbunden sein. In verschiedenen Ausführungsformen kann sich eine Plattform 302 auf einer Leiterplatte befinden, die in einem Gehäuse, Rack oder einer anderen geeigneten Struktur installiert ist, die mehrere Plattformen umfasst, die durch das Netz 308 (das z. B. einen Rack- oder Rückwandswitch umfassen kann) miteinander verbunden sind.
  • Die CPUs 312 können jeweils eine beliebige geeignete Anzahl von Prozessorkernen und unterstützender Logik (z. B. Unkernen) umfassen. Die Kerne können miteinander, mit dem Speicher 314, mit mindestens einem Chipsatz 316 und/oder mit einer Kommunikationsschnittstelle 318 über einen oder mehrere Controller verbunden sein, die sich auf der CPU 312 und/oder dem Chipsatz 316 befinden. In bestimmten Ausführungsformen ist eine CPU 312 ist in einem Sockel verkörpert, der dauerhaft oder entfernbar mit der Plattform 302A verbunden ist. Obwohl vier CPUs gezeigt sind, kann eine Plattform 302 eine beliebige geeignete Anzahl von CPUs umfassen.
  • Der Speicher 314 kann irgendeine Form von flüchtigem oder nichtflüchtigem Speicher enthalten, der ohne Beschränkung darauf magnetische Medien (z. B. ein oder mehrere Bandlaufwerke), optische Medien, Direktzugriffsspeicher (RAM), Nur-Lese-Speicher (ROM), Flash-Speicher, Wechselmedien oder andere geeignete lokale oder entfernte Speicherkomponenten oder Komponenten umfasst. Der Speicher 314 kann durch die Plattform 302A für die Kurz-, Mittel- und/oder Langzeitspeicherung verwendet werden. Der Speicher 314 kann beliebige geeignete Daten oder Informationen speichern, die von der Plattformlogik 310 verwendet werden, einschließlich Software, die in einem computerlesbaren Medium eingebettet ist, und/oder codierte Logik, die in Hardware integriert oder anderweitig gespeichert ist (z. B. Firmware). Der Speicher 314 kann Daten speichern, die von Kernen der CPUs 312 verwendet werden. In einigen Ausführungsformen kann der Speicher 314 auch Speicher für Befehle umfassen, die von den Kernen der CPUs 312 oder anderen Verarbeitungselementen (z. B. Logik auf Chipsätzen 316) ausgeführt werden können, um eine Funktionalität bereitzustellen, die der Verwaltbarkeits-Engine 326 oder anderen Komponenten der Plattformlogik 310 zugeordnet ist. Eine Plattform 302 kann auch einen oder mehrere Chipsätze 316 umfassen, die irgendeine geeignete Logik enthalten, um den Betrieb der CPUs 312 zu unterstützen. In verschiedenen Ausführungsformen kann sich der Chipsatz 316 auf dem gleichen Chip oder der gleichen Baugruppe wie eine CPU 312 oder auf einem oder mehreren anderen Chips oder Baugruppen befinden. Jeder Chipsatz kann eine beliebige geeignete Anzahl von CPUs 312 unterstützen. Ein Chipsatz 316 kann auch einen oder mehrere Controller enthalten, um andere Komponenten der Plattformlogik 310 (z. B. die Kommunikationsschnittstelle 318 oder den Speicher 314) mit einer oder mehreren CPUs zu koppeln. In der dargestellten Ausführungsform umfasst jeder Chipsatz 316 auch eine Verwaltbarkeits-Engine 326. Die Verwaltbarkeits-Engine 326 kann eine beliebige geeignete Logik umfassen, um den Betrieb des Chipsatzes 316 zu unterstützen. In einer bestimmten Ausführungsform ist eine Verwaltbarkeits-Engine 326 (die auch als Innovations-Engine bezeichnet werden kann) in der Lage, Echtzeittelemetriedaten von dem Chipsatz 316, dem/n CPU(s) 312 und/oder dem Speicher 314, der von dem Chipsatz 316 verwaltet wird, anderen Komponenten der Plattformlogik 310 und/oder verschiedenen Verbindungen zwischen Komponenten der Plattformlogik 310 zu sammeln. In verschiedenen Ausführungsformen umfassen die gesammelten Telemetriedaten die hierin beschriebenen Belastungsinformationen.
  • In verschiedenen Ausführungsformen arbeitet eine Verwaltbarkeits-Engine 326 als ein bandexterner asynchroner Rechenagent, der mit den verschiedenen Elementen der Plattformlogik 310 kommunizieren kann, um Telemetriedaten ohne oder nur mit minimaler Unterbrechung laufender Prozesse auf CPUs 312 zu sammeln. Zum Beispiel kann die Verwaltbarkeits-Engine 326 ein dediziertes Verarbeitungselement (z. B. einen Prozessor, einen Controller oder eine andere Logik) auf dem Chipsatz 316 umfassen, das die Funktionalität der Verwaltbarkeits-Engine 326 bereitstellt (z. B. durch Ausführen von Softwarebefehlen), wodurch Verarbeitungszyklen der CPUs 312 für Operationen, die den von der Plattformlogik 310 ausgeführten Arbeitslasten zugeordnet sind, gespart werden. Außerdem kann die dedizierte Logik für die Verwaltbarkeits-Engine 326 in Bezug auf die CPUs 312 asynchron arbeiten und kann zumindest einige der Telemetriedaten sammeln, ohne die Last auf die CPUs zu erhöhen.
  • Eine Verwaltbarkeits-Engine 326 kann Telemetriedaten verarbeiten, die sie sammelt (spezifische Beispiele der Verarbeitung von Belastungsinformationen werden hierin bereitgestellt). In verschiedenen Ausführungsformen meldet die Verwaltbarkeits-Engine 326 die Daten, die sie sammelt, und/oder die Ergebnisse ihrer Verarbeitung an andere Elemente in dem Computersystem wie etwa einen oder mehrere Hypervisoren 320 oder andere Betriebssysteme und/oder Systemmanagementsoftware (die auf irgendeiner geeigneten Logik wie etwa der Systemmanagementplattform 306 laufen kann). In bestimmten Ausführungsformen kann ein kritisches Ereignis, wie etwa ein Kern, bei dem sich eine übermäßige Menge an Belastung angesammelt hat, vor dem normalen Intervall für das Melden von Telemetriedaten gemeldet werden (z. B. kann eine Benachrichtigung unmittelbar nach der Detektion gesendet werden).
  • Zudem kann die Verwaltbarkeits-Engine 326 programmierbaren Code enthalten, der konfigurierbar ist, um einzustellen, welche CPU(s) 312 ein bestimmter Chipsatz 316 verwalten wird und/oder welche Telemetriedaten gesammelt werden.
  • Die Chipsätze 316 enthalten auch jeweils eine Kommunikationsschnittstelle 328. Die Kommunikationsschnittstelle 328 kann für die Kommunikation von Signalisierung und/oder Daten zwischen dem Chipsatz 316 und einer oder mehreren I/O-Vorrichtungen, einem oder mehreren Netzen 308 und/oder einer oder mehreren Vorrichtungen, die mit dem Netz 308 gekoppelt sind, (z. B. der Systemmanagementplattform 306) verwendet werden. Zum Beispiel kann die Kommunikationsschnittstelle 328 zum Senden und Empfangen von Netzverkehr wie etwa Datenpaketen verwendet werden. In einer bestimmten Ausführungsform umfasst eine Kommunikationsschnittstelle 328 einen oder mehrere physische Netzschnittstellencontroller (NICs), die auch als Netzschnittstellenkarten oder Netzadapter bekannt sind. Ein NIC kann eine elektronische Schaltung zum Kommunizieren unter Verwendung irgendeiner geeigneten Bitübertragungsschicht und eines Datenverbindungsschichtstandards wie etwa Ethernet (wie z. B. durch einen IEEE-802.3-Standard definiert), Faserkanals, InfiniBand, Wi-Fi oder eines anderen geeigneten Standards umfassen. Ein NIC kann einen oder mehrere physische Ports enthalten, die an ein Kabel (z. B. ein Ethernet-Kabel) gekoppelt sein können. Ein NIC kann eine Kommunikation zwischen einem beliebigen geeigneten Element des Chipsatzes 316 (z. B. der Verwaltbarkeits-Engine 326 oder dem Switch 330) und einer anderen mit dem Netz 308 verbundenen Vorrichtung ermöglichen. In verschiedenen Ausführungsformen kann ein NIC in den Chipsatz integriert sein (d. h. sich auf derselben integriert Schaltung oder Platine wie der Rest der Chipsatzlogik befinden) oder auf einer anderen integrierten Schaltung oder Leiterplatte sein, die elektromechanisch mit dem Chipsatz gekoppelt ist.
  • In bestimmten Ausführungsformen können die Kommunikationsschnittstellen 328 die Kommunikation von Daten (z. B. zwischen der Verwaltbarkeits-Engine 326 und der Datenzentrums-Managementplattform 306) ermöglichen, die Management- und Überwachungsfunktionen zugeordnet sind, die von der Verwaltbarkeits-Engine 326 ausgeführt werden. In verschiedenen Ausführungsformen kann die Verwaltbarkeits-Engine Elemente (z. B. einen oder mehrere NICs) der Kommunikationsschnittstellen 328 verwenden, um die Telemetriedaten (z. B. an Systemmanagementplattform 306) zu melden, um die Verwendung der NICs der Kommunikationsschnittstelle 318 für Operationen zu reservieren, die von der Plattformlogik 310 ausgeführten Arbeitslasten zugeordnet sind.
  • Die Switches 330 können mit verschiedenen Ports (z. B. durch NICs bereitgestellt) der Kommunikationsschnittstelle 328 gekoppelt sein und können Daten zwischen diesen Ports und verschiedenen Komponenten des Chipsatzes 316 (z. B. einer oder mehreren Bahnen für die Express-Peripheriekomponenten-Zwischenverbindung (PCIe), die mit den CPUs 312 gekoppelt sind) vermitteln. Die Switches 330 können physische oder virtuelle (d. h. Software-) Switches sein.
  • Die Plattformlogik 310 kann eine zusätzliche Kommunikationsschnittstelle 318 enthalten. Ähnlich den Kommunikationsschnittstellen 328 können die Kommunikationsschnittstellen 318 für die Kommunikation von Signalisierung und/oder Daten zwischen der Plattformlogik 310 und einem oder mehreren Netzen 308 und einer oder mehreren Vorrichtungen, die mit dem Netz 308 gekoppelt sind, verwendet werden. Zum Beispiel kann die Kommunikationsschnittstelle 318 verwendet werden, um Netzverkehr wie etwa Datenpakete zu senden und zu empfangen. In einer bestimmten Ausführungsform umfassen die Kommunikationsschnittstellen 318 einen oder mehrere physische NICs. Diese NICs können eine Kommunikation zwischen einem beliebigen geeigneten Element der Plattformlogik 310 (z. B. CPUs 512 oder einem Speicher 514) und einer anderen mit dem Netz 308 gekoppelten Vorrichtung (z. B. Elemente anderer Plattformen oder Fernrechenvorrichtungen, die über ein oder mehrere Netze mit dem Netz 308 gekoppelt sind) ermöglichen.
  • Die Plattformlogik 310 kann beliebige geeignete Arten von Arbeitslasten empfangen und ausführen. Eine Arbeitslast kann jede Anforderung zum Verwenden eines oder mehrerer Betriebsmittel der Plattformlogik 310, wie beispielsweise eines oder mehrerer Kerne oder zugehöriger Logik, umfassen. Zum Beispiel kann eine Arbeitslast umfassen: eine Anforderung zum Instanziieren einer Softwarekomponente wie z. B. eines I/O-Vorrichtungs-Treibers 324 oder eines Gastsystems 322; eine Anforderung zum Verarbeiten eines Netzpakets, das von einer virtuellen Maschine 332 oder einer Vorrichtung außerhalb der Plattform 302A (wie etwa einem Netzknoten, der mit dem Netz 308 gekoppelt ist) empfangen wird; eine Anforderung zum Ausführen eines Prozesses oder Strangs, der einem Gastsystem 322 zugeordnet ist, einer Anwendung, die auf der Plattform 302A läuft, eines Hypervisors 320 oder eines anderen Betriebssystems, das auf der Plattform 302A läuft; oder eine andere geeignete Verarbeitungsanforderung.
  • Eine virtuelle Maschine 332 kann ein Computersystem mit eigener dedizierter Hardware emulieren. Eine virtuelle Maschine 332 kann ein Gastbetriebssystem über dem Hypervisor 320 laufen lassen. Die Komponenten der Plattformlogik 310 (z. B. die CPU 312, der Speicher 314, der Chipsatz 316 und die Kommunikationsschnittstelle 318) können virtualisiert werden, so dass es dem Gastbetriebssystem scheint, als wiese die virtuelle Maschine 332 eigene dedizierte Komponenten auf.
  • Eine virtuelle Maschine 332 kann einen virtualisierten NIC (vNIC) umfassen, der von der virtuellen Maschine als ihre Netzschnittstelle verwendet wird. Einem vNIC kann eine Medienzugriffssteuerungsadresse (MAC-Adresse) oder eine andere Kennung zugewiesen werden, wodurch es ermöglicht wird, dass mehrere virtuelle Maschinen 332 einzeln in einem Netz adressierbar sind.
  • Eine VNF 334 kann eine Softwareimplementierung eines funktionalen Bausteins mit definierten Schnittstellen und definiertem Verhalten umfassen, die in einer virtualisierten Infrastruktur eingesetzt werden kann. In bestimmten Ausführungsformen kann eine VNF 334 eine oder mehrere virtuelle Maschinen 332 umfassen, die gemeinsam spezifische Funktionalitäten bereitstellen (z. B. Weitbereichsnetz-Optimierung (WAN-Optimierung), Terminierung für ein virtuelles privates Netz (VPN-Terminierung), Firewall-Operationen, Lastausgleichsoperationen, Sicherheitsfunktionen etc.). Eine VNF 334, die auf der Plattformlogik 310 läuft, kann die gleiche Funktionalität bereitstellen wie traditionelle Netzkomponenten, die durch dedizierte Hardware implementiert sind. Zum Beispiel kann eine VNF 334 Komponenten zum Ausführen beliebiger geeigneter NFV-Arbeitslasten wie beispielsweise Komponenten des virtualisierten entwickelten Paketkerns (vEPC-Komponenten), Mobilitätsmanagemententitäten, Steuerungs- und Datenebenenkomponenten für das Partnerschaftsprojekt der 3. Generation (3GPP) usw. umfassen.
  • Die SFC 336 ist eine Gruppe von VNFs 334, die als eine Kette organisiert sind, um eine Reihe von Operationen wie etwa Netzpaketverarbeitungsoperationen durchzuführen. Das Verketten von Dienstfunktionen kann die Möglichkeit bereitstellen, eine geordnete Liste von Netzdiensten (z. B. Firewalls, Lastausgleicher) zu definieren, die in dem Netz verkettet werden, um eine Dienstkette zu erzeugen.
  • Ein Hypervisor 320 (auch bekannt als ein Monitor für virtuelle Maschinen) kann eine Logik zum Erzeugen und Ausführen von Gastsystemen 322 umfassen. Der Hypervisor 320 kann Gastbetriebssysteme darstellen, die von virtuellen Maschinen mit einer virtuellen Betriebsplattform ausgeführt werden (d. h. es scheint den virtuellen Maschinen, die auf separaten physischen Knoten laufen, als ob sie tatsächlich auf einer einzelnen Hardwareplattform zusammengelegt wären), und die Ausführung der Gastbetriebssysteme durch die Plattformlogik 310 verwalten. Dienste des Hypervisors 320 können durch Virtualisierung in Software oder durch hardwareunterstützte Betriebsmittel, die eine minimale Softwareintervention erfordern, oder beides bereitgestellt werden. Mehrere Instanzen einer Vielzahl von Gastbetriebssystemen können durch den Hypervisor 320 verwaltet werden. Jede Plattform 302 kann eine separate Instanz eines Hypervisors 320 aufweisen.
  • Der Hypervisor 320 kann ein nativer oder Bare-Metal-Hypervisor sein, der direkt auf der Plattformlogik 310 läuft, um die Plattformlogik zu steuern und die Gastbetriebssysteme zu verwalten. Alternativ kann der Hypervisor 320 ein gehosteter Hypervisor sein, der auf einem Host-Betriebssystem läuft und die Gastbetriebssysteme von dem Hostbetriebssystem abstrahiert. Der Hypervisor 320 kann einen virtuellen Switch 338 umfassen, der virtuelle Vermittlungs- und/oder Routing-Funktionen für virtuelle Maschinen der Gastsysteme 322 bereitstellen kann. Der virtuelle Switch 338 kann eine logische Vermittlungs-Fabric umfassen, die die vNICs der virtuellen Maschinen 332 miteinander koppelt, wodurch ein virtuelles Netz erstellt wird, über das virtuelle Maschinen miteinander kommunizieren können.
  • Der virtuelle Switch 338 kann ein Softwareelement umfassen, das unter Verwendung von Komponenten der Plattformlogik 310 ausgeführt wird. In verschiedenen Ausführungsformen kann der Hypervisor 320 mit irgendeiner geeigneten Entität (z. B. einem SDN-Controller) in Verbindung stehen, die den Hypervisor 320 dazu veranlassen kann, die Parameter des virtuellen Schalters 338 als Antwort auf sich ändernde Bedingungen in der Plattform 302 (z. B. ein Hinzufügen oder Entfernen von virtuellen Maschinen 332 oder eine Identifizierung von Optimierungen, die vorgenommen werden können, um das Leistungsvermögen der Plattform zu verbessern) umzukonfigurieren.
  • Der Hypervisor 320 kann auch eine Betriebsmittelzuteilungslogik 344 umfassen, die eine Logik zum Bestimmen einer Zuteilung von Plattformbetriebsmitteln basierend auf den Telemetriedaten (die Belastungsinformationen enthalten können) umfassen kann. Die Betriebsmittelzuteilungslogik 344 kann auch Logik zum Kommunizieren mit verschiedenen Komponenten von Entitäten der Plattformlogik 310 der Plattform 302A wie etwa Komponenten der Plattformlogik 310 zum Implementieren einer solchen Optimierung umfassen.
  • Eine beliebige geeignete Logik kann eine oder mehrere dieser Optimierungsentscheidungen treffen. Zum Beispiel kann die Systemmanagementplattform 306; die Betriebsmittelzuteilungslogik 344 des Hypervisors 320 oder eines anderen Betriebssystems; oder eine andere Logik der Computerplattform 302A solche Entscheidungen treffen. In verschiedenen Ausführungsformen kann die Systemmanagementplattform 306 Telemetriedaten von mehreren Plattformen 302 empfangen und die Arbeitslastunterbringung über mehrere Plattformen 302 verwalten. Die Systemmanagementplattform 306 kann mit Hypervisoren 320 (z. B. in einem bandexternen Modus) oder anderen Betriebssystemen der verschiedenen Plattformen 302 zum Implementieren von Arbeitslastunterbringungen, die von der Systemmanagementplattform gesteuert werden, kommunizieren.
  • Die Elemente der Plattformlogik 310 können auf beliebige geeignete Weise miteinander verbunden sein. Zum Beispiel kann ein Bus beliebige der Komponenten zusammenkoppeln. Ein Bus kann jegliche bekannte Verbindung umfassen, beispielsweise einen Multi-Drop-Bus, eine Gitterzwischenverbindung, eine Ringzwischenverbindung, eine Punkt-zu-Punkt-Zwischenverbindung, eine serielle Zwischenverbindung, einen parallelen Bus, einen kohärenten (z. B. cachekohärenten) Bus, eine geschichtete Protokollarchitektur, einen differentiellen Bus oder einen Gunning-Sendempfängerlogik-Bus (GTL-Bus).
  • Elemente der Computerplattform 302A können auf beliebige geeignete Weise miteinander gekoppelt sein, beispielsweise durch ein oder mehrere Netze 308. Ein Netz 308 kann ein beliebiges geeignetes Netz oder eine Kombination aus einem oder mehreren Netzen sein, die unter Verwendung eines oder mehrerer geeigneter Netzprotokolle arbeiten. Ein Netz kann eine Reihe von Knoten, Punkten und miteinander verbundenen Kommunikationswegen zum Empfangen und Senden von Informationspaketen, die sich durch ein Kommunikationssystem ausbreiten, darstellen. Zum Beispiel kann ein Netz eine oder mehrere Firewalls, Router, Switches, Sicherheitseinrichtungen, Antivirus-Server oder andere nützliche Netzvorrichtungen umfassen.
  • 4 ist ein Blockdiagramm einer Mikrodienste-Architektur gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In diesem Fall umfasst die Mikrodienste-Architektur 400 eine Hostsoftware 404, die auf einem Rechenknoten in einem Datenzentrum läuft, der eine VM umfassen kann, die auf einer Hardwareplattform gehostet wird. Die Hostsoftware 404 benötigt möglicherweise Zugriff auf verschiedene Betriebsmittel wie nichtflüchtigen Speicher, persistenten schnellen Speicher, FPGAs und andere geeignete Dienste. In einem veranschaulichenden Beispiel stellt die Mikrodienste-Architektur 400 eine Sicherheitsfunktion bereit, wie z. B. einen Fabric-Durchfluss-Mikrodienst zur Nichtabstreitbarkeit, um einen Nachweis der Integrität oder des Ursprungs von Daten bereitzustellen.
  • In einem Beispiel muss die Hostsoftware 404 möglicherweise Fabric-Verkehr durch einen Mikrodienst fließen lassen, um den Verkehr zu verschlüsseln und zu signieren, und dann per DMA (direkten Speicherzugriff) den Verkehr im Betrieb in den persistenten Speicher bringen, bevor er zu der nächsten Etappe weitergeleitet wird.
  • In diesem Beispiel sind mehrere Mikrodienst-Beschleuniger 415 verfügbar, einschließlich lokaler Software 430, eines Betriebsmittelpools 424, einer FPGA (oder eines FPGA-Pools) 420 und eines Hardwarebeschleunigers 416. Es ist zu beachten, dass die hier offenbarten Mikrodienst-Beschleuniger 415 nur als nicht einschränkende Beispiele bereitgestellt sind und Hardwarebeschleuniger 415 auch eine beliebige andere Vorrichtung oder Funktion umfassen können, die dazu ausgelegt ist, den Mikrodienst bereitzustellen.
  • Die lokale Software 430 kann eine Software sein, die unter demselben Betriebssystem läuft wie die Software 404. Mit anderen Worten kann die lokale Software 430 eine Subroutine oder ein Modul sein, das auf der gleichen Plattformhardware wie die Hostsoftware 404 läuft.
  • Der Betriebsmittelpool 424 kann ein Betriebsmittelpool sein, wie er auf einem Rechnerschlitten oder in einem Rechenrack bereitgestellt werden kann, wobei eine große Anzahl von identischen oder nahezu identischen Betriebsmitteln vorgesehen ist und dynamisch für andere Knoten in dem Datenzentrum bereitgestellt wird. Dies könnte einen Speicherserver einschließlich eines PFM-Servers, eines Speicherservers oder verschiedener Beschleuniger oder andere Betriebsmittel umfassen.
  • Der FPGA-Pool 420 mit einer Anzahl von FPGAs, die dynamisch bereitgestellt und programmiert werden können, um die gewünschte Mikrodienstfunktion auszuführen, ist ebenfalls verfügbar.
  • Die Hardwarebeschleuniger 416 können ebenfalls bereitgestellt sein. Die Hardwarebeschleuniger 416 können ASICs, SoCs oder andere dedizierte Hardware, die eine Funktion im Vergleich zu Software mit sehr hoher Geschwindigkeit ausführt, umfassen.
  • Wenn ein jeweiliges Betriebsmittel online geht, kann es sich bei einer Diensterkennungsfunktion (SDF) 440 registrieren. Die SDF 400 kann eine separate VM, die in dem Datenzentrum läuft, oder ein Modul oder eine Funktion eines Orchestrators (z. B. des Orchestrators 260 von 2) sein.
  • Zum Beispiel kann das lokale Softwaremodul 430 online gehen und sich bei der SDF 440 registrieren. Diese Registrierung kann die Fähigkeit der Funktion (in diesem Fall eine Verschlüsselung und Signierung für die Nichtabstreitbarkeit bereitzustellen) beinhalten. Sie kann die Art der Instanz und ihre Ausführung (z. B. in Software, die auf einem Vierkern-Xeon™-Prozessor von Intel® ausgeführt wird, bei dem zwei Kerne für die Verschlüsselungs- und Signaturfunktion verfügbar sind) beinhalten. Sie kann zudem bei der SDF 440 zur Interoperabilität mit lokaler Software 430 Details darüber registrieren, wie jeder Funktionsaufruf formatiert sein sollte.
  • In ähnlicher Weise können der Betriebsmittelpool 424, die FPGA 420 und der Hardwarebeschleuniger 416 ebenfalls ihre Fähigkeiten bei der SDF 440 registrieren. Die SDF 440 speichert diese alle in einem Katalog 448. Es ist zu beachten, dass beispielsweise im Fall der FPGA 420 die Registrierung bei der SDF 440 kann nicht nur die Fähigkeit der FPGA 420 zum Durchführen von Verschlüsselung und Signierung beinhalten kann, sondern auch eine Gatterkonfiguration zum Konfigurieren der FPGA 420 mit der Logik zum Durchführen der Funktion und Zuordnungen von Pins oder Ports zu Eingabe- und Ausgabefunktionen.
  • In diesem Beispiel können die lokale Software 430, der Betriebsmittelpool 424, der FPGA-Pool 420 und der Hardwarebeschleuniger 416 jeweils eine identische oder nahezu identische Funktion bereitstellen (oder so konfiguriert sein, dass sie bereitgestellt wird), wie etwa einen Nichtabstreitbarkeits-Mikrodienst, der eine Verschlüsselung und Signierung erfordert.
  • Unter Beibehaltung der Nichtabstreitbarkeit als Beispiel könnte die Hostsoftware 404 einfach die Verschlüsselung und Signierung über ihren eigenen Softwarestapel durchführen. Dies kann jedoch rechenintensiv und betriebsmittelintensiv sein und dazu führen, dass der Dienst zu einem Engpass im Netzfluss wird. Das Auslagern der Funktion in einen Beschleuniger kann effizienter und schneller sein und dafür sorgen, dass Pakete das Datenzentrum reibungsloser durchlaufen. Zur Zeiten des Entwurfs weiß ein Programmierer der Hostsoftware 404 jedoch vielleicht nicht, welche Nichtabstreitbarkeits-Beschleunigungsfähigkeiten verfügbar sein werden.
  • Um die Effizienz der Hostsoftware 404 zu steigern, kann die Hostsoftware 404, statt ihre eigene native Subroutine aufzurufen oder zu versuchen, die genauen Betriebsmittel vorauszusehen, die im Datenzentrum verfügbar sein werden, einen Aufruf an die Mikrodienste-API 408 ausgeben. Diese kann eine vereinheitlichte „cloudfreundliche“ API sein. Anstatt auf eine spezifische Plattform oder eine spezifisches Vorrichtung ausgerichtet zu sein, kann der Aufruf an die Mikrodienste-API 408 als ein einzelner Verfahrensaufruf in einer standardisierten Form formatiert sein (z. B. „Dienst.Nichtabstreitbarkeit ([Parameter])“, der über Betriebsmittelinstanzen hinweg vereinheitlicht ist. Dies kann dynamisches Versenden und Einbinden von Funktionen hinter der Mikrodienste-API 408 einschließen und den Zugriff auf Mikrodienste mit einer vereinheitlichten Adressierung ermöglichen. Einige Funktionen in dem Katalog 448 können ausgewählt werden oder die Auswahl kann durch eine ontologische Katalogisierung von Eigenschaften unterstützt werden.
  • Die Mikrodienste-API 408 kommuniziert mit dem Mikrodienste-Treiber 412, der die SDF 440 abfragt, um eine beste verfügbare Mikrodienst-Instanz zum Ausführen der Nichtabstreitbarkeitsfunktion zu identifizieren. Die Identifizierung einer besten verfügbaren Instanz kann Faktoren wie die Priorität der Hostsoftware 404 im gesamten Datenzentrum, die Belastung vorhandener Instanzen der Mikrodienst-Funktion, die relativen Geschwindigkeiten der Instanzen und jeden anderen Faktor, der zur Optimierung der Gesamtfunktion des Rechenzentrums verwendet werden kann, umfassen.
  • Man betrachte zum Beispiel einen Fall, in dem der Hardwarebeschleuniger 416 die schnellste Verarbeitung für Verschlüsselungs- und Signierfunktionen bietet. Dies liegt möglicherweise daran, dass der Hardwarebeschleuniger 416 vollständig in Hardware implementiert ist und somit sehr schnell ist. Andere Knoten in dem Datenzentrum können jedoch bereits Instanzen des Hardwarebeschleunigers 416 an oder nahe an ihrer optimalen Kapazität verwenden. Somit kann das Einbringen eines neuen Flusses in den Hardwarebeschleuniger 416 statt einer Optimierung von Datenzentrums-Betriebsmitteln tatsächlich zu einer zusätzlichen Belastung für Datenzentrums-Betriebsmittel werden. Stattdessen kann der Mikrodienste-Treiber 412, der mit der SDF 440 in Kommunikation steht, einen FPGA-Pool 420 als das beste verfügbare Betriebsmittel zum Ausführen des Verschlüsselungs- und Signierungs-Mikrodienste identifizieren. Statt den Hardwarebeschleuniger 416 zusätzlich zu belasten, kann der Mikrodienste-Treiber 412 von der SDF 440 über den Katalog 448 eine Gatterkonfiguration zum Zuteilen eines oder mehrerer FPGAs in dem FPGA-Pool 420 zum Ausführen der Verschlüsselungs- und Signierfunktion empfangen. Es ist jedoch zu beachten, dass der Mikrodienste-Treiber 412 möglicherweise nicht der Agent ist, der tatsächlich die Programmierung der FPGA ausführt. Diese Funktion kann an spezialisierte Hardware delegiert werden und die Befehle zum Ausführen der Programmierung können von dem Mikrodienst-Treiber 412, von dem Orchestrator oder von irgendeiner anderen Vorrichtung kommen, die dazu ausgelegt ist, die FPGA-Programmierung zu veranlassen. Sobald ein oder mehrere FPGAs zugeteilt und programmiert worden sind, können sie dann weiterhin mit den Flüssen arbeiten, die in die Hostsoftware 404 eingehen, bis sich die Mikrodienste-Lage des Systems ändert und es notwendig ist, Mikrodienst-Instanzen neu zuzuteilen.
  • Es ist zu beachten, dass in diesem Beispiel der Mikrodienste-Treiber 412 nicht nur die Dienste, sondern auch Flüsse, die dem Dienst zugeordnet sind, bereitstellt. Diese Fähigkeit, Nachrichtenflüsse dynamisch zu definieren, führt zu einem Konzept der Verkettung, dessen Vorteil es ist, dass Aufrufe von mehreren Mikrodiensten in eine Pipeline gebracht werden und somit der Latenzaufbau reduziert wird. Anstelle dessen, dass eine Anwendung auf den Abschluss eines Aufrufs einer Funktion wartet, können die Mikrodienste einfach in einem einzigen Ablauf verkettet werden.
  • Wenn beispielsweise eine Dienstkette definiert wird, in der eingehende Pakete zuerst entschlüsselt werden und ihre Signaturen verifiziert werden und dann Pakete der DPI unterzogen werden, kann der Mikrodienste-Treiber 412 nicht nur eine Instanz der Entkapselungs- und Signierungs-Mikrodienste bereitstellen, sondern auch eine Instanz des DPI-Mikrodienstes. Diese Instanzen werden so bereitgestellt, dass dann, wenn die Entkapselungs- und Signaturprüfungsfunktion abgeschlossen ist, das Ergebnis nicht an die Hostsoftware 404 zurückgegeben werden muss, um dann über die Mikrodienste-API 408 eine Instanz der DPI aufzurufen. Vielmehr kann der Mikrodienste-Treiber 412, wenn er beide Dienste bereitstellt, eine Schnittstelle zwischen ihnen erstellen, so dass, sobald der Entschlüsselungs-Mikrodienst das Entschlüsseln des Pakets abschließt, er das entschlüsselte Paket direkt an die sDPI-Mikrodienst-Instanz liefern kann. Die DPI-Mikrodienst-Instanz kann dann ihre DPI-Funktion ausführen und entweder das Ergebnis zurück an die Hostsoftware 404 senden oder, wenn es einen anderen Mikrodienst in der Kette gibt, das Paket an den nächsten Mikrodienst weiterleiten.
  • 5 ist ein Ablaufdiagramm eines Verfahrens 500 zum Registrieren und Verwenden von Mikrodiensten gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung.
  • In Block 508 registriert sich eine Anzahl von Mikrodiensten oder mikrodienstfähigen Betriebsmittelregistern bei der SDF 540. Die SDF 540 kann die registrierten Instanzen in einem ontologischen Katalog 548 speichern.
  • In Block 504 stellt eine Anwendung eine Mikrodienste-Erkennungsanforderung für eine bestimmte Funktion, die in dem ontologischen Modell beschrieben ist. Diese Anforderung wird an ein Diensterkennungsmodul 512 gesendet.
  • In Block 516 führt das Diensterkennungsmodul eine Katalogsuche mittels der SDF 540 durch. Die SDF 540 liefert eine Liste verfügbarer Mikrodienst-Instanzen einschließlich der Attribute jeder Instanz.
  • In Block 520 kann ein Mikrodienste-Treiber die Attribute aus dem Katalog 548 mit den Anforderungen der Instanz-Dienst-Anforderung 504 abgleichen.
  • Wenn eine passende Instanz mit ausreichender Bandbreite verfügbar ist, dann kann der Mikrodienste-Treiber in Block 524 den Zugriff auf die Instanz orchestrieren, also beispielsweise eine neue vereinheitlichte Endpunkt-Betriebsmittelkennung (Endpunkt-URI) bereitstellen, damit die Hostsoftware auf die Mikrodienst-Instanz zugreifen kann.
  • Wenn keine Instanz verfügbar ist, dann kann der Mikrodienste-Treiber in Block 528 eine neue Instanz bereitstellen, und die Kommunikation mit dieser neuen Instanz kann mit der Dienstanforderung koordiniert werden.
  • In Block 532 kann die anfordernde Hostsoftware mit der Mikrodienst-Instanz verbunden werden. Dies könnte beispielsweise einen einfachen Handshake beinhalten, so dass jeder weiß, dass er mit dem anderen kommuniziert.
  • Schließlich beginnt der Hostdienst in Block 536 mit der Verwendung der bereitgestellten Mikrodienst-Instanz, beispielsweise durch Vermitteln eines Pakets an die bereitgestellte URI.
  • Es ist zu beachten, dass in diesem grundlegenden Szenario sowohl die Implementierung als auch der Weg zu ihr dynamisch waren und die Anwendung selbst nichts über das Verfahren der Instanziierung der am besten passenden Implementierung der Funktion und das optimale Verfahren der Kommunikation mit der Funktion weiß.
  • Die 6 und 7, die folgen, zeigen zusätzliche Einzelheiten einer Mikrodienste-Architektur, wobei 6 eine erstmalige Einrichtung einer Mikrodienst-Instanz darstellt und 7 eine spätere Verwendung der Mikrodienste-Instanz zeigt.
  • 6 ist ein Blockdiagramm einer anfänglichen Einrichtung einer Mikrodienst-Instanz gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung. In diesem Fall verwendet eine Anwendung 604 die Middleware 610, um mit den Treibern 614 zu kommunizieren. Die Anwendung 604 hat den Bedarf, auf einen Mikrodienst zuzugreifen.
  • In Operation 1 stellt die Anwendung 604 eine Mikrodienste-Erkennungsanforderung bei dem Mikrodienste-Treiber. Der Mikrodienste-Treiber kann dann eine Erkennungsanforderung 620 über die Fabric ausgeben. Ferner kann der Mikrodienste-Treiber in Block 620 eine gewünschte Implementierungsoption, beispielsweise einen Hardwarebeschleuniger, eine FPGA oder einen Betriebsmittelpool, auswählen und eine Anforderung an einen Management- und Netzorchestrierungsserver (MANO-Server) (z. B. den Orchestrator 260) ausgeben, der in diesem Fall die SDF bereitstellen kann.
  • In Operation 3 startet der MANO 628 eine Instanz der gewünschten Mikrodienst-Instanz oder stellt sie anderweitig bereit. Dies könnte beispielsweise einen Anwendungscontainer 640 mit einem API-Wrapper 644 und eine Softwarebibliothek 648 umfassen. In einem anderen Beispiel umfasst dies einen Anwendungscontainer 650 mit einem API-Wrapper 654, einem Treiber oder einer Middleware 658 und einem Hardwarebeschleuniger 660.
  • Die entsprechenden Attribute der bereitgestellten Instanz sind in einer Mikrodienste-Beschreibung 634 eingekapselt, die in der Mikrodienste-Registrierung 630 registriert ist.
  • In Operation 4 wird ein Nachrichtenweiterleiter 624 eingerichtet, um es der Anwendung 604 zu ermöglichen, mit der neuen Instanz des Mikrodienstes zu kommunizieren. Dies kann beispielsweise ein dynamisches Nachrichtenweiterleitungselement des erforderlichen Typs sein. Der Nachrichtenweiterleiter 624 kann als eine Konfiguration einer Fabric implementiert sein, die eine Anwendung mit geeigneten Mikrodiensten verbindet (Netz, Bus usw.). In einer solchen Ausführungsform wäre das Weiterleiten eine „passive“ Übertragung von Daten.
  • In Operation 5 wird die notwendige Verknüpfung zwischen dem Nachrichtenweiterleiter 624 und der Anwendung 604 abgeschlossen, wodurch eine offene Kommunikationsleitung zwischen der Anwendung und der Mikrodienst-Instanz bereitgestellt wird. Dies stellt eine Verknüpfung zum Anfordern einer Instanz der Aufgabe bereit, die von dem Mikrodienst sowohl gegenwärtig als auch für zukünftige Flüsse bereitgestellt wird, wie es ferner in 7 (wie in den Operationen 6 und 7) gezeigt ist.
  • Im Allgemeinen kann eine Kette von Mikrodienst-Aufrufen aufgebaut werden, indem diese Operation weiter wiederholt wird, so dass jede Instanz eines Mikrodienstes dynamisch ausgewählt wird und für direkte Kommunikation von seiner Vorgänger-Mikrodienst-Instanz in der Kette angepasst ist. Somit sieht die Einrichtung des Nachrichtenweiterleiters 624 im Falle einer Mikrodienstkette in einigen Fällen nicht eine Verknüpfung zwischen der Anwendung 604 und dem Mikrodienst, sondern vielmehr zwischen einem vorhergehenden Mikrodienst und dem nächsten Mikrodienst in der Dienstkette vor. Wie bei der Anwendung 604 kann jeder Vorgänger-Mikrodienst nichts von den Implementierungsdetails seines Nachfolge-Mikrodienstes und von den Einzelheiten des Bereitstellens eines besten Wegs zum Erzeugen des Aufrufs wissen.
  • 7 ist eine Darstellung des Betriebs von Mikrodiensten, die als eine Erweiterung des Blockdiagramms von 6 betrachtet werden kann.
  • In dem Beispiel von 7 hat die Hostsoftware 702 die Bereitstellung mehrerer Mikrodienste angefordert, nämlich eines Mikrodienst 704-1, Mikrodienstes 704-2 und Mikrodienstes 704-3.
  • In Operation 6 greift die Hostsoftware 702 auf den Mikrodienst 704-1 zu, beispielsweise durch Bereitstellen eines Datenflusses zu der URI, die dem Mikrodienst 704-1 zugeordnet ist.
  • Der Mikrodienst 704-1 empfängt den Fluss von der Hostsoftware 702 und führt seinen speziellen Mikrodienst für den Fluss aus. Zum Beispiel könnte der Mikrodienst 704-1 eine Entschlüsselung und Schlüsselverifizierung an eingehenden Paketen bereitstellen.
  • Der Mikrodienst 704-1 betreibt in Operation 7 nun den Nachrichtenweiterleiter 708, um das Paket an den Mikrodienst 704-2 weiterzuleiten.
  • Der Mikrodienst 704-2 kann beispielsweise ein DPI-Mikrodienst sein, der eine detaillierte Analyse des eingehenden Pakets durchführt.
  • Sobald der Mikrodienst 704-2 seine vertiefte Paketinspektion abgeschlossen hat, betreibt er einen weiteren Nachrichtenweiterleiter 708, um das Paket an den Mikrodienst 704-3 weiterzuleiten.
  • Der Mikrodienst 704-3 kann irgendeine andere Hilfsfunktion ausführen, beispielsweise eine statistische Funktion oder Funktion für große Datenmengen, die den Wert des Pakets nicht beeinflusst, die aber zum Verwalten des Datenzentrums und der Dienste, die für den Kunden bereitgestellt werden, verwendet wird.
  • Sobald der Mikrodienst 704-3 seine Funktion abgeschlossen hat, gibt er das Paket an die Hostsoftware 702 zurück, die nun das Paket gemäß ihrem normalen Prozess behandeln kann.
  • In dem Beispiel von 7 kann der Nachrichtenweiterleiter 708 ein einzelner, monolithischer Nachrichtenweiterleiter sein, der eine Verbindung zwischen Mikrodienst-Instanzen bereitstellt (ähnlich einem schlanken vSwitch, der zum Weiterleiten von Paketen zwischen Mikrodiensten ausgelegt ist), so dass der Nachrichtenweiterleiter 708 als ein Hub zwischen Mikrodiensten fungiert. In einem anderen Beispiel kann jede Mikrodienst-Instanz ihre eigene dedizierte Verbindung zu anderen Mikrodiensten aufweisen, so dass Mikrodienste miteinander „verkettet“ werden, ohne dass ein zwischengeschalteter Hub erforderlich ist.
  • Es ist zu beachten, dass in diesem Fall eine gesamte Dienstkette auf das Paket angewendet wurde, nachdem es bei der Hostsoftware 702 eingetroffen ist, ohne dass das Paket zwischen der Hostsoftware 702 und den verschiedenen Mikrodienste in der Dienstkette „hin und herspringen“ musste. Es ist auch zu beachten, dass die Verwendung von Mikrodiensten es der Hostsoftware 702 ermöglicht, die verschiedenen Funktionen in der Dienstkette so zu behandeln, als wären sie ein einzelner Aufruf an eine Instanz eines lokalen Moduls. Anstatt also explizit auf eine Anzahl von Beschleunigern zuzugreifen, wobei das Paket an einen Beschleuniger gesendet, zu dem Host zurückgesendet, an einen zweiten Beschleuniger gesendet, wieder zu dem Host gesendet, an einen dritten Beschleuniger gesendet und ein drittes Mal zu dem Host zurückgesendet wird, werden eine Reihe von Beschleunigern in einer Kette verwendet und durch einen einzigen Funktionsaufruf aus der Hostsoftware 702 aufgerufen.
  • Es ist zu beachten, dass die in 5 bis 7 offenbarten Diagramme und Abläufe beispielsweise eine Abstraktion von Hardware, wie z. B. Beschleuniger niedriger Ebene, hinter einer gemeinsamen Mikrodienste-API bereitstellen. Dies ermöglicht sowohl die lokale Ausführung als auch die Fernausführung, eine flexible Adressierung und einen flexiblen Aufruf. Die für den Registrierungskatalog beschriebene Ontologie kann in einer erweiterbaren Sprache zum Definieren und Erkennen von Mikrodiensten basierend auf der gewünschten Funktionalität der Mikrodienste bereitgestellt werden. Zum Beispiel könnte ein Merkmal der ontologischen Sprache ein Deskriptor wie etwa „Funktion gleich Verschlüsselung (AES-GCM)“ sein. Somit kann die Anwendung die gewünschte Funktion und die Parameter wie etwa den Typ der Verschlüsselung spezifizieren, ohne bestimmte Implementierungsdetails zu spezifizieren. In einigen Fällen können jedoch einige Details bereitgestellt werden, wie beispielsweise eine maximal akzeptable Latenz, eine minimal akzeptable Bandbreite oder andere Faktoren, die das Leistungsvermögen beeinflussen können, das von einer bestimmten Anwendung benötigt wird. Die ontologische Sprache kann in ihrer Grammatik auch die Verkettung von Unterfunktionen unterstützen. In einer Ausführungsform kann die ontologische Sprache mit OpenAPI kompatibel sein und kann eine einfache Erkennung durch Menschen und durch Computer bieten.
  • Das Folgende wird mehrere Bausteine zum Realisieren der oben beschriebenen Mikrodienste-Architektur veranschaulichen. Dies umfasst spezifische Beschreibungen folgender Punkte:
  • Es ist zu beachten, dass die in 5 bis 7 offenbarten Diagramme und Abläufe beispielsweise eine Abstraktion von Hardware, wie z. B. Beschleuniger niedriger Ebene, hinter einer gemeinsamen Mikrodienste-API bereitstellen. Dies ermöglicht sowohl die lokale Ausführung als auch die Fernausführung, eine flexible Adressierung und einen flexiblen Aufruf. Die für den Registrierungskatalog beschriebene Ontologie kann in einer erweiterbaren Sprache zum Definieren und Erkennen von Mikrodiensten basierend auf der gewünschten Funktionalität der Mikrodienste bereitgestellt werden. Zum Beispiel könnte ein Merkmal der ontologischen Sprache ein Deskriptor wie etwa „Funktion gleich Verschlüsselung (AES-GCM)“ sein. Somit kann die Anwendung die gewünschte Funktion und die Parameter wie etwa den Typ der Verschlüsselung spezifizieren, ohne bestimmte Implementierungsdetails zu spezifizieren. In einigen Fällen können jedoch einige Details bereitgestellt werden, wie beispielsweise eine maximal akzeptable Latenz, eine minimal akzeptable Bandbreite oder andere Faktoren, die das Leistungsvermögen beeinflussen können, das von einer bestimmten Anwendung benötigt wird. Die ontologische Sprache kann in ihrer Grammatik auch die Verkettung von Unterfunktionen unterstützen. In einer Ausführungsform kann die ontologische Sprache mit OpenAPI kompatibel sein und kann eine einfache Erkennung durch Menschen und durch Computer verhindern.
  • Das Folgende wird mehrere Bausteine zum Realisieren der oben beschriebenen Mikrodienste-Architektur veranschaulichen. Dies umfasst spezifische Beschreibungen folgender Punkte:
    • • Vereinheitlichte APIs und vereinheitlichte Adressierung, wie weiter unten in Absatz [0133] beschrieben.
    • • Mikrodienst-Registrierung (SR), wie weiter unten in Absatz [0134] beschrieben.
    • • Mikrodienst-Erkennung (SD), wie weiter unten in Absatz [0136] beschrieben.
    • • Vereinheitlichte Zugriffsverfahren, wie weiter unten in Absatz [0137] beschrieben.
    • • Middleware und Treiber, wie weiter unten in Absatz [0138] beschrieben.
    • • Nachrichtenweiterleiter, wie weiter unten in Absatz [0139] beschrieben.
    • • Mikrodienst-Verkettung, wie weiter unten in Absatz [0141] beschrieben.
    • • Mikrodienst-Erkennungs-Endpunkt (SDE), wie weiter unten in Absatz [0148] beschrieben.
    • • Nachrichtendienst (MS), wie weiter unten in Absatz [0150] beschrieben.
    • • Mikrodienst-Anforderung, wie weiter unten in Absatz [0150] beschrieben.
    • • Adressierungsdienst (AS), wie weiter unten in Absatz [0151] beschrieben.
    • • Mikrodienste-Beschreibungskatalog, wie weiter unten in Absatz [0152] beschrieben.
    • • Nachrichtendienst-Wegkonfiguration, wie weiter unten in Absatz [0156] beschrieben.
    • • Nachrichtendienstfluss, wie weiter unten in Absatz [0158] beschrieben.
    • • Lastausgleichs-Engine (LBE), wie weiter unten in Absatz [0176] beschrieben.
  • Für vereinheitlichte APIs in vereinheitlichter Adressierung kann in diesem Fall die offene API verwendet werden, um eine standardmäßige sprachunabhängige Schnittstelle zu APIs zur Übertragung repräsentativer Zustände (REST-APIs) zu definieren, die es sowohl Menschen als auch Computern ermöglicht, die Fähigkeiten eines Mikrodienstes zu erkennen und zu verstehen und damit aus der Ferne mit minimaler Implementierungslogik zu interagieren. Weitere Einzelheiten sind nachstehend in der Beschreibung des Adressierungsdienstes zu finden.
  • Der Mikrodienste-Registrierungs-Mechanismus (SR-Mechanismus) ermöglicht eine weitere Erkennung von Diensten basierend auf ihren Beschreibungen. Ein Anbieter oder Ersteller eines Dienstes kann Einzelheiten zu Endpunkten und Beschreibungen von Diensten als nicht einschränkendes Beispiel in der erweiterbaren Sprache mit möglichen Kombinationen von Funktionen, Telemetriedetails, Lizenzierungs- und Erfassungsdetails, Skalierbarkeit und Instanziierung und Zugriffsverfahren bereitstellen.
  • Die Registrierung kann Teil einer Konfigurationsdatei oder einer Datenbank sein. Weitere Einzelheiten sind in der nachstehenden Beschreibung des Mikrodienste-Beschreibungskatalogs zu finden.
  • Die Mikrodienst-Erkennung (SD) identifiziert bei Anforderung verfügbare Dienste einschließlich der Identität einer besten Instanz oder optimalen Instanz oder der Option, eine neue Instanz zu erzeugen, wenn dies möglich ist, sowie die Konfiguration von Verkettungen und Diensten. Auf SD kann über einen bekannten Mechanismus oder eine bekannte Adresse zugegriffen werden, beispielsweise über eine bestimmte URI oder einen anderen Mechanismus, der Teil einer Middleware oder eines SDK sein kann. Die SD-Funktion lokalisiert Dienste, die zu einer angeforderten Funktion in der Lage sind, und konfiguriert bestimmte Dienstinstanzen und Nachrichtenweiterleiter zum Übertragen von Daten zwischen der anfordernden Anwendung und der Dienstinstanz oder verschiedenen Dienstinstanzen in einer Dienstkette. Wenn die Instanz von einer Anwendung aufgerufen wird, kann der Mikrodienst seine Ausgabe entweder an die aufrufende Software oder an einen nächsten Dienst in der Dienstkette weiterleiten. Auf Anforderung von der Anwendung kann die SD-Funktion eine vorhandene Instanz verwenden oder eine neue Instanz erzeugen, wenn dies von der Implementierung unterstützt wird. Die SD-Funktion kann auch als Lastausgleicher dienen, und zwar optional zusätzlich zum dynamischen Lastenausgleich, der von einem Nachrichtenweiterleiter durchgeführt wird, und mit dem MANO beim Erstellen und Entfernen von Instanzen zusammenarbeiten. Der MANO kann Einzelheiten der Lokalität und Präferenzen und Plattformfähigkeiten verwenden, um eine am besten geeignete Instanz eines Hardware- oder Softwaredienstes zu erzeugen. Weitere Einzelheiten sind in der nachstehenden Beschreibung des SDE zu finden.
  • Das vereinheitlichte Zugriffsverfahren ermöglicht die Verwendung bestmöglicher Aufrufverfahren in Abhängigkeit von dem Ort eines Dienstes und den Fähigkeiten der Umgebung. In einem Beispiel wird auf Mikrodienste über REST-APIs zugegriffen, die über das Netz ausgeführt werden. In anderen Fällen kann der Zugriff jedoch durch einen anderen Mechanismus erfolgen, beispielsweise durch direkten Fernspeicherzugriff (RDMA), gemeinsam genutzten Speicher, speicherabgebildete Eingabe/Ausgabe (MMIO) oder dergleichen. Der vereinheitlichte Zugriff kann erweiterbar sein und verschiedene Zugriffsverfahren unterstützen und in einigen Beispielen kann er in Middlewarekomponenten gehandhabt werden.
  • Middlewarekomponenten und Kernel-Treiber können zur Handhabung eines vereinheitlichten Zugriffs verwendet werden, wodurch der Zugriff von der tatsächlichen Implementierung abstrahiert wird. In einigen Fällen sind diese Komponenten bestehende Teile einer Cloud-Infrastruktur.
  • Nachrichtenweiterleiter können während der Mikrosystemerkennung und - bereitstellung bereitgestellt werden und können Details darüber enthalten, welche Dienste angefordert werden. Der Nachrichtenweiterleiter kann Instanzen von Diensten konfigurieren, um eine Weiterleitung zu dem nächsten Dienst durchzuführen. Dies schafft die Vorstellung eines Dienstflusses. Zusätzliche Details, die sich auf den Nachrichtenweiterleiter beziehen, sind nachfolgend in Verbindung mit der Nachrichtendienst-Wegkonfiguration und der Nachrichtendienst-Flussbeschreibung beschrieben.
  • Es ist zu beachten, dass eine Anwendung, die die Mikrodienst-Erkennung verwendet, um Endpunkte und Zugriffsverfahren zu finden, diese während der Verarbeitung aufrufen kann. Für eine Anwendung kann die Verwendung von Mikrodiensten so einfach sein wie das Ausgeben eines Subroutinenaufrufs, der durch den Mikrodienst-Treiber transparent über einen Nachrichtenweiterleiter gehandhabt wird, der Anforderungen an die richtige Mikrodienstinstanz vermittelt, hinsichtlich Lastausgleichs verteilt und/oder umgeleitet. Die Verwendung des Nachrichtenweiterleiters kann durch eine Richtlinie definiert sein, wie sie weiter unten in der Beschreibung des Nachrichtendienstablaufs beschrieben wird. Die Nachrichtendienstverkettung wird in Verbindung mit 8 weiter veranschaulicht.
  • 8 ist ein Blockdiagramm einer Nachrichtendienstverkettung gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Die Nachrichtendienstverkettung ist ein Verfahren, um die Funktionalität von Hardware- und Softwarebeschleunigern in einer cloudfreundlichen Weise unter Verwendung von Mikrodiensten mit einem einheitlichen Adressierungsschema freizulegen. Die Registrierung eines Mikrodienstes kann die Registrierung einer Mikrodienst-Verbindungsfähigkeit beinhalten, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren.
  • In Operation 1 gibt die Anwendung 830 eine Anforderung bezüglich der Funktion an den Diensterkennungsblock 812 aus.
  • In Operation 2 antwortet die Diensterkennung 812 mit einem „Hole Weg-ID“ an die Anwendung 830, um die Funktion und den Eintrittspunkt zu liefern.
  • Die Diensterkennungsfunktion 812 greift dann auf die Konfiguration 816 und die Nachrichtenweiterleitungsdaten 820 zu, um die geeignete Dienstkette bereitzustellen. Dies kann die Bereitstellung einer Dienstimplementierung 804 umfassen, die mehrere Dienste 0 bis n umfasst. Jeder Dienst kann eine Weg-ID und eine Nächste-Etappe-URI enthalten.
  • In Operation 3 erstellt die Anwendung 830 eine Nachricht 824, die eine Weg-ID, einen Nachrichteninhalt und eine Verfolgungs-ID enthalten kann. In Operation 4 sendet die Anwendung 830 die Nachricht 824 an die Dienstimplementierung 804.
  • In Operation 5 stellt die Dienstimplementierung 804 die geeignete Kette von Mikrodiensten bereit und beginnt mit der Leitung der Nachricht 824 durch die Mikrodienste.
  • In Operation 6 kann die Dienstimplementierung 804 optional einen Abschlussstatus an den Nachrichtenweiterleitungsblock 820 zurückgeben.
  • Der Diensterkennungs-Endpunkt stellt eine erweiterbare Infrastruktur zur Erkennung verfügbarer Dienste bereit, unabhängig von deren Implementierung und Lokalität. Dies unterstützt direkte Austausch-Ersetzungen und Optimierungen basierend auf den Anwendungspräferenzen, der Art der Arbeitslast und der Kombination von Diensten.
  • In diesem Zusammenhang bedeutet der Begriff „Endpunkt“ eine bekannte API, die von einer Anwendung zum Ausführen einer Funktion verwendet wird. Die Diensterkennung wird für die Anwendung in verschiedenen Kombinationen angeboten, z. B. als nicht einschränkendes Beispiel folgendermaßen:
    • • Eine spezielle URL oder URI als Einstiegspunkt.
    • • Eine PCI- oder PCIe-Vorrichtung, egal ob es sich um eine reale Vorrichtung oder eine emulierte Vorrichtung handelt, das mit B/D/F mit definierten Codierungen und Datenformaten für Nachrichten adressiert wird. Dies ermöglicht eine einfache Virtualisierung mit virtioähnlichen Vorrichtungen oder SR-IOV (im Falle von Hardwareimplementierungen) mit ioctl-basierter API, cHr-DeV oder Pseudo-NIC.
    • • Systemaufrufe oder andere Bibliotheken für Anrufe mit niedriger Latenz. Diensterkennungs-Endpunkte können in einigen Fällen fest codiert sein oder teilweise als Teil eines Cloud-INIT-Skripts oder dergleichen bereitgestellt werden.
  • 9 ist ein Blockdiagramm der Diensterkennung gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Im Fall einer Dienstanforderung fordert eine Anwendung eine spezifische Funktion von dem Nachrichtendienst (d. h. der Mikrodiensterkennungsfunktion (MDF)) an, indem sie eine Beschreibung der ausgeführten oder auszuführenden Funktion liefert. Dies ist in 9 zu sehen, in der die Diensterkennungsfunktion 900 eine Beschreibung des gewünschten Dienstes als Eingabe empfängt. Dies kann eine einzelne Funktion oder eine Folge von Funktionen, die auf die gleiche Nachricht in einer Dienstkette angewendet werden, sein. In einem weiteren Beispiel kann dies eine aufgezählte Liste von gewünschten Fähigkeiten sein. In einem Beispiel kann die offene API für diesen Zweck verwendet werden, obwohl dies ein nicht einschränkendes Beispiel ist. Die Beschreibung von Diensten kann auf verschiedene Arten oder in verschiedenen Formaten bereitgestellt werden und erforderliche Funktionen können zusätzlich zu anderen Informationen wie etwa funktionsspezifischen Parametern oder gewünschten Leistungsparametern geliefert werden. Die Ausgabe der Diensterkennungsfunktion 900 kann eine Weg-ID, die für den Dienst zu verwenden ist, Einzelheiten über den Endpunkt und verfügbare Optionen enthalten.
  • Für den Adressierungsdienst kann ein vereinheitlichtes Adressierungsschema verwendet werden, um dieselbe Aufrufkonvention bereitzustellen, um entfernte entfernte oder lokale Betriebsmittel sowie entweder geeignete Hardware- oder Software-Mikrodienste anzufordern. Der vereinheitlichte Adressierungsdienst kann implementiert werden, indem Aufrufe umgeleitet werden und Datenübertragungen an die tatsächliche Instanz geliefert werden. Die Anwendung selbst kann von der Instanz und ihrer Position oder ihren Implementierungsdetails unabhängig sein. Diese können mehreren Instanzen mit Lastausgleich zugeordnet werden, um die automatische Skalierung zu unterstützen. Ein Endpunkt wie beispielsweise ein Aufruf an eine lokale Host-URL kann bei diesem Ansatz ein Einstiegspunkt für einen Nachrichtenweiterleiter sein. Der Nachrichtenweiterleiter kann die Eingabeparameter der Nachricht, beispielsweise die Weg-ID, verarbeiten und sie in einen tatsächlichen Laufzeitaufruf der Mikrodienst-Instanz übersetzen.
  • Der Mikrodienste-Beschreibungskatalog kann zur Registrierung von Diensten verwendet werden. Wenn sie verfügbar werden, können eine neue Mikrodienst-Implementierung und -Instanz an der Diensterkennungsfunktion registriert werden. Eine Registrierung kann als Eingaben eine Beschreibung der bereitgestellten Dienste, eine Beschreibung der Funktionen einschließlich solcher Elemente wie Skalierungsoptionen, eine gemeinsame Nutzung von Betriebsmitteln und Datentypen enthalten und kann auch Telemetriedaten, Qualitätsfaktoren und dergleichen enthalten. Die Ausgabe der Registrierung kann einen Bestätigungsstatus enthalten.
  • Die Registrierung eines Mikrodienstes kann die Konfiguration eines Eintrittspunkts umfassen, das heißt als nicht einschränkendes Beispiel eine Beschreibung, wie der Dienst aufgerufen wird, eine Beschreibung unterstützter Funktionen und SLA-Einzelheiten. Wenn beispielsweise ein spezifisches Paket für eine FPGA geladen ist, kann es als ein Mikrodienst registriert werden, um den Einsatz durch Anwendungen zu ermöglichen, und als bevorzugt markiert werden, während Softwareimplementierungen immer noch nach Bedarf Nachrichten akzeptieren können. Neue Instanzen können auch transparent für aufrufende Anwendungen hinzugefügt werden, die auf die Mikrodienste über die Weg-ID und nicht über die Instanz-ID zugreifen. Die dynamische Zuteilung neuer Instanzen kann unterstützt werden, um eine automatische Skalierung zu aktivieren.
  • Dienste können auch eine API für Telemetrie verwenden, um ihre Verwendung, ihre Last und alle auftretenden Probleme zu melden. In einigen Fällen können die Namensräume und Kontext zur Isolierung von VMs oder Funktionsdomänen unterstützt werden. Vorteilhafterweise sind in diesem Fall keine Änderungen an der Vorrichtung selbst erforderlich.
  • Bei der Verwendung von Quick Assist™ von Intel® als Beispiel anstelle von SR-IOV zum Zuordnen einer Vorrichtung in VM ermöglicht die Architektur der vorliegenden Spezifikation, dass eine Instanz eines SSL-Mikrodiensts als Wrapper in einer QAT-Instanz implementiert wird und mit einem Eintrittspunkt wie einer URI eingerichtet wird. Wenn eine Anwendung Daten verschlüsseln oder entschlüsseln muss, erstellt sie eine Nachricht, die die zu verarbeitenden Daten und die zu verwendende Verschlüsselungs- oder Entschlüsselungsfunktion angibt. Anstatt das Paket an die anfordernde Anwendung zurückzugeben, kann das nächste Ziel ein Ethernet-Mikrodienst sein, der den verschlüsselten Inhalt tatsächlich über die Leitung sendet.
  • In dem Fall einer Nachrichtendienst-Wegkonfiguration während der Mikrodienste-Erkennung kann der Nachrichtendienst dann, wenn eine Anwendung eine spezifische Funktion anfordert, Folgendes ausführen:
    • • Überprüfen, ob die angeforderte Funktion unterstützt wird.
    • • Zuteilen einer Weg-ID für die angeforderte Folge von Funktionen und Zurückgeben der Weg-ID für die spätere Verwendung durch die Anwendung.
    • • Zuteilen von Betriebsmitteln, um die streamartige Verarbeitung zu aktivieren (Instanzen verbinden, Speicher teilen usw.). Eine Aufgabe kann synchrone oder asynchrone Ausführung spezifizieren. Gemeinsam genutzte Speicherpuffer können Mikrodienste-Instanzen verbinden und können auch für verschiedene Plattformoperationen verwendet werden, wie Fernaufruf (z. B. über Ethernet, RDMA oder Ähnliches). Dies kann zur Erstellung eines Dienstflusses führen.
  • Ein vereinheitlichter Mechanismus zum Adressieren von Diensten kann eine lokale Softwareinstanz, eine lokale Hardwareimplementierung oder eine Fernimplementierung eines beliebigen Typs umfassen. Der Nachrichtendienst kann sich um die Einrichtung des Dienstwegs kümmern, einschließlich der Konfiguration von zwischengeschalteten Diensten für domänenübergreifende oder serverübergreifende Verbindungen. Die Anwendung kann ein beliebiges implementiertes Verfahren zur Kommunikation mit dem Nachrichtendienst verwenden, wie beispielsweise eine URI, PCIe, einen Bibliotheksaufruf oder Ähnliches. Die Anwendung unterstützt möglicherweise auch ein Senden von Nachrichten an die Instanzen von Mikrodiensten.
  • Der Nachrichtendienstfluss unterstützt verschiedene Merkmale:
    • • Eine Eingangswarteschlange kann hardwaregerecht mit gemeinsam genutzten Speicherpuffern implementiert werden.
    • • Eine Eingangswarteschlangenumleitung kann verwendet werden, um die Verarbeitung zu verzögern oder zu delegieren, wenn die aktuelle Instanz die Verarbeitung aus irgendeinem Grund nicht akzeptieren kann, wodurch ein „Brisanz“-Lastausgleich ermöglicht wird.
    • • eine Dienst-Implementierung, bei der es sich um Software oder Hardware handeln kann.
    • • Optionale Hardwareunterstützungen, die einen als Mikrocode implementierten Plattform-Pseudo-Befehl bereitstellen, der eine Nachrichtenweiterleitung durchführen kann. Dieser kann interne Tabellen für den Status verwenden und zudem Lastenausgleich, Argumentvalidierung usw. durchführen.
  • Dies ermöglicht es dem Dienststapel, viele gut formulierte Operationen und Verantwortlichkeiten an die Plattform oder Cloud-Dienste zu delegieren. Infrastrukturspezialisierung und Teilnahme können somit unabhängig und parallel mit der Entwicklung und Optimierung von Aufgaben erfolgen. Bedenken wie etwa, ob die Vermittlung virtuell ist oder nicht oder wie sich dies auf die Skalierung oder Latenz auswirkt, können auf niedrigere Ebenen verlagert werden, wo sie am besten auf eine dynamische Umgebung angepasst werden. Ein Mikrodienst kann somit wissen, wohin er eine Nachricht entlang eines spezifischen Weges weiterleiten soll; beispielsweise kann die Nachrichtenweiterleitungsfunktion einen Speicherkanal implementieren (Instanz auf demselben Server) oder einen Fernaufruf über RDMA oder eine Fabric-Bibliothek über OmniPath™ von Intel® verwenden.
    • • Dienste können sowohl eine Software- als auch eine Hardwareimplementierung oder eine Kombination aus beidem aufweisen.
    • • Ein hardwarebasierter Lastausgleich kann die Verwendung von Hardwareimplementierungen von Diensten erleichtern.
    • • Ein Pipelineüberlauf-Benachrichtigungsmechanismus kann verwendet werden, wenn entlang des Dienstwegs ein Engpass auftritt.
    • • Die Benachrichtigung über neue Nachrichten an den nächsten Dienst kann durch schlanke Semaphore bereitgestellt werden, insbesondere wenn sich der Empfänger auf demselben Host befindet, oder durch Interrupts. In einem weiteren Beispiel kann der empfangende Dienst Eingangswarteschlangen abfragen.
  • Für Anwendungsanforderungen bereitet die Anwendung eine zu sendende Nachricht vor, die vier Teile umfasst:
    • • Eine vom Nachrichtendienst bereitgestellte Weg-ID.
    • • Inhalt.
    • • Eine optionale Token-ID (wird für die Abschlussbenachrichtigung verwendet).
    • • Ein optionaler Prolog oder Epilog.
  • Die Weg-ID definiert einen logischen Weg, dem die Nachricht folgen sollte, und codiert implizit den gesamten Fluss, wodurch ermöglicht wird, dass Nachrichten gesendet werden, ohne auf den Abschluss der Verarbeitung früherer Nachrichten zu warten. Der Nachrichtendienst kann einen Status mit einer Token-ID liefern, wenn dies von der Anwendung angefordert wird, um den Abschluss von Anforderungen zu verfolgen.
  • Prologe und Epiloge können verwendet werden, um polymorphe und pipelineartige Nachrichtenflüsse zu unterstützen. Prologe passen die Verarbeitung einer Nachricht an ein Ziel an, so dass die Anpassung näher an den Ort der Datenbehandlung verschoben wird, und Epiloge spezifizieren Fortsetzungen und Weiterleitungen von Daten, Ergebnissen, Ereignissen oder Status. Dies muss nicht unbedingt nur für den Aufrufer sein, sondern möglicherweise auch für andere Entitäten. Dies erweitert das Konzept aktiver Nachrichten auf aktive Flüsse.
  • 10 ist ein Blockdiagramm, das eine Nachrichtenweiterleitung gemäß einem oder mehreren Beispielen der vorliegenden Offenbarung veranschaulicht. In diesem Fall empfängt ein Nachrichtenweiterleitungsblock Eingaben und Ausgaben wie dargestellt.
  • Intern kann ein Nachrichtenweiterleiter als eine Umleitungstabelle implementiert sein, die die folgenden Arten von Dienstinstanz-Eintrittspunkten enthält, aber nicht darauf beschränkt ist:
    • • Zu einer Netzkarte oder eine entfernte Adresse wie etwa eine Fern-URI.
    • • Zu einer PCIe-BDF.
    • • Zu Software über Ausnahme- oder Abfragemodus.
    • • Über eine Fabric.
    • • Zu einem Speicher oder einer speicherabgebildeten I/O (MMIO).
  • Im Fall von zwei kommunizierenden Anwendungen sendet die Anwendung A eine Nachricht an eine Nachrichtenweiterleitungs-Funktion (MF-Funktion) 1000, anstelle dass die Anwendung A Daten an einen Dienst B sendet, der sowohl Softwareals auch Hardwareimplementierungen aufweisen kann,.
  • Eingaben in die MF-Funktion 1000 können Weginformationen oder einen Weginformations-Handle sowie die zu weiterzuleitenden Nutzdaten enthalten.
  • Die MF-Funktion 1000 kann die Nachricht nach Bedarf umwandeln, um sie für die nächste Etappe geeignet zu machen. Dies kann eine Einkapselung, Entkapselung oder anderweitige Umwandlung der Nachricht umfassen. Der Nachrichtenweiterleiter 1000 sendet dann die umgewandelte Nachricht zusammen mit neuen Weginformationen oder einem Weginformations-Handle.
  • In verschiedenen Ausführungsformen kann die Nachrichtenweiterleitungsfunktion 1000 eine direkte oder indirekte Rolle beim Übertragen der Nachricht übernehmen. Bei der direkten Verwendung empfängt die MF 1000 eine Nachricht von der Anwendung und leitet sie an eine entsprechende Dienstinstanz weiter. Im indirekten Fall ist die MF 1000 eine Konfiguration und Anforderungen bezüglich Dienst-Endpunkten werden direkt an die angegebene Instanz gesendet, vorausgesetzt, die Instanz unterstützt den direkten Aufruf.
  • Die MF 1000 kann eine Aktivierung und Adress-/Zugriffsvermittlung bereitstellen. Mit anderen Worten kann die MF 1000 kann als Informationsaktivierungsvermittler fungieren. Zum Beispiel kann die MF 1000 ein Token an die Ziel-Dienstfunktion senden oder weiterleiten. Das Ziel kann dieses Token verwenden, um Daten von der MF 1000 abzurufen. Die Dienstfunktion kann dieses Token verwenden, um die MF 1000 abzufragen und zu erfahren, ob die Quellanwendung bereit zur Auslieferung ist oder nicht. Dies unterscheidet sich beispielsweise davon, dass die Ziel-Dienstinstanz Daten von der Anwendung empfängt und dann die MF 1000 kontaktiert. Mit anderen Worten können Ziele zu aktiven Objekten werden, die etwas tun, und höherer Code kann als ein Zusammensteller dieser Aktionen niedrigerer Ebene fungieren, sie einleiten und dann Platz machen.
  • Eine Weiterleitungsvorrichtung, die die MF 1000 implementiert, kann eine Adressierung implementieren, die nicht auf Knoten und Ports abgebildet werden muss. Adressen können stattdessen auf benennbare Einträge und Entitätsfunktionen abgebildet werden. Eine Entität kann Hardware, Software, Firmware oder eine beliebige Kombination davon sein, die einen Empfänger aufweist, den eine Fabric-Schnittstelle auslösen kann. Das Ergebnis an dem empfangenden Endpunkt ähnelt dem Aufruf einer Funktion:
    • • Wenn die ausgelöste Entität Software ist, ist der Funktionsaufruf ein Lambda oder ein RPC.
    • • Wenn die ausgelöste Entität eine Smartdisk ist, kann der Funktionsaufruf eine Plattenoperation sein.
    • • Wenn die ausgelöste Entität ein Hardwarebeschleuniger ist, kann der Funktionsaufruf eine NQ-Operation sein.
    • • Wenn das Ziel eine FPGA ist, kann ein intransparenter Handshake vorhanden sein, der die FPGA orchestriert und mit dieser verknüpft.
  • Das Vorangehende ist als nicht einschränkendes Beispiel gegeben und viele andere Konfigurationen sind möglich. Das Endergebnis ist, dass Aktivitäten entkoppelt werden und in Pipelines ausgeführt werden.
  • Im Fall der Fluss- und Ausführungsverwaltung kann der Inhalt einer Nachricht sowohl Zwischendaten zur Verarbeitung als auch einen Verweis auf die Daten enthalten. Zum Beispiel kann die Anwendung A eine verschlüsselte Nachricht an den Mikrodienst F senden und ein Token T an die Anwendung C, die ein Gegenstück zu A ist, senden. Wenn C F mit dem Token T kontaktiert, entschlüsselt C automatisch und gibt C ein weiteres Token M. Wenn C sich dafür entscheidet, öffnet es den Strom M und liest die klaren Daten. Zyklisches Abfragen ist ein effizientes Mittel zur Kommunikation zwischen entfernten Entitäten und erfordert keine Warnungen oder Anforderungen zur Kontrolle. Stattdessen kann die entfernte Entität Tokens durch zyklisches Abfragen abrufen. Andere Optionen umfassen Netzkarten, in/aus Warteschlangen Einfügen/Entfernen von Datenströmen oder dergleichen.
  • Die Nachrichtenweiterleitung schiebt die Nachricht in vorab zugeteilte Puffer für einen spezifischen Strom oder spezifische Flüsse. Ein kopieloser Ansatz kann auch verwendet werden, wenn vorab zugeteilte Puffer gemeinsam mit der Anwendung verwendet werden. Die MF ruft dann eine Ausführung von Hardware- oder Softwareimplementierungen auf. Puffer- und Burst-Verarbeitung kann auch dazu ausgelegt sein, den Mehraufwand zu minimieren und die Auslastung der Betriebsmittel zu verbessern, während gleichzeitig die Dienstgüte (QoS) oder die Fristen eingehalten werden, wenn sie von der Anwendung angefordert werden. In einem Beispiel können Ringpuffer als eine Implementierung von Verbindungen zwischen einer Anwendung, einem Nachrichtenweiterleiter und Dienstimplementierungen verwendet werden.
  • Polymorphes Verhalten wird ebenfalls geboten. Dadurch wird das Konzept der aktiven Nachrichtenübermittlung in einer polymorphen Weise beigemischt, bei der der aktive Teil der aktiven Nachrichtenübermittlung behandelt wird. Dies führt zu einer Verwischung der Grenze zwischen Hardware, Software oder Beschleuniger, zwischen lokal oder fern, zwischen mit zyklischem Abrufen oder ohne zyklisches Abrufen, so dass der Rahmen die Vorstellung unterstützt, dass Intelligenz auf hohen Ebenen verteilt und koordiniert werden kann, während die Daten- und Ereignisverarbeitung auf niedrigen Ebenen stattfindet.
  • Die Nachrichtendienstverkettung kann auch ein Verfahren zur Interprozesskommunikation (IPC) sein. Dies sorgt für zusätzliche Flexibilität und sinkende Integrationskosten und kann Funktionen als Dienst (FaaS) oder Mikrodienste mit Verbindungen zu einer Vielzahl von IPC-APIs und verschiedenen Sprachen verwenden.
  • 11 ist ein Blockdiagramm einer Lastausgleichs-Engine (LBE 1100) gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In verschiedenen Ausführungsformen kann die Nachrichtenweiterleitung mehrere Lastenausgleichsoptionen unterstützen. In diesem Beispiel empfängt die LBE 1100 Weginformationen oder ein Weginformations-Handle für eine eingehende Nachricht sowie Telemetrie von verschiedenen Instanzen der Ziel-Dienstfunktion und Dienstgüteziele. Dies liefert der LBE 1100 Informationen, um zu entscheiden, an welche Instanz eines Mikrodienstes die Anforderung weitergeleitet werden soll oder ob eine neue Instanz eines Mikrodiensts erzeugt werden soll. Die LBE 1100 leitet das eingehende Paket über neue Weginformationen oder ein Weginformations-Handle an eine Instanz und kann auch Protokolle speichern, beispielsweise zur Hintergrundanalyse oder Neuanpassung.
  • Lastausgleichs-Optionen umfassen als nicht einschränkendes Beispiel:
    • • Schlichtung bezüglich einer freien Instanz basierend auf dem Busstatus.
    • • Round-Robin-Lastausgleich.
    • • Gewichtete faire Warteschlange.
    • • Lastausgleich durch Brisanz-Routing oder auf Fristbasis (einschließlich fristgerechtem Maximum-Ausgleich). Eine Weiterleitungstabelle an dem Eingang kann alternative Ziele auswählen, wenn die aktuelle Instanz überlastet ist.
    • • Priorisierung (z. B. Hardwareinstanzen bevorzugen, mit Überlauf zu Softwareinstanzen).
  • Das Vorstehende umreißt Merkmale verschiedener Ausführungsformen, so dass Fachleute verschiedene Aspekte der vorliegenden Offenbarung besser verstehen können. Fachleute sollten erkennen, dass sie die vorliegende Offenbarung ohne weiteres als Grundlage zum Entwerfen oder Abwandeln anderer Prozesse und Strukturen zum Ausführen der gleichen Aufgaben und/oder zum Erreichen der gleichen Vorteile wie die hier vorgestellten Ausführungsformen verwenden kann. Fachleute sollten auch erkennen, dass solche äquivalenten Konstruktionen nicht vom Gedanken und Umfang der vorliegenden Offenbarung abweichen, und dass sie hier verschiedene Änderungen, Ersetzungen und Abwandlungen vornehmen können, ohne vom Gedanken und Umfang der vorliegenden Offenbarung abzuweichen.
  • Die Gesamtheit oder ein Teil eines hierin offenbarten Hardwareelements kann ohne weiteres in einem Ein-Chip-System (SoC) bereitgestellt werden, das eine Baugruppe der zentralen Verarbeitungseinheit (CPU-Baugruppe) enthält. Ein SoC stellt eine integrierte Schaltung (IC) dar, die Komponenten eines Computers oder eines anderen elektronischen Systems in einen einzelnen Chip integriert. So können beispielsweise Clientvorrichtungen oder Servervorrichtungen ganz oder teilweise in einem SoC bereitgestellt werden. Das SoC kann Digital-, Analog-, Mischsignal- und Hochfrequenz-Funktionen enthalten, die alle auf einem einzelnen Chipsubstrat bereitgestellt werden können. Andere Ausführungsformen können ein Mehrchip-Modul (MCM) mit einer mehreren Chips umfassen, die in einer einzelnen elektronischen Baugruppe angeordnet und so ausgelegt sind, dass sie über die elektronische Baugruppe stark miteinander interagieren.
  • Es ist auch zu beachten, dass in bestimmten Ausführungsformen einige der Komponenten weggelassen oder konsolidiert werden können. Im Allgemeinen können die in den Figuren dargestellten Anordnungen in ihren Darstellungen logischer sein, wobei eine physische Architektur verschiedene Permutationen, Kombinationen und/oder Mischformen dieser Elemente beinhalten kann. Es ist unbedingt zu beachten, dass unzählige mögliche Designkonfigurationen verwendet werden können, um die hierin beschriebenen Betriebsziele zu erzielen. Dementsprechend weist die zugehörige Infrastruktur eine Vielzahl von Ersatzanordnungen, Designauswahlmöglichkeiten, Vorrichtungsmöglichkeiten, Hardwarekonfigurationen, Softwareimplementierungen, Ausrüstungsoptionen usw. auf.
  • In einem allgemeinen Sinn kann jeder geeignet konfigurierte Prozessor irgendeinen Typ von Befehlen, der den Daten zugeordnet ist, ausführen, um die hierin beschriebenen Operationen zu erreichen. Jeder hier offenbarte Prozessor könnte ein Element oder einen Artikel (z. B. Daten) von einem Zustand oder Objekt in einen anderen Zustand oder ein anderes Objekt umwandeln. Im Betrieb kann ein Speicher Informationen in jeder geeigneten Art von konkretem, nicht transitorischem Speichermedium (z. B. Direktzugriffsspeicher (RAM), Nur-Lese-Speicher (ROM), feldprogrammierbare Gatteranordnung (FPGA), löschbarem programmierbaren Nur-Lese-Speicher (EPROM), elektrisch löschbarem programmierbarem ROM (EEPROM) usw.), Software, Hardware (z. B. Prozessorbefehle oder Mikrocode) oder in irgendeiner anderen geeigneten Komponente, Vorrichtung, geeigneten Element oder Objekt speichern, basierend auf Eignung und bestimmten Bedürfnissen. Darüber hinaus können die Informationen, die in einem Prozessor verfolgt, gesendet, empfangen oder gespeichert werden, in irgendeiner Datenbank, einem Register, einer Tabelle, einem Cache, einer Warteschlange, einer Steuerliste oder einer Speicherstruktur basierend auf bestimmten Bedürfnissen und Implementierungen bereitgestellt werden, auf die alle in einem geeigneten Zeitrahmen verwiesen werden kann. Jegliche hier offenbarten Speicher- oder Datenspeicherelemente sollten so ausgelegt werden, dass sie in geeigneter Weise in den allgemeinen Begriffen „Speicher“ und „Datenspeicher“ eingeschlossen sind. Ein nicht-transitorisches Speichermedium soll hierin ausdrücklich jede nicht-transitorische spezialisierte oder Hardware einschließen, die dazu ausgelegt ist, die offenbarten Operationen bereitzustellen oder einen Prozessor zu veranlassen, die offenbarten Operationen durchzuführen.
  • Computerprogrammlogik, die die Gesamtheit oder einen Teil der hierin beschriebenen Funktionalität implementiert, ist in verschiedenen Formen verkörpert, einschließlich, aber nicht beschränkt auf, einer Quellcodeform, einer computerausführbaren Form, Maschinenbefehle oder Mikrocode, programmierbarer Hardware und verschiedener Zwischenformen (z. B. Formen, die von einem Assembler, Compiler, Linker oder Locator generiert werden). In einem Beispiel umfasst der Quellcode eine Reihe von Computerprogrammbefehlen, die in verschiedenen Programmiersprachen wie beispielsweise einem Objektcode, einer Assemblersprache oder einer Hochsprache wie OpenCL, FORTRAN, C, C++, JAVA oder HTML zur Verwendung mit verschiedenen Betriebssystemen oder Betriebsumgebungen oder in Hardwarebeschreibungssprachen wie Spice, Verilog und VHDL implementiert sind. Der Quellcode kann verschiedene Datenstrukturen und Kommunikationsnachrichten definieren und verwenden. Der Quellcode kann in einer computerausführbaren Form (z. B. über einen Interpreter) vorliegen oder der Quellcode kann (z. B. über einen Übersetzer, Assembler oder Compiler) in eine computerausführbare Form umgewandelt werden oder in eine Zwischenform wie etwa einen Bytecode umgewandelt werden. Gegebenenfalls kann irgendetwas aus dem Vorstehenden dazu verwendet werden, geeignete diskrete oder integrierte Schaltungen zu bauen oder zu beschreiben, egal ob nun sequentiell, kombinatorisch, per Zustandsmaschine oder anderweitig.
  • In einer beispielhaften Ausführungsform kann eine beliebige Anzahl von elektrischen Schaltungen aus den Figuren auf einer Platine einer zugeordneten elektronischen Vorrichtung implementiert sein. Die Platine kann eine allgemeine Platine sein, die verschiedene Komponenten des internen elektronischen Systems der elektronischen Vorrichtung aufnehmen kann und ferner Anschlüsse für andere Peripherievorrichtungen bereitstellen kann. Ein beliebiger geeigneter Prozessor und Speicher können basierend auf bestimmten Konfigurationsanforderungen, Verarbeitungsanforderungen und Computerentwürfen in geeigneter Weise mit der Platine gekoppelt sein. Es ist zu beachten, dass bei den zahlreichen hierin bereitgestellten Beispielen eine Wechselwirkung in Bezug auf zwei, drei, vier oder mehr elektrische Komponenten beschrieben werden kann. Dies wird jedoch nur zu Zwecken der Klarheit und Veranschaulichung gemacht. Es sollte erkannt werden, dass das System auf beliebige geeignete Weise zusammengefasst oder neu konfiguriert werden kann. Entlang ähnlicher Designalternativen können beliebige der dargestellten Komponenten, Module und Elemente der Figuren in verschiedenen möglichen Konfigurationen kombiniert werden, die alle innerhalb des weiten Umfangs dieser Offenbarung liegen.
  • Zahlreiche andere Veränderungen, Ersetzungen, Variationen, Abänderungen und Abwandlungen können für Fachleute ersichtlich sein und es ist beabsichtigt, dass die vorliegende Offenbarung alle derartigen Veränderungen, Ersetzungen, Variationen, Abänderungen und Abwandlungen als in den Umfang der beigefügten Ansprüche fallend einschließt. Um das United States Patent and Trademark Office (USPTO) und zusätzlich jegliche Leser jedes zu dieser Anmeldung ausgestellten Patents bei der Auslegung der beigefügten Ansprüche zu unterstützen, merkt der Anmelder an, dass der Anmelder: (a) nicht beabsichtigt, dass sich irgendeiner der beigefügten Ansprüche auf Absatz sechs (6) aus 35 U.S.C. Abschnitt 112 (vor AIA) oder Absatz (f) desselben Abschnitts (nach AIA) beruft, wie er am Datum der Einreichung gültig ist, außer die Worte „Mittel für“ oder „Schritt für“ werden spezifisch in den jeweiligen Ansprüchen verwenden; und (b) nicht beabsichtigt, durch jegliche Aussage in der Patentschrift die Offenbarung in jeglicher Art einzuschränken, die nicht anderweitig ausdrücklich in den beigefügten Ansprüchen wiedergegeben ist.
  • Beispielhafte Implementierungen
  • Die folgenden Beispiele werden zur Veranschaulichung bereitgestellt.
  • Beispiel 1 umfasst eine Rechenvorrichtung, die enthält: eine Hardware-Rechenplattform; und Logik zum Arbeiten auf der Hardware-Rechenplattform, die zu Folgendem ausgelegt ist: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen soll, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.
  • Beispiel 2 umfasst die Rechenvorrichtung von Beispiel 1, wobei die Logik ferner dazu ausgelegt ist, die Mikrodienst-Registrierung an einen Mikrodienste-Treiber herauszugeben.
  • Beispiel 3 umfasst die Rechenvorrichtung von Beispiel 1, wobei die Mikrodienst-Registrierungsdatenbank eine ontologische Datenbank ist.
  • Beispiel 4 umfasst die Rechenvorrichtung von Beispiel 1, wobei die Verbindungsfähigkeit Informationen umfasst, die dazu ausgelegt sind, den Mikrodienst-Beschleuniger einer Dienstkette zuzuteilen. Dies kann ein Aufrufen eines Satzes von Mikrodiensten in einer Sequenz umfassen, um eine angeforderte Funktion auszuführen.
  • Beispiel 5 umfasst die Rechenvorrichtung von Beispiel 1, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Abbilden eines Mikrodienste-Anwendungsprogrammierschnittstellen-Aufrufs (Mikrodienste-API-Aufrufs) auf einen nativen Aufruf für den Mikrodienst-Beschleuniger enthält, wobei die Mikrodienste-API eine universelle API für Vorrichtungen, die auf den Mikrodienst-Beschleuniger zugreifen, ist. Der native Aufruf kann basierend auf der Implementierung und dem Ort des Mikrodienstes und des Anforderers des Dienstes optimal effizient sein.
  • Beispiel 6 umfasst die Rechenvorrichtung nach einem der Beispiele 1-5, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers enthält.
  • Beispiel 7 umfasst die Rechenvorrichtung von Beispiel 6, wobei die Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers Informationen zum Programmieren der neuen Instanz umfassen.
  • Beispiel 8 umfasst die Rechenvorrichtung von Beispiel 7, wobei die Informationen zum Programmieren der neuen Instanz eine Gatterkonfiguration für eine feldprogrammierbare Gatteranordnung (FPGA) umfassen. Andere Ausführungsformen können andere Firmware enthalten, die auf einen Hardwarebeschleuniger (wie eine GPU) geladen wird, um sie auf eine spezifische Funktion zu programmieren.
  • Beispiel 9 umfasst die Rechenvorrichtung nach einem der Beispiele 1-5, wobei die Logik ferner dazu ausgelegt ist, Informationen über die Belastung auf vorhandenen Instanzen des Mikrodienst-Beschleunigers zu empfangen und zu speichern. Vorhandene Instanzen des Mikrodienst-Beschleunigers können so programmiert werden, dass sie auch einem neuen Anforderer dienen, wodurch der Betriebsmittelaufwand für das Erzeugen einer neuen Instanz reduziert wird.
  • Beispiel 10 umfasst ein oder mehrere konkrete, nichttransitorische computerlesbare Medien, auf denen ausführbare Befehle zum Bereitstellen einer Mikrodienst-Erkennungsfunktion (MDF) gespeichert sind, die dazu ausgelegt sind, eine Vorrichtung zu Folgendem zu veranlassen: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen kann, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.
  • Beispiel 11 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von Beispiel 10, wobei die Logik ferner dazu ausgelegt ist, die Mikrodienst-Registrierung an einen Mikrodienste-Treiber herauszugeben.
  • Beispiel 12 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von Beispiel 10, wobei die Mikrodienst-Registrierungsdatenbank eine ontologische Datenbank ist.
  • Beispiel 13 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von Beispiel 10, wobei die Verbindungsfähigkeit Informationen umfasst, die dazu ausgelegt sind, den Mikrodienst-Beschleuniger einer Dienstkette zuzuteilen.
  • Beispiel 14 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von Beispiel 10, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Abbilden eines Mikrodienste-Anwendungsprogrammierschnittstellen-Aufrufs (Mikrodienste-API-Aufrufs) auf einen nativen Aufruf für den Mikrodienst-Beschleuniger enthält, wobei die Mikrodienste-API eine universelle API für Vorrichtungen, die auf den Mikrodienst-Beschleuniger zugreifen, ist.
  • Beispiel 15 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von einem der Beispiele 10 bis 14, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers enthält.
  • Beispiel 16 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von Beispiel 15, wobei die Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers Informationen zum Programmieren der neuen Instanz umfassen.
  • Beispiel 17 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von Beispiel 16, wobei die Informationen zum Programmieren der neuen Instanz eine Gatterkonfiguration für eine feldprogrammierbare Gatteranordnung (FPGA) umfassen.
  • Beispiel 18 umfasst das eine oder die mehreren konkreten, nichttransitorischen computerlesbaren Medien von einem der Beispiele 10-14, wobei die Logik ferner dazu ausgelegt ist, Informationen über die Belastung auf vorhandenen Instanzen des Mikrodienst-Beschleunigers zu empfangen und zu speichern.
  • Beispiel 19 umfasst ein computerimplementiertes Verfahren zum Bereitstellen einer Mikrodienst-Erkennungsfunktion (MDF), das umfasst: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen soll, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.
  • Beispiel 20 umfasst das Verfahren von Beispiel 19, das ferner ein Herausgeben der Mikrodienst-Registrierung an einen Mikrodienste-Treiber umfasst.
  • Beispiel 21 umfasst das Verfahren von Beispiel 19, wobei die Mikrodienst-Registrierungsdatenbank eine ontologische Datenbank ist.
  • Beispiel 22 umfasst ein Verfahren von Beispiel 19, wobei die Verbindungsfähigkeit Informationen umfasst, die dazu ausgelegt sind, den Mikrodienst-Beschleuniger einer Dienstkette zuzuteilen.
  • Beispiel 23 umfasst das Verfahren von Beispiel 19, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Abbilden eines Mikrodienste-Anwendungsprogrammierschnittstellen-Aufrufs (Mikrodienste-API-Aufrufs) auf einen nativen Aufruf für den Mikrodienst-Beschleuniger enthält, wobei die Mikrodienste-API eine universelle API für Vorrichtungen, die auf den Mikrodienst-Beschleuniger zugreifen, ist.
  • Beispiel 24 umfasst das Verfahren von einem der Beispiele 19-23, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers enthält.
  • Beispiel 25 umfasst das Verfahren von Beispiel 24, wobei die Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers Informationen zum Programmieren der neuen Instanz umfassen.
  • Beispiel 26 umfasst das Verfahren von Beispiel 25, wobei die Informationen zum Programmieren der neuen Instanz eine Gatterkonfiguration für eine feldprogrammierbare Gatteranordnung (FPGA) umfassen.
  • Beispiel 27 umfasst das Verfahren nach einem der Beispiele 19-23, wobei die Logik ferner dazu ausgelegt ist, Informationen über die Belastung auf vorhandenen Instanzen des Mikrodienst-Beschleunigers zu empfangen und zu speichern.
  • Beispiel 28 umfasst eine Vorrichtung, die Mittel zum Durchführen des Verfahrens nach einem der Beispiele 19 bis 27 enthält.
  • Beispiel 29 umfasst die Vorrichtung von Beispiel 28, wobei die Mittel zum Durchführen des Verfahrens einen Prozessor und einen Speicher umfassen.
  • Beispiel 30 umfasst die Vorrichtung von Beispiel 29, wobei der Speicher maschinenlesbare Befehle umfasst, die, wenn sie ausgeführt werden, veranlassen, dass die Vorrichtung das Verfahren nach einem der Ansprüche 19-27 durchführt.
  • Beispiel 31 umfasst die Vorrichtung nach einem der Beispiele 28 bis 30, wobei die Vorrichtung ein Rechensystem ist.
  • Beispiel 32 umfasst mindestens ein konkretes nichttransitorisches computerlesbares Medium, das Befehle enthält, die, wenn sie ausgeführt werden, ein Verfahren implementieren oder eine Vorrichtung realisieren, wie sie in einem der Beispiele 19-31 beansprucht sind.
  • Beispiel 33 umfasst eine Rechenvorrichtung, die umfasst: eine Hardware-Rechenplattform; und Logik, die auf der Hardware-Rechenplattform für Folgendes implementiert ist: Empfangen eines Anwendungsprogrammierschnittstellen-Aufrufs (API-Aufrufs) an einen Mikrodienst; Erkennen eines verfügbaren Mikrodienst-Beschleunigers, der dazu ausgelegt ist, den Mikrodienst bereitzustellen; Übersetzen des API-Aufrufs in einen nativen Aufruf für den Mikrodienst-Beschleuniger; und Weiterleiten des nativen Aufrufs an den Mikrodienst Beschleuniger.
  • Beispiel 34 umfasst die Rechenvorrichtung von Beispiel 33, wobei das Erkennen des verfügbaren Mikrodienst-Beschleunigers ein Abfragen einer Mikrodienst-Erkennungsfunktion (MDF) umfasst.
  • Beispiel 35 umfasst die Rechenvorrichtung von Beispiel 34, wobei die Logik dazu ausgelegt ist, von der MDF eine Liste verfügbarer Mikrodienst-Beschleuniger zu empfangen, die dazu ausgelegt sind, den Mikrodienst bereitzustellen.
  • Beispiel 36 umfasst die Rechenvorrichtung von Beispiel 35, wobei die Logik dazu ausgelegt ist, zu bestimmen, dass keine Instanz eines Mikrodienst-Beschleunigers mit akzeptabler freier Bandbreite für den Mikrodienst verfügbar ist, und eine neue Instanz des Mikrodienst-Beschleunigers zu erzeugen.
  • Beispiel 37 umfasst die Rechenvorrichtung von Beispiel 36, wobei das Erzeugen der neuen Instanz ein Programmieren einer neuen Instanz des Mikrodienst-Beschleunigers umfasst.
  • Beispiel 38 umfasst die Rechenvorrichtung von Beispiel 36, wobei das Erzeugen der neuen Instanz ein Programmieren einer feldprogrammierbaren Gatteranordnung (FPGA) umfasst, um die neue Instanz bereitzustellen.
  • Beispiel 39 umfasst die Rechenvorrichtung nach einem der Beispiele 33 bis 38, wobei die Logik dazu ausgelegt ist, den Mikrodienst-Beschleuniger innerhalb einer Mikrodienst-Kette bereitzustellen.
  • Beispiel 40 umfasst die Rechenvorrichtung von Beispiel 39, wobei der API-Aufruf an den Mikrodienst von einer Hostvorrichtung stammt, und wobei die Mikrodienst-Kette dazu ausgelegt ist, unabhängig von der Hostvorrichtung zu arbeiten.
  • Beispiel 41 umfasst die Rechenvorrichtung von Beispiel 40, wobei die Logik dazu ausgelegt ist, einen Nachrichtenweiterleiter für die Mikrodienst-Kette in einer Hub-Konfiguration bereitzustellen.
  • Beispiel 42 umfasst die Rechenvorrichtung von Beispiel 40, wobei die Logik dazu ausgelegt ist, Mikrodienste in der Mikrodienst-Kette in Reihe zu verketten.
  • Beispiel 43 umfasst ein oder mehrere konkrete nichttransitorische computerlesbare Medien, auf denen Befehle zum Bereitstellen eines Mikrodienste-Treibers gespeichert sind, die zu Folgendem ausgelegt sind: Empfangen eines Anwendungsprogrammierschnittstellen-Aufrufs (API-Aufrufs) an einen Mikrodienst; Erkennen eines verfügbaren Mikrodienst-Beschleunigers, der dazu ausgelegt ist, den Mikrodienst bereitzustellen; Übersetzen des API-Aufrufs in einen nativen Aufruf für den Mikrodienst-Beschleuniger; und Weiterleiten des nativen Aufrufs an den Mikrodienst Beschleuniger.
  • Beispiel 44 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 43, wobei das Erkennen des verfügbaren Mikrodienst-Beschleunigers ein Abfragen einer Mikrodienst-Erkennungsfunktion (MDF) umfasst.
  • Beispiel 45 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 44, wobei die Logik dazu ausgelegt ist, von der MDF eine Liste verfügbarer Mikrodienst-Beschleuniger zu empfangen, die dazu ausgelegt sind, den Mikrodienst bereitzustellen.
  • Beispiel 46 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 45, wobei die Logik dazu ausgelegt ist, zu bestimmen, dass keine Instanz eines Mikrodienst-Beschleunigers mit akzeptabler freier Bandbreite für den Mikrodienst verfügbar ist, und eine neue Instanz des Mikrodienst-Beschleunigers zu erzeugen.
  • Beispiel 47 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 46, wobei das Erzeugen der neuen Instanz ein Programmieren einer neuen Instanz des Mikrodienst-Beschleunigers umfasst.
  • Beispiel 48 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 46, wobei das Erzeugen der neuen Instanz ein Programmieren einer feldprogrammierbaren Gatteranordnung (FPGA) umfasst, um die neue Instanz bereitzustellen.
  • Beispiel 49 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von einem der Beispiele 43 bis 48, wobei die Logik dazu ausgelegt ist, den Mikrodienst-Beschleuniger innerhalb einer Mikrodienst-Kette bereitzustellen.
  • Beispiel 50 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 49, wobei der API-Aufruf an den Mikrodienst von einer Hostvorrichtung stammt, und wobei die Mikrodienst-Kette dazu ausgelegt ist, unabhängig von der Hostvorrichtung zu arbeiten.
  • Beispiel 51 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 50, wobei die Logik dazu ausgelegt ist, einen Nachrichtenweiterleiter für die Mikrodienst-Kette in einer Hub-Konfiguration bereitzustellen.
  • Beispiel 52 umfasst das eine oder die mehreren konkreten nichttransitorischen computerlesbaren Medien von Beispiel 50, wobei die Logik dazu ausgelegt ist, Mikrodienste in der Mikrodienst-Kette in Reihe zu verketten.
  • Beispiel 53 umfasst ein computerimplementiertes Verfahren zum Bereitstellen eines Mikrodienste-Treibers, das umfasst: Empfangen eines Anwendungsprogrammierschnittstellen-Aufrufs (API-Aufrufs) an einen Mikrodienst; Erkennen eines verfügbaren Mikrodienst-Beschleunigers, der dazu ausgelegt ist, den Mikrodienst bereitzustellen; Übersetzen des API-Aufrufs in einen nativen Aufruf für den Mikrodienst-Beschleuniger; und Weiterleiten des nativen Aufrufs an den Mikrodienst Beschleuniger.
  • Beispiel 54 umfasst das Verfahren von Beispiel 53, wobei das Erkennen des verfügbaren Mikrodienst-Beschleunigers ein Abfragen einer Mikrodienst-Erkennungsfunktion (MDF) umfasst.
  • Beispiel 55 umfasst das Verfahren von Beispiel 54, das ferner umfasst: Empfangen einer Liste verfügbarer Mikrodienst-Beschleuniger, die dazu ausgelegt sind, den Mikrodienst bereitzustellen, von der MDF.
  • Beispiel 56 umfasst das Verfahren von Beispiel 55, das ferner umfasst: Bestimmen, dass keine Instanz eines Mikroservice-Beschleunigers mit akzeptabler freier Bandbreite für den Mikrodienst verfügbar ist, und Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers.
  • Beispiel 57 umfasst das Verfahren von Beispiel 56, wobei das Erzeugen der neuen Instanz ein Programmieren einer neuen Instanz des Mikroservice-Beschleunigers umfasst.
  • Beispiel 58 umfasst das Verfahren von Beispiel 56, wobei das Erzeugen der neuen Instanz ein Programmieren einer feldprogrammierbaren Gatteranordnung (FPGA) umfasst, um die neue Instanz bereitzustellen.
  • Beispiel 59 umfasst das Verfahren von einem der Beispiele 53 bis 58, das ferner ein Bereitstellen des Mikrodienst-Beschleunigers in einer Mikrodienst-Kette umfasst.
  • Beispiel 60 umfasst das Verfahren von Beispiel 59, wobei der API-Aufruf an den Mikrodienst von einer Hostvorrichtung stammt und wobei die Mikrodienst-Kette dazu ausgelegt ist, unabhängig von der Hostvorrichtung zu arbeiten.
  • Beispiel 61 umfasst das Verfahren von Beispiel 60, das ferner ein Bereitstellen eines Nachrichtenweiterleiters für die Mikrodienst-Kette in einer Hub-Konfiguration umfasst.
  • Beispiel 62 umfasst das Verfahren von Beispiel 60, das ferner Verketten von Mikrodiensten in Reihe in der Mikrodienst-Kette umfasst.

Claims (25)

  1. Rechenvorrichtung, die Folgendes umfasst: eine Hardware-Rechenplattform; und Logik zum Arbeiten auf der Hardware-Rechenplattform, die zu Folgendem ausgelegt ist: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen soll, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.
  2. Rechenvorrichtung nach Anspruch 1, wobei die Logik ferner dazu ausgelegt ist, die Mikrodienst-Registrierung an einen Mikrodienste-Treiber herauszugeben.
  3. Rechenvorrichtung nach Anspruch 1, wobei die Mikrodienst-Registrierungsdatenbank eine ontologische Datenbank ist.
  4. Rechenvorrichtung nach Anspruch 1, wobei die Verbindungsfähigkeit Informationen umfasst, die dazu ausgelegt sind, den Mikrodienst-Beschleuniger einer Dienstkette zuzuteilen.
  5. Rechenvorrichtung nach Anspruch 1, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Abbilden eines Mikrodienste-Anwendungsprogrammierschnittstellen-Aufrufs (Mikrodienste-API-Aufrufs) auf einen nativen Abruf für den Mikrodienst-Beschleuniger zu enthalten, wobei die Mikrodienste-API eine universelle API für Vorrichtungen, die auf den Mikrodienst-Beschleuniger zugreifen, ist.
  6. Rechenvorrichtung nach einem der Ansprüche 1-5, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers enthält.
  7. Rechenvorrichtung nach Anspruch 6, wobei die Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers Informationen zum Programmieren der neuen Instanz umfassen.
  8. Rechenvorrichtung nach Anspruch 7, wobei die Informationen zum Programmieren der neuen Instanz eine Gatterkonfiguration für eine feldprogrammierbare Gatteranordnung (FPGA) umfassen.
  9. Rechenvorrichtung nach einem der Ansprüche 1-5, wobei die Logik ferner dazu ausgelegt ist, Informationen über die Belastung auf vorhandenen Instanzen des Mikrodienst-Beschleunigers zu empfangen und zu speichern.
  10. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien, auf denen ausführbare Befehle zum Bereitstellen einer Mikrodienst-Erkennungsfunktion (MDF) gespeichert sind, die dazu ausgelegt sind, eine Einrichtung zu Folgendem zu veranlassen: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen soll, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.
  11. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach Anspruch 10, wobei die Logik ferner dazu ausgelegt ist, die Mikrodienst-Registrierung an einen Mikrodienste-Treiber herauszugeben.
  12. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach Anspruch 10, wobei die Mikrodienst-Registrierungsdatenbank eine ontologische Datenbank ist.
  13. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach Anspruch 10, wobei die Verbindungsfähigkeit Informationen umfasst, die dazu ausgelegt sind, den Mikrodienst-Beschleuniger einer Dienstkette zuzuteilen.
  14. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach Anspruch 10, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Abbilden eines Mikrodienste-Anwendungsprogrammierschnittstellen-Aufrufs (Mikrodienste-API-Aufrufs) auf einen nativen Abruf für den Mikrodienst-Beschleuniger enthält, wobei die Mikrodienste-API eine universelle API für Vorrichtungen, die auf den Mikrodienst-Beschleuniger zugreifen, ist.
  15. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach einem der Ansprüche 10-14, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers enthält.
  16. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach Anspruch 15, wobei die Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers Informationen zum Programmieren der neuen Instanz umfassen.
  17. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach Anspruch 16, wobei die Informationen zum Programmieren der neuen Instanz eine Gatterkonfiguration für eine feldprogrammierbare Gatteranordnung (FPGA) umfassen.
  18. Konkretes nichttransitorisches computerlesbares Medium oder mehrere konkrete nichttransitorische computerlesbare Medien nach einem der Ansprüche 10-14, wobei die Logik ferner dazu ausgelegt ist, Informationen über die Belastung auf vorhandenen Instanzen des Mikrodienst-Beschleunigers zu empfangen und zu speichern.
  19. Computerimplementiertes Verfahren zum Bereitstellen einer Mikrodienst-Erkennungsfunktion (MDF), das Folgendes umfasst: Empfangen einer Mikrodienst-Instanz-Registrierung für einen Mikrodienst-Beschleuniger, wobei die Registrierung einen Mikrodienst, den der Mikrodienst-Beschleuniger bereitstellen soll, und eine Mikrodienst-Verbindungsfähigkeit, die eine Fähigkeit der Mikrodienst-Instanz angibt, direkt mit anderen Instanzen des gleichen oder eines anderen Mikrodienstes zu kommunizieren, umfasst; und Protokollieren der Registrierung in einer Mikrodienst-Registrierungsdatenbank.
  20. Verfahren nach Anspruch 19, das ferner ein Herausgeben der Mikrodienst-Registrierung an einen Mikrodienste-Treiber umfasst.
  21. Verfahren nach Anspruch 19, wobei die Mikrodienst-Registrierungsdatenbank eine ontologische Datenbank ist.
  22. Verfahren nach Anspruch 19, wobei die Verbindungsfähigkeit Informationen umfasst, die dazu ausgelegt sind, den Mikrodienst-Beschleuniger einer Dienstkette zuzuteilen.
  23. Verfahren nach Anspruch 19, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Abbilden eines Mikrodienste-Anwendungsprogrammierschnittstellen-Aufrufs (Mikrodienste-API-Aufrufs) auf einen nativen Abruf für den Mikrodienst-Beschleuniger enthält, wobei die Mikrodienste-API eine universelle API für Vorrichtungen, die auf den Mikrodienst-Beschleuniger zugreifen, ist.
  24. Verfahren nach einem der Ansprüche 19-23, wobei die Mikrodienst-Registrierungsdatenbank ferner so ausgelegt ist, dass sie Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers enthält.
  25. Verfahren nach Anspruch 24, wobei die Informationen zum Erzeugen einer neuen Instanz des Mikrodienst-Beschleunigers Informationen zum Programmieren der neuen Instanz umfassen.
DE102018210537.5A 2017-06-28 2018-06-27 Mikrodienste-Architektur Pending DE102018210537A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/636,119 US10860390B2 (en) 2017-06-28 2017-06-28 Microservices architecture
US15/636,119 2017-06-28

Publications (1)

Publication Number Publication Date
DE102018210537A1 true DE102018210537A1 (de) 2019-01-03

Family

ID=64662219

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018210537.5A Pending DE102018210537A1 (de) 2017-06-28 2018-06-27 Mikrodienste-Architektur

Country Status (3)

Country Link
US (4) US10860390B2 (de)
CN (2) CN115480869A (de)
DE (1) DE102018210537A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111475372A (zh) * 2020-03-10 2020-07-31 中国平安人寿保险股份有限公司 微服务的服务实例监控方法、装置、设备及存储介质
CN111866140A (zh) * 2020-07-21 2020-10-30 腾讯科技（深圳）有限公司 融合管理设备、管理系统、服务调用方法及介质

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10642648B2 (en) * 2017-08-24 2020-05-05 Futurewei Technologies, Inc. Auto-adaptive serverless function management
US10642667B1 (en) * 2018-03-18 2020-05-05 Juniper Networks, Inc. Apparatus, system, and method for efficiently sharing data between processes
SG11202011209XA (en) * 2018-05-11 2020-12-30 Jpmorgan Chase Bank Na Function as a service gateway
US10901581B2 (en) * 2018-05-16 2021-01-26 ChartIQ, Inc. Assimilation method and system for browser and non-browser display window
US11799952B2 (en) * 2019-01-07 2023-10-24 Intel Corporation Computing resource discovery and allocation
CN109618002B (zh) * 2019-01-11 2022-07-05 武汉斗鱼鱼乐网络科技有限公司 一种微服务网关优化方法、装置及存储介质
US11120188B2 (en) * 2019-01-28 2021-09-14 King Fahd University Of Petroleum And Minerals FPGA virtualization
CN110069354A (zh) * 2019-04-15 2019-07-30 必成汇(成都)科技有限公司 微服务全链路跟踪方法及微服务架构
US11456921B2 (en) * 2019-04-29 2022-09-27 Ncr Corporation Self-contained microservice platform
CN110224855B (zh) * 2019-05-13 2022-07-22 平安科技（深圳）有限公司 微服务实例的注册方法、装置、计算机设备及存储介质
CN111949454B (zh) * 2019-05-14 2022-09-16 华为技术有限公司 一种基于微服务组件的数据库系统及相关方法
US10983769B2 (en) * 2019-05-16 2021-04-20 Citrix Systems, Inc. Systems and methods for using a call chain to identify dependencies among a plurality of microservices
CN110489139A (zh) * 2019-07-03 2019-11-22 平安科技（深圳）有限公司 一种基于微服务的实时数据处理方法及其相关设备
CN110381058B (zh) * 2019-07-18 2023-05-16 深圳前海微众银行股份有限公司 基于全双工通信协议WebSocket的请求传输方法及装置
US11405280B2 (en) 2019-07-24 2022-08-02 Cisco Technology, Inc. AI-driven capacity forecasting and planning for microservices apps
CN110430079B (zh) * 2019-08-05 2021-03-16 腾讯科技（深圳）有限公司 车路协同系统
WO2021040582A1 (en) * 2019-08-23 2021-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for providing a function as a service platform
CN110750307B (zh) * 2019-09-04 2023-04-11 北京旷视科技有限公司 一种微服务架构构建方法及装置
CN110602208B (zh) * 2019-09-12 2022-01-21 北京笔新互联网科技有限公司 一种分布式微服务治理系统及系统的构建方法
US11593084B2 (en) * 2019-10-31 2023-02-28 Dell Products L.P. Code development for deployment on a cloud platform
US11076019B2 (en) * 2019-11-15 2021-07-27 F5 Networks, Inc. Scheduling services on a platform including configurable resources
CN112929195A (zh) * 2019-12-05 2021-06-08 北京沃东天骏信息技术有限公司 服务系统、由服务系统执行的方法、处理装置和存储介质
FR3105851B1 (fr) * 2019-12-27 2023-01-06 Bull Sas Procede et systeme d’agregation de donnees pour une plateforme de gouvernance unifiee d’une pluralite de solutions de calcul intensif
US11182218B2 (en) * 2019-12-31 2021-11-23 Vmware, Inc. Method and apparatus for orchestrating cross-FaaS provider functions declaratively
CN111245925B (zh) * 2020-01-09 2021-08-24 北京理工大学 一种用于现代分布式微服务架构的通信方法与系统
US11044173B1 (en) * 2020-01-13 2021-06-22 Cisco Technology, Inc. Management of serverless function deployments in computing networks
CN111341445B (zh) * 2020-02-05 2024-04-16 网宿科技股份有限公司 微服务调用链的健康检测方法和健康检测系统
CN111371840B (zh) * 2020-02-14 2021-05-11 平安科技（深圳）有限公司 微服务部署方法、装置、计算机设备和存储介质
FR3108746B1 (fr) 2020-03-27 2022-04-01 Bull Sas Procédé et système de Découverte et d’Enregistrement de nouveaux microservices pour une Plateforme de gouvernance unifiée d’une pluralité de solutions de calcul intensif
CN111478955B (zh) * 2020-03-31 2023-04-18 招商局金融科技有限公司 微服务注册方法、系统、装置和计算机可读存储介质
CN111600930B (zh) * 2020-04-09 2022-12-09 网宿科技股份有限公司 微服务请求的流量管理方法、装置、服务器及存储介质
US11252025B2 (en) * 2020-04-16 2022-02-15 Juniper Networks, Inc. Model driven configuration management for microservices
EP4243361A3 (de) * 2020-04-16 2023-11-22 Juniper Networks, Inc. Modellgesteuerte konfigurationsverwaltung für mikrodienste
US11425028B2 (en) * 2020-04-28 2022-08-23 Cisco Technology, Inc. Priority based automated network selection for micro-services in service mesh
CN112083912B (zh) * 2020-08-17 2024-03-12 山东中创软件商用中间件股份有限公司 服务编排的中间结果处理方法、装置、设备及存储介质
US11513875B2 (en) * 2020-08-28 2022-11-29 Ncr Corporation Multiplatform microservice connection techniques
CN112035228B (zh) * 2020-08-28 2024-04-12 光大科技有限公司 一种资源调度方法及装置
US11405451B2 (en) * 2020-09-30 2022-08-02 Jpmorgan Chase Bank, N.A. Data pipeline architecture
US20210117242A1 (en) * 2020-10-03 2021-04-22 Intel Corporation Infrastructure processing unit
CN114363233B (zh) * 2020-10-12 2023-12-22 网联清算有限公司 一种分组路由方法、装置、电子设备及存储介质
CN112965446B (zh) * 2021-01-29 2022-06-14 华中科技大学 一种基于微服务架构的柔性生产线控制系统平台
CN113014666B (zh) * 2021-03-17 2023-02-28 深圳壹账通智能科技有限公司 一种区块链协议栈架构方法、系统、设备及存储介质
WO2022203377A1 (ko) * 2021-03-23 2022-09-29 (주)인스웨이브시스템즈 마이크로 서비스 아키텍처를 가지는 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
CN112732534B (zh) * 2021-03-30 2021-07-23 北京宇信科技集团股份有限公司 一种支持分布式微服务的esb系统
US11606317B1 (en) * 2021-04-14 2023-03-14 Xilinx, Inc. Table based multi-function virtualization
US11829810B2 (en) * 2021-04-15 2023-11-28 Ncr Corporation Single device independent backend interface to a frontend interface of a microservice
US11683227B2 (en) * 2021-06-15 2023-06-20 Infinera Corporation Streaming and config for event driven microservice architecture for embedded services
CN113253710B (zh) * 2021-06-16 2021-09-28 奥特酷智能科技(南京)有限公司 一种区块网关电控单元的控制软件实现架构
CN113391568B (zh) * 2021-06-25 2023-04-07 北京猎户星空科技有限公司 适配用于机器人的多个底盘的中间件及控制方法
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization
CN113489809B (zh) * 2021-09-08 2021-12-07 广州易方信息科技股份有限公司 微服务的数据传输方法、结构以及计算机设备
CN114327767B (zh) * 2021-12-28 2022-08-05 元心信息科技集团有限公司 任务处理的方法、装置、电子设备及计算机可读存储介质
US11570279B1 (en) 2022-02-25 2023-01-31 International Business Machines Corporation Automated port configuration management in a service mesh
CN116760650B (zh) * 2023-08-23 2023-11-21 深圳开源互联网安全技术有限公司 基于iast技术确认微服务调用中http参数污染传播链的方法
CN117648123B (zh) * 2024-01-30 2024-06-11 中国人民解放军国防科技大学 一种微服务快速集成方法、系统、设备及存储介质

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7257308B2 (en) * 2001-12-06 2007-08-14 Scientific-Atlanta, Inc. Converting time-shift buffering for personal video recording into permanent recordings
US7447720B2 (en) * 2003-04-23 2008-11-04 Micron Technology, Inc. Method for finding global extrema of a set of bytes distributed across an array of parallel processing elements
JP2007538313A (ja) * 2004-04-29 2007-12-27 インターナショナル・ビジネス・マシーンズ・コーポレーション 分散ネットワーキング・アーキテクチャ内にサービスをモデル化し、動的にデプロイするためのシステムおよび方法
US8229985B2 (en) * 2005-02-07 2012-07-24 Cisco Technology, Inc. Arrangement for a distributed file system having data objects mapped independent of any data object attribute
KR100739715B1 (ko) * 2005-07-12 2007-07-13 삼성전자주식회사 웹서비스 정책 합의를 수행하는 장치 및 방법
EP1983425A4 (de) * 2006-02-01 2009-03-18 Fujitsu Ltd Objektrelation-anzeigeprogramm und objektrelation-anzeigeverfahren
US9024957B1 (en) * 2007-08-15 2015-05-05 Nvidia Corporation Address independent shader program loading
US8751626B2 (en) * 2007-10-23 2014-06-10 Microsoft Corporation Model-based composite application platform
US8627328B2 (en) * 2008-11-14 2014-01-07 Oracle International Corporation Operation control for deploying and managing software service in a virtual environment
JP2014171211A (ja) * 2013-02-06 2014-09-18 Ricoh Co Ltd 情報処理システム
US9892177B2 (en) * 2013-07-11 2018-02-13 Salesforce.Com, Inc. Systems and methods for interacting with external content objects
CN104754010B (zh) * 2013-12-31 2019-01-25 华为技术有限公司 信息处理的方法及业务平台
CN104978176B (zh) * 2014-04-10 2019-03-08 腾讯科技（北京）有限公司 应用程序接口调用方法、装置及计算机可读存储介质
JP2016134798A (ja) * 2015-01-20 2016-07-25 株式会社リコー 画像形成装置、情報処理システム及び情報処理プログラム
CN107667517B (zh) * 2015-06-03 2021-03-19 瑞典爱立信有限公司 用于能够实现第二容器上的反向代理的在第一服务容器内的被植入代理器
US9819732B2 (en) * 2015-07-31 2017-11-14 Netapp, Inc. Methods for centralized management API service across disparate storage platforms and devices thereof
US10057185B1 (en) * 2015-09-21 2018-08-21 Amazon Technologies, Inc. User-initiated activation of multiple interruptible resource instances
US9858105B1 (en) * 2015-11-24 2018-01-02 Amazon Technologies, Inc. Service for managing custom virtual machine images
CN105577780B (zh) * 2015-12-21 2018-12-04 武汉理工大学 一种基于微服务的高校教学云平台
WO2017170309A1 (ja) * 2016-03-31 2017-10-05 日本電気株式会社 ネットワークシステム、その管理方法および装置ならびにサーバ
US9804886B1 (en) * 2016-05-27 2017-10-31 Intuit Inc. Extending object-schema-based application programming interfaces (APIS)
WO2018006072A1 (en) * 2016-06-30 2018-01-04 Clause, Inc. Systems and method for forming, storing, managing,and executing contracts
US10613700B2 (en) * 2016-10-31 2020-04-07 Intuit Inc. Rendering user-interface elements based on variation metamodels
US10489402B2 (en) * 2016-11-08 2019-11-26 International Business Machines Corporation Bridging native JDBC calls with DBaaS using ESB
CN106610836B (zh) * 2016-12-23 2019-12-31 国网信息通信产业集团有限公司 一种微服务运行管理工具
US10365932B2 (en) * 2017-01-23 2019-07-30 Essential Products, Inc. Dynamic application customization for automated environments
US20180219949A1 (en) * 2017-01-27 2018-08-02 Obigo Inc. Method for automatically controlling network access using api map in cloud-based vehicle environment and device using the same
CN106603582B (zh) * 2017-02-23 2020-03-13 北京工业大学 一种网络微服务发现方法
US10558467B2 (en) * 2017-03-30 2020-02-11 International Business Machines Corporation Dynamically generating a service pipeline comprising filtered application programming interfaces
US10523507B2 (en) * 2017-05-11 2019-12-31 Nirmata, Inc. Method and system for tuning performance of microservices-based applications
US10824483B2 (en) * 2018-11-20 2020-11-03 R Software Inc. Application programming interface scoring, ranking and selection
US11201790B2 (en) * 2019-03-27 2021-12-14 Saudi Arabian Oil Company System and method for virtual private network connectivity

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111475372A (zh) * 2020-03-10 2020-07-31 中国平安人寿保险股份有限公司 微服务的服务实例监控方法、装置、设备及存储介质
CN111866140A (zh) * 2020-07-21 2020-10-30 腾讯科技（深圳）有限公司 融合管理设备、管理系统、服务调用方法及介质
CN111866140B (zh) * 2020-07-21 2023-09-15 腾讯科技（深圳）有限公司 融合管理设备、管理系统、服务调用方法及介质

Also Published As

Publication number Publication date
US20190004871A1 (en) 2019-01-03
US20230251915A1 (en) 2023-08-10
US20210191789A1 (en) 2021-06-24
CN109144660A (zh) 2019-01-04
US20220350679A1 (en) 2022-11-03
US11645127B2 (en) 2023-05-09
US10860390B2 (en) 2020-12-08
US11467888B2 (en) 2022-10-11
CN115480869A (zh) 2022-12-16

Similar Documents

Publication Publication Date Title
DE102018210537A1 (de) Mikrodienste-Architektur
US10997106B1 (en) Inter-smartNIC virtual-link for control and datapath connectivity
Kim et al. {FreeFlow}: Software-based Virtual {RDMA} Networking for Containerized Clouds
CN115516832A (zh) 网络和边缘加速瓦片（next）体系结构
US11296956B2 (en) Oversubscribable resource allocation
US20180357086A1 (en) Container virtual switching
DE102019105069A1 (de) Technologien zur netzpaketverarbeitung zwischen cloud- und telekommunikationsnetzen
US11586575B2 (en) System decoder for training accelerators
DE112008002416T5 (de) Gemeinsame Nutzung von Legacy-Geräten in einer Multithost-Umgebung
CN105190557A (zh) 用于通过多级api集成在公共与私有云之间进行桥接的系统和方法
DE102018004111B4 (de) Rechensystem, computerlesbares medium und bedarfsskalierungsengine zum kommunikativen koppeln an einen prozessor
DE102022104207A1 (de) Pooling von Netzwerkverarbeitungsressourcen
DE112018007780T5 (de) Transparente verschlüsselung
DE112022002284T5 (de) Auslagerung der vermittlungsschicht 7 an eine infrastrukturverarbeitungseinheit für ein vermaschtes dienstnetz
DE112021003869T5 (de) Verfahren und einrichtung zur performanzskalierung mit paralleler verarbeitung der gleitfensterverwaltung auf einer mehrkernarchitektur
DE112019000965T5 (de) Technologien zur reduzierung der nic-anschlüsse mit beschleunigter schaltung
DE102022126611A1 (de) Service-mesh-auslagerung an netzwerkvorrichtungen
Eran et al. Flexdriver: A network driver for your accelerator
DE112016007292T5 (de) Technologien für paravirtualisierte netzwerkvorrichtungswarteschlangen und speicherverwaltung
Steinert et al. Hardware and software components towards the integration of network-attached accelerators into data centers
Nandugudi et al. Network function virtualization: through the looking-glass
WO2019173937A1 (en) Improved memory-mapped input/output (mmio) region access
CN113037812A (zh) 数据包调度方法、装置、电子设备、介质和智能网卡
Baymani et al. RapidIO as a multi-purpose interconnect
US20230319133A1 (en) Network interface device to select a target service and boot an application

Legal Events

Date Code Title Description
R130 Divisional application to

Ref document number: 102018010501

Country of ref document: DE