Unsere Mission bei Jitterbit ist es, selbst die komplexesten Konnektivitätsherausforderungen zu vereinfachen und es jedem zu ermöglichen, sich in der heutigen digitalen Welt zu verbinden. Obwohl wir betonen, dass Sie kein Entwickler sein müssen, um die Produkte von Jitterbit zu verwenden – hinter jeder großartigen Softwarelösung steht ein Team fantastischer Entwickler. Im Jitterbit Tech Talk blog Series geben uns Mitglieder des Jitterbit-Entwicklungsteams einen Einblick in den Aufbau einer Cloud-Plattform der Enterprise-Klasse und die Herausforderungen, die sie in Bezug auf Mandantenfähigkeit, Skalierbarkeit und Sicherheit lösen mussten.
Diese Woche befasst sich Pankaj Arora, unser Sr. Director of Technology, damit, wie Sie eine hochgradig skalierbare Cloud-Plattform der Enterprise-Klasse entwerfen und aufbauen.
Die Cloud bietet Unternehmen eine leistungsstarke Möglichkeit, ihre Produkte und Dienstleistungen anzubieten, die von überall und auf jedem Gerät leicht zugänglich sind. Darüber hinaus bietet es dem Anbieter enorme Vorteile, einschließlich der Transparenz darüber, wie sein Angebot genutzt wird, einer schnellen Entwicklung und Bereitstellung sowie einer allgemeinen Reduzierung der IT- und Wartungskosten. Infolgedessen fast jeder company ist heute bestrebt, seine Lösungen in der Cloud verfügbar zu machen.
Aber es gehört noch viel mehr dazu, eine echte Cloud zu werden company als Software auf einem gehosteten Server zu installieren und Ihre Marketingmaterialien mit „Cloud“ zu versehen.
Ich habe mich kürzlich mit einem Technologiestrategen unterhalten, und sie stellten fest, dass rund 75 % der Unternehmen ihre Legacy-Unternehmensangebote gerne in die Cloud migrieren würden. Überraschenderweise entwerfen 90 % von ihnen einen ersten Plan, der auf einer Architektur aufbaut, in der ihre Legacy-Anwendungen einfach auf einem öffentlich zugänglichen Cloud-Server bereitgestellt würden. Dieser Ansatz negiert alle Vorteile, die die Cloud zu bieten hat.
Der Aufbau einer echten mandantenfähigen Cloud-Plattform erfordert die Lösung einer Reihe verschiedener Herausforderungen wie Sicherheit, Zuverlässigkeit, Skalierbarkeit, Hochverfügbarkeit, Fehlertoleranz, Protokollierung, Überwachung, Benachrichtigungssystem, kontinuierliche Bereitstellungsfähigkeit und mehr.
Im heutigen Beitrag werden wir uns genauer ansehen, wie wir bei der Entwicklung unserer mandantenfähigen Cloud-Integrationsplattform mit der Herausforderung der „Skalierbarkeit“ umgegangen sind.
Das Ausmaß der Skalierbarkeit einer Anwendung hängt von ihrer Fähigkeit ab, vertikal und horizontal zu skalieren. In einer Cloud-Umgebung bedeutet dies, Dienste zu entwerfen, die externe Anfragen bedienen, die so skalieren, dass sie interne Backend-Systeme wie Datenbanken, Caches, Mediator-Layer, Batch-Prozesse (Analyse-Engine, Empfehlungs-Engine) usw. nutzen können, um praktisch unbegrenzte Anfragen auf vernünftige Weise zu verarbeiten kurze Zeit. Es ist nicht immer möglich, die Anzahl der Benutzer vorherzusagen, die auf Ihre Plattform zugreifen. Das Entwerfen einer Architektur, die dies im Multi-Tenancy-Modell berücksichtigt, trägt dazu bei, diese Unsicherheit zu einem allgemeinen Skalierbarkeitsproblem zu machen.
Vertikale Skalierung
Vertikale Skalierbarkeit beinhaltet das Hinzufügen von Ressourcen wie zusätzliche CPUs oder Speicher zu einem einzelnen Knoten in einem System, und dies sollte das erste sein, woran Sie denken, wenn Sie Ihre Dienste skalieren. Es ist sehr wichtig, Ihre Anwendungen so zu gestalten, dass sie diese Ressourcen optimal nutzen. Nehmen Sie den allgemeinen Anwendungsfall für unsere Hybrid-Integrations-Cloud-Plattform, bei der Integrationsvorgänge von einem On-Premise- oder Cloud-Server-Knoten bereitgestellt werden. Hier sollten die Dienste eine Anfrage zum Ausführen von Integrationen entgegennehmen, die Anfrage an Serverknoten weiterleiten und weitere Anfragen bedienen. Die Diensteschicht sollte nicht von den Prozessen abhängig sein oder durch diese blockiert werden, die auf verschiedenen Schichten des Systems ablaufen. Daher ist es sehr wichtig, eine asynchrone, ereignisgesteuerte Architektur zu haben.
Eine einfache Möglichkeit, asynchrone Architektur zu verstehen, besteht darin, sich Ihre Architektur als Restaurant vorzustellen. Ein Kellner nimmt Bestellungen von einem Tisch entgegen und gibt sie an den Koch weiter. Während sich der Koch, der Food-Runner und der Busboy um Aktivitäten wie Kochen, Servieren und Putzen kümmern, bedient der Kellner weiterhin neue Kunden und führt am Ende des Service Kontrollen durch.
Es ist sehr wichtig, die Asynchronität aufrechtzuerhalten, während das System mit allen Komponenten wie Datenbank, Cache und Mediator-Schicht arbeitet. Durch das Weiterleiten von Last an geclusterte, hochverfügbare Serverknoten, auf denen Integrationen ausgeführt werden, werden Ressourcen für die Dienstschicht frei, damit diese mehr Anforderungen annehmen und reagieren kann, wenn Prozesse abgeschlossen sind.
Horizontale Skalierung
Die nächste wichtige Überlegung sollte sein, dass die Dienste so geschrieben sind, dass es keine Rolle spielt, wie viele Instanzen dieser Dienste ausgeführt werden und welches gemeinsam genutzte System zu einem bestimmten Zeitpunkt Transaktionen durchführt. Dies gibt unserer Cloud-Plattform die Flexibilität, die Serviceebene automatisch zu skalieren. Jeder Teil des Backends ist hochverfügbar und automatisch skalierbar, um mit der Nachfrage nach wachsenden Servicecontainern Schritt zu halten.
Wir können jedoch keine unendlichen Container haben, auf denen Dienstschichten ausgeführt werden, die gemeinsam genutzte Komponenten verwenden. Das ist nicht das optimale Design. Kommen wir zurück zu unserem Restaurant-Beispiel. Mit vertikaler Skalierung könnte ein einzelnes Restaurant durch Hinzufügen von mehr Personal hochgradig skalierbar werden, aber an einem bestimmten Punkt wird die Anzahl der Ressourcen (Köche, Läufer, Busjungen) einen Sättigungspunkt erreichen. Um weiter zu skalieren, müsste dieses Unternehmen zusätzliche Standorte eröffnen, die helfen würden, Kunden zu verteilen und die Last auszugleichen.
Es ist besser, die gesamte Plattform in mehrere Zonen zu unterteilen, wobei sich jede Zone wie eine Kopie der ursprünglichen Zone verhält. Dadurch können wir mehrere Zonen verwenden, um zukünftige Anforderungen auszugleichen.
Dieses Modell hat mehrere Vorteile:
1. Mögliche unendliche horizontale Skalierung, da wir beliebig viele Zonen einbringen können
2. Fehlertoleranz, falls die gesamte Zone aufgrund einer Naturkatastrophe ausfällt
3. Datentrennung, im Fall einer SaaS-Plattform, die sogar eine ortsbezogene Metadatentrennung erfordert, wie z. B. für die USA, EMEA-Zonen usw.
Das gewünschte Ergebnis hier ist, dass die Erfahrung eines Benutzers gleich sein sollte, egal wo er sich befindet und welche Zone er erreicht. Es sollte kein manueller Eingriff von einem Benutzer erforderlich sein, um die Arbeit zu erledigen.
In unserer hybride Integrations-Cloud bloghaben wir diskutiert, wie wir auf die Herausforderung gestoßen sind, eine Mediatorschicht so zu verwenden, dass sie eine begrenzte vertikale Skalierung unterstützt. Durch das Schreiben unserer eigenen angepassten nicht blockierenden Verbindungsschicht basierend auf sicherem HTTPS-Transport konnten wir die Architektur auf eine 50-fache vertikale Skalierung erweitern. Natürlich ist es auch horizontal skalierbar. Diese Kombination aus vertikaler und horizontaler Skalierung gab uns eine kostengünstigere und leicht erweiterbare Ebene, um unseren wachsenden Anforderungen gerecht zu werden.
Optimierung der Verwendung gemeinsam genutzter Komponenten:
Gemeinsam genutzte Komponenten sollten selbst skalierbar und hochverfügbar sein, um die Cloud-Plattform zu unterstützen. Gemeinsam genutzte Komponenten werden jedoch gemeinsam genutzt und sind daher nicht so skalierbar wie die Dienstschicht. Es ist sehr wichtig, sich um einige Komponenten zu kümmern, die empfindlich auf eine hohe Belastung reagieren können, z. B. Datenbanken. Ein Modell kann darin bestehen, die Verwendung gemeinsam genutzter Komponenten zu priorisieren und in eine Warteschlange zu stellen, wenn mehrere gleichzeitige Lasten mit hohem Volumen Probleme verursachen können. Die Priorisierung kann die Last verringern und Fehler bei allen unternehmenskritischen Anforderungen mindern. Zurück in unserem Restaurant ist die Küche eine gemeinsame Komponente, und während der Kellner die Bestellung eines Abendessens für eine Vorspeise, ein Hauptgericht und ein Dessert entgegennehmen kann, wird die Küche das Kochen dieser Speisen priorisieren und ihre Last ausgleichen.
Eine andere Möglichkeit, die Last zu bewältigen, besteht darin, Daten zwischenzuspeichern, die sich selten ändern, um eine hohe Nutzung dieser Komponenten zu verhindern. Wenn Pommes Frites ein beliebtes Element auf der Speisekarte sind, kann das Restaurant entscheiden, eine kontinuierliche Charge „zwischenzuspeichern“, anstatt sie auf Bestellung zu frittieren.
Überwachung von Komponenten:
Schließlich ist es sehr wichtig, jede Komponente zu überwachen und ihre Grenzen zu kennen. Das System sollte in der Lage sein, die Bandbreite automatisch und zum richtigen Zeitpunkt zu erhöhen, um die Systeme gemäß den Anforderungen der Cloud-Plattform am Laufen zu halten. Die Überwachung kann extern oder anwendungsinitiiert erfolgen, aber in jedem Fall besteht das Endziel darin, das System basierend auf der Last automatisch skalieren zu lassen.
Im nächsten blog Post werden wir über Überwachung, Protokollierung und andere Elemente der Architektur sprechen.
