ฉันใช้ Node.js ในที่ทำงานและพบว่ามันมีประสิทธิภาพมาก บังคับให้เลือกหนึ่งคำเพื่ออธิบาย Node.js ฉันจะพูดว่า "น่าสนใจ" (ซึ่งไม่ใช่คำคุณศัพท์เชิงบวกล้วนๆ) ชุมชนมีชีวิตชีวาและเติบโต จาวาสคริปต์แม้จะมีความแปลกประหลาดของมันสามารถเป็นภาษาที่ดีในการเขียนโค้ดและคุณจะคิดใหม่ทุกวันถึงความเข้าใจของคุณเองเกี่ยวกับ "แนวปฏิบัติที่ดีที่สุด" และรูปแบบของโค้ดที่มีโครงสร้างที่ดี มีพลังงานความคิดมหาศาลไหลเข้าสู่ Node.js ในขณะนี้และการทำงานในนั้นทำให้คุณได้รับความคิดทั้งหมดนี้ - ยกน้ำหนักทางจิตที่ดี
Node.js ในการผลิตเป็นไปได้แน่นอน แต่ไกลจากการปรับใช้ "เทิร์นคีย์" ซึ่งดูเหมือนว่าจะมีสัญญาไว้ในเอกสาร ด้วย Node.js v0.6.x ทำให้ "cluster" ถูกรวมเข้ากับแพลตฟอร์มโดยให้เป็นหนึ่งในหน่วยการสร้างที่สำคัญ แต่สคริปต์ "production.js" ของฉันยังคงเป็นตรรกะ ~ 150 บรรทัดเพื่อจัดการกับสิ่งต่าง ๆ เช่นการสร้างบันทึก ไดเรกทอรีรีไซเคิลคนงานตาย ฯลฯ สำหรับ "ร้ายแรง" บริการการผลิตนอกจากนี้คุณยังจะต้องมีการเตรียมที่จะเชื่อมต่อเข้ามาเค้นและทำทุกสิ่งที่ Apache ไม่สำหรับPHP เพื่อความเป็นธรรมRuby on Railsมีปัญหาตรงนี้ มันถูกแก้ไขผ่านสองกลไกเสริม: 1) การวาง Ruby on Rails / NodeApache / Lighttd ) เว็บเซิร์ฟเวอร์สามารถให้บริการเนื้อหาแบบคงที่ได้อย่างมีประสิทธิภาพการบันทึกการเข้าถึงเขียน URL ใหม่ยุติSSLบังคับใช้กฎการเข้าถึงและจัดการบริการย่อยหลายรายการ สำหรับคำขอที่เข้าใช้บริการโหนดจริงเว็บเซิร์ฟเวอร์จะทำหน้าที่ผ่านการร้องขอ 2) การใช้เฟรมเวิร์กเช่นยูนิคอร์นที่จะจัดการกระบวนการของผู้ปฏิบัติงานรีไซเคิลเป็นระยะ ๆ ฯลฯ ฉันยังไม่พบ Node.js ที่ให้บริการเฟรมเวิร์กที่ดูเหมือนอบเต็มที่ อาจมีอยู่ แต่ฉันยังไม่พบและยังคงใช้ ~ 150 บรรทัดใน "production.js" ที่รีดด้วยมือของฉัน
การอ่านเฟรมเวิร์กอย่างExpressทำให้ดูเหมือนว่าการปฏิบัติมาตรฐานคือการให้บริการทุกอย่างผ่านบริการ Node.js แบบแจ็คทุกการซื้อขาย ... "app.use (express.static (__ dirname + '/ public'))" . สำหรับบริการโหลดและการพัฒนาที่ต่ำกว่าอาจเป็นเรื่องปกติ แต่ทันทีที่คุณพยายามโหลดครั้งใหญ่ในบริการของคุณและเปิดให้บริการตลอด 24 ชั่วโมงคุณจะค้นพบแรงจูงใจที่ผลักดันเว็บไซต์ขนาดใหญ่ให้มี C-code ที่อบและแข็งเช่นNginx ที่อยู่ด้านหน้าไซต์และจัดการทั้งหมด ของคำขอเนื้อหาแบบสแตติก (... จนกว่าคุณจะตั้งค่าCDNเช่นAmazon CloudFront ) สำหรับสิ่งที่ค่อนข้างตลกขบขันและเป็นลบในเรื่องนี้ดูผู้ชายคนนี้นี้
Node.js กำลังค้นหาการใช้ที่ไม่ใช่บริการมากขึ้นเรื่อย ๆ แม้ว่าคุณกำลังใช้สิ่งอื่นเพื่อแสดงเนื้อหาเว็บคุณอาจยังคงใช้ Node.js เป็นเครื่องมือสร้างโดยใช้โมดูลnpmเพื่อจัดระเบียบรหัสของคุณBrowserifyเพื่อเย็บมันเป็นเนื้อหาเดียวและuglify-jsเพื่อย่อมันสำหรับการปรับใช้ . สำหรับการจัดการกับเว็บ JavaScript นั้นเป็นการจับคู่ที่สมบูรณ์แบบและบ่อยครั้งที่ทำให้เป็นเส้นทางการโจมตีที่ง่ายที่สุด ตัวอย่างเช่นหากคุณต้องการคลี่คลายภาระการตอบสนองต่อJSON จำนวนมากคุณควรใช้โมดูลขีดล่าง - CLIของฉันสายพานยูทิลิตี้ของข้อมูลที่มีโครงสร้าง
ข้อเสียข้อดี:
- Pro: สำหรับคนที่ใช้เซิร์ฟเวอร์การเขียน JavaScript บนแบ็กเอนด์นั้นเป็น "ยาเสพติดที่ประตู" เพื่อเรียนรู้รูปแบบ UI ที่ทันสมัย ฉันไม่กลัวการเขียนรหัสลูกค้าอีกต่อไป
- Pro: มีแนวโน้มที่จะสนับสนุนการตรวจสอบข้อผิดพลาดที่เหมาะสม (ข้อผิดพลาดจะถูกส่งกลับโดยการโทรกลับแทบทั้งหมดซึ่งจู้จี้โปรแกรมเมอร์เพื่อจัดการมันเช่นกัน async.js และห้องสมุดอื่น ๆ จัดการกับ "ล้มเหลวหากงานย่อยใด ๆ เหล่านี้ล้มเหลว" )
- Pro: งานที่น่าสนใจและยากโดยทั่วไปกลายเป็นเรื่องเล็กน้อยเช่นรับสถานะงานในเที่ยวบินสื่อสารระหว่างคนงานหรือแชร์สถานะแคช
- Pro: ชุมชนขนาดใหญ่และห้องสมุดที่ยอดเยี่ยมมากมายโดยใช้ตัวจัดการแพคเกจที่มั่นคง (npm)
- ข้อเสีย: JavaScript ไม่มีไลบรารี่มาตรฐาน คุณคุ้นเคยกับการนำเข้าฟังก์ชั่นที่รู้สึกแปลก ๆ เมื่อคุณใช้ JSON.parse หรือวิธีการสร้างอื่น ๆ ที่ไม่ต้องการเพิ่มโมดูล npm ซึ่งหมายความว่ามีทุกสิ่งห้ารุ่น แม้แต่โมดูลที่รวมอยู่ใน "หลัก" ของ Node.js ก็มีอีกห้าสายพันธุ์หากคุณไม่พึงพอใจกับการใช้งานเริ่มต้น สิ่งนี้นำไปสู่การวิวัฒนาการอย่างรวดเร็ว แต่ก็มีระดับของความสับสน
เปรียบเทียบกับรูปแบบหนึ่งกระบวนการต่อคำขอที่เรียบง่าย ( LAMP ):
- Pro: ปรับได้ตามการเชื่อมต่อที่ใช้งานอยู่หลายพัน เร็วมากและมีประสิทธิภาพมาก สำหรับกองทัพเรือทางเว็บนี่อาจหมายถึงการลดจำนวน 10X ในจำนวนช่องที่ต้องการเมื่อเทียบกับ PHP หรือ Ruby
- Pro: การเขียนรูปแบบคู่ขนานเป็นเรื่องง่าย ลองจินตนาการว่าคุณจำเป็นต้องเรียกสาม (หรือ N) Blobs จากMemcached ทำสิ่งนี้ใน PHP ... คุณเพิ่งเขียนโค้ดที่เรียกว่า blob แรกจากนั้นก็ที่สองและที่สาม? ว้าวนั่นมันช้า มีโมดูลPECLพิเศษเพื่อแก้ไขปัญหาเฉพาะสำหรับ Memcached แต่ถ้าคุณต้องการดึงข้อมูล Memcached บางส่วนพร้อมกับแบบสอบถามฐานข้อมูลของคุณ ใน Node.js เนื่องจากกระบวนทัศน์ไม่ตรงกันการมีคำขอทางเว็บทำหลายอย่างพร้อมกันนั้นเป็นเรื่องธรรมดามาก
- คอนดิชั่น: รหัสแบบอะซิงโครนัสมีความซับซ้อนมากกว่าโค้ดแบบอะซิงโครนัสและเส้นโค้งการเรียนรู้ล่วงหน้าอาจเป็นเรื่องยากสำหรับนักพัฒนาโดยไม่ต้องเข้าใจอย่างชัดเจนว่า ยังคงเป็นเรื่องยากยิ่งกว่าการเขียนรหัสแบบมัลติเธรดชนิดใด ๆ ที่มีการล็อค
- คอนดิชั่น: หากคำขอที่ใช้งานแบบประมวลผลเช่น 100 ms มันจะทำการประมวลผลคำร้องขออื่น ๆ ที่ถูกจัดการในกระบวนการ Node.js เดียวกัน ... AKA, การทำงานร่วมกันแบบหลายกลุ่ม สิ่งนี้สามารถลดลงได้ด้วยรูปแบบ Web Workers (การปั่นกระบวนการย่อยเพื่อจัดการกับงานที่มีราคาแพง) หรือคุณสามารถใช้คนงาน Node.js จำนวนมากและอนุญาตให้แต่ละคนจัดการคำขอเดียวพร้อมกัน (ยังคงมีประสิทธิภาพพอสมควรเพราะไม่มีกระบวนการรีไซเคิล)
- คอนดิชั่น: การใช้งานระบบการผลิตนั้นซับซ้อนกว่าแบบCGIเช่น Apache + PHP, Perl , Rubyและอื่น ๆ ข้อยกเว้นที่ไม่สามารถจัดการได้จะทำให้กระบวนการทั้งหมดล้มลงโดยใช้ตรรกะในการรีสตาร์ทผู้ทำงานที่ล้มเหลว (ดูที่คลัสเตอร์ ) โมดูลที่มีเนทิฟ buggy สามารถทำให้กระบวนการขัดข้องได้ยาก เมื่อใดก็ตามที่ผู้ปฏิบัติงานเสียชีวิตคำขอใด ๆ ที่ถูกจัดการจะถูกดร็อปดังนั้นหนึ่ง buggy API สามารถลดประสิทธิภาพการให้บริการสำหรับ Cohosted API อื่น ๆ ได้อย่างง่ายดาย
เมื่อเทียบกับการเขียนบริการ "ของจริง" ใน Java / C # / C (C จริงเหรอ?)
- Pro: การทำแบบอะซิงโครนัสใน Node.js ง่ายกว่าการทำเธรดเพื่อความปลอดภัยที่อื่นและให้ประโยชน์ที่มากกว่า Node.js เป็นกระบวนทัศน์แบบอะซิงโครนัสที่เจ็บปวดน้อยที่สุดที่ฉันเคยทำงานด้วยห้องสมุดที่ดีมันยากกว่าการเขียนโค้ดซิงโครนัสเพียงเล็กน้อยเท่านั้น
- Pro: ไม่มีข้อบกพร่องมัลติเธรด / ล็อค จริงคุณลงทุนล่วงหน้าในการเขียนรหัส verbose มากขึ้นที่แสดงเวิร์กโฟลว์แบบอะซิงโครนัสที่เหมาะสมโดยไม่มีการดำเนินการปิดกั้น และคุณจำเป็นต้องเขียนแบบทดสอบและทำงานให้สำเร็จ (มันเป็นภาษาสคริปต์และชื่อตัวแปร fingering ไขมันจะถูกจับในเวลาทดสอบเท่านั้น) แต่เมื่อคุณทำให้มันทำงานพื้นที่ผิวสำหรับheisenbugs - ปัญหาแปลก ๆ ที่ปรากฏขึ้นครั้งเดียวในรอบล้านครั้ง - พื้นที่ผิวนั้นต่ำกว่ามาก ภาษีที่เขียนรหัส Node.js ถูกโหลดเข้าสู่ขั้นตอนการเข้ารหัสอย่างหนัก จากนั้นคุณมักจะจบลงด้วยรหัสที่มั่นคง
- Pro: JavaScript มีน้ำหนักเบากว่ามากสำหรับการแสดงฟังก์ชั่น มันยากที่จะพิสูจน์สิ่งนี้ด้วยคำพูด แต่JSON , การพิมพ์แบบไดนามิก, สัญญลักษณ์แลมบ์ดา, การรับมรดกต้นแบบ, โมดูลน้ำหนักเบา, ไม่ว่า ... มันแค่ใช้รหัสน้อยลงในการแสดงความคิดเดียวกัน
- คอนดิชั่น: บางทีคุณอาจชอบบริการการเข้ารหัสใน Java จริงเหรอ?
สำหรับมุมมองอื่นเกี่ยวกับ JavaScript และ Node.js ให้ตรวจสอบจาก Java ถึง Node.jsโพสต์บล็อกเกี่ยวกับการแสดงผลของนักพัฒนา Java และประสบการณ์การเรียนรู้ Node.js
โมดูล
เมื่อพิจารณาจากโหนดเก็บไว้ในใจว่าทางเลือกของห้องสมุด JavaScript จะDEFINEประสบการณ์ของคุณ คนส่วนใหญ่ใช้ตัวช่วยรูปแบบอะซิงโครนัสอย่างน้อยสองตัว (ขั้นตอน, ฟิวเจอร์ส, Async) และโมดูลน้ำตาล JavaScript ( Underscore.js )
ผู้ช่วย / JavaScript น้ำตาล:
- Underscore.js - ใช้สิ่งนี้ แค่ทำมัน. มันทำให้โค้ดของคุณดีและอ่านได้ด้วยสิ่งต่าง ๆ เช่น _.isString () และ _.isArray () ฉันไม่แน่ใจจริงๆว่าคุณจะเขียนรหัสที่ปลอดภัยได้อย่างไร นอกจากนี้สำหรับการปรับปรุงบรรทัดคำสั่ง-Fu ตรวจสอบตัวเองเน้น-CLI
โมดูลรูปแบบอะซิงโครนัส:
- ขั้นตอน - วิธีที่หรูหรามากในการแสดงการผสมผสานของการกระทำแบบอนุกรมและขนาน คำแนะนำส่วนตัวของฉัน ดูโพสต์ของฉันในลักษณะรหัสขั้นตอน
- ฟิวเจอร์ส - มีความยืดหยุ่นมากขึ้น (เป็นสิ่งที่ดีจริง ๆ หรือไม่) วิธีในการแสดงความต้องการผ่านการสั่งซื้อ สามารถแสดงสิ่งต่าง ๆ เช่น "เริ่ม a, b, c ในแบบคู่ขนานเมื่อ A และ B เสร็จให้เริ่ม AB เมื่อ A และ C เสร็จให้เริ่ม AC" ความยืดหยุ่นดังกล่าวต้องใช้ความระมัดระวังมากขึ้นเพื่อหลีกเลี่ยงข้อบกพร่องในเวิร์กโฟลว์ของคุณ (เช่นไม่เคยโทรกลับหรือโทรหลายครั้ง) ดูโพสต์ของ Raynosเกี่ยวกับการใช้ฟิวเจอร์ส (นี่คือโพสต์ที่ทำให้ฉัน "รับ" ฟิวเจอร์ส)
- Async - ไลบรารีแบบดั้งเดิมมากขึ้นด้วยวิธีหนึ่งสำหรับแต่ละรูปแบบ ฉันเริ่มต้นด้วยสิ่งนี้ก่อนที่ฉันจะเปลี่ยนศาสนาเป็นขั้นตอนและทำให้เกิดความเข้าใจว่ารูปแบบทั้งหมดใน Async สามารถแสดงในขั้นตอนด้วยกระบวนทัศน์ที่อ่านง่ายขึ้น
- TameJS - เขียนโดย OKCupid เป็นพรีคอมไพเลอร์ที่เพิ่มภาษาดั้งเดิมใหม่ "คอย" สำหรับการเขียนเวิร์กโฟลว์แบบอนุกรมและแบบขนานอย่างหรูหรา รูปแบบดูน่าทึ่ง แต่ก็ต้องมีการรวบรวมล่วงหน้า ฉันยังคงตัดสินใจของฉันในนี้
- StreamlineJS - คู่แข่งของ TameJS ฉันกำลังโน้มตัวเข้าหาเชื่อง แต่คุณสามารถตัดสินใจเองได้
หรือหากต้องการอ่านทั้งหมดเกี่ยวกับไลบรารีแบบอะซิงโครนัสดูบทสัมภาษณ์ผู้เขียนคนนี้
กรอบงานเว็บ:
- แสดง Great Ruby on Rails-esk framework สำหรับการจัดระเบียบเว็บไซต์ มันใช้JADEเป็นเครื่องมือสร้างเทมเพลต XML / HTML ซึ่งทำให้การสร้าง HTML นั้นเจ็บปวดน้อยลง
- jQueryแม้ว่าจะไม่ใช่โมดูลโหนดในทางเทคนิค jQuery กำลังกลายเป็นมาตรฐาน de-facto อย่างรวดเร็วสำหรับส่วนติดต่อผู้ใช้ฝั่งไคลเอ็นต์ jQuery จัดเตรียมตัวเลือกคล้าย CSS เพื่อ 'เคียวรี' สำหรับชุดของอิลิเมนต์ DOM ที่สามารถดำเนินการได้ (ตัวจัดการชุดคุณสมบัติสไตล์ ฯลฯ ) ตามเส้นเลือดเดียวกันเฟรมเวิร์กBootstrap CSS ของ Twitter , Backbone.jsสำหรับรูปแบบMVCและBrowserify.jsเพื่อรวมไฟล์ JavaScript ทั้งหมดของคุณไว้ในไฟล์เดียว โมดูลเหล่านี้ล้วน แต่กลายเป็นมาตรฐานตามความเป็นจริงดังนั้นอย่างน้อยคุณควรตรวจสอบพวกเขาหากคุณไม่เคยได้ยินพวกเขา
การทดสอบ:
- JSHint - ต้องใช้; ฉันไม่ได้ใช้สิ่งนี้ในตอนแรกซึ่งตอนนี้ดูเหมือนจะเข้าใจไม่ได้ JSLint เพิ่มการตรวจสอบพื้นฐานจำนวนมากที่คุณได้รับด้วยภาษาที่คอมไพล์อย่าง Java วงเล็บที่ไม่ตรงกันตัวแปรที่ไม่ได้ประกาศประเภทของรูปทรงและขนาดต่าง ๆ นอกจากนี้คุณยังสามารถเปิดรูปแบบต่าง ๆ ของสิ่งที่ฉันเรียกว่า "โหมดทวารหนัก" ซึ่งคุณยืนยันรูปแบบของช่องว่างและ whatnot ซึ่งก็โอเคถ้านั่นคือถ้วยชาของคุณ - แต่คุณค่าที่แท้จริงนั้นมาจากการได้รับผลตอบรับทันที คุณลืมปิด ")" ... โดยไม่ต้องเรียกใช้รหัสของคุณและกดบรรทัดที่ละเมิด "JSHint" เป็นตัวแปรเพิ่มเติมกำหนดของดักลาส Crockford 's JSLint
- มอคค่าคู่แข่งให้คำสัตย์สาบานซึ่งฉันเริ่มชอบ เฟรมเวิร์กทั้งสองจัดการพื้นฐานได้ดีพอ แต่รูปแบบที่ซับซ้อนมีแนวโน้มที่จะแสดงในมอคค่าได้ง่ายขึ้น
- คำสัตย์สาบานคำสัตย์สาบานที่สวยงามจริงๆ และจะพิมพ์รายงานที่น่ารัก (- สเปค) แสดงให้คุณเห็นว่ากรณีทดสอบใดผ่าน / ล้มเหลว ใช้เวลาเรียนรู้ 30 นาทีและคุณสามารถสร้างการทดสอบขั้นพื้นฐานสำหรับโมดูลของคุณได้อย่างง่ายดาย
- Zombie - การทดสอบแบบหัวขาดสำหรับ HTML และ JavaScript โดยใช้JSDomเป็น "เบราว์เซอร์" เสมือน สิ่งที่ทรงพลังมาก รวมเข้ากับReplayเพื่อรับการทดสอบอย่างรวดเร็วของรหัสในเบราว์เซอร์
- ความคิดเห็นเกี่ยวกับวิธีการ "คิดเกี่ยวกับ" การทดสอบ:
- การทดสอบไม่ใช่ทางเลือก ด้วยภาษาแบบไดนามิกเช่น JavaScript มีการตรวจสอบแบบคงที่น้อยมาก ตัวอย่างเช่นการส่งผ่านสองพารามิเตอร์ไปยังวิธีการที่คาดว่า 4 จะไม่หยุดจนกว่าจะมีการใช้รหัส แถบต่ำสวยสำหรับการสร้างข้อบกพร่องใน JavaScript การทดสอบขั้นพื้นฐานจำเป็นต่อการสร้างช่องว่างการตรวจสอบด้วยภาษาที่รวบรวม
- ลืมการตรวจสอบเพียงให้โค้ดทำงาน สำหรับทุกวิธีกรณีการตรวจสอบครั้งแรกของฉันคือ "ไม่มีการหยุดพัก" และนั่นคือกรณีที่เกิดไฟไหม้บ่อยที่สุด ยืนยันว่าโค้ดของคุณทำงานโดยไม่ต้องทำการดักจับข้อผิดพลาด 80% และจะทำอย่างมากเพื่อปรับปรุงความมั่นใจในโค้ดของคุณว่าคุณจะกลับมาอีกครั้งและเพิ่มกรณีการตรวจสอบที่เหมาะสมยิ่งที่คุณข้าม
- เริ่มต้นเล็ก ๆ และทำลายกำแพงป้องกันแรงเฉื่อย เราทุกคนขี้เกียจและกดเวลาและมันง่ายที่จะเห็นการทดสอบว่าเป็น "งานพิเศษ" ดังนั้นเริ่มต้นเล็ก ๆ เขียนกรณีทดสอบ 0 - โหลดโมดูลของคุณและรายงานผลสำเร็จ หากคุณบังคับตัวเองให้ทำสิ่งนี้มากสิ่งกีดขวางในการทดสอบแรงเฉื่อยก็จะพัง นั่นคือ <30 นาทีในการทำครั้งแรกของคุณรวมถึงการอ่านเอกสาร ตอนนี้เขียนกรณีทดสอบ 1 - เรียกหนึ่งในวิธีการของคุณและตรวจสอบ "ไม่มีตัวแบ่ง" นั่นคือคุณไม่ได้รับข้อผิดพลาดกลับมา กรณีทดสอบ 1 ควรใช้เวลาน้อยกว่าหนึ่งนาที เมื่อความเฉื่อยหายไปมันจะกลายเป็นเรื่องง่ายที่จะขยายความครอบคลุมการทดสอบของคุณเพิ่มขึ้น
- ตอนนี้วิวัฒนาการการทดสอบของคุณด้วยรหัสของคุณ อย่าได้รับการข่มขู่จากสิ่งที่การทดสอบแบบ end-to-end ที่ "ถูกต้อง" จะดูเหมือนกับเซิร์ฟเวอร์จำลองและทุกอย่าง รหัสเริ่มง่ายและวิวัฒนาการเพื่อจัดการกับกรณีใหม่; การทดสอบควรเกินไป เมื่อคุณเพิ่มเคสใหม่และความซับซ้อนใหม่ให้กับรหัสของคุณให้เพิ่มเคสทดสอบเพื่อออกกำลังกายโค้ดใหม่ ในขณะที่คุณพบข้อบกพร่องเพิ่มการตรวจสอบและ / หรือกรณีใหม่เพื่อให้ครอบคลุมรหัสที่มีข้อบกพร่อง เมื่อคุณทำการดีบั๊กและหมดความมั่นใจในโค้ดให้ย้อนกลับไปและเพิ่มการทดสอบเพื่อพิสูจน์ว่ามันทำในสิ่งที่คุณคิด รวบรวมสตริงของข้อมูลตัวอย่าง (จากบริการอื่น ๆ ที่คุณโทรเว็บไซต์ที่คุณขูดไม่ว่าอะไรก็ตาม) และป้อนไปยังรหัสการแยกวิเคราะห์ของคุณ สองสามกรณีที่นี่ปรับปรุงการตรวจสอบที่นั่นและคุณจะพบกับรหัสที่เชื่อถือได้สูง
นอกจากนี้ให้ตรวจสอบรายการอย่างเป็นทางการของโมดูล Node.js ที่แนะนำ อย่างไรก็ตามNode Modules Wiki ของ GitHub นั้นมีความสมบูรณ์มากกว่าและเป็นแหล่งข้อมูลที่ดี
เพื่อให้เข้าใจถึง Node จะเป็นประโยชน์ในการพิจารณาตัวเลือกการออกแบบที่สำคัญสองสามข้อ:
Node.js อ้างอิงจากเหตุการณ์และASYNCHRONOUS / การปิดกั้น. กิจกรรมเช่นการเชื่อมต่อ HTTP ที่เข้ามาจะทำการปิดฟังก์ชั่น JavaScript ที่ทำงานเล็กน้อยและเริ่มต้นงานแบบอะซิงโครนัสอื่น ๆ เช่นการเชื่อมต่อกับฐานข้อมูลหรือดึงเนื้อหาจากเซิร์ฟเวอร์อื่น เมื่องานเหล่านี้ถูกเตะออกไปแล้วฟังก์ชั่นเหตุการณ์จะเสร็จสิ้นและ Node.js กลับเข้าสู่โหมดสลีป ทันทีที่มีสิ่งอื่นเกิดขึ้นเช่นการเชื่อมต่อฐานข้อมูลที่ถูกสร้างขึ้นหรือเซิร์ฟเวอร์ภายนอกที่ตอบสนองต่อเนื้อหาฟังก์ชันการเรียกกลับจะทำงานและรหัส JavaScript ทำงานอีกมากซึ่งอาจทำให้เกิดงานอะซิงโครนัสมากยิ่งขึ้น (เช่นแบบสอบถามฐานข้อมูล) ด้วยวิธีนี้ Node.js จะมีความสุขในการสอดแทรกกิจกรรมสำหรับเวิร์กโฟลว์แบบขนานหลาย ๆ ชุดโดยเรียกใช้กิจกรรมใด ๆ ที่ไม่ได้ถูกบล็อกในเวลาใดก็ได้ นี่คือเหตุผลที่ Node.js ทำงานได้อย่างยอดเยี่ยมในการจัดการการเชื่อมต่อหลายพันรายการพร้อมกัน
ทำไมไม่ใช้เพียงหนึ่งกระบวนการ / เธรดต่อการเชื่อมต่อเหมือนทุกคนใน Node.js การเชื่อมต่อใหม่เป็นการจัดสรรฮีปขนาดเล็กมาก การหมุนกระบวนการใหม่จะใช้หน่วยความจำเพิ่มขึ้นอย่างมากเมกะไบต์บนบางแพลตฟอร์ม แต่ต้นทุนที่แท้จริงคือค่าใช้จ่ายที่เกี่ยวข้องกับการสลับบริบท เมื่อคุณมีเธรดเคอร์เนล 10 ^ 6 เคอร์เนลต้องทำงานเป็นจำนวนมากเพื่อหาว่าใครควรทำงานต่อไป งานจำนวนมากได้สร้างตัวจัดตารางเวลา O (1) สำหรับ Linux แต่ในที่สุดมันก็เป็นวิธีที่มีประสิทธิภาพมากกว่าที่จะมีกระบวนการที่ขับเคลื่อนด้วยเหตุการณ์เดียวมากกว่า 10 ^ 6 กระบวนการที่แข่งขันกันสำหรับเวลาของ CPU นอกจากนี้ภายใต้เงื่อนไขที่มากเกินไปโมเดลหลายกระบวนการจะทำงานได้ไม่ดีมากบริการด้านการจัดการและการจัดการที่สำคัญโดยเฉพาะ SSHD (หมายถึงคุณไม่สามารถเข้าสู่กล่องเพื่อดูว่ามันเป็นเกลียวจริง ๆ )
Node.js เป็นเกลียวเดียวและLOCK ฟรี Node.js ซึ่งเป็นตัวเลือกการออกแบบที่มีเจตนามากมีเพียงเธรดเดียวต่อกระบวนการ ด้วยเหตุนี้จึงเป็นไปไม่ได้ที่หลายเธรดจะสามารถเข้าถึงข้อมูลได้พร้อมกัน ดังนั้นไม่จำเป็นต้องล็อค หัวข้อเป็นเรื่องยาก ยากมากจริงๆ หากคุณไม่เชื่ออย่างนั้นคุณยังไม่ได้เขียนโปรแกรมแบบเธรดเพียงพอ การล็อคที่ถูกต้องนั้นทำได้ยากและส่งผลให้เกิดข้อบกพร่องที่ยากต่อการติดตาม การกำจัดการล็อกและการทำเธรดหลายทำให้หนึ่งในคลาสที่น่ารังเกียจที่สุดของบั๊กหายไป นี่อาจเป็นข้อได้เปรียบที่ใหญ่ที่สุดของโหนด
แต่ฉันจะใช้ประโยชน์จากกล่องหลัก 16 กล่องได้อย่างไร
สองทาง:
- สำหรับงานที่ต้องคำนวณหนัก ๆ ขนาดใหญ่เช่นการเข้ารหัสภาพ Node.js สามารถเปิดไฟกระบวนการเด็กหรือส่งข้อความไปยังกระบวนการผู้ปฏิบัติงานเพิ่มเติม ในการออกแบบนี้คุณจะต้องมีหนึ่งเธรดที่จัดการการไหลของเหตุการณ์และกระบวนการ N ที่ทำงานหนักในการคำนวณและเคี้ยวซีพียูอีก 15 ตัว
- สำหรับการปรับปริมาณงานบนเว็บเซอร์วิซคุณควรรันเซิร์ฟเวอร์ Node.js หลายเครื่องในหนึ่งกล่องต่อหนึ่งคอร์โดยใช้คลัสเตอร์ (ด้วย Node.js v0.6.x โมดูล "คลัสเตอร์" อย่างเป็นทางการที่เชื่อมโยงที่นี่จะแทนที่รุ่น Learnboost ซึ่งมี API อื่น) เซิร์ฟเวอร์ Node.js ในพื้นที่เหล่านี้สามารถแข่งขันกับซ็อกเก็ตเพื่อยอมรับการเชื่อมต่อใหม่สร้างสมดุลให้กับโหลด เมื่อยอมรับการเชื่อมต่อแล้วจะผูกเข้ากับกระบวนการที่ใช้ร่วมกันเหล่านี้อย่างแน่นหนา ในทางทฤษฎีสิ่งนี้ฟังดูแย่ แต่ในทางปฏิบัติมันใช้งานได้ค่อนข้างดีและช่วยให้คุณหลีกเลี่ยงการปวดหัวในการเขียนโค้ดที่ปลอดภัยสำหรับเธรด นอกจากนี้ยังหมายความว่า Node.js ได้รับความเกี่ยวข้องกับ CPU แคชที่ยอดเยี่ยมและมีประสิทธิภาพยิ่งขึ้นโดยใช้แบนด์วิดท์หน่วยความจำ
Node.js ให้คุณทำสิ่งที่ทรงพลังจริงๆโดยไม่ทำให้เหนื่อย สมมติว่าคุณมีโปรแกรม Node.js ที่ทำงานหลากหลายฟังพอร์ต TCPสำหรับคำสั่งเข้ารหัสรูปภาพบางรูป ด้วยโค้ดห้าบรรทัดคุณสามารถเพิ่มในพอร์ทัลการจัดการเว็บที่ใช้ HTTP ซึ่งแสดงสถานะปัจจุบันของงานที่ใช้งานอยู่ นี่เป็นเรื่องง่ายที่จะทำ:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");
ตอนนี้คุณสามารถกด URL และตรวจสอบสถานะของกระบวนการทำงานของคุณ เพิ่มปุ่มไม่กี่ปุ่มและคุณมี "พอร์ทัลการจัดการ" หากคุณมีสคริปต์ Perl / Python / Ruby ที่กำลังรันอยู่เพียงแค่ "เข้าสู่พอร์ทัลการจัดการ" ก็ไม่ใช่เรื่องง่าย
แต่ JavaScript ไม่ช้า / ไม่ดี / ไม่ดี / วางไข่ของปีศาจ? JavaScript มีความแปลกประหลาดบางอย่าง แต่ด้วย "ส่วนที่ดี" มีภาษาที่ทรงพลังมากและในทุกกรณี JavaScript คือภาษาบนไคลเอนต์ (เบราว์เซอร์) จาวาสคริปต์อยู่ที่นี่เพื่ออยู่; ภาษาอื่นกำลังกำหนดเป้าหมายเป็น IL และความสามารถระดับโลกกำลังแข่งขันกันเพื่อสร้างเครื่องมือ JavaScript ที่ทันสมัยที่สุด เนื่องจากบทบาทของ JavaScript ในเบราว์เซอร์จึงมีความพยายามด้านวิศวกรรมจำนวนมากที่ทำให้ JavaScript เป็นที่รู้จักอย่างรวดเร็ว V8เป็นเครื่องมือจาวาสคริปต์ล่าสุดและยิ่งใหญ่ที่สุดอย่างน้อยในเดือนนี้ มันทำให้ภาษาสคริปต์อื่น ๆ ทั้งในด้านประสิทธิภาพและความเสถียร (มองที่คุณทับทิม) และก็จะได้รับเท่านั้นที่ดีกว่ากับทีมใหญ่ทำงานกับปัญหาที่ Microsoft, Google, และ Mozilla ที่การแข่งขันในการสร้างเครื่องมือ JavaScript ที่ดีที่สุด (มันไม่ได้เป็น "ล่าม" JavaScript กับทุกที่ทันสมัยเครื่องมือทำตันของJITรวบรวมภายใต้ประทุนที่มีการตีความเพียงทางเลือกสำหรับรหัสรันครั้งเดียว) ใช่เราทุกคนหวังว่าเราจะสามารถแก้ไขตัวเลือกภาษาจาวาสคริปต์สองสามตัวได้ แต่มันก็ไม่ได้แย่ขนาดนั้น และภาษามีความยืดหยุ่นมากจนคุณไม่ได้เข้ารหัส JavaScript คุณกำลังเข้ารหัส Step หรือ jQuery มากกว่าภาษาอื่น ๆ ใน JavaScript ไลบรารีจะกำหนดประสบการณ์ ในการสร้างเว็บแอปพลิเคชั่นคุณต้องรู้จักจาวาสคริปต์อยู่แล้วดังนั้นการเขียนโค้ดลงบนเซิร์ฟเวอร์จึงมีการทำงานร่วมกันของทักษะ มันทำให้ฉันไม่ได้กลัวการเขียนรหัสลูกค้า
นอกจากนี้หากคุณจริงๆเกลียด JavaScript คุณสามารถใช้น้ำตาลประโยคเช่นCoffeeScript หรือสิ่งอื่นใดที่สร้างรหัส JavaScript เช่นGoogle Web Toolkit (GWT)
พูดถึง JavaScript อะไรคือ "การปิด" - ค่อนข้างเป็นวิธีแฟนซีในการบอกว่าคุณเก็บตัวแปรที่ จำกัด ขอบเขตไว้ในเครือข่ายการโทร ;) แบบนี้:
var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();
มาดูกันว่าคุณสามารถใช้ "myData" โดยไม่ทำอะไรที่น่าอึดอัดใจเช่นการ stashing มันลงในวัตถุได้อย่างไร และแตกต่างจากใน Java ตัวแปร "myData" ไม่จำเป็นต้องเป็นแบบอ่านอย่างเดียว คุณสมบัติภาษาที่ทรงพลังนี้ทำให้การเขียนโปรแกรมแบบอะซิงโครนัสน้อยลงอย่างมากและเจ็บปวดน้อยลง
การเขียนโค้ดแบบอะซิงโครนัสจะมีความซับซ้อนมากกว่าการเขียนสคริปต์แบบเธรดง่าย ๆ แต่ด้วย Node.js มันไม่ได้ยากขนาดนั้นและคุณจะได้รับประโยชน์มากมายนอกเหนือจากประสิทธิภาพและความสามารถในการขยายการเชื่อมต่อพร้อมกันนับพัน ..