Die traditionelle Software -Stapelstruktur von Taobao -Online -Anwendungen ist Nginx + Geschwindigkeit + Java, d. H.:
In diesem System leitet NGINX die Anforderung an eine Java -Anwendung weiter, die die Transaktion übernimmt und die Daten mithilfe einer Geschwindigkeitsvorlage in die endgültige Seite verwaltet.
Nachdem wir Node.js eingeführt haben, werden wir zwangsläufig die folgenden Probleme haben:
So entwerfen Sie die Topologiestruktur des Technologiestapels und wie Sie die Bereitstellungsmethode auswählen. Wird sie als wissenschaftlich und vernünftig angesehen? Wie kann nach Abschluss des Projekts den Verkehr teilnehmen, der bequem und schnell für den Betrieb und die Wartung ist? Wie kann man bei Online -Problemen so bald wie möglich Gefahr beseitigen und mehr Verluste vermeiden? Wie kann ich die Gesundheit der Anwendung sicherstellen und sie auf der Lastausgleichsplanungsebene verwalten? Systemtopologie
Nach unserem Denken und unserer Praxis über die Trennung von Vorder- und Rücksenden (ii) - basierend auf der Vorlageerforschung der Vorder- und Rücksenden muss die Geschwindigkeit durch Knoten.js ersetzt werden, so dass diese Struktur wird:
Dies ist natürlich das ideale Ziel. Die erste Einführung der Node.js -Schicht im traditionellen Stapel ist jedoch schließlich ein neuer Versuch. Um sicher zu sein, haben wir beschlossen, nur neue Technologien auf der Favoriten -Seite (shoucang.taobao.com/item_collect.htm) unserer Favoriten zu ermöglichen, während andere Seiten weiterhin traditionelle Lösungen verwenden. Das heißt, Nginx bestimmt den Seitentyp der Anforderung und bestimmt, ob die Anforderung an node.js oder java weitergeleitet werden soll. Die endgültige Struktur wurde also:
Einsatzplan
Die obige Struktur scheint in Ordnung zu sein, aber tatsächlich wartet das neue Problem immer noch auf die Front. In der traditionellen Struktur werden Nginx und Java auf demselben Server bereitgestellt. Nginx hört auf Port 80 und kommuniziert mit Java, die Port 7001 auf dem hohen Bit anhört. Jetzt, da Node.js eingeführt wird, ist ein neuer Prozess erforderlich, der einen Höranschluss ausführen muss. Sollten Node.js auf derselben Maschine mit Nginx + Java oder Node.js in einem separaten Cluster bereitgestellt werden?
Vergleichen wir die Eigenschaften der beiden Methoden:
Taobao -Favoriten sind eine Anwendung mit einem täglichen durchschnittlichen PV von Millionen von Millionen, was äußerst hohe Anforderungen an Stabilität hat (tatsächlich ist die Online -Instabilität eines Produkts inakzeptabel). Wenn Sie dieselbe Cluster -Bereitstellungslösung übernehmen, müssen Sie nur einmal Dateien verteilen und zweimal neu starten, um die Version abzuschließen. Falls Sie zurückrollen müssen, müssen Sie das Basispaket nur einmal bedienen. In Bezug auf die Leistung hat die gleiche Cluster -Bereitstellung auch einige theoretische Vorteile (obwohl die Switch -Bandbreite und Latenz des Intranet sehr optimistisch sind). In Bezug auf die Eins-zu-Viele- oder viele-zu-Eins-Beziehung kann sie theoretisch vom Server theoretisch besser genutzt werden, aber im Vergleich zu den Stabilitätsanforderungen ist dieser Punkt nicht so dringend zu lösen. Bei der Transformation von Favoriten haben wir die gleiche Cluster -Bereitstellungslösung gewählt.
Graustufen
Um die maximale Stabilität zu gewährleisten, hat diese Transformation den Geschwindigkeitscode nicht direkt vollständig entfernt. Es gibt fast 100 Server im Anwendungscluster. Wir verwenden den Server als Granularität und führen allmählich den Verkehr ein. Mit anderen Worten, obwohl Java + Node.js -Prozesse auf allen Servern ausgeführt werden, stellt fest, ob es entsprechende Weiterleitungsregeln für Nginx vorliegt, ob die Anfrage zur Erlangung der Babysammlung auf diesem Server über Node.Js. verarbeitet wird. Die Konfiguration von Nginx lautet:
location = "/item_collect.htm" {proxy_pass http://127.0.0.1:6001; # Node.js verarbeiten Hörport}Nur Server, die diese Nginx -Regel hinzugefügt haben, lassen die ninx.js die entsprechende Anforderung verarbeiten. Durch die NGINX -Konfiguration ist es sehr bequem und schnell und verringert den Graustufenverkehr, und die Kosten sind sehr niedrig. Wenn Sie auf Probleme stoßen, können Sie die NGINX -Konfiguration direkt zurückrollen und sofort zur traditionellen Technologiestapelstruktur zurückkehren, um die Gefahr zu lindern.
Als wir zum ersten Mal veröffentlicht wurden, haben wir diese Regel nur auf zwei Servern aktiviert, was bedeutet, dass weniger als 2% des Online -Datenverkehrs in Node.js verarbeitet werden und die Anfragen für den verbleibenden Verkehr weiterhin durch Geschwindigkeit gerendert werden. In Zukunft wird der Verkehr je nach Situation allmählich erhöht, und schließlich werden in der dritten Woche alle Server aktiviert. Zu diesem Zeitpunkt werden die Produktsammlungsseiten mit 100% Verkehr in der Produktionsumgebung von Node.js gerendert (Sie können den Quellcode überprüfen, um nach dem Schlüsselwort node.js zu suchen).
ändern
Der Graustufenprozess ist nicht glatt. Bevor ich den Fluss vollständig abschneidet, stieß ich auf einige Probleme, ob groß oder klein. Der größte Teil des Unternehmens bezieht sich auf bestimmtes Geschäft, und es ist eine Lernung wert, eine Falle in Bezug auf technische Details.
Gesundheitsprüfung
In der herkömmlichen Architektur wird das Lastausgleichsplanungssystem jede Sekunde für eine bestimmte URL auf Port 80 jedes Servers eine get -Anforderung einleiten und feststellen, ob der Server normal funktioniert, basierend darauf, ob der zurückgegebene HTTP -Statuscode 200 beträgt. Wenn das Zeitübergang nach 1S angefordert ist oder der HTTP -Statuscode nicht 200 ist, wird kein Datenverkehr auf den Server eingeführt, um Online -Probleme zu vermeiden.
Der Pfad zu dieser Anforderung ist Nginx -> Java -> Nginx, was bedeutet, dass Nginx und Java dieses Servers in einem gesunden Zustand sind, solange 200 zurückgegeben werden. Nach der Einführung von node.js wird dieser Pfad zu nginx -> node.js -> java -> node.js -> nginx. Der entsprechende Code ist:
var http = required ('http'); app.get ('/status.taobao', function (req, res) {http.get ({host: '127.1', port: 7001, path: '/status.taobao'}, function (res) {res.send (res.statuscode);}). });Während des Testprozesses wurde jedoch festgestellt, dass es einige Sekunden oder sogar zehn Sekunden dauerte, bis Node.js solche Anfragen weiterleitet, bis die Java -Mannschaft alle sechs oder sieben Mal einmal zurückkehrte. Dies führt dazu, dass das Lastausgleichsplanungssystem der Ansicht ist, dass auf dem Server eine Abnormalität aufgetreten ist und dann den Verkehr abschneidet. Tatsächlich kann der Server jedoch normal funktionieren. Dies ist offensichtlich ein großes Problem.
Nach einer Suche stellte ich fest, dass Node.js standardmäßig die HTTP Agent zum Erstellen von HTTP -Verbindungen verwendet. Diese Klasse implementiert einen Socket -Verbindungspool. Die Standard-Obergrenze der Anzahl der Verbindungen für jedes Host + -Portpaar beträgt 5. Gleichzeitig umfassen die von HTTP Agent eingeleiteten Anforderungen standardmäßig Connection: Keep-Alive , was dazu führt, dass die zurückgegebene Verbindung nicht rechtzeitig freigegeben wird, und die später eingeleiteten Anfragen können nur nachgefragt werden.
Es gibt drei letzte Lösungen:
Deaktivieren Sie HTTP Agent , dh zusätzliche Parameter agent: false beim Aufrufen der get -Methode, und der endgültige Code lautet:
var http = required ('http'); app.get ('/status.taobao', function (req, res) {http.get ({host: '127.1', port: 7001, agent: false, path: '/status.taobao'}, function (res) {res.send (res.statuscode);}). res.send (404); Stellen Sie die obere Grenze der globalen Socket -Anzahl von http -Objekten fest:
http.globalagent.maxsockets = 1000;
Wenn die Anfrage zurücksetzt, ist sie zeitnah und proaktiv unterbrochen:
http.get (Optionen, Funktion (res) {}). On ("Socket", Funktion (Socket) {Socket.Emit ("AgentRemove"); // Hören Sie Socket -Ereignisse und Dispatch AgentRemove -Ereignisse im Rückruf});In der Praxis haben wir die erste Methode gewählt. Nach dieser Anpassung wurden bei der Gesundheitsprüfung keine weiteren Probleme gefunden.
kombinieren
Die Praxis, Node.js mit traditionellen Geschäftsszenarien zu kombinieren, hat gerade erst begonnen, und es gibt immer noch viele Optimierungspunkte, die es wert sind, Tiefe zu untersuchen. Können Sie beispielsweise nach der vollständig zentralisierten Java -Anwendungen den Test der Cluster -Bereitstellung durchführen, um die Serverauslastung zu verbessern? Oder können die Veröffentlichungs- und Rollback -Methoden flexibler und kontrollierbarer sein? Alle Details sind weitere Recherchen wert.