Ich arbeite an einer Website, die sowohl hinsichtlich der Nutzerbasis als auch der Funktionalität so weit gewachsen ist, dass sich herausstellt, dass einige der Verwaltungsaufgaben von der öffentlichen Website getrennt sein sollten. Ich habe mich gefragt, wie der beste Weg dazu aussehen könnte.
Zum Beispiel hat die Seite eine große soziale Komponente und eine öffentliche Verkaufsschnittstelle. Aber zur gleichen Zeit gibt es auch Back-Office-Aufgaben, Bulk-Upload-Verarbeitung, Dashboards (mit lang andauernden Abfragen) und Tools für Kundenbeziehungen im Admin-Bereich, die nicht durch Spikes im öffentlichen Verkehr beeinträchtigt werden vor der Reaktionszeit).
Die Site läuft auf einem relativ standardmäßigen Rails / MySQL / Linux-Stack, aber ich denke, das ist eher ein Architekturproblem als eine Implementierung: Hauptsächlich, wie man die Daten- und Geschäftslogik zwischen diesen verschiedenen Anwendungen synchronisiert hält ?
Einige Strategien, die ich evaluiere:
1) Erstellen Sie eine Slave-Datenbank der öffentlich zugänglichen Datenbank auf einem anderen Computer. Extrahieren Sie den gesamten Modell- und Bibliothekscode, damit er von den Anwendungen gemeinsam genutzt werden kann. Erstellen Sie neue Controller und Ansichten für die Admin-Schnittstellen.
Ich habe nur begrenzte Erfahrung mit der Replikation und bin mir nicht einmal sicher, ob es auf diese Weise verwendet werden soll (meistens habe ich es gesehen, um die Lesefähigkeiten der gleichen Anwendung zu skalieren, anstatt mehrere zu haben verschiedene). Ich mache mir auch Sorgen wegen möglicher Latenzprobleme, wenn sich der Slave nicht im selben Netzwerk befindet.
2) Erstellen Sie neue aufgaben- / abteilungsspezifische Anwendungen und verwenden Sie eine nachrichtenorientierte Middleware, um sie zu integrieren. Ich habe Enterprise Integration Patterns schon einmal gelesen und sie befürworteten dies für verteilte Systeme. (Alternativ kann in einigen Fällen die grundlegende REST-konforme API-Funktionalität im Rails-Stil ausreichen.) Aber ich habe Alpträume über Probleme bei der Datensynchronisierung und die damit verbundene massive Re-Architecture.
3) Eine Mischung aus beidem. Zum Beispiel ist die einzige öffentliche Information, die für einige der Back-Office-Aufgaben erforderlich ist, eine Nur-Lese-Vervollständigungszeit oder -status. Wäre es sinnvoll, das auf einem völlig separaten System zu haben und die Daten an die Öffentlichkeit zu senden? In der Zwischenzeit würde die Benutzer / Gruppen-Admin-Funktionalität auf einem separaten System ausgeführt werden, das die Datenbank gemeinsam nutzt. Der Nachteil ist, dass dies viele der Sorgen, die ich mit den ersten beiden habe, insbesondere die Re-Architecture, zu behalten scheint.
Ich bin mir sicher, dass die Antworten stark von den spezifischen Bedürfnissen einer Site abhängen werden, aber ich würde gerne Erfolgsgeschichten hören.
Soweit ich aus Ihrer Beschreibung ersehen kann, müssen Sie, wenn Sie wirklich sicherstellen wollen, dass sich die öffentliche Leistung und die Admin-Leistung nicht gegenseitig beeinflussen, separate Datenbanken auf separaten Servern verwenden.
Der Schlüssel besteht darin, zu verstehen, welche Daten wo verwendet werden und wie die Daten in den Prozess eingebunden sind. Wenn Sie das tun können, dann versuchen Sie festzustellen, ob Sie eine Datenbank als "führende" Datenbank definieren können. Dies wären Ihre Live-Daten und die andere Datenbank wäre Ihr Operations Data Store (ODS). Der ODS ist immer eine Ableitung von Ihren Live-Daten. Der Prozess der Aktualisierung des ODS aus den Live-Daten kann in einem Intervall erfolgen und sowohl die Daten vereinfachen als auch zusätzliche Verarbeitungen vornehmen, um sie für die Anwendung, die das ODS verwendet, besser geeignet zu machen.
Wenn Sie nun feststellen, dass dies für Ihre aktuelle Situation zu einem großen Sprung führt, können Sie versuchen, die Daten in der Datenbank zumindest zu trennen, sodass Sie sich nicht mit Leistungsproblemen wie Tabellensperren usw. befassen müssen. Es kann auch ein Schritt in die richtige Richtung sein, wenn Sie in Zukunft zu einem ODS-ähnlichen Modell wechseln müssen.
Ich bin kein Fan davon, zu replizieren, was nicht sein muss. Ich würde markieren, was nur Admin ist und diesen Teil als separate DB mit einer internen IP oder einem anderen Port erstellen. Erstellen Sie dann Fremdschlüsselbeziehungen für den öffentlichen Zugriff auf der öffentlichen Website. Es wie eine indizierte Tabelle zu behandeln, wäre viel einfacher zu administrieren als zu replizieren und API-Entwicklung ist eine unnötige Aufgabe, wenn Sie nicht mit Legacy-Systemen sprechen. Auch warum replizieren, wenn Sie die Systeme getrennt halten möchten. Themes meine zwei Cent.
Tags und Links architecture administration modularity admin