การตั้งค่าเซิร์ฟเวอร์ของฉันสำหรับ API ที่ใช้งานหนัก


9

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

ฉันมีแอปพลิเคชันซึ่งจะใช้ประโยชน์จาก API ที่ฉันเขียน ผู้ใช้ / นักพัฒนารายอื่นจะใช้ API นี้ด้วย เซิร์ฟเวอร์ API จะได้รับคำขอและส่งต่อไปยังเซิร์ฟเวอร์ผู้ปฏิบัติงาน API จะทำการร้องขอ mysql db สำหรับการบันทึกการพิสูจน์ตัวตนและการ จำกัด อัตราเท่านั้น

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

การตั้งค่านี้มีประสิทธิภาพสำหรับคุณหรือไม่ มีวิธีที่ดีกว่าในการปรับโครงสร้างนี้หรือไม่? ฉันควรพิจารณาปัญหาอะไรบ้าง โปรดดูภาพด้านล่างฉันหวังว่ามันจะช่วยให้เข้าใจป้อนคำอธิบายรูปภาพที่นี่

คำตอบ:


17

ห้องว่างที่สูงขึ้น

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

ดำเนินการต่อไปในเส้นทางเดียวกัน

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

ใช้เซิร์ฟเวอร์ Queue Message

มีประสิทธิภาพมากขึ้นการจัดคิวข้อความซอฟต์แวร์โครงสร้างพื้นฐานการใช้งานที่ออกแบบมาเพื่อการนี้เช่นActiveMQ คุณสามารถใช้ RESTful API ของ ActiveMQ เพื่อรับคำขอ POST จากผู้ใช้ API และคนทำงานที่ไม่ทำงานสามารถรับข้อความต่อไปในคิว อย่างไรก็ตามนี่อาจเกินความต้องการของคุณ - มันถูกออกแบบมาเพื่อความหน่วงแฝงความเร็วและข้อความนับล้านต่อวินาที

ใช้ผู้ดูแลสัตว์เลี้ยง

โดยพื้นฐานแล้วคุณอาจต้องการดูZookeeperแม้ว่าจะไม่ใช่เซิร์ฟเวอร์คิวข้อความโดยเฉพาะ เราใช้เงิน $ เพื่อวัตถุประสงค์ที่แน่นอนนี้ เรามีชุดเซิร์ฟเวอร์สามชุด (คล้ายกับเซิร์ฟเวอร์ API ของคุณ) ที่รันซอฟต์แวร์เซิร์ฟเวอร์ Zookeeper และมีส่วนหน้าเว็บสำหรับจัดการคำขอจากผู้ใช้และแอปพลิเคชัน ส่วนหน้าของเว็บรวมถึงการเชื่อมต่อแบ็คเอนด์ของ Zookeeper กับพนักงานนั้นมี load balancer เพื่อให้แน่ใจว่าเราดำเนินการประมวลผลคิวต่อไปแม้ว่าเซิร์ฟเวอร์จะหยุดทำงานเพื่อการบำรุงรักษา เมื่องานเสร็จแล้วผู้ปฏิบัติงานจะบอกคลัสเตอร์ Zookeeper ว่างานเสร็จสมบูรณ์ หากผู้ปฏิบัติงานเสียชีวิตงานนั้นจะถูกส่งไปทำงานอื่นให้เสร็จ

ข้อกังวลอื่น ๆ

  • ตรวจสอบให้แน่ใจว่างานเสร็จสมบูรณ์ในกรณีที่ผู้ปฏิบัติงานไม่ตอบสนอง
  • API จะทราบได้อย่างไรว่างานเสร็จสมบูรณ์และดึงข้อมูลจากฐานข้อมูลของผู้ปฏิบัติงาน
  • พยายามลดความซับซ้อน คุณต้องการเซิร์ฟเวอร์ MySQL อิสระในแต่ละโหนดของผู้ปฏิบัติงานหรือพวกเขาสามารถพูดคุยกับเซิร์ฟเวอร์ MySQL (หรือจำลองแบบ MySQL Cluster) บนเซิร์ฟเวอร์ API ได้หรือไม่?
  • ความปลอดภัย ทุกคนสามารถส่งงานได้หรือไม่ มีการรับรองความถูกต้องหรือไม่
  • คนงานคนไหนควรได้งานต่อไป คุณไม่ได้พูดถึงว่างานนั้นคาดว่าจะใช้เวลา 10ms หรือ 1 ชั่วโมง หากพวกมันเร็วคุณควรลบเลเยอร์เพื่อลดความหน่วง หากพวกเขาช้าคุณควรระวังให้มากเพื่อให้แน่ใจว่าคำขอที่สั้นกว่านั้นจะไม่ติดอยู่กับคำขอที่ใช้งานมานาน

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

@Abs - ขอบคุณสำหรับการโหวตครั้งแรก! หากคุณตัดสินใจที่จะเอาชั้น API ที่ผมขอแนะนำไม่ได้ทำ DNS robin ปัดและการติดตั้ง HAProxy (โดยเฉพาะคู่) ตามที่อธิบายในเรื่องนี้บทความ ด้วยวิธีนี้คุณไม่จำเป็นต้องจัดการกับการหมดเวลา
คลั่ง

@abs คุณไม่ต้องลบเลเยอร์ API แต่การเพิ่มความซ้ำซ้อน (ความล้มเหลวของ CARP หรือที่คล้ายกัน) จะเป็นข้อพิจารณาที่สำคัญในการขจัดจุดความล้มเหลวจุดเดียว ...
voretaq7

เท่าที่การส่งข้อความไปฉันขอแนะนำให้ดูอย่างใกล้ชิดที่ RabbitMQ ก่อนที่คุณจะตัดสินใจ: rabbitmq.com
Antonius Bloch

2

ปัญหาที่ใหญ่ที่สุดที่ฉันเห็นคือการขาดการวางแผนล้มเหลว

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

ฉันขอแนะนำให้คุณดูโครงการ Linux Virtual Server ( http://www.linuxvirtualserver.org/ ) เพื่อรับทราบว่าการทำงานของ load balancing และ failover ทำงานอย่างไรและเพื่อให้ทราบว่าสิ่งเหล่านี้มีประโยชน์ต่อการออกแบบของคุณอย่างไร

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


คุณจะใช้กลไกการล้มเหลวในสถานการณ์นี้อย่างไร ภาพรวมทั่วไปน่าจะดีมาก
Abs

จากแผนภาพของคุณคุณควรศึกษา Linux Virtual Server (LVS) ไปที่linuxvirtualserver.orgและเริ่มเรียนรู้ทุกสิ่งที่คุณทำได้
Chris Ting

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

@Abs: มีปัญหามากมายที่คุณอาจเผชิญ คำถามของคุณมีชิ้นส่วนที่เป็นอัตนัยมากมายและฉันไม่ต้องการที่จะบอกคุณในสิ่งที่ฉันทำเอง ฉันไม่ต้องสนับสนุนการตั้งค่าของคุณ คุณทำ. คำตอบที่แท้จริงของฉันคือเรียนรู้เกี่ยวกับ failover และความพร้อมใช้งานสูง
Chris Ting
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.