Η λίστα ελέγχου παραγωγής Ultimate Node.js

Κάνετε αυτό το πράγμα κόμβου στην παραγωγή; Ας δούμε μερικά κοινά λάθη που κάνουν οι χρήστες να τρέχουν το Node στην παραγωγή (προέρχονται κατευθείαν από τα δικά μου έργα - όπως το codedamn) και πώς μπορούν να μετριαστούν.

Μπορείτε να το χρησιμοποιήσετε ως λίστα ελέγχου κατά την παραγωγή κατά την ανάπτυξη εφαρμογών Node. Δεδομένου ότι πρόκειται για ένα προϊόν έτοιμο για πρακτικές , πολλά από αυτά δεν θα ισχύουν όταν αναπτύσσετε εφαρμογές στο τοπικό σας σύστημα.

Εκτέλεση κόμβου σε λειτουργία συμπλέγματος / ξεχωριστές διαδικασίες κόμβου

Θυμηθείτε ότι ο κόμβος είναι ένα νήμα. Μπορεί να αναθέσει πολλά πράγματα (όπως αιτήματα HTTP και ανάγνωση / εγγραφή συστήματος αρχείων) στο λειτουργικό σύστημα που το χειρίζεται σε περιβάλλον πολλαπλών νημάτων. Ωστόσο, ο κώδικας που γράφετε, η λογική της εφαρμογής, εκτελείται πάντα σε ένα νήμα.

Τρέχοντας σε ένα νήμα, η διαδικασία του κόμβου σας περιορίζεται πάντα σε έναν μόνο πυρήνα στο μηχάνημά σας. Επομένως, εάν έχετε διακομιστή με πολλούς πυρήνες, σπαταλάτε τη δύναμη υπολογισμού που εκτελεί τον κόμβο μόνο μία φορά στον διακομιστή σας.

Τι σημαίνει "εκτέλεση κόμβου μόνο μία φορά"; Βλέπετε, τα λειτουργικά συστήματα διαθέτουν έναν προγραμματιστή ενσωματωμένο σε αυτά, ο οποίος είναι υπεύθυνος για τον τρόπο διανομής της εκτέλεσης των διεργασιών σε όλες τις CPU του μηχανήματος. Όταν εκτελείτε μόνο 2 διαδικασίες σε ένα μηχάνημα 2 πυρήνων, το λειτουργικό σύστημα καθορίζει ότι είναι καλύτερο να εκτελέσετε και τις δύο διαδικασίες σε ξεχωριστούς πυρήνες για να συμπιέσετε τη μέγιστη απόδοση.

Ένα παρόμοιο πράγμα πρέπει να γίνει με το Node. Έχετε δύο επιλογές σε αυτό το σημείο:

  1. Εκτέλεση κόμβου σε λειτουργία συμπλέγματος - Η λειτουργία συμπλέγματος είναι μια αρχιτεκτονική που ενσωματώνεται στον κόμβο. Με απλά λόγια, ο Node διαχωρίζει περισσότερες διαδικασίες από μόνος του και διανέμει φορτίο μέσω μιας μόνο κύριας διαδικασίας.
  2. Εκτελέστε ανεξάρτητες διεργασίες κόμβου - Αυτή η επιλογή είναι ελαφρώς διαφορετική από τα παραπάνω, με την έννοια ότι δεν έχετε πλέον μια κύρια διαδικασία ελέγχου των θυγατρικών διαδικασιών κόμβου. Αυτό σημαίνει ότι όταν δημιουργείτε διαφορετικές διεργασίες κόμβου, θα εκτελούνται εντελώς ανεξάρτητα το ένα από το άλλο. Χωρίς κοινόχρηστη μνήμη, χωρίς IPC, χωρίς επικοινωνία, ήχο.

Σύμφωνα με μια απάντηση στο stackoverflow, η τελευταία (σημείο 2) αποδίδει πολύ καλύτερη από την πρώτη (σημείο 1), αλλά είναι λίγο πιο δύσκολο να ρυθμιστεί.

Γιατί; Επειδή σε μια εφαρμογή Node, όχι μόνο υπάρχει λογική εφαρμογής, αλλά σχεδόν πάντα όταν ρυθμίζετε διακομιστές σε κώδικα κόμβου, πρέπει να δεσμεύσετε θύρες. Και μια βάση κώδικα μιας εφαρμογής δεν μπορεί να συνδέσει την ίδια θύρα δύο φορές στο ίδιο λειτουργικό σύστημα.

Αυτό το πρόβλημα, ωστόσο, είναι εύκολα επιλύσιμο. Μεταβλητές περιβάλλοντος, κοντέινερ Docker, διακομιστής μεσολάβησης NGiNX και ούτω καθεξής είναι μερικές από τις λύσεις για αυτό.

Βαθμός που περιορίζει τα τελικά σημεία σας

Ας το παραδεχτούμε. Δεν έχουν όλοι οι καλύτεροι προθέσεις για την αρχιτεκτονική σας. Σίγουρα, επιθέσεις όπως το DDoS είναι απλά πολύ περίπλοκες για τον μετριασμό, και ακόμη και γίγαντες όπως το GitHub κατεβαίνουν όταν συμβαίνει κάτι τέτοιο.

Αλλά το λιγότερο που μπορείτε να κάνετε είναι να αποτρέψετε ένα script-kiddie να καταργήσει τον διακομιστή σας μόνο και μόνο επειδή έχετε ένα ακριβό τελικό σημείο API που εκτίθεται από τον διακομιστή σας χωρίς κανένα περιορισμό τιμών.

Εάν χρησιμοποιείτε το Express with Node, υπάρχουν 2 όμορφα πακέτα που λειτουργούν απρόσκοπτα μαζί για να αξιολογήσουν την οριακή κυκλοφορία στο Layer 7:

  1. Όριο ταχείας τιμής - //www.npmjs.com/package/express-rate-limit
  2. Express Slow Down - //www.npmjs.com/package/express-slow-down

Το Express Slow Down προσθέτει πραγματικά σταδιακά καθυστέρηση στα αιτήματά σας αντί να τα απορρίψει. Με αυτόν τον τρόπο, οι νόμιμοι χρήστες, εάν αυτοί κατά λάθος DDoS (σούπερ δραστηριότητα κάνοντας κλικ στα κουμπιά εδώ και εκεί), απλώς επιβραδύνονται και δεν περιορίζονται στην τιμή.

Από την άλλη πλευρά, εάν υπάρχει σενάριο-παιδάκι που εκτελεί δέσμες ενεργειών για την κατάργηση του διακομιστή, ο περιορισμός ταχύτητας Express παρακολουθεί και περιορίζει το συγκεκριμένο ποσοστό χρήστη, ανάλογα με την IP χρήστη, τον λογαριασμό χρήστη ή οτιδήποτε άλλο θέλετε

Ο περιορισμός των τιμών θα μπορούσε (πρέπει!) Να εφαρμοστεί και στο Layer 4 (Layer 4 σημαίνει αποκλεισμός της κυκλοφορίας πριν ανακαλύψετε τα περιεχόμενά του - HTTP) μέσω της διεύθυνσης IP. Εάν θέλετε, μπορείτε να ρυθμίσετε έναν κανόνα NGiNX που αποκλείει την κυκλοφορία στο επίπεδο 4 και απορρίπτει την πλημμύρα της κυκλοφορίας που προέρχεται από ένα μόνο IP, εξοικονομώντας έτσι τις διαδικασίες του διακομιστή σας από συντριπτική.

Χρησιμοποιήστε έναν διακομιστή frontend για τερματισμό SSL

Ο κόμβος παρέχει δωρεάν υποστήριξη για χειραψίες SSL με το πρόγραμμα περιήγησης χρησιμοποιώντας τη httpsμονάδα διακομιστή σε συνδυασμό με τα απαιτούμενα πιστοποιητικά SSL.

Αλλά ας είμαστε ειλικρινείς εδώ, ούτως ή άλλως, η αίτησή σας δεν πρέπει να ασχολείται με το SSL. Αυτό δεν πρέπει να κάνει η λογική της εφαρμογής. Ο κωδικός κόμβου σας θα πρέπει να είναι υπεύθυνος μόνο για το τι συμβαίνει με το αίτημα και όχι για την προεπεξεργασία και μετά την επεξεργασία των δεδομένων που εισέρχονται και εξέρχονται από τον διακομιστή σας.

Ο τερματισμός SSL αναφέρεται στη μετατροπή επισκεψιμότητας από HTTPS σε HTTP. Και υπάρχουν πολύ καλύτερα διαθέσιμα εργαλεία από το Node για αυτό. Συνιστώ NGiNX ή HAProxy για αυτό. Και οι δύο διαθέτουν δωρεάν εκδόσεις που ολοκληρώνουν τη δουλειά και εκφορτώνουν τον τερματισμό SSL από το Node.

Χρησιμοποιήστε έναν διακομιστή frontend για στατική προβολή αρχείων

Και πάλι, αντί να χρησιμοποιείτε ενσωματωμένες μεθόδους, όπως express.staticη εξυπηρέτηση στατικών αρχείων, χρησιμοποιήστε διακομιστές μεσολάβησης αντίστροφου διακομιστή μεσολάβησης, όπως το NGiNX, για την εξυπηρέτηση στατικών αρχείων από δίσκο.

Πρώτα απ 'όλα, το NGiNX μπορεί να το κάνει γρηγορότερα από το Node (επειδή είναι κατασκευασμένο από το μηδέν για να κάνει μόνο αυτό). Αλλά εκφορτώνει επίσης την εξυπηρέτηση αρχείων από μια διαδικασία κόμβου ενός νήματος που θα μπορούσε να χρησιμοποιήσει τους κύκλους ρολογιού σε κάτι καλύτερο.

Όχι μόνο αυτό - οι διακομιστές μεσολάβησης frontend όπως το NGiNX μπορούν επίσης να σας βοηθήσουν να παραδώσετε περιεχόμενο πιο γρήγορα χρησιμοποιώντας τη συμπίεση GZIP. Μπορείτε επίσης να ορίσετε κεφαλίδες λήξης, δεδομένα προσωρινής μνήμης και πολλά άλλα, κάτι που δεν πρέπει να περιμένουμε από τον κόμβο (ωστόσο, ο κόμβος μπορεί να το κάνει ακόμα).

Διαμόρφωση χειρισμού σφαλμάτων

Ο σωστός χειρισμός σφαλμάτων μπορεί να σας σώσει από ώρες εντοπισμού σφαλμάτων και προσπαθώντας να αναπαραγάγετε δύσκολα σφάλματα. Στον διακομιστή, είναι ιδιαίτερα εύκολο να ρυθμίσετε την αρχιτεκτονική για το χειρισμό σφαλμάτων επειδή είστε αυτός που το εκτελείτε. Προτείνω εργαλεία όπως το Sentry with Node που καταγράφει, αναφέρει και σας στέλνει μηνύματα ηλεκτρονικού ταχυδρομείου κάθε φορά που ο διακομιστής διακόπτεται λόγω σφάλματος στον πηγαίο κώδικα.

Μόλις τεθεί σε ισχύ, τώρα είναι καιρός να κάνετε επανεκκίνηση του διακομιστή όταν διακόπτεται, οπότε ολόκληρος ο ιστότοπος δεν απενεργοποιείται μόνο για ώρες έως ότου τον καταργήσετε ξανά.

Για αυτό, μπορείτε να χρησιμοποιήσετε έναν διαχειριστή διεργασιών όπως το PM2. Ή ακόμα καλύτερα, χρησιμοποιήστε ένα περιβάλλον κοντέινερ που έχει αγκυροβοληθεί με πολιτικές όπως restart: alwaysμε τη σωστή μνήμη και ρύθμιση ορίων δίσκου.

Η ρύθμιση Docker διασφαλίζει ότι ακόμη και αν το κοντέινερ σας εκτελείται σε OME, η διαδικασία περιστρέφεται ξανά (κάτι που ενδέχεται να μην συμβαίνει σε περιβάλλον PM2, καθώς το λειτουργικό σύστημα μπορεί να σκοτώσει το PM2 εάν υπάρχει διαρροή μνήμης κάπου σε μια διαδικασία που εκτελείται).

Ρυθμίστε σωστά τα αρχεία καταγραφής

Όλες οι απαντήσεις βρίσκονται στα αρχεία καταγραφής. Διακοπές διακομιστή, σφάλματα διακομιστή, ύποπτη συμπεριφορά χρήστη κ.λπ. Για αυτό, πρέπει να βεβαιωθείτε ότι:

  1. Κάθε προσπάθεια αιτήματος καταγράφεται με τη διεύθυνση IP / τη μέθοδο αιτήματος / πρόσβαση στη διαδρομή, βασικά όσες περισσότερες πληροφορίες μπορείτε να καταγράψετε (εκτός από ιδιωτικές πληροφορίες όπως κωδικούς πρόσβασης και πληροφορίες πιστωτικών καρτών, φυσικά)
  2. Αυτό μπορεί να επιτευχθεί μέσω του πακέτου morgan
  3. Ρύθμιση ροής αρχείων καταγράφει παραγωγή αντί για έξοδο κονσόλας. Αυτό είναι πιο γρήγορο, πιο εύκολο στην προβολή και σας επιτρέπει να εξάγετε αρχεία καταγραφής σε διαδικτυακές υπηρεσίες προβολής αρχείων καταγραφής.
  4. Δεν έχουν όλα τα μηνύματα καταγραφής το ίδιο βάρος. Ορισμένα αρχεία καταγραφής υπάρχουν μόνο για εντοπισμό σφαλμάτων, ενώ εάν υπάρχουν, ενδέχεται να υποδηλώνει μια κατάσταση παντελονιού (όπως μια εισβολή διακομιστή ή μη εξουσιοδοτημένη πρόσβαση). Χρησιμοποιήστε το winston-logger για την καταγραφή διαφορετικών επιπέδων αρχείων καταγραφής.
  5. Ρυθμίστε την περιστροφή του αρχείου καταγραφής, έτσι ώστε να μην λαμβάνετε μέγεθος καταγραφής σε GB μετά από περίπου ένα μήνα, όταν βλέπετε το διακομιστή.
  6. GZIP τα αρχεία καταγραφής σας μετά από περιστροφή. Το κείμενο είναι φθηνό και είναι εξαιρετικά συμπιέσιμο και εύκολο στην αποθήκευση. Δεν θα πρέπει ποτέ να αντιμετωπίζετε πρόβλημα με αρχεία καταγραφής κειμένου, εφόσον είναι συμπιεσμένα και εκτελείτε διακομιστή με αξιοπρεπή χώρο στο δίσκο (25 GB +).

συμπέρασμα

Είναι εύκολο να σημειώσετε μερικές πρακτικές παραγωγής που θα μπορούσαν να σας εξοικονομήσουν δάκρυα και ώρες εντοπισμού σφαλμάτων αργότερα. Βεβαιωθείτε ότι ακολουθείτε αυτές τις βέλτιστες πρακτικές και επιτρέψτε μου να ξέρω τι σκέφτεστε λέγοντας Γεια στη λαβή μου στο twitter.

Αν σας άρεσε αυτό το άρθρο, ας συναντηθούμε στα μέσα κοινωνικής δικτύωσης. Εδώ είναι το Instagram και το Twitter μου. Είμαι πολύ ενεργός και θα ήθελα να κάνω μια συνομιλία! Ας συνδεθούμε.

Ειρήνη!

Μεχούλ