RFC mit einer modularen Architektur Umsetzung

Question

Suche nach Meinungen über die Modularisierung von Web-Anwendungen. Bereits die meisten Anwendungen unabhängig von der Sprache haben ein Back-End-DB und Support-Tie-Ins mit ihren jeweiligen Web Application Server (Apache, IIS, Lighttp, etc.), aber viele Entwickler ich behandelt habe mit haben kommen Probleme, sich mit mit Memcached oder irgendetwas außerhalb des unmittelbaren Prozessraum des Web-App.

Ist Modularisierung einer Web-Anwendung als gute Sache eine Sache, wie ich glaube, oder gibt es etwas, was ich bin fehlt, das jeder von Sr. Entwickler zu CTO führt zu zögern aus dem Web-Front-spezifische Teile der Geschäftslogik zu bewegen Ende und in spezialisiertem Backend-Service?

Zum Beispiel vor ein paar Jahren habe ich in einem Projekt Design Sitzung für eine sehr hohe Traffic Website abgeschossen, als ich vorgeschlagen, dass wir den Prozess intensiv ACL-Logik aus dem vorderen Ende Rahmen und machen es zu einem semi-cluster Service rippen Anwendung im Backend. Für mich war die Vorteile eine sauberere Trennung von Code und die Fähigkeit, unter Verwendung REST / JSON als Brücke zwischen etwa PHP & Python der ACL-Logik an mehreren Stellen wieder zu verwenden.

Die Entwickler, die mit meiner Idee nicht einverstanden argumentiert, es sei „zu kompliziert“ war, aber ich konnte einfach nicht sehen, wie? Meine Argumente sind, dass so wie es Tag Suppe für die Schicht Präsentation sein kann, kann es und ist oft eine logische Suppe von Code, der so verzahnt ist zusammen, dass, wenn ein Problem auftritt es nahezu unmöglich sein könnte, einen „chirurgischen“ fix auszuführen.

So ist es zu verkürzen, nach unten, was ist die con u oder Profis der Pause großer Anwendungen nach unten in unabhängige, aber kooperative Prozesse (keine Threads oder Sub-Anfragen). MySQL, Memcache, ähnlich Service-Prozess ist toll ... aber warum nicht etwas anderes? Wie wird auf diesem Weg „zu kompliziert“?

Answer 1

Nun, manchmal „zu kompliziert“ bedeutet: „Ich will nicht außerhalb meiner Komfort-Zone denken.“

Die grundlegende Idee klingt gut --- Sie sprechen ziemlich plausible serviceorientierten Architektur hier.

Nun, so weit wie die Vor-und Nachteile, ist das erste, was dagegen, dass Sie tun müssen in der Tat Menschen außerhalb ihrer Komfortzonen zu denken zu bekommen. Ein technischer Nachteil ist, dass Sie erhalten muß, was ist in der Tat, den Sitzungsstatus. Sagen Sie die Authentifizierungs-Token von Ihrem Auth Service abholen; wie ist das Token mit der korrekten Benutzersitzung bleiben assoziiert gehen.

Ein weiteres Problem ist, dass es schwieriger zu debuggen sein könnte, da es mehr dynamisch geschieht.

Auf der positiven Seite, aber, wenn Sie das Sitzungszustands Problem erfüllen können, erhalten Sie eine hoch skalierbare Architektur; wenn Sie mehr Service benötigen, können Sie entweder den Server erweitern, oder einfach einen anderen Server hinzuzufügen.

Answer 2

Ich bin ein Fan von der Core Server / Business-Logik-Funktionalität aus dem Web-Anwendungs-Code zu trennen. Dies ist für ein paar verschiedenen Gründe:

1. Sie können besser steuern, um die Geschäftslogik. Es gibt keine Möglichkeit, dies mit GUI-Code in mischen und ein Chaos zu schaffen. Sie wollen alle die Geschäftslogik getrennt zu halten, so dass Sie später eine API machen den Code Funktionalität zu nennen und nicht darauf hoffen, dass keine Geschäftslogik seinen Weg in den GUI-Code gemacht.
2. Von dem get-go Sie eine gute API zu entwerfen, die Sie haben, sie zu verwenden, um mit dem Server von dem Client zu kommunizieren. Der Client kann die Web-Oberfläche sein oder es kann ein Remote-Benutzer sein.
3. Stabilität. GUI Web-Code kann leicht falsch geschrieben werden und verbrauchen zu viel Speicher nahm damit die gesamte App nach unten.
4. So skalieren Sie diese separaten Komponenten auf verschiedene Server verschieben können. Wenn Sie ein Caching-System verwenden, das bereits für das Clustering ermöglicht die Skalierung kann so einfach sein wie nur mehr Caching-Server hinzugefügt wird.
5. Ich habe festgestellt, dass Anwendungs-Updates am häufigsten auf den GUI-Code vorgenommen werden, so dass die Kernleistung nicht getroffen werden muss, die meiste Zeit nach unten.
6. Sicherheit. Sie können sicher sein, dass der Sicherheitscode in dem Server-Code implementiert wird, so dass, wenn jemand Ihre API verwendet, werden sie nicht in der Lage sein, jeden Sicherheitscode zu umgehen, die ihren Weg in den GUI-Code gemacht.

Unser System hat einen Kern ‚Motor‘ Service als Java-Anwendung implementiert. Die Web-Anwendung ist auch in Java geschrieben und (derzeit) Kommunikation über RMI. Unsere Website / Anwendung wächst und wir haben noch nicht hatte einen Caching-Dienst wie Memcached oder JCS zu beginnen.