Erstellen einer skalierbaren ASP.NET MVC-Webanwendung

Ich bin gerade dabei, eine ASP.NET MVC-Webanwendung in C# zu erstellen.Erstellen einer skalierbaren ASP.NET MVC-Webanwendung

Ich möchte sicherstellen, dass diese Anwendung so gebaut wird, dass sie in der Zukunft skaliert werden kann, ohne dass ein größeres Re-Factoring erforderlich ist.

Ich bin ziemlich scharf darauf, eine Art von Warteschlange zu verwenden, um alle Schreibvorgänge in meine Datenbank zu buchen und einen Prozess zu haben, der diese Warteschlange asynchron abfragt, um das Update durchzuführen. Sobald diese Daten in die Datenbank zurückgeschrieben wurden, muss der Client mit den neuen Informationen aktualisiert werden. Dies hat zur Folge, dass der Prozess zum Zurückschreiben der Daten in die Datenbank aufgrund von Geschäftsregeln, die auf dem Server ausgeführt werden, eine kurze Zeit in Anspruch nehmen kann.

Meine Frage ist, was wäre der beste Weg, um das Update aus der Perspektive Client \ Browser zu behandeln.

Ich denke entlang der Linien der Entsendung der Daten zurück auf den Server und Hinzufügen der Daten in die Warteschlange und sofort eine Antwort an den Client senden, dann mit einer Frequenz abfragen, um die aktualisierten Daten zu erhalten. Irgendwelche Best Practices oder Muster hierzu würden geschätzt werden.

Auch in Bezug auf das Lesen von Daten aus der Datenbank würden Sie vorschlagen, bestimmte Techniken zu verwenden oder würde lesen direkt aus db ausreichend sein, mein Szenario gegeben.

Update Ich dachte, ich würde ein Update auf diesem, wie es schon eine Weile ist. Wir haben tatsächlich Windows Azure verwendet, aber die Lösung ist auch für andere Plattformen geeignet.

Wir haben die Windows Azure-Warteschlange verwendet, um Nachrichten \ Befehle zu veröffentlichen. Dies ist ein sehr schneller Prozess und kehrt sofort zurück. Wir haben dann eine Worker-Rolle, die diese Nachrichten in einem anderen Thread verarbeitet. Dies ermöglicht es uns, db writes \ updates auf der Web-Rolle in der Theorie zu minimieren, was es uns erlaubt, leichter zu skalieren.

Wir behandeln den Benutzer per E-Mail oder sogar im Hintergrund, je nachdem, um welche Art von Daten es sich handelt.

Quelle

2009-05-27 gsobocinski

Meine erste Frage mit dieser würde sein, warum möchten Sie Ihre Datenbank schreibt asynchron, wenn Sie dann Ihre Benutzer warten auf die Ergebnisse geschrieben werden? –

Mein Problem ist, dass es möglicherweise eine Geschäftsregel gibt, die für einen bestimmten Zeitraum ähnlich einem db-Trigger ausgeführt wird. Während dies für eine kleine Anzahl von Benutzern in Ordnung sein könnte, sehe ich dies als einen Flaschenhals, der möglicherweise dazu führen könnte, dass Benutzeranforderungen auf dem Client auslaufen, was ich vermeiden möchte. – gsobocinski

Nicht sicher, ob das hilft, aber warum haben Sie zum Beispiel keine automatische Aktualisierung auf der Seite alle 30 Sekunden. Das ist manchmal der Fall, wenn Newsfeeds auf Sportwebsites funktionieren. Die Seite wird alle x Minuten aktualisiert.

 
<meta http-equiv="refresh" content="120;url=index.aspx">

Quelle

2009-05-27 15:30:20 David

Danke, ich mag den Klang der Verwendung von so etwas. Ich werde es mir ansehen. – gsobocinski

Wahrscheinlich am besten, dies nicht zu tun, wenn Sie sich Sorgen um Serverlast machen. – Luke

Warum lassen Sie den Benutzer nicht manuell den Status der Anfrage abfragen? So wird Ihre typische E-Commerce-App implementiert. Wenn Sie etwas online kaufen, wird die Bestellung zur Erfüllung an eine Warteschlange gesendet. Nach der Übermittlung erhält der Benutzer eine "Danke für Ihre Bestellung" -Seite und einen Link, über den er den Status der Bestellung überprüfen kann. Der Benutzer kann den Link jederzeit aufrufen, um den Status zu überprüfen, ohne dass ein automatischer Abrufmechanismus erforderlich ist.

Ist Ihr Szenario so anders?

Quelle

2009-05-27 23:16:53 DSO

Danke, aber ich denke nicht, dass dies in die Anwendung passt. Es könnte nützlich sein, zu sagen, dass dies eher eine Geschäftszweig-App ist, bei der Benutzer nicht immer zurückgehen und den Status von etwas überprüfen müssen. Generell bevorzuge ich es, so viel wie möglich für den Benutzer zu automatisieren. – gsobocinski

@gsobocinski - Ich denke DSO macht einen guten Punkt. Wenn Sie Transaktionen haben, von denen der Benutzer erwartet, dass sie kurz sind, dann lassen Sie die Anfrage direkt die Datenbank aktualisieren und aktualisieren Sie sofort die Benutzeroberfläche. Lassen Sie den Benutzer für die Transaktionen, die eine Weile dauern können, dies jedoch wissen, und weisen Sie sie an, regelmäßig nach den Ergebnissen zu suchen. – mbeckish

Sorry in meiner vorherigen Antwort habe ich vielleicht missverstanden. Ich sprach von einer "Warteschlange" als etwas, das in einer SQL-DB gespeichert ist, aber es scheint, dass Sie beim Lesen Ihres Posts möglicherweise über eine separate Message-Queuing-Komponente wie MSMQ oder JMS sprechen?

Ich würde nie eine Nachrichtenwarteschlange in das Frontend zwischen einem Benutzer und Back-End SQL DB setzen. Warteschlangen sind für die Skalierung über die Zeit hinweg gut geeignet, was für Backend-Komponenten geeignet ist, bei denen Varianzen in den Verarbeitungszeiten akzeptabel sind (z. B. Auftragserfüllung) ... im Umgang mit Benutzern ist diese Abweichung normalerweise nicht akzeptabel.

Quelle

2009-05-28 17:49:54 DSO

Die Idee hinter der Verwendung der Nachrichtenwarteschlange bestand darin, den ASP.net-Worker-Prozess von jedem potenziell blockierenden I/O freizugeben, db schreibt in meinem Fall. Ich habe ein paar Artikel gelesen, die vorschlagen, dies zu verwenden, ist eine gute Methode, um Webanwendungen zu skalieren und entfernt einige Abhängigkeit zwischen dem Webfrontend und meiner Anwendungsebene. Natürlich müssten Sie etwas mit der Benutzeroberfläche machen, um die Tatsache zu ignorieren, dass Dinge in die Warteschlange gestellt werden, um sofort reagieren zu können, was mich wahrscheinlich eher in Richtung eines AJAX-ähnlichen Ansatzes treibt. Zum Beispiel auf einem Post mit einer Art "Bitte warten" Grafik. – gsobocinski

Während ich nicht weiß, ob ich der Logik des warum zustimme, weiß ich, dass etwas wie jQuery Ihr Leben viel leichter machen wird. Ich würde vorschlagen, eine RESTful-Web-API zu erstellen, die von Ihrem clientseitigen Code konsumiert wird. Möchten Sie beispielsweise eine neue Bestellung an das System senden und den Kunden darauf reagieren lassen? Machen Sie einen Post auf www.mystore.com/order/create und lassen Sie den neuen URI zurück, um auf die Bestellung (d. H. Bestellnummer) als URI (www.mystore.com/order/1234) zuzugreifen. Diese Antwort wird dann im Client-Code gespeichert und jQuery call wird eingerichtet, um nach einer Antwort zu suchen oder die Abfrage nach einem Fehler zu stoppen.

Für weitere Informationen überprüfen Sie this Wikipedia article auf das Konzept von REST.

Zusätzlich können Sie die Reactive Extensions for .NET und innerhalb von diesem prüfen Sie das RxJS-Unterprojekt, das einige ziemlich glatte Möglichkeiten der Handhabung mit dem Abrufproblem hat, ohne dass Sie den Abrufcode selbst schreiben. Lustige Dinge zum Spielen!

Quelle

2010-11-09 02:21:34

Vielleicht können Sie der Benutzeroberfläche einen Bereich für ausstehende Transaktionen hinzufügen. Wenn Sie eine Transaktion in eine Warteschlange stellen, fügen Sie sie der Liste "Ausstehende Transaktionen" des Benutzers hinzu.

Wenn dies abgeschlossen ist, zeigen Sie in der Liste der ausstehenden Transaktionen des Benutzers an, wann sie das nächste Mal eine neue Seite anfordern.

Sie können festlegen, dass eine abgeschlossene Transaktion so lange aufgelistet bleibt, bis der Benutzer darauf klickt oder für eine bestimmte Zeitspanne.

Quelle

2010-11-09 02:57:13 mbeckish

Erstellen einer skalierbaren ASP.NET MVC-Webanwendung

Antwort

Verwandte Themen