สถาปัตยกรรม Micro vs เสาหินเซิร์ฟเวอร์

ขณะนี้เรากำลังทำงานเกี่ยวกับผลิตภัณฑ์ / โครงการใหม่ของเรามันเป็นแอปพลิเคชันไคลเอนต์ - เซิร์ฟเวอร์ที่มุ่งไปยังผู้ประกอบการอุตสาหกรรม / บริการเฉพาะ เรากำลังสร้างเซิร์ฟเวอร์ (ภาษา C และ Linux เท่านั้น) ที่ใช้โปรโตคอลที่กำหนดเองบน TCP ด้วย Java front-end เรามีงานเขียนโค้ดประมาณ 20% และต้องเผชิญกับสถานการณ์ที่ต้องเลือกระหว่างสถาปัตยกรรมเคอร์เนลแบบไมโครหรือเสาหิน

ฉันรู้ว่า Micro กับเสาหินมักจะเกี่ยวข้องกับสถาปัตยกรรมเคอร์เนล แต่เรากำลังพูดถึงเซิร์ฟเวอร์โดยเฉพาะ

ทำไมเซิร์ฟเวอร์ที่กำหนดเองและไม่ใช่สิ่งที่มีอยู่?

• ความต้องการ UI ของเรานั้นมีความสำคัญและมีพลวัตมากดังนั้นโซลูชันบนเว็บ / เว็บเบราว์เซอร์จึงไม่เหมาะสม
• การประมวลผลเชิงสถิติมีความสำคัญในตอนท้ายของไคลเอ็นต์ดังนั้นเบราว์เซอร์ก็มีความช่วยเหลือเล็กน้อย (แน่นอนว่าเราสามารถทำการประมวลผลที่จุดสิ้นสุดของเซิร์ฟเวอร์และส่งผ่านข้อมูลที่ประมวลผลไปยังไคลเอนต์ แต่นั่นก็หมายถึงโหลดจำนวนมากบนเซิร์ฟเวอร์และการสูญเสียทรัพยากรของลูกค้า)
• ยิ่งไปกว่านั้นด้วยเทคโนโลยีอย่างน้อยสามอย่าง (JS / HTML / CSS) เพื่อจัดการแม้กระทั่งเหตุการณ์เดียวทำให้ประสบการณ์ทั้งหมดเหมือนการกวาดบ้านท่ามกลางพายุทะเลทราย - คุณกวาดมันเป็นครั้ง n ครั้งฝุ่นสะสม n + 1 ครั้ง

แล้ว Micro และ Monolithic Server ล่ะ คุณกำลังพูดอะไร?

พิจารณาคำขอของลูกค้า (สมมุติ) ต่อไปนี้:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

ในการรับคำขอดังกล่าวเซิร์ฟเวอร์มักจะทำ (เราไม่สนใจเทคนิคการทำงานพร้อมกันเช่น thread และ forks เพื่อความเรียบง่าย):

• แยกสตริงคำขอ
• ระบุการกระทำ (ดึงข้อมูลHistoricDataSets LIMIT Year (2010)ในกรณีของเรา)
• โต้ตอบกับเลเยอร์แบบต่อเนื่อง (Oracle ในตัวอย่างของเรา) และดึงข้อมูล

• จัดรูปแบบข้อมูลตามโปรโตคอล Ex:

  response-id: 123
  สำเร็จ: true
  response-text: DataSets

• ตอบสนองต่อลูกค้าด้วยข้อมูลที่จัดรูปแบบดังนั้น

นี่คือสิ่งที่เรากำลังเรียกเซิร์ฟเวอร์เสาหิน (คล้ายกับเคอร์เนลเสาหินที่การทำงานของระบบปฏิบัติการทั้งหมดจะทำในพื้นที่เคอร์เนล)

พิจารณาคำขอเดิมอีกครั้งเมื่อได้รับในครั้งนี้เซิร์ฟเวอร์ (เราได้สมมติว่าหน่วยความจำที่แชร์เป็น IPC เท่านั้นเพื่อความเรียบง่าย):

• ทำให้การร้องขอลงในหน่วยความจำที่ใช้ร่วมกันสำหรับParserกระบวนการ
• Parserแยกวิเคราะห์สตริงระบุงานและนำExecutionerกระบวนการในการดำเนินการงาน
• Executionerแล้วผ่านข้อมูลไปยังFomatterกระบวนการซึ่งหลังจากการจัดรูปแบบข้อมูลลงในสตริงโปรโตคอลผลตอบแทนไปยังเซิร์ฟเวอร์
• เซิร์ฟเวอร์ส่งไปยังลูกค้า (ตอบกลับ)

แน่นอนแทนParser, ExecutionerและFormatterมันจะได้รับขั้นตอนเดียว แต่แยกต่างหาก นี่คือสิ่งที่เรากำลังเรียกไมโครเซิร์ฟเวอร์ (คล้ายกับไมโครเคอร์เนลที่ทำขั้นต่ำสุดที่จำเป็น) เซิร์ฟเวอร์จะรับฟังและตอบกลับอย่างมีประสิทธิภาพในขณะที่ทุกขั้นตอนได้รับการดูแลโดยกระบวนการที่แตกต่างกัน

เลือกอันไหนดี? เรากำลังสับสน! ในขณะที่เซิร์ฟเวอร์เสาหินถูกทดลองและทดสอบ (HTTP-Web Servers ส่วนใหญ่?) และโปรแกรมได้ง่ายขึ้นและสามารถจัดการการทำงานพร้อมกันได้ค่อนข้างดี เซิร์ฟเวอร์ขนาดเล็กซึ่งดูเหมือนว่ารวดเร็วและสอดคล้องกับหลักการ UNIX ของโปรแกรมเดียวที่จะทำภารกิจเดียว แต่ก็มีความซับซ้อนในการพัฒนาเช่นกัน การรักษาภาวะพร้อมกันในใจ

คำถาม
- ข้อดีและข้อเสียของแต่ละวิธีคืออะไร?
- ควรใช้เมื่อใด (อาจตีความได้ว่าเป็นคำถามทั่วไป: จะใช้ IPC เมื่อใด)
- หากเลือกเคอร์เนล Micro แล้วฟังก์ชั่นใดที่จำเป็นต้องเป็นส่วนหนึ่งของคอร์ - เซิร์ฟเวอร์

คำถามที่คล้ายกัน / ที่เกี่ยวข้อง

• อันตรายจากการใช้เสาหินขนาดใหญ่
• เบราว์เซอร์ Vs ภายนอกฝัง (Tangential)
• คำแนะนำสำหรับการแปลงแอปเสาหินเป็นมัลติเธรด (Tangential)

• ลูกค้าที่คาดหวังของเราสามารถแบ่งออกเป็นสองประเภท:
  • ใหญ่: ประมาณ 1,700 - 2,000 คำขอต่อนาที
  • เล็ก: ประมาณ 650 - 700 คำขอต่อนาที
• ปริมาณข้อมูลต่อรอบการร้องขอ (การร้องขอและการตอบสนองต่อมา) สามารถสันนิษฐานได้ว่าโดยปกติแล้วจะกระจายด้วยค่าเฉลี่ยประมาณ 1.20 MB และกรณีที่แย่กว่านั้นคือประมาณ 250-300 MB
• แนวคิดผลิตภัณฑ์ค่อนข้างใหม่ แต่มีความสามารถในการส่งผลกระทบต่อการดำเนินงานหลักดังนั้นเราคาดว่างบประมาณของลูกค้าจะมีความยืดหยุ่นเพียงโพสต์การติดตั้งล่าช้า (9-12 เดือน) หลังการติดตั้งซึ่ง จำกัด จำนวนฮาร์ดแวร์ที่ลูกค้าจะเต็มใจ ที่จะกระทำ esp คนตัวเล็ก
• ลูกค้าแต่ละรายจะมีสแต็กไคลเอ็นต์ - เซิร์ฟเวอร์ของตัวเอง เซิร์ฟเวอร์จะทำงานบนฮาร์ดแวร์ของลูกค้าที่จัดการโดยทีมงานของลูกค้าในขณะที่ลูกค้าจะได้รับการปรับใช้บนเครื่องของพนักงานที่ใช้งานได้
• การอัปเดตระยะไกลสำหรับไคลเอ็นต์และเซิร์ฟเวอร์แอปพลิเคชันเป็นสิ่งที่จำเป็น
• PUSHบริการแบบเรียลไทม์โดยเซิร์ฟเวอร์อาจเป็นที่ต้องการอย่างมากหากมีการคลิกผลิตภัณฑ์!

เศรษฐศาสตร์บางครั้งควบคุมคำตอบที่สำคัญยิ่งกว่าทฤษฎีหลักที่อยู่เบื้องหลังตัวเลือก สิ่งที่สำคัญที่สุดคือถ้าคุณกำลังมองหาบางสิ่งที่ 'กว้างใหญ่' ในกรณีของคุณที่แอพพลิเคชั่นของคุณต้องการการติดตั้งที่ยากลำบากอย่างแท้จริง - ยิ่งจำนวนล้อที่คุณประดิษฐ์น้อยลงเท่าไหร่ ถ้ามันใช้งานได้ฉันจะไม่สนใจว่ามันเป็นเสาหินหรือไมโคร ถ้าไม่ฉันก็ไม่สนใจเหมือนกัน!

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

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

2. HTTP ยังดีที่สุดหากคุณต้องการเพิ่มระดับ (คุณสามารถซื้อเครื่องถ่วงโหลดได้ง่ายถ้าคุณใช้) โปรโตคอลที่กำหนดเองต้องมีการเตรียมการที่กำหนดเอง

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

4. แม้ว่า HTTP จะไม่เหมาะกับการเรียกเก็บเงินอย่างแน่นอนให้ลองใช้BEEPซึ่งช่วยให้คุณทำสิ่งต่างๆให้มีประสิทธิภาพมากขึ้น หรือมีกลไก RPC ที่ได้รับการพิสูจน์แล้วมากมาย

5. ลองดูว่าคุณสามารถทำงานได้มากขึ้นโดยการประมวลผลแบบขนานในส่วนหลังและเซิร์ฟเวอร์จะถูกสอบถามเมื่อทำงานเสร็จแล้วเท่านั้น หากใช้งานได้ - มีเฟรมเวิร์กเช่นMPIหรือมีชุดเครื่องมือคำนวณอื่น ๆ อีกมากมายที่สามารถช่วยเหลือได้

6. ท้ายที่สุดในขณะที่ฉันอาจไม่อยู่ในฐานะที่จะรู้ถึงความต้องการที่แน่นอน แต่คุณอาจต้องกระจายข้อมูลจำนวนมากหรือทำการคำนวณจำนวนมากหากคุณต้องการทั้งคู่ - ยังมีความไร้ประสิทธิภาพของสถาปัตยกรรมหลักอยู่

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

ประสบความสำเร็จในการวิจัยระบบกระจายมากกว่าในเว็บแอป ดังนั้นคุณควรศึกษาว่า

Dipan

ดูเหมือนว่าฉันจะเป็นนักวิชาการ และตรงไปตรงมาฉันพบว่าวิธีที่สองจะเป็นเช่นเสาหิน นี่คือเท่าที่คุณควรไป:

1. แยกวิเคราะห์คำขอ
2. จัดการการร้องขอ

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

1. เคอร์เนลเสาหินมีอายุมากกว่า Microkernelมาก มันถูกใช้ใน Unix ขณะที่ความคิดของ microkernel ปรากฏในตอนท้ายของปี 1980

2. ตัวอย่างของระบบปฏิบัติการที่มีเคอร์เนลเสาหินคือUNIX, LINUX ในขณะที่ระบบปฏิบัติการที่มี Microkernel คือQNX, L4, HURD , ตอนแรกมัค (ไม่ใช่ mac os x) ในภายหลังมันจะแปลงเป็นไฮบริดเคอร์เนลแม้MINIXไม่ใช่เคอร์เนลบริสุทธิ์ รวบรวมเป็นส่วนหนึ่งของเคอร์เนล

3. เสาหินเคอร์เนลเร็วกว่า microkernel ขณะที่จักร microkernel แรกคือ 50% ช้ากว่าเสาหินเคอร์เนลในขณะที่รุ่นที่ใหม่กว่าเช่น L4 เพียง2% หรือ 4% ช้ากว่าเคอร์เนลเสาหิน

4. เสาหินเคอร์เนลโดยทั่วไปจะมีขนาดใหญ่ ในขณะที่เคอร์เนลบริสุทธิ์จะต้องมีขนาดเล็กแม้จะอยู่ในหน่วยประมวลผลแคชระดับแรก (microkernel รุ่นแรก)

5. ในเสาหินเคอร์เนลอาศัยโปรแกรมควบคุมอุปกรณ์ในพื้นที่ว่างของเคอร์เนล ในขณะที่ใน Microkernel อาศัยโปรแกรมควบคุมอุปกรณ์ในพื้นที่ของผู้ใช้

6. เนื่องจากไดรเวอร์อุปกรณ์อยู่ในพื้นที่เคอร์เนลจึงทำให้เคอร์เนลเสาหินมีความปลอดภัยน้อยกว่า microkernel (ความล้มเหลวในไดรเวอร์อาจนำไปสู่ความผิดพลาด) ในขณะที่ Microkernels มีความปลอดภัยมากกว่าเคอร์เนลเสาหินดังนั้นจึงใช้ในอุปกรณ์ทางทหารบางอย่าง

7. เสาหินเมล็ดใช้สัญญาณและซ็อกเก็ตเพื่อให้แน่ใจว่า IPC ในขณะที่วิธีการ microkernel ใช้คิวข้อความ microkernel 1 เจนดำเนินการ IPC ไม่ดีดังนั้นจึงช้าในบริบทของสวิตช์

8. เพิ่มคุณลักษณะใหม่กับระบบเสาหินหมายถึงrecompiling เมล็ด ในขณะที่คุณสามารถเพิ่มคุณลักษณะใหม่หรือแพทช์โดยไม่ต้อง recompiling