Vorwort
Um die verschiedenen Probleme des traditionellen Webentwicklungsmodells zu lösen, haben wir viele Versuche unternommen, aber aufgrund der physischen Kluft zwischen Vorder- und Rückseite sind die von uns ausprobierten Lösungen ähnlich. Wenn wir aus den Schmerzen lernen, überdenken wir heute die Definition von "Front and Back End" und führen NodeJs vor, die den Front-End-Schülern bekannt sind und versuchen, einen brandneuen Front-End-Trennungsmodus zu erkunden.
Mit dem Anstieg verschiedener Terminals (PAD/Mobile/PC) haben Entwickler zunehmend hohe Anforderungen. Die Reaktionsfähigkeit der reinen Browserseite kann nicht mehr den hohen Anforderungen der Benutzererfahrung erfüllen. Wir müssen häufig maßgeschneiderte Versionen für verschiedene Terminals entwickeln. Um die Entwicklungseffizienz zu verbessern, wird der Bedarf an Trennung von Front- und Rückenenden zunehmend geschätzt. Das Back -End ist für Unternehmens-/Datenschnittstellen verantwortlich, das Frontend ist für die Anzeige-/Interaktionslogik verantwortlich und wir können mehrere Versionen derselben Datenschnittstelle anpassen und entwickeln.
Dieses Thema wurde in letzter Zeit viel diskutiert, und einige Alibaba -Bus machen auch einige Versuche. Nach einer langen Diskussion beschloss unser Team, ein Satz von Front-End- und Back-End-Trennungsschema basierend auf NodeJs zu erkunden. Es gab einige veränderte Verständnisse und Gedanken im Prozess. Ich habe es hier aufgenommen. Ich hoffe auch, dass die von mir gesehenen Schüler an der Diskussion teilgenommen haben und uns geholfen haben, sie zu verbessern.
1. Was ist Front-End-Trennung?
Während der ersten Diskussion innerhalb der Gruppe stellte ich fest, dass jeder ein anderes Verständnis der Front-End-Trennung hat. Um sicherzustellen, dass sie auf demselben Kanal diskutieren können, werden wir zunächst eine Vereinbarung darüber erzielen, was "Front-Back-End-Trennung" ist.
Ein Beispiel für die Front-End-Trennung, mit der alle einverstanden sind, ist Spa (einseitige Anwendung). Alle verwendeten Präsentationsdaten werden vom Backend über die asynchrone Schnittstelle (AJAX/JSONP) bereitgestellt, und das Front-End zeigt sie nur an.
In gewisser Weise erreicht Spa Front-End-Trennung, aber es gibt zwei Probleme mit dieser Methode:
Unter den Webdiensten macht Spa einen sehr geringen Teil aus. In vielen Szenarien gibt es auch einen synchronen/synchronen + asynchronen Hybridmodus, und Spa kann nicht als allgemeine Lösung verwendet werden.
Im aktuellen SPA -Entwicklungsmodell wird die Schnittstelle normalerweise gemäß der Präsentationslogik bereitgestellt. Manchmal hilft uns das Backend, um die Effizienz zu verbessern, eine Präsentationslogik, was bedeutet, dass das Backend immer noch an der Arbeit der View -Schicht beteiligt ist, nicht an der tatsächlichen Trennung von Front- und Backends.
Die Front-End-Trennung im Spa-Stil unterscheidet sich von der physischen Schicht (denken Sie, solange es sich um den Client handelt, ist das Front-End und das Back-End der Server). Diese Klassifizierung kann unseren Bedürfnissen nach Front-End-Trennung nicht mehr erfüllen. Wir glauben, dass wir unsere aktuellen Nutzungsszenarien nur durch Dividierung der Verantwortung erfüllen können:
Front-End: Verantwortlich für die Ansicht und Controller-Ebenen.
Backend: Nur für die Modellschicht, die Geschäftsverarbeitung/Daten usw. verantwortlich.
Warum wird diese Aufteilung der Verantwortlichkeiten später erörtert?
2. Warum sollten wir die vorderen und hinteren Enden trennen?
In diesem Thema erklärt der Artikel von Yu Bo in der Entwicklung des Web -F & -Modells sehr umfassend. Lassen Sie uns es kurz überprüfen:
2.1 Anwendbare Szenarien für bestehende Entwicklungsmodelle
Die von Yu Bo erwähnten Entwicklungsmodelle haben jeweils ihre eigenen anwendbaren Szenarien, und keiner von ihnen ersetzt den anderen vollständig.
Zum Beispiel ist es für MVC, das hauptsächlich auf dem Backend basiert, sehr effizient, ein Synchron -Display -Geschäft auszuführen. Bei der Begegnung einer synchronen und asynchronen Seite wird es jedoch problematischer, mit der Backend -Entwicklung zu kommunizieren.
AJAX ist das Hauptmodell für Spa-Entwicklungen, das eher für die Entwicklung von App-Typ-Szenarien geeignet ist, aber nur für die Herstellung von Apps geeignet ist, da SEO und andere Probleme schwer zu lösen sind. Für viele Arten von Systemen ist diese Entwicklungsmethode auch zu schwer.
2.2 Die Verantwortlichkeiten vorne und hinterher sind unklar
In Systemen mit komplexer Geschäftslogik haben wir am meisten Angst davor, den Code mit den vorderen und hinteren Enden zu behalten. Da es keine Einschränkung gibt, kann der Code anderer MVC -Schichten in jeder Schicht erscheinen. Im Laufe der Zeit gibt es überhaupt keine Wartung.
Obwohl die Trennung von Vorder- und Rücksenden dieses Problem nicht vollständig lösen kann, kann es stark gelindert werden. Weil es aus einer physischen Ebene garantiert ist, dass Sie dies nicht tun können.
2.3 Probleme der Entwicklungseffizienz
Das Web von Taobao basiert im Wesentlichen auf dem MVC Framework Webx, und die Architektur bestimmt, dass das Front-End nur auf das Back-End beruhen kann.
Unser Entwicklungsmodell ist also immer noch, dass das Front-End statische Demos schreibt und das Back-End sie in VM-Vorlagen übersetzt. Ich werde nicht über das Problem mit diesem Modell sprechen und bin seit langem kritisiert.
Es ist auch schmerzhaft, sich direkt auf der Back-End-Umgebung zu entwickeln, und es ist problematisch, zu konfigurieren, zu installieren und zu verwenden. Um dieses Problem zu lösen, haben wir verschiedene Tools wie VMARKET erfunden, aber das Front-End muss noch VMs schreiben und sich auf Back-End-Daten verlassen, sodass die Effizienz immer noch nicht hoch ist.
Darüber hinaus kann das Backend nicht den starken Fokus ausstellen und sich somit auf die Entwicklung der Geschäftslogikschicht konzentrieren.
2.4 Einschränkungen der Front-End-Leistung
Wenn die Leistungsoptimierung nur am vorderen Ende durchgeführt wird, benötigen wir häufig eine Backend -Zusammenarbeit, um Funken zu erstellen. Aufgrund der Einschränkungen des Backend -Frameworks fällt es uns jedoch schwierig, Comet, BigPipe und andere technische Lösungen zu verwenden, um die Leistung zu optimieren.
Um einige der oben genannten Probleme zu lösen, haben wir viele Versuche unternommen und verschiedene Werkzeuge entwickelt, aber es gab nie viel Verbesserung, hauptsächlich, weil wir nur das von uns im Backend geteilte kleine Raum nutzen können. Nur wenn wir die vorderen und hinteren Enden wirklich trennen, können wir die oben genannten Probleme vollständig lösen.
3. Wie kann man die vorderen und hinteren Enden trennen?
Wie trennen Sie die Front- und Rückenenden? Tatsächlich gibt es im ersten Abschnitt eine Antwort:
Front-End: Verantwortlich für die Ansicht und Controller-Ebenen.
Backend: Verantwortlich für Modellschicht, Geschäftsverarbeitung/Daten usw.
Stellen Sie sich vor, wir können entscheiden, ob wir das Rendern auf dem Server gemäß der Szene synchronisieren oder JSON-Daten ausgeben können, wenn der Front-End den Controller meistert, das Rendern auf dem Server synchronisiert, und wir können auch Bigpipe, Comet, Socket usw. nach den Anforderungen der Präsentationsschicht problemlos durchführen. Es ist vollständig die von den Anforderungen bestimmte Verwendungsmethoden.
3.1 "Full Stack" -Entwicklung basierend auf NodeJs
Wenn Sie die Überlagerung der obigen Abbildung implementieren möchten, benötigen Sie zwangsläufig einen Webdienst, um uns zu erkennen, was wir vor und nach dem Backend tun. Daher gibt es den Titel "Full-Stack-Entwicklung basierend auf NodeJs".
Dieses Bild sieht einfach und leicht zu verstehen aus, hat es aber nicht ausprobiert und es wird viele Fragen geben.
Im Spa -Modus hat das Backend die erforderliche Datenschnittstelle bereitgestellt, und das View -Frontend kann bereits gesteuert werden. Warum die NodeJS -Schicht hinzufügen?
Wie wäre es mit einer weiteren Ebene?
Wenn Sie eine weitere Ebene hinzufügen, erhöhen Sie die Arbeitsbelastung des Front-Ends?
Das Hinzufügen einer weiteren Ebene führt zu einer anderen Risikoschicht. Wie kann man es brechen?
Nodejs kann etwas tun, warum brauchst du noch Java?
Es ist nicht einfach, diese Probleme klar zu erklären. Lassen Sie mich unten über meinen Verständnisprozess sprechen.
3.2 Warum eine Notenschicht hinzufügen?
In diesem Stadium entwickeln wir hauptsächlich das Backend MVC -Modell. Dieses Modell behindert ernsthaft die Effizienz der Front-End-Entwicklung und verhindert, dass sich das Back-End auf die Geschäftsentwicklung konzentriert.
Die Lösung besteht darin, das Front-End zu ermöglichen, die Controller-Ebene zu steuern, aber es ist schwierig, dies unter dem vorhandenen Technologiesystem zu tun, da es unmöglich ist, alle Frontends Java zu lernen, die Back-End-Entwicklungsumgebung zu installieren und VMs zu schreiben.
NodeJs können dieses Problem sehr gut lösen. Wir können das tun, was uns die Entwicklung zuvor geholfen hat, und alles scheint so natürlich.
3.3 Leistungsprobleme
Schichten beinhaltet die Kommunikation zwischen jeder Schicht, und es wird definitiv bestimmte Leistungsverluste geben. Eine angemessene Schichtung kann jedoch die Verantwortung klar und kollaborativ machen, was die Entwicklungseffizienz erheblich verbessern wird. Die durch Schichtungen verursachten Verluste werden in anderen Aspekten definitiv kompensiert.
Sobald wir uns für die Verbindung entscheiden, können wir die Verluste minimieren, indem wir Kommunikationsmethoden und Kommunikationsprotokolle optimieren.
Zum Beispiel:
Nachdem die Seite "Taobao-Babydetails" statisch ist, gibt es immer noch viele Informationen, die in Echtzeit wie Logistik, Werbeaktionen usw. erhalten werden müssen, da diese Informationen in verschiedenen Geschäftssystemen enthalten sind, das Front-End muss 5 oder 6 asynchrone Anfragen senden, um diese Inhalte zu erfüllen.
Mit NodeJS kann das Front-End diese 5 asynchronen Anfragen in NodeJs in den Vordergrund stellen und leicht BigPipe durchführen. Diese Optimierung kann die gesamte Rendering -Effizienz erheblich verbessern.
Sie denken vielleicht, dass es in Ordnung ist, 5 oder 6 asynchrone Anfragen auf den PC zu senden, aber auf der drahtlosen Seite ist es sehr teuer, eine HTTP -Anfrage auf dem Mobiltelefon des Kunden festzulegen. Mit dieser Optimierung wird die Leistung mehrmals verbessert.
Die Details von Taobao basieren auf der NodeJS -Optimierung. Wir sind in Arbeit. Nach dem Start werde ich den Optimierungsprozess teilen.
3.4 Hat die Front-End-Arbeitsbelastung zugenommen?
Im Vergleich zum Schneiden von Seiten/Demos muss es etwas mehr sein, aber es gibt Verknüpfungen und Kommunikation im aktuellen Modus. Dieser Prozess dauert viel Zeit, ist anfällig für Fehler und ist schwer zu pflegen.
Obwohl die Arbeitsbelastung ein wenig steigt, wird die allgemeine Entwicklungseffizienz erheblich verbessert.
Darüber hinaus können die Testkosten viel gespart werden. Die in der Vergangenheit entwickelten Schnittstellen richten sich alle auf die Präsentationsschicht, und es ist schwierig, Testfälle zu schreiben. Wenn die vordere und hintere Endtrennung durchgeführt wird, kann sogar der Test getrennt werden. Eine Gruppe von Personen ist auf das Testen der Schnittstelle spezialisiert, und die andere Gruppe von Personen konzentriert sich auf das Testen der Benutzeroberfläche (dieser Teil der Arbeit kann sogar durch Tools ersetzt werden).
3.5 Wie kann man die Risiken steuern, die durch Hinzufügen der Knotenschicht eingeführt werden?
Mit der groß angelegten Verwendung des Knotens werden Schüler aus der Abteilung System/Betrieb und Wartung/Sicherheit definitiv der Infrastrukturkonstruktion beitreten. Sie helfen uns, mögliche Probleme in jedem Link zu verbessern und die Stabilität der Abteilung sicherzustellen.
3.6 Knoten kann etwas tun, warum brauchst du noch Java?
Unsere ursprüngliche Absicht ist es, die vorderen und hinteren Enden zu trennen. Wenn wir dieses Problem berücksichtigen, wird es unserer ursprünglichen Absicht ein wenig widersprechen. Selbst wenn wir einen Knoten verwenden, um Java zu ersetzen, können wir nicht garantieren, dass wir keine Probleme haben, auf die wir heute begegnen, z. B. unklare Verantwortlichkeiten. Unser Ziel ist es, sich auf schichtbare Weise zu entwickeln, professionelle Menschen und sich darauf zu konzentrieren, professionelle Dinge zu tun. Die auf Java basierende Infrastruktur ist bereits sehr mächtig und stabil und eignet sich besser für die heutige Architektur.
4. Taobaos knotenbasierte Front-End-Trennung
Das obige Bild verstehe ich auf Taobaos Front-End- und Back-End-Trennung und -schicht basierend auf dem Knoten sowie auf dem Umfang der Verantwortlichkeiten des Knotens. Eine kurze Erklärung:
Das obere Ende ist der Server, was wir oft das Backend nennen. Für uns ist das Backend eine Sammlung von Schnittstellen, und der Server bietet verschiedene Schnittstellen für die Verwendung. Da es eine Knotenschicht gibt, besteht nicht erforderlich, welche Form die Form des Dienstes ist. Für die Backend -Entwicklung verwenden sie nur Schnittstellen, die sich um die Geschäftsordnung kümmern.
Der Server befindet sich unter der Knotenanwendung.
In der Knotenanwendung gibt es eine Modellschicht von Modellprofi, die mit dem Server kommuniziert. Diese Schicht wird hauptsächlich verwendet, um die Art und Weise zu glätten, wie wir verschiedene Schnittstellen aufrufen und einige Modelle, die von der Ansichtsschicht benötigt werden, einkapseln.
Die Knotenschicht kann auch einfach das ursprüngliche VMCommon, das TMS (unter Berufung auf das Taobao -Content -Management -System) und andere Anforderungen erreichen.
Welches Framework für die Knotenschicht zu verwenden ist, ist dem Entwickler zu entscheiden. Es wird jedoch empfohlen, eine Kombination aus Express + Xtemplate zu verwenden, die für die vorderen und hinteren Enden verwendet werden kann.
Jeder entscheidet, wie man einen Knoten benutzt, aber es ist aufregend, dass wir endlich den Knoten verwenden können, um die gewünschte Ausgabemethode einfach zu implementieren: JSON/JSONP/RESTFUR/HTML/BIGPIPE/COMET/SOCKKET/Synchron und asynchron. Es kann getan werden, was Sie wollen, und es wird ausschließlich auf Ihrem Szenario entschieden.
Die Browserschicht hat sich in unserer Architektur nicht verändert, und wir möchten Ihr vorheriges Verständnis der Entwicklung im Browser aufgrund der Einführung des Knotens nicht ändern.
Die Einführung des Knotens soll nur den Front-End-Steuerteil übergeben, der vom Front-End gesteuert werden sollte.
Wir haben zwei Projekte in der Entwicklung in diesem Modell. Obwohl sie noch nicht gestartet wurden, haben wir bereits die Süße in Bezug auf Entwicklungseffizienz und Leistungsoptimierung probiert.
5. Was müssen wir noch tun?
Integrieren Sie den Entwicklungsprozess von Node in den vorhandenen SCM -Prozess von Taobao.
Infrastrukturkonstruktion wie Sitzung, Logger und andere allgemeine Module.
Beste Entwicklungspraktiken
Online -Erfolgsgeschichten
Das Verständnis aller für das Konzept der Trennung von Knoten vorne und hinten endet
Sicherheit
Leistung
…
Es wird nicht zu viel Technologie geben, die Innovation und Forschung benötigt, und es gab viele fertige Akkumulation. Tatsächlich ist der Schlüssel die Öffnung einiger Prozesse und die Ansammlung allgemeiner Lösungen. Ich glaube, dass dieser Bereich mit mehr Projektpraktiken nach und nach zu einem stabilen Prozess wird.
6. "Midway Island"
Obwohl das Modell "Full-Stack-Entwicklung basierend auf NodeJS" -Modell spannend ist, gibt es immer noch viel zu tun, um die Aufbasierung der Vollstapel-Entwicklung in etwas zu verwandeln, das jeder akzeptieren kann. Unser fortlaufendes "Midway" -Projekt besteht darin, dieses Problem zu lösen. Obwohl wir nicht lange zuvor sind, kommen wir unserem Ziel immer näher! !