วิธีเพิ่มประสิทธิภาพโครงสร้างพื้นฐานการผลิต Node.js: แนวทางปฏิบัติที่ดีที่สุดใน 2025

แนวปฏิบัติที่ดีที่สุดในการปรับใช้การผลิต Node.js จากโครงสร้างพื้นฐานที่ผ่านการทดสอบการใช้งานจริงของเราซึ่งจัดการกับคำขอหลายล้านรายการต่อวัน

ที่ Forward Email เราใช้เวลาหลายปีในการปรับปรุงการตั้งค่าสภาพแวดล้อมการผลิต Node.js ของเราให้สมบูรณ์แบบ คู่มือฉบับสมบูรณ์นี้จะแบ่งปันแนวทางปฏิบัติที่ดีที่สุดในการปรับใช้ Node.js ในการผลิตซึ่งผ่านการทดสอบการใช้งานจริง โดยเน้นที่การเพิ่มประสิทธิภาพการทำงาน การตรวจสอบ และบทเรียนที่เราได้เรียนรู้ในการปรับขนาดแอปพลิเคชัน Node.js ให้รองรับธุรกรรมรายวันนับล้านรายการ

การปฏิวัติการเพิ่มประสิทธิภาพแกนเดี่ยว 573% ของเรา

เมื่อเราเปลี่ยนจากโปรเซสเซอร์ Intel มาเป็นโปรเซสเซอร์ AMD Ryzen เราก็ประสบความสำเร็จ ปรับปรุงประสิทธิภาพ 573% ในแอปพลิเคชัน Node.js ของเรา นี่ไม่ใช่แค่การเพิ่มประสิทธิภาพเล็กน้อยเท่านั้น แต่ยังเปลี่ยนแปลงวิธีการทำงานของแอปพลิเคชัน Node.js ในการผลิตโดยพื้นฐาน และแสดงให้เห็นถึงความสำคัญของการเพิ่มประสิทธิภาพการทำงานแบบแกนเดียวสำหรับแอปพลิเคชัน Node.js ใดๆ ก็ตาม

[!TIP] สำหรับแนวทางปฏิบัติที่ดีที่สุดในการใช้งาน Node.js ในการผลิต การเลือกฮาร์ดแวร์ถือเป็นสิ่งสำคัญ เราเลือก DataPacket hosting โดยเฉพาะเนื่องจากความพร้อมใช้งานของ AMD Ryzen เนื่องจากประสิทธิภาพแบบคอร์เดียวมีความสำคัญสำหรับแอปพลิเคชัน Node.js เนื่องจากการทำงานของ JavaScript เป็นแบบเธรดเดียว

เหตุใดการเพิ่มประสิทธิภาพการทำงานของ Single Core จึงมีความสำคัญสำหรับ Node.js

การโยกย้ายของเราจาก Intel ไปสู่ AMD Ryzen ส่งผลให้:

  • ปรับปรุงประสิทธิภาพ 573% ในการประมวลผลคำขอ (มีการบันทึกไว้ใน หน้าสถานะของเรา GitHub Issue #1519)
  • ขจัดความล่าช้าในการประมวลผล เพื่อตอบสนองเกือบจะทันที (กล่าวถึงใน GitHub ฉบับที่ 298)
  • อัตราส่วนราคาต่อประสิทธิภาพที่ดีขึ้น สำหรับสภาพแวดล้อมการผลิต Node.js
  • ปรับปรุงเวลาตอบสนอง ครอบคลุมจุดสิ้นสุดแอปพลิเคชันทั้งหมดของเรา

การเพิ่มประสิทธิภาพนั้นมีความสำคัญมากจนตอนนี้เราถือว่าโปรเซสเซอร์ AMD Ryzen เป็นสิ่งจำเป็นสำหรับการใช้งานการผลิต Node.js อย่างจริงจัง ไม่ว่าคุณจะรันแอปพลิเคชันเว็บ API ไมโครเซอร์วิส หรือเวิร์กโหลด Node.js อื่นใดก็ตาม

หากต้องการดูรายละเอียดเพิ่มเติมเกี่ยวกับตัวเลือกโครงสร้างพื้นฐานของเรา โปรดดูที่:

การตั้งค่าสภาพแวดล้อมการผลิต Node.js: สแต็กเทคโนโลยีของเรา

แนวทางปฏิบัติที่ดีที่สุดในการปรับใช้การผลิต Node.js ของเราประกอบด้วยการเลือกเทคโนโลยีอย่างรอบคอบโดยพิจารณาจากประสบการณ์การผลิตหลายปี นี่คือสิ่งที่เราใช้และเหตุผลที่ตัวเลือกเหล่านี้ใช้ได้กับแอปพลิเคชัน Node.js ใดๆ:

ตัวจัดการแพ็คเกจ: pnpm เพื่อประสิทธิภาพการผลิต

สิ่งที่เราใช้: pnpm (เวอร์ชั่นปักหมุด)

เราเลือก pnpm แทน npm และ yarn สำหรับการตั้งค่าสภาพแวดล้อมการผลิต Node.js ของเราเนื่องจาก:

  • เวลาในการติดตั้งเร็วขึ้น ในท่อ CI/CD
  • ประสิทธิภาพพื้นที่ดิสก์ ผ่านการเชื่อมโยงแบบฮาร์ด
  • การแก้ไขการพึ่งพาอย่างเคร่งครัด ซึ่งป้องกันการพึ่งพาแบบหลอกๆ
  • ประสิทธิภาพการทำงานที่ดีขึ้น ในการใช้งานการผลิต

[!NOTE] ในฐานะส่วนหนึ่งของแนวทางปฏิบัติที่ดีที่สุดในการปรับใช้การผลิต Node.js ของเรา เราได้กำหนดเวอร์ชันที่แน่นอนของเครื่องมือที่สำคัญ เช่น pnpm เพื่อให้แน่ใจว่ามีการทำงานที่สอดคล้องกันในทุกสภาพแวดล้อมและเครื่องของสมาชิกในทีม

รายละเอียดการดำเนินการ:

กรอบงานเว็บ: Koa สำหรับการผลิต Node.js สมัยใหม่

สิ่งที่เราใช้:

เราเลือก Koa แทน Express สำหรับโครงสร้างพื้นฐานการผลิต Node.js ของเราเนื่องจากรองรับ async/wait ที่ทันสมัยและมีมิดเดิลแวร์ที่สะอาดขึ้น Nick Baugh ผู้ก่อตั้งของเรามีส่วนสนับสนุนทั้ง Express และ Koa ทำให้เราเข้าใจเฟรมเวิร์กทั้งสองสำหรับการใช้งานการผลิตอย่างลึกซึ้ง

รูปแบบเหล่านี้ใช้ได้ไม่ว่าคุณจะกำลังสร้าง REST API, เซิร์ฟเวอร์ GraphQL, แอปพลิเคชันเว็บ หรือไมโครเซอร์วิส

ตัวอย่างการนำไปใช้ของเรา:

การประมวลผลงานพื้นฐาน: Bree สำหรับความน่าเชื่อถือของการผลิต

สิ่งที่เราใช้: bree ผู้จัดตารางเวลา

เราสร้างและดูแล Bree เนื่องจากตัวกำหนดตารางงานที่มีอยู่ไม่ตรงตามความต้องการของเราในการรองรับเธรดเวิร์กเกอร์และฟีเจอร์ JavaScript สมัยใหม่ในสภาพแวดล้อม Node.js ของการผลิต ซึ่งใช้ได้กับแอปพลิเคชัน Node.js ใดๆ ที่ต้องการการประมวลผลเบื้องหลัง งานที่กำหนดเวลาไว้ หรือเธรดเวิร์กเกอร์

ตัวอย่างการนำไปใช้ของเรา:

การจัดการข้อผิดพลาด: @hapi/boom เพื่อความน่าเชื่อถือของการผลิต

สิ่งที่เราใช้: @hapi/boom

เราใช้ @hapi/boom สำหรับการตอบสนองต่อข้อผิดพลาดแบบมีโครงสร้างตลอดการใช้งาน Node.js ของเรา รูปแบบนี้ใช้ได้กับแอปพลิเคชัน Node.js ใดๆ ที่ต้องการการจัดการข้อผิดพลาดที่สม่ำเสมอ

ตัวอย่างการนำไปใช้ของเรา:

วิธีการตรวจสอบแอปพลิเคชัน Node.js ในการผลิต

แนวทางของเราในการตรวจสอบแอปพลิเคชัน Node.js ในระบบการผลิตได้พัฒนามาจากการทำงานแอปพลิเคชันตามขนาดต่างๆ เป็นเวลาหลายปี เราใช้การตรวจสอบในหลายชั้นเพื่อให้มั่นใจถึงความน่าเชื่อถือและประสิทธิภาพสำหรับแอปพลิเคชัน Node.js ทุกประเภท

การตรวจสอบการผลิต Node.js ระดับระบบ

การดำเนินงานหลักของเรา: helpers/monitor-server.js

สิ่งที่เราใช้: node-os-utils

เกณฑ์การติดตามการผลิตของเรา (จากโค้ดการผลิตจริงของเรา):

  • จำกัดขนาดฮีป 2GB พร้อมแจ้งเตือนอัตโนมัติ
  • ใช้หน่วยความจำ 25% เกณฑ์การเตือน
  • การใช้งานซีพียู 80% เกณฑ์การแจ้งเตือน
  • การใช้งานดิสก์ 75% เกณฑ์การเตือน

[!WARNING] เกณฑ์เหล่านี้ใช้ได้กับการกำหนดค่าฮาร์ดแวร์เฉพาะของเรา เมื่อใช้งานการตรวจสอบการผลิตของ Node.js โปรดตรวจสอบการใช้งาน monitor-server.js ของเราเพื่อทำความเข้าใจตรรกะที่แน่นอนและปรับค่าให้เหมาะกับการตั้งค่าของคุณ

การตรวจสอบระดับแอปพลิเคชันสำหรับการผลิต Node.js

การจำแนกข้อผิดพลาดของเรา: helpers/is-code-bug.js

ตัวช่วยนี้จะแยกแยะระหว่าง:

  • ข้อผิดพลาดของโค้ดจริง ที่ต้องได้รับความใส่ใจทันที
  • ข้อผิดพลาดของผู้ใช้ ที่เป็นพฤติกรรมที่คาดหวัง
  • ความล้มเหลวของบริการภายนอก ที่เราไม่สามารถควบคุมได้

รูปแบบนี้ใช้ได้กับแอปพลิเคชัน Node.js ทั้งหมด ไม่ว่าจะเป็นแอปพลิเคชันเว็บ API ไมโครเซอร์วิส หรือบริการพื้นหลัง

การใช้งานการบันทึกข้อมูลของเรา: helpers/logger.js

เราใช้การแก้ไขภาคสนามแบบครอบคลุมเพื่อปกป้องข้อมูลที่ละเอียดอ่อนในขณะที่ยังคงรักษาความสามารถในการดีบักที่มีประโยชน์ในสภาพแวดล้อมการผลิต Node.js ของเรา

การตรวจสอบเฉพาะแอปพลิเคชัน

การใช้งานเซิร์ฟเวอร์ของเรา:

การติดตามคิว: เราใช้การจำกัดคิวที่ 5GB และระยะเวลาหมดเวลา 180 วินาทีสำหรับการประมวลผลคำขอเพื่อป้องกันการใช้ทรัพยากรจนหมด รูปแบบเหล่านี้ใช้ได้กับแอปพลิเคชัน Node.js ที่มีคิวหรือการประมวลผลเบื้องหลัง

การตรวจสอบการผลิต Node.js ด้วยการตรวจสอบสุขภาพ PM2

เราได้ปรับปรุงการตั้งค่าสภาพแวดล้อมการผลิต Node.js ด้วย PM2 จากประสบการณ์การผลิตหลายปี การตรวจสอบสุขภาพ PM2 ของเรามีความจำเป็นสำหรับการรักษาความน่าเชื่อถือในแอปพลิเคชัน Node.js

ระบบตรวจสุขภาพ PM2 ของเรา

การดำเนินงานหลักของเรา: jobs/check-pm2.js

การตรวจสอบการผลิต Node.js ของเราพร้อมการตรวจสอบสุขภาพ PM2 ประกอบด้วย:

  • วิ่งทุก ๆ 20 นาที ผ่านการกำหนดตารางเวลา cron
  • ต้องใช้เวลาทำงานขั้นต่ำ 15 นาที ก่อนที่จะพิจารณากระบวนการที่ดีต่อสุขภาพ
  • ตรวจสอบสถานะกระบวนการและการใช้หน่วยความจำ
  • รีสตาร์ทกระบวนการที่ล้มเหลวโดยอัตโนมัติ
  • ป้องกันการเริ่มระบบใหม่อีกครั้ง ผ่านการตรวจสุขภาพอัจฉริยะ

[!CAUTION] For Node.js production deployment best practices, we require 15+ minutes uptime before considering a process healthy to avoid restart loops. This prevents cascading failures when processes are struggling with memory or other issues.

การกำหนดค่าการผลิต PM2 ของเรา

การตั้งค่าระบบนิเวศของเรา: ศึกษาไฟล์เริ่มต้นเซิร์ฟเวอร์ของเราสำหรับการตั้งค่าสภาพแวดล้อมการผลิต Node.js:

รูปแบบเหล่านี้ใช้ได้ไม่ว่าคุณจะรันแอป Express, เซิร์ฟเวอร์ Koa, GraphQL API หรือแอปพลิเคชัน Node.js อื่น ๆ

การปรับใช้ PM2 อัตโนมัติ

การใช้งาน PM2: ansible/playbooks/node.yml

เราทำให้การตั้งค่า PM2 ทั้งหมดของเราเป็นแบบอัตโนมัติโดยใช้ Ansible เพื่อให้แน่ใจว่าการปรับใช้การผลิต Node.js สอดคล้องกันบนเซิร์ฟเวอร์ทั้งหมดของเรา

ระบบจัดการและจำแนกข้อผิดพลาดในการผลิต

แนวทางปฏิบัติที่ดีที่สุดในการปรับใช้การผลิต Node.js ที่มีคุณค่าที่สุดประการหนึ่งของเราคือการจำแนกข้อผิดพลาดอัจฉริยะที่ใช้ได้กับแอปพลิเคชัน Node.js ทุกแอปพลิเคชัน:

การใช้งาน isCodeBug ของเราสำหรับการผลิต

แหล่งที่มา: helpers/is-code-bug.js

ตัวช่วยนี้ให้การจำแนกข้อผิดพลาดอัจฉริยะสำหรับแอปพลิเคชัน Node.js ในการผลิตเพื่อ:

  • ให้ความสำคัญกับจุดบกพร่องที่แท้จริง ข้อผิดพลาดของผู้ใช้มากเกินไป
  • ปรับปรุงการตอบสนองต่อเหตุการณ์ของเรา โดยมุ่งเน้นไปที่ประเด็นที่แท้จริง
  • ลดความเหนื่อยล้าจากการเตือน จากข้อผิดพลาดของผู้ใช้ที่คาดว่าจะเกิดขึ้น
  • เข้าใจมากขึ้น ปัญหาที่เกิดจากแอปพลิเคชันกับผู้ใช้

รูปแบบนี้ใช้ได้กับแอปพลิเคชัน Node.js ทุกแอปพลิเคชัน ไม่ว่าคุณจะกำลังสร้างไซต์อีคอมเมิร์ซ แพลตฟอร์ม SaaS, API หรือไมโครเซอร์วิส

การบูรณาการกับการบันทึกการผลิตของเรา

การรวมระบบบันทึกของเรา: helpers/logger.js

เครื่องบันทึกของเราใช้ isCodeBug เพื่อกำหนดระดับการแจ้งเตือนและการแก้ไขข้อมูลภาคสนาม เพื่อให้แน่ใจว่าเราได้รับการแจ้งเตือนเกี่ยวกับปัญหาจริงในขณะที่กรองสัญญาณรบกวนในสภาพแวดล้อมการผลิต Node.js ของเรา

เรียนรู้เพิ่มเติมเกี่ยวกับรูปแบบการจัดการข้อผิดพลาดของเรา:

การดีบักประสิทธิภาพขั้นสูงด้วย v8-profiler-next และ cpupro

เราใช้เครื่องมือสร้างโปรไฟล์ขั้นสูงเพื่อวิเคราะห์สแน็ปช็อตฮีปและแก้ไขปัญหา OOM (Out of Memory) คอขวดด้านประสิทธิภาพ และปัญหาหน่วยความจำของ Node.js ในสภาพแวดล้อมการผลิตของเรา เครื่องมือเหล่านี้มีความจำเป็นสำหรับแอปพลิเคชัน Node.js ใดๆ ที่ประสบปัญหาหน่วยความจำรั่วไหลหรือปัญหาด้านประสิทธิภาพ

แนวทางการสร้างโปรไฟล์ของเราสำหรับการผลิต Node.js

เครื่องมือที่เราแนะนำ:

  • v8-profiler-next - สำหรับการสร้างสแน็ปช็อตฮีปและโปรไฟล์ CPU
  • cpupro - สำหรับวิเคราะห์โปรไฟล์ CPU และสแน็ปช็อตฮีป

[!TIP] เราใช้ v8-profiler-next และ cpupro ร่วมกันเพื่อสร้างเวิร์กโฟลว์การดีบักประสิทธิภาพที่สมบูรณ์สำหรับแอปพลิเคชัน Node.js การผสมผสานนี้ช่วยให้เราสามารถระบุการรั่วไหลของหน่วยความจำ จุดคอขวดของประสิทธิภาพ และเพิ่มประสิทธิภาพโค้ดการผลิตของเรา

เราใช้การวิเคราะห์ Heap Snapshot อย่างไร

การดำเนินการติดตามของเรา: helpers/monitor-server.js

การตรวจสอบการผลิตของเราประกอบด้วยการสร้างสแน็ปช็อตฮีปอัตโนมัติเมื่อเกินขีดจำกัดหน่วยความจำ ซึ่งช่วยให้เราแก้ไขปัญหา OOM ก่อนที่จะทำให้แอปพลิเคชันขัดข้อง

รูปแบบการดำเนินการที่สำคัญ:

  • การถ่ายสแน็ปช็อตอัตโนมัติ เมื่อขนาดฮีปเกินขีดจำกัด 2GB
  • โปรไฟล์ตามสัญญาณ สำหรับการวิเคราะห์ตามความต้องการในการผลิต
  • นโยบายการเก็บรักษา สำหรับการจัดการพื้นที่จัดเก็บสแน็ปช็อต
  • การบูรณาการกับงานการทำความสะอาดของเรา สำหรับการบำรุงรักษาแบบอัตโนมัติ

เวิร์กโฟลว์การดีบักประสิทธิภาพ

ศึกษาการใช้งานจริงของเรา:

สำหรับการวิเคราะห์สแน็ปช็อตฮีป:

  1. ติดตั้ง v8-profiler-next สำหรับการสร้างสแน็ปช็อต
  2. ใช้ cpupro สำหรับวิเคราะห์สแนปช็อตที่สร้างขึ้น
  3. ดำเนินการตามเกณฑ์การตรวจสอบ คล้ายกับ monitor-server.js ของเรา
  4. ตั้งค่าการทำความสะอาดอัตโนมัติ เพื่อจัดการพื้นที่จัดเก็บสแน็ปช็อต
  5. สร้างตัวจัดการสัญญาณ สำหรับการสร้างโปรไฟล์ตามความต้องการในการผลิต

สำหรับการสร้างโปรไฟล์ CPU:

  1. สร้างโปรไฟล์ CPU ในช่วงที่มีโหลดสูง
  2. วิเคราะห์ด้วย cpupro เพื่อระบุคอขวด
  3. เน้นเส้นทางที่ร้อนแรง และโอกาสในการเพิ่มประสิทธิภาพ
  4. ติดตามก่อน/หลัง การปรับปรุงประสิทธิภาพ

[!WARNING] การสร้างสแน็ปช็อตฮีปและโปรไฟล์ CPU อาจส่งผลกระทบต่อประสิทธิภาพ เราขอแนะนำให้ใช้การควบคุมปริมาณและเปิดใช้งานการสร้างโปรไฟล์เฉพาะเมื่อตรวจสอบปัญหาเฉพาะหรือในช่วงเวลาการบำรุงรักษา

การบูรณาการกับการตรวจสอบการผลิตของเรา

เครื่องมือสร้างโปรไฟล์ของเราบูรณาการกับกลยุทธ์การตรวจสอบที่กว้างขึ้นของเรา:

  • การกระตุ้นอัตโนมัติ ขึ้นอยู่กับเกณฑ์หน่วยความจำ/ซีพียู
  • การรวมการแจ้งเตือน เมื่อตรวจพบปัญหาด้านประสิทธิภาพ
  • การวิเคราะห์ทางประวัติศาสตร์ เพื่อติดตามแนวโน้มประสิทธิภาพในช่วงเวลาต่างๆ
  • ความสัมพันธ์กับเมตริกแอปพลิเคชัน เพื่อการแก้ไขข้อบกพร่องอย่างครอบคลุม

แนวทางนี้ช่วยให้เราสามารถระบุและแก้ไขการรั่วไหลของหน่วยความจำ เพิ่มประสิทธิภาพเส้นทางโค้ดร้อน และรักษาประสิทธิภาพที่เสถียรในสภาพแวดล้อมการผลิต Node.js ของเรา

การรักษาความปลอดภัยโครงสร้างพื้นฐานการผลิต Node.js

เราใช้ระบบรักษาความปลอดภัยที่ครอบคลุมสำหรับโครงสร้างพื้นฐานการผลิต Node.js ของเราผ่านระบบอัตโนมัติของ Ansible แนวทางปฏิบัตินี้ใช้ได้กับแอปพลิเคชัน Node.js ทุกแอปพลิเคชัน:

ความปลอดภัยระดับระบบสำหรับการผลิต Node.js

การใช้งาน Ansible ของเรา: ansible/playbooks/security.yml

มาตรการรักษาความปลอดภัยที่สำคัญของเราสำหรับสภาพแวดล้อมการผลิต Node.js:

  • สลับปิดการใช้งาน เพื่อป้องกันข้อมูลสำคัญไม่ให้ถูกเขียนลงในดิสก์
  • ปิดการใช้งาน Core dumps เพื่อป้องกันการถ่ายโอนข้อมูลหน่วยความจำที่มีข้อมูลที่ละเอียดอ่อน
  • ที่เก็บข้อมูล USB ถูกบล็อค เพื่อป้องกันการเข้าถึงข้อมูลที่ไม่ได้รับอนุญาต
  • การปรับแต่งพารามิเตอร์เคอร์เนล ทั้งด้านความปลอดภัยและประสิทธิภาพการทำงาน

[!WARNING] เมื่อนำแนวทางปฏิบัติที่ดีที่สุดในการปรับใช้ Node.js มาใช้ การปิดใช้งานการสลับอาจทำให้เกิดปัญหาหน่วยความจำไม่เพียงพอหากแอปพลิเคชันของคุณมี RAM เกินขีดจำกัด เราตรวจสอบการใช้หน่วยความจำอย่างระมัดระวังและปรับขนาดเซิร์ฟเวอร์ของเราให้เหมาะสม

ความปลอดภัยของแอปพลิเคชันสำหรับแอปพลิเคชัน Node.js

การแก้ไขฟิลด์บันทึกของเรา: helpers/logger.js

เราลบข้อมูลสำคัญออกจากบันทึกต่างๆ รวมถึงรหัสผ่าน โทเค็น คีย์ API และข้อมูลส่วนบุคคล ซึ่งจะช่วยปกป้องความเป็นส่วนตัวของผู้ใช้ในขณะที่ยังคงความสามารถในการแก้ไขข้อบกพร่องในสภาพแวดล้อมการผลิต Node.js

ระบบอัตโนมัติความปลอดภัยโครงสร้างพื้นฐาน

การตั้งค่า Ansible ที่สมบูรณ์ของเราสำหรับการผลิต Node.js:

เนื้อหาความปลอดภัยของเรา

เรียนรู้เพิ่มเติมเกี่ยวกับแนวทางการรักษาความปลอดภัยของเรา:

สถาปัตยกรรมฐานข้อมูลสำหรับแอปพลิเคชัน Node.js

เราใช้แนวทางฐานข้อมูลไฮบริดที่ปรับให้เหมาะสมสำหรับแอปพลิเคชัน Node.js ของเรา รูปแบบเหล่านี้สามารถปรับให้เหมาะกับแอปพลิเคชัน Node.js ใดๆ ก็ได้:

การนำ SQLite ไปใช้สำหรับการผลิต Node.js

สิ่งที่เราใช้:

การกำหนดค่าของเรา: ansible/playbooks/sqlite.yml

เราใช้ SQLite สำหรับข้อมูลเฉพาะผู้ใช้ในแอปพลิเคชัน Node.js เนื่องจากมีคุณลักษณะเหล่านี้:

  • การแยกข้อมูล ต่อผู้ใช้/ผู้เช่า
  • ประสิทธิภาพการทำงานที่ดีขึ้น สำหรับการสอบถามผู้ใช้รายเดียว
  • การสำรองข้อมูลแบบง่ายๆ และการอพยพ
  • ลดความซับซ้อน เมื่อเทียบกับฐานข้อมูลที่ใช้ร่วมกัน

รูปแบบนี้ใช้งานได้ดีสำหรับแอปพลิเคชัน SaaS ระบบผู้เช่าหลายราย หรือแอปพลิเคชัน Node.js ใดๆ ที่ต้องการแยกข้อมูล

การนำ MongoDB ไปใช้สำหรับการผลิต Node.js

สิ่งที่เราใช้:

การใช้งานการตั้งค่าของเรา: helpers/setup-mongoose.js

การกำหนดค่าของเรา: config/mongoose.js

เราใช้ MongoDB สำหรับข้อมูลแอปพลิเคชันในสภาพแวดล้อมการผลิต Node.js เนื่องจากมีสิ่งต่อไปนี้:

  • โครงร่างที่ยืดหยุ่น เพื่อการวิวัฒนาการโครงสร้างข้อมูล
  • ประสิทธิภาพการทำงานที่ดีขึ้น สำหรับการสอบถามที่ซับซ้อน
  • การปรับขนาดแนวนอน ความสามารถ
  • ภาษาสอบถามที่อุดมไปด้วย

[!หมายเหตุ] แนวทางไฮบริดของเราปรับให้เหมาะสมสำหรับกรณีการใช้งานเฉพาะของเรา ศึกษารูปแบบการใช้งานฐานข้อมูลจริงในฐานโค้ดเพื่อทำความเข้าใจว่าแนวทางนี้เหมาะกับความต้องการแอปพลิเคชัน Node.js ของคุณหรือไม่

งานเบื้องหลังการผลิต Node.js

เราสร้างสถาปัตยกรรมงานเบื้องหลังโดยยึดตาม Bree เพื่อการปรับใช้การผลิต Node.js ที่เชื่อถือได้ ซึ่งใช้ได้กับแอปพลิเคชัน Node.js ใดๆ ที่ต้องการการประมวลผลเบื้องหลัง:

การตั้งค่าเซิร์ฟเวอร์ Bree ของเราสำหรับการผลิต

การดำเนินการหลักของเรา: bree.js

การใช้งาน Ansible ของเรา: ansible/playbooks/bree.yml

ตัวอย่างงานการผลิต

การติดตามสุขภาพ: jobs/check-pm2.js

การทำความสะอาดอัตโนมัติ: jobs/cleanup-tmp.js

งานทั้งหมดของเรา: เรียกดูไดเรกทอรีงานทั้งหมดของเรา

รูปแบบเหล่านี้ใช้ได้กับแอปพลิเคชัน Node.js ที่ต้องการ:

  • งานตามกำหนดเวลา (การประมวลผลข้อมูล, รายงาน, การล้างข้อมูล)
  • การประมวลผลพื้นหลัง (การปรับขนาดภาพ การส่งอีเมล การนำเข้าข้อมูล)
  • การตรวจติดตามและบำรุงรักษาสุขภาพ
  • การใช้เธรดเวิร์กเกอร์สำหรับงานที่ใช้ CPU เข้มข้น

รูปแบบการจัดตารางงานของเราสำหรับการผลิต Node.js

ศึกษารูปแบบการจัดตารางงานจริงของเราในไดเร็กทอรีงานเพื่อทำความเข้าใจ:

  • เราใช้การกำหนดตารางเวลาแบบ cron ในการผลิต Node.js ได้อย่างไร
  • การจัดการข้อผิดพลาดและการลองใหม่อีกครั้งของเรา
  • เราใช้เวิร์กเกอร์เธรดสำหรับงานที่ใช้ CPU หนักๆ อย่างไร

การบำรุงรักษาอัตโนมัติสำหรับแอปพลิเคชัน Node.js การผลิต

เราใช้การบำรุงรักษาเชิงรุกเพื่อป้องกันปัญหาการผลิต Node.js ทั่วไป รูปแบบเหล่านี้ใช้ได้กับแอปพลิเคชัน Node.js ทุกแอปพลิเคชัน:

การดำเนินการทำความสะอาดของเรา

แหล่งที่มา: jobs/cleanup-tmp.js

การบำรุงรักษาอัตโนมัติของเราสำหรับแอปพลิเคชันการผลิต Node.js มีเป้าหมาย:

  • ไฟล์ชั่วคราว เก่ากว่า 24 ชั่วโมง
  • ไฟล์บันทึก เกินขีดจำกัดการเก็บรักษา
  • ไฟล์แคช และข้อมูลชั่วคราว
  • อัพโหลดไฟล์ ที่ไม่จำเป็นอีกต่อไป
  • สแนปช็อตของกอง จากการดีบักประสิทธิภาพ

รูปแบบเหล่านี้ใช้กับแอปพลิเคชัน Node.js ใด ๆ ที่สร้างไฟล์ชั่วคราว บันทึก หรือข้อมูลแคช

การจัดการพื้นที่ดิสก์สำหรับการผลิต Node.js

เกณฑ์การตรวจสอบของเรา: helpers/monitor-server.js

  • ข้อจำกัดคิว สำหรับการประมวลผลพื้นหลัง
  • การใช้งานดิสก์ 75% เกณฑ์การเตือน
  • การทำความสะอาดอัตโนมัติ เมื่อเกินขีดจำกัด

การบำรุงรักษาโครงสร้างพื้นฐานระบบอัตโนมัติ

การทำงานอัตโนมัติ Ansible ของเราสำหรับการผลิต Node.js:

คู่มือการนำไปใช้งานการปรับใช้การผลิต Node.js

ศึกษาโค้ดจริงของเราสำหรับแนวทางปฏิบัติที่ดีที่สุดในการผลิต

เริ่มต้นด้วยไฟล์สำคัญเหล่านี้สำหรับการตั้งค่าสภาพแวดล้อมการผลิต Node.js:

  1. การกำหนดค่า: config/index.js
  2. การติดตาม: helpers/monitor-server.js
  3. การจัดการข้อผิดพลาด: helpers/is-code-bug.js
  4. การบันทึก: helpers/logger.js
  5. สุขภาพกระบวนการ: jobs/check-pm2.js

เรียนรู้จากโพสต์บล็อกของเรา

คู่มือการใช้งานทางเทคนิคของเราสำหรับการผลิต Node.js:

โครงสร้างพื้นฐานอัตโนมัติสำหรับการผลิต Node.js

คู่มือ Ansible ของเราสำหรับการศึกษาการใช้งานการผลิต Node.js:

กรณีศึกษาของเรา

การใช้งานองค์กรของเรา:

บทสรุป: แนวทางปฏิบัติที่ดีที่สุดในการปรับใช้การผลิต Node.js

โครงสร้างพื้นฐานการผลิต Node.js ของเราแสดงให้เห็นว่าแอปพลิเคชัน Node.js สามารถบรรลุความน่าเชื่อถือระดับองค์กรได้ผ่าน:

  • ตัวเลือกฮาร์ดแวร์ที่ได้รับการพิสูจน์แล้ว (AMD Ryzen เพิ่มประสิทธิภาพการทำงานแบบ Single Core ได้ 573%)
  • การตรวจสอบการผลิต Node.js ที่ผ่านการทดสอบการใช้งานจริง ด้วยเกณฑ์เฉพาะและการตอบสนองอัตโนมัติ
  • การจำแนกข้อผิดพลาดแบบสมาร์ท เพื่อปรับปรุงการตอบสนองต่อเหตุการณ์ในสภาพแวดล้อมการผลิต
  • การดีบักประสิทธิภาพขั้นสูง ด้วย v8-profiler-next และ cpupro เพื่อป้องกัน OOM
  • การเสริมความแข็งแกร่งด้านความปลอดภัยอย่างครอบคลุม ผ่านระบบอัตโนมัติ Ansible
  • สถาปัตยกรรมฐานข้อมูลไฮบริด ปรับให้เหมาะสมสำหรับความต้องการของแอปพลิเคชัน
  • การบำรุงรักษาแบบอัตโนมัติ เพื่อป้องกันปัญหาการผลิต Node.js ทั่วไป

สิ่งสำคัญที่ต้องจดจำ: ศึกษาไฟล์การใช้งานจริงและโพสต์บล็อกของเราแทนที่จะปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดทั่วไป ฐานโค้ดของเรามอบรูปแบบการใช้งานจริงสำหรับการปรับใช้การผลิต Node.js ที่สามารถปรับให้เหมาะกับแอปพลิเคชัน Node.js ใดๆ ก็ได้ ไม่ว่าจะเป็นแอปบนเว็บ API ไมโครเซอร์วิส หรือบริการเบื้องหลัง

รายการทรัพยากรที่สมบูรณ์สำหรับการผลิต Node.js

ไฟล์การใช้งานหลักของเรา

การใช้งานเซิร์ฟเวอร์ของเรา

โครงสร้างพื้นฐานอัตโนมัติของเรา

บทความบล็อกทางเทคนิคของเรา

กรณีศึกษาองค์กรของเรา