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.
• Using ‘faster’ technologies.
• 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
The first force that led to the surge in microservices was a reaction against normal monolithic architecture. While a monolithic app is One Big Program with many responsibilities, microservice-based applications are composed of smaller programs, each with a single responsibility. This allows teams of devs to work independently on different services. The inherent decoupling also encourages smaller, simpler programs that are easier to understand, so new devs can start contributing more quickly. Finally, since no single program represents the whole of application, services can change direction without massive costs. If new technology becomes available that makes more sense for a particular service, it’s feasible to rewrite just that service. Similarly, since microservices communicate across a different languages, an application can be composed of several different platforms – Ruby, Java, PHP, Node, Go, etc without any issue.

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.