Aufteilung der Monolithic Rails-Anwendung auf Microservices

Wenn ein Unternehmen größer wird, benötigt es mehr Funktionalitäten und daher kommt man nicht umhin, der bestehenden Rails-Anwendung neue Modelle/Controller hinzuzufügen, und manchmal wird sie zu einem Monolithen. Wenn Sie es mit einer monolithischen Anwendung zu tun haben, die nicht mehr wartbar und schwer bereitzustellen ist, müssen Sie einige Möglichkeiten zur Verwaltung kennen. Wenn Ihr Team Tausende von Zeilen durchgehen muss, um das Projekt zu verstehen und einige Änderungen vorzunehmen, ist es an der Zeit, diese aufzuteilen.

Wann sollte die Anwendung aufgeteilt werden?

• Wenn Ihre Tests länger als 20 Minuten dauern.
• Auf mehrere Hundert oder Tausende angewachsene Modelle.
• Unabhängige Funktionalität.
• Wenn Entwickler nicht unabhängig an der Entwicklung/Bereitstellung ihrer eigenen Module arbeiten können.

Verschiedene Möglichkeiten zur Aufteilung einer monolithischen Anwendung

• Nutzung von Microservices.
• Nutzung „schnellerer“ Technologien.
• Fügen Sie eine Reihe von Servern hinzu.

Was ist Microservice?                                                                                                                                           Microservices sind eine strategische Möglichkeit, ein großes Projekt in kleinere, besser verwaltbare Teile zu zerlegen. Ein Microservice ist ein Teil der Anwendungsfunktionalität, der in seine eigene Codebasis integriert wurde und über ein Standardprotokoll mit anderen Microservices kommuniziert. Um dies zu erreichen, unterteilen Sie zunächst Ihre Geschäftsanforderungen in verwandte Gruppen wie Benutzerverwaltungslogik, Werbelogik und eine Webbenutzeroberfläche.

Warum Microservice
Die erste Kraft, die zum Anstieg der Microservices führte, war eine Reaktion gegen die normale monolithische Architektur. Während eine monolithische App ein großes Programm mit vielen Verantwortlichkeiten ist, bestehen Microservice-basierte Anwendungen aus kleineren Programmen mit jeweils einer einzigen Verantwortung. Dadurch können Entwicklerteams unabhängig voneinander an verschiedenen Diensten arbeiten. Die inhärente Entkopplung fördert auch kleinere, einfachere und leichter verständliche Programme, sodass neue Entwickler schneller mit dem Beitrag beginnen können. Da schließlich kein einzelnes Programm die gesamte Anwendung repräsentiert, können Dienste ohne große Kosten ihre Richtung ändern. Wenn neue Technologien verfügbar werden, die für einen bestimmten Dienst sinnvoller sind, ist es möglich, nur diesen Dienst neu zu schreiben. Da Microservices in verschiedenen Sprachen kommunizieren, kann eine Anwendung problemlos aus mehreren verschiedenen Plattformen bestehen – Ruby, Java, PHP, Node, Go usw.

Vorteile

• Module können wiederverwendet werden.
• Die Bereitstellung verläuft unabhängig von der gesamten großen Anwendung reibungslos.
• Einfaches Hinzufügen von Funktionen.
• Reduziert die Testzeit, um ein Modul anstelle aller zu testen.
• Große Anwendungen sind tendenziell schwieriger zu warten als kleine.
• Da wir über eine Reihe kleiner Anwendungen verfügen, können wir uns auf die Arbeit an isolierten Teilen konzentrieren.
• Möglicherweise haben wir eine größere Chance, andere Teile der Anwendung nicht zu beschädigen.
• Zuverlässigkeit und Fehlertoleranz.
• Einfache Migration oder Aktualisierung.
• Technologievielfalt.
• Wenn eine einzelne Anwendungsfunktion nicht funktioniert, fällt nicht die gesamte Anwendung aus.
• Erleichtert es einem neuen Entwickler, die Funktionalität eines Dienstes zu verstehen.

Nachteile
Because everything is now an independent service, you have to handle requests carefully travelling between your modules. There can be a scenario where any of services may not be responding.
Multiple databases and transaction management can be painful.
Productivity will be less till the microservice base is set.

Monolithische vs. Microservices
Das folgende Diagramm zeigt den Unterschied zwischen herkömmlichen monolithischen Apps und Microservices im Hinblick auf Personalressourcen, Zeit, Wartung und Handhabungskomplexität von Anwendungen.

So richten Sie Microservices ein
Eine strategische Möglichkeit, die monolithische Anwendung zu verkleinern, besteht darin, die Schichten wie Präsentations-, Geschäftslogik- und Datenzugriffsschichten aufzuteilen. Eine typische Unternehmensanwendung besteht aus mindestens drei verschiedenen Arten von Komponenten:

• Presentation layer – Components that handle HTTP requests and implement either a (REST) API or an
  HTML-based web UI. In an application that has a sophisticated user interface.
• Geschäftslogikschicht – Komponenten, die den Kern der Anwendung bilden, in der Geschäftsregeln implementiert werden.
• Datenzugriffsschicht – Komponenten, die Zugriff auf Infrastrukturkomponenten wie Datenbanken und Nachrichtenbroker haben.

RailsCarma hat Ruby on Rails-Anwendungen von Anfang an für die Entwicklung, Schulung, Bereitstellung und Beiträge zur Rails-Community implementiert. RailsCarma bietet durch vertrauenswürdiges technisches Fachwissen und umfassenden Kundenservice ein angenehmes Kundenerlebnis Ruby on Rails-Entwicklung,Beratung, Architektur, Management und Erweiterung für Unternehmen auf der ganzen Welt. Kontaktieren Sie uns, um mehr zu erfahren.