เรามีแอปพลิเคชั่น Ruby on Rails ขนาดใหญ่ (ผู้ใช้ 25 ล้านคนต่อเดือน) ผู้บริหารของเราตัดสินใจเขียนใหม่ใน Node.js ฉันบ้าไหม


24

กรุณาบอกฉันว่า:

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

เพื่อชี้แจงเรากำลังเขียนเซิร์ฟเวอร์ส่วนหน้าซึ่งจะพูดคุยกับแอพพลิเคชั่น Ruby on Rails ที่เรามีอยู่ในฐานะ API ในขณะเดียวกันเราจะปรับปรุงแอพพลิเคชัน Ruby on Rails ของเราให้เป็นบริการ

รายละเอียดเพิ่มเติมเกี่ยวกับสถาปัตยกรรมที่มีอยู่:

  • Memcachedสำหรับการแคช partials HTML
  • redisสำหรับเซสชั่นและบางแคชข้อมูลที่มีโครงสร้าง
  • MySQLหลักเดียวหลายทาส
    • มีโต๊ะขนาดใหญ่ที่ยอมรับการเขียนได้มากมาย (ลองนึกภาพโพล)
    • มิฉะนั้นส่วนใหญ่อ่าน
  • MongoDBสำหรับข้อมูลเมตาบางส่วน
  • Ruby on Rails 3.0
  • nginxและยูนิคอร์น

33
Sheesh, ภาษาฮิปสเตอร์เหล่านี้ทั้งหมด แอปพลิเคชั่น php ที่เขียนขึ้นอย่างดีจะปรับขนาดได้อย่างง่ายดายเครื่องมือแบบดั้งเดิมทำงานได้อย่าปล่อยให้ฮิปสเตอร์เหล่านั้นบอกคุณเป็นอย่างอื่น
Darknight

5
คำถามที่ควรเพิ่มเติมตามแนวของ "การปรับปรุงจะประหยัดเงินให้กับธุรกิจมากพอที่จะทำให้คุ้มค่าหรือไม่" มันอาจประหยัดเงินได้มากกว่า 5 ปี แต่การเขียนใหม่มีราคาแพงและใช้เวลานาน - ถ้าโค้ดของคุณยุ่งเหยิงน่ากลัวฉันคิดว่าผู้จัดการของคุณกำลังโมโห
Mikey C

4
หากพิจารณาว่ามีการเขียนซ้ำคุณสามารถพิจารณาย้ายฟรอนต์เอนด์ของคุณไปยังจาวาสคริปต์ฝั่งไคลเอ็นต์ซึ่งหมายความว่าคุณจะไม่มีเซิร์ฟเวอร์หน้าแบบไดนามิกอีกต่อไปเพียงแค่ไฟล์คงที่
Joeri Sebrechts

11
@Darknight จำไว้ว่า ณ จุดหนึ่ง PHP เป็นภาษาฮิปสเตอร์และผู้คนที่แสดงให้เห็นว่าสามารถนำไปใช้ในผลิตภัณฑ์ที่ประสบความสำเร็จได้รับการส่งเสริมการยอมรับในขณะที่นักพัฒนาเว็บ Perl กำลังคึกคักที่ PHP hipsters

9
ฉันกำลังประหลาดใจมากที่ไม่มีใครได้นำขึ้นโจ Spolsky บทความสิ่งที่คุณไม่ควรทำ ฉันไม่ได้บอกว่าการเขียนซ้ำทั้งหมดนั้นไม่ดี แต่ฉันเห็นด้วยกับ @MikeyC ว่าพวกเขาควรเข้าหาด้วยความระมัดระวังอย่างยิ่ง
Dan Pichelman

คำตอบ:


22

คำถามส่วนใหญ่ที่คุณถามไม่สามารถตอบได้โดยไม่มีบริบทและมีการจัดการที่มากขึ้นหรือน้อยลงทำให้เลือกสำหรับคุณ ... เว้นแต่คุณจะถาม 'ฉันควรจะออกจากและหางานใหม่ในการเผชิญกับการเปลี่ยนแปลงทั้งหมดนี้ ?'

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

ฉันเพิ่งเริ่มเส้นทางของการเขียนลอจิกของเซิร์ฟเวอร์เล็กน้อยใน node.js เหตุผลหลักก็คือมันถูกเขียนใน. NET และเราต้องการที่จะย้ายออกจากสภาพแวดล้อม MS ลงในการติดตาม

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

มันมีด้านมืดแม้ว่าทุกคนและสุนัขของเขาที่ได้ทำการพัฒนา front-end ด้วย JavaScript - และนั่นจะเป็นนักพัฒนา front-end ทุกคนที่ฉันหวังว่า - จะตื่นเต้นเล็กน้อยเมื่อคุณพูดถึง node.js ว่า 'server side javascript 'แต่นั่นไม่ได้หมายความว่านักพัฒนาส่วนหน้าจะมีประสบการณ์ที่จำเป็นในการเขียนแอพฝั่งเซิร์ฟเวอร์ที่ดี

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

สำหรับผู้ที่ได้ทำทั้งด้านหน้าและด้านหลัง - และเพลิดเพลินไปกับทั้งสอง - โดยไม่ต้องเปลี่ยนบริบททางจิตจากส่วนหน้าไปยังส่วนท้ายของภาษาเป็นโบนัสจริง ๆ ที่ฉันคิดว่าในท้ายที่สุดจะช่วยเพิ่มผลผลิตในทีมของเรา


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

ใช่ประเด็นหลักของฉันที่มีข้อความนั้นคือส่วนหน้าเฉพาะนักพัฒนาเท่านั้นโดยทั่วไปจะไม่ยุ่งเหยิงโดยเฉพาะเมื่อพูดถึงการจัดการข้อยกเว้น Come on, มันเกือบจะ 2017 แล้ว!
dave.zap

8

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

  1. Node.js ไม่ใช่เวทมนต์ แอปพลิเคชันของคุณมีผู้ใช้จำนวนมากดังนั้นจึงไม่มีทางแน่ใจได้ว่าจะทำให้เร็วขึ้น

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

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

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

เนื่องจาก Node.js เป็นเธรดเดี่ยวเว้นแต่ว่าจะกำหนดค่าไว้อย่างชัดเจนจึงไม่สามารถใช้ประโยชน์จากCPUหลายตัวได้

ดูความคิดเห็นด้วย พวกเขาให้ข้อมูลเชิงลึกที่ดีเกี่ยวกับการทำงานของ Node.js


16
ทรัพยากรน้อยลงเพราะหัวข้อเดียว? คุณคิดว่ากระทู้พิเศษเหล่านั้นจะทำอะไร
โจ

@ โจเท่าที่ฉันเข้าใจว่าพวกเขาจะเพิ่มขึ้นในโหนด js มันเป็นวิธีที่ดีที่สุดในการกำจัดคำขอโดยเร็วที่สุดเท่าที่จะทำได้โดยการกรอกในหนึ่งครั้งหรือดำเนินการต่อในครั้งต่อไปเพื่อเป็นโหนดที่ซื่อสัตย์ js เป็นเทคโนโลยีเดียวที่ฉันได้ผลิตแอพพลิเคชั่นสำหรับดังนั้นฉันอาจไม่ใช่คนที่ดีที่สุดในการเปรียบเทียบกับเทคโนโลยีด้านเซิร์ฟเวอร์อื่น ๆ ซึ่งเป็นเหตุผลที่ฉันละเว้นจากการเปรียบเทียบและเพิ่งวางสิ่งที่ฉันคิดว่าฉันรู้ในโหนด js คำตอบของฉัน.
Akshat Jiwan Sharma

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

ฉันเห็นสิ่งที่คุณหมายถึงฉันจะปรับปรุงคำตอบในไม่ช้า (อ่านหลังจากการวิจัยบางอย่าง)
Akshat Jiwan Sharma

10
มันไม่ใช่แค่ซีพียูเท่านั้น เหตุผลที่ว่าทำไมมันเป็นสิ่งสำคัญที่จะจัดการกับทุกคำขอให้เร็วที่สุดเท่าที่เป็นไปได้ (ในระบบเดียวเธรดไม่มีอื่น ๆ พร้อมกัน) เป็นเพราะเซิร์ฟเวอร์ไม่สามารถให้บริการการร้องขอหลายครั้งเพื่อให้ทุกคำขอต้องรอจนกว่าคุณจะได้เสร็จสิ้นการจัดการทั้งหมดของ คำขอก่อนมัน การทำงานพร้อมกันถูกต้องหมายถึงการรอคอยน้อยลง การใช้เธรดไม่ได้ทำให้ประสิทธิภาพลดลงและการมีเธรดเดี่ยว (โดยค่าเริ่มต้นหรืออย่างอื่น) ไม่ใช่ข้อได้เปรียบด้านประสิทธิภาพ
Peter Hosey
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.