10 Aspekte, die beim Entwurf und Aufbau einer umfangreichen Website-Architektur berücksichtigt werden müssen

Wir diskutieren hier nicht über PHP-, JSP- oder .NET-Umgebungen. Wir betrachten das Problem aus der Perspektive der Architektur. Die Implementierungssprache ist kein Problem. Der Vorteil der Sprache liegt eher in der Implementierung als in der Qualität. Egal, welche Sprache Sie wählen, die Architektur ist etwas, mit dem Sie sich auseinandersetzen müssen.

1. Verarbeitung großer Datenmengen

Wie wir alle wissen, ist die Datenmenge bei einigen relativ kleinen Sites nicht sehr groß. Auswählen und Aktualisieren können die Probleme lösen, mit denen wir konfrontiert sind. Die Belastung selbst ist nicht sehr groß und kann durch das Hinzufügen von höchstens einigen Indizes gelöst werden. Bei großen Websites kann das tägliche Datenvolumen mehrere Millionen betragen. Wenn eine Viele-zu-viele-Beziehung nicht gut konzipiert ist, gibt es im Anfangsstadium keine Probleme, aber mit zunehmender Benutzerzahl steigt die Datenmenge exponentiell an. Derzeit ist der Aufwand für die Auswahl und Aktualisierung einer Tabelle (ganz zu schweigen von gemeinsamen Abfragen mehrerer Tabellen) sehr hoch.

2. Gleichzeitige Datenverarbeitung

Irgendwann hat der CTO von 2.0 ein Zauberschwert: den Cache. Auch beim Caching stellt eine hohe Parallelität und Verarbeitung ein großes Problem dar. Der Cache wird global für die gesamte Anwendung freigegeben. Wenn wir jedoch Änderungen vornehmen und zwei oder mehr Anfragen gleichzeitig eine Aktualisierung des Caches anfordern, stürzt die Anwendung ab. Zu diesem Zeitpunkt sind eine gute Strategie für die parallele Datenverarbeitung und Caching-Strategie erforderlich.

Darüber hinaus gibt es das Problem von Datenbank-Deadlocks. Normalerweise spüren wir das vielleicht nicht, aber unter Bedingungen mit hoher Parallelität ist die Wahrscheinlichkeit eines Deadlocks sehr hoch, und der Festplattencache stellt ein großes Problem dar.

3. Probleme mit der Dateispeicherung

Bei einigen 2.0-Sites, die Datei-Uploads unterstützen, sind wir zwar dankbar dafür, dass die Festplattenkapazität immer größer wird, wir sollten uns jedoch mehr Gedanken darüber machen, wie Dateien gespeichert und effektiv indiziert werden sollten. Eine gängige Lösung besteht darin, Dateien nach Datum und Typ zu speichern. Wenn jedoch das Dateivolumen sehr groß ist und eine Festplatte 500 GB an unwichtigen Dateien speichert, stellt die E/A der Festplatte bei Wartung und Nutzung ein großes Problem dar. Selbst wenn Ihre Bandbreite ausreicht, reagiert Ihre Festplatte möglicherweise nicht. Wenn zu diesem Zeitpunkt ein Upload erfolgt, ist die Festplatte schnell voll.

Vielleicht kann die Verwendung von RAID und dedizierten Speicherservern das aktuelle Problem lösen, aber es besteht auch das Problem des Zugriffs von verschiedenen Standorten aus. Vielleicht steht unser Server in Peking, aber wie können wir die Zugriffsgeschwindigkeit in Yunnan oder Xinjiang-Tibet lösen? Wenn wir verteilten Speicher verwenden, wie sollten wir unseren Dateiindex und unsere Architektur planen?

Wir müssen also zugeben, dass die Dateispeicherung ein sehr schwieriges Problem ist.

4. Verarbeitung von Datenbeziehungen

Wir können problemlos eine Datenbank planen, die der dritten Normalform entspricht, die voller Viele-zu-viele-Beziehungen ist und GUID als Ersatz für INDENTIFY COLUMN verwenden kann. Im 2.0-Zeitalter voller Viele-zu-viele-Beziehungen ist die dritte Normalform jedoch die erste, die aufgegeben werden sollte. Es ist notwendig, gemeinsame Abfragen mehrerer Tabellen effektiv zu minimieren.

5. Probleme bei der Datenindizierung

Wie wir alle wissen, ist die Indizierung der bequemste, billigste und einfachste Weg, die Effizienz von Datenbankabfragen zu verbessern. Bei hohen UPDATE-Aufkommen sind die Kosten für das Aktualisieren und Löschen jedoch unvorstellbar hoch. Ich bin auf eine Situation gestoßen, in der die Aktualisierung eines fokussierten Indexes 10 Minuten dauerte. Für die Site ist das im Grunde unerträglich.

Indizierung und Aktualisierung sind natürliche Feinde. Die Probleme A, D und E sind Aspekte, die wir bei der Architektur berücksichtigen müssen, und sie sind möglicherweise auch die Aspekte, die am meisten Zeit in Anspruch nehmen.

6. Verteilte Verarbeitung

Aufgrund der hohen Interaktivität ist der Effekt der CDN-Implementierung bei 2.0-Websites praktisch gleich Null. Der Inhalt wird in Echtzeit aktualisiert und wir gehen routinemäßig damit um. Um die Zugriffsgeschwindigkeit an verschiedenen Orten sicherzustellen, müssen wir uns einem großen Problem stellen: Wie können wir die Datensynchronisierung und -aktualisierung effektiv realisieren? Die Echtzeitkommunikation zwischen Servern an verschiedenen Orten ist ein Problem, das berücksichtigt werden muss.

7. Analyse der Vor- und Nachteile von Ajax

AJAX ist der Grund für Erfolg und Misserfolg. AJAX ist zum Mainstream-Trend geworden und plötzlich stellen wir fest, dass Posten und Abrufen auf XMLHTTP-Basis so einfach sind. Der Client ruft Daten ab oder sendet sie an den Server, und der Server gibt die Daten nach Erhalt der Datenanforderung zurück. Dies ist eine normale AJAX-Anforderung. Wenn wir jedoch bei der AJAX-Verarbeitung ein Tool zur Paketerfassung verwenden, sind die Datenrückgabe und -verarbeitung auf einen Blick klar. Für einige AJAX-Anfragen, die viel Rechenleistung erfordern, können wir einen Paketdispatcher erstellen, der einen Webserver problemlos lahmlegen kann.

8. Analyse der Datensicherheit

Beim HTTP-Protokoll werden Datenpakete im Klartext übertragen. Vielleicht können wir sagen, dass wir Verschlüsselung verwenden können, aber beim G-Problem kann der Verschlüsselungsprozess im Klartext erfolgen (wir wissen beispielsweise, dass QQ seine Verschlüsselung leicht bestimmen und effektiv eine Verschlüsselungs- und Entschlüsselungsmethode schreiben kann, die mit dieser übereinstimmt). Wenn der Verkehr auf Ihrer Site nicht sehr groß ist, kümmert sich niemand um Sie, aber wenn der Verkehr zunimmt, werden die sogenannten Plug-Ins und die sogenannten Massennachrichten nacheinander erscheinen (Sie können die Hinweise in den Massennachrichten von QQ am Anfang sehen). Vielleicht können wir mit Genugtuung sagen, dass wir dies mit einem Urteilsvermögen auf höherer Ebene oder sogar mit HTTPS erreichen können. Bitte beachten Sie, dass Sie bei der Durchführung dieser Prozesse enorme Datenbank-, IO- und CPU-Kosten zahlen. Bei manchen Massennachrichten ist dies grundsätzlich nicht möglich. Der Autor kann bereits Gruppennachrichten auf Baidu Space und QQ Space realisieren. Wenn jeder bereit ist, es zu versuchen, ist es eigentlich gar nicht so schwierig.

9. Probleme bei der Datensynchronisierung und Clusterverarbeitung

Wenn einer unserer Datenbankserver überlastet ist, müssen wir eine datenbankbasierte Belastung und Clusterbildung durchführen. Dies ist möglicherweise das problematischste Problem. Die Datenübertragung über das Netzwerk kann je nach Datenbankdesign zu Datenverzögerungen führen. Dies ist ein schreckliches und unvermeidliches Problem. In diesem Fall müssen wir andere Mittel einsetzen, um eine effektive Interaktion innerhalb der Verzögerung von einigen Sekunden oder sogar einigen Minuten sicherzustellen. Beispielsweise Daten-Hashing, Segmentierung, Inhaltsverarbeitung und andere Probleme.

10. Datenaustauschkanäle und OPENAPI-Trends

OpenAPI ist zu einem unvermeidlichen Trend geworden. Von Google, Facebook, Myspace bis hin zu inländischen Campussen – alle denken über dieses Thema nach. Es kann Benutzer effektiver binden und mehr Interesse bei den Benutzern wecken und mehr Menschen ermöglichen, Ihnen bei der effektivsten Entwicklung zu helfen. Zu diesem Zeitpunkt sind eine effektive Plattform für den Datenaustausch und eine offene Datenplattform unverzichtbar geworden. Die Gewährleistung der Sicherheit und Leistung von Daten unter offenen Schnittstellen ist ein weiteres Thema, das wir ernsthaft in Betracht ziehen müssen.