ระบบแอปพลิเคชันแบบกระจายคืออะไร (แปล)

ปัจจุบันด้วยการพัฒนาอย่างรวดเร็วของอุตสาหกรรมสารสนเทศ การแข่งขันระหว่างองค์กรจะรุนแรงมากขึ้น ด้วยการขยายขนาดอย่างต่อเนื่องและการอัปเดตธุรกิจอย่างต่อเนื่อง องค์กรต่างๆ จึงต้องการโซลูชันแบบกระจายที่สมบูรณ์อย่างเร่งด่วนเพื่อจัดการสภาพแวดล้อมที่แตกต่างกันที่ซับซ้อน และบรรลุการบูรณาการอย่างสมบูรณ์ระหว่างอุปกรณ์ฮาร์ดแวร์ ระบบซอฟต์แวร์ สภาพแวดล้อมเครือข่าย และระบบฐานข้อมูลต่างๆ

ตลอดประวัติศาสตร์การพัฒนาของคอมพิวเตอร์ของมนุษย์ อุตสาหกรรมข้อมูลจะมีการเปลี่ยนแปลงแบบวัฏจักรทุกๆ สิบถึงสิบห้าปี ตั้งแต่ปีพ.ศ. 2493 ถึง พ.ศ. 2513 องค์กรต่างๆ ได้นำสถาปัตยกรรมเมนเฟรมเทอร์มินัลมาใช้เป็นหลัก ในขณะที่ระบบแอปพลิเคชันระดับองค์กรได้นำบริการแบ่งปันทรัพยากรมาใช้ในที่เดียว ,แบบรวมศูนย์. ในช่วงต้นทศวรรษ 1980 ระบบเปิดและระบบการจัดการฐานข้อมูลเชิงสัมพันธ์ถูกนำมาใช้กันอย่างแพร่หลายในองค์กรต่างๆ ด้วยความนิยมของ Windows ทำให้ทศวรรษ 1990 เป็นยุคของแอพพลิเคชั่นกราฟิก และสถาปัตยกรรมไคลเอนต์/เซิร์ฟเวอร์ก็ถูกนำมาใช้อย่างกว้างขวางเช่นกัน ในช่วงปลายทศวรรษ 1990 เทคโนโลยีวัตถุแบบกระจายปรากฏขึ้นในอุตสาหกรรมข้อมูล แอปพลิเคชันสามารถเผยแพร่บนแพลตฟอร์มระบบที่แตกต่างกัน และการสื่อสารร่วมกันของวัตถุระหว่างแพลตฟอร์มที่ต่างกันสามารถทำได้ผ่านเทคโนโลยีแบบกระจาย การรวมระบบองค์กรที่มีอยู่เข้ากับระบบแบบกระจายสามารถปรับปรุงความสามารถในการปรับขนาดของระบบแอปพลิเคชันระดับองค์กรได้อย่างมาก การเกิดขึ้นของแอปพลิเคชันแบบกระจายหลายระดับในช่วงปลายทศวรรษ 1990 ชี้ให้เห็นถึงหนทางสำหรับองค์กรต่างๆ ในการพัฒนาระบบแอปพลิเคชันให้ง่ายขึ้น

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

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

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

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

ความท้าทายที่เกิดจากแอปพลิเคชันแบบกระจายหลายระดับ

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

1. ความหลากหลายของมาตรฐานวัตถุแบบกระจาย

หากองค์กรต้องการสร้างระบบแบบกระจายหลายชั้น พวกเขาจะต้องปฏิบัติตามมาตรฐานอุตสาหกรรมแบบกระจาย มาตรฐานที่อิงอยู่นั้นส่งผลโดยตรงต่อการเปิดกว้างและความสามารถในการปรับขนาดของระบบแอปพลิเคชันระดับองค์กร ปัจจุบันมีมาตรฐานหลักสามมาตรฐานสำหรับออบเจ็กต์แบบกระจาย: DCOM ของ Microsoft, Enterprise JavaBeans/RMI ของ Sun Microsystems และ CORBA ของ OMG (Object Management Group) (Common Object Request Broker Architecture) DCOM เป็นมาตรฐานออบเจ็กต์แบบกระจายตามสภาพแวดล้อม Windows ดังนั้นประเภทของแพลตฟอร์มที่รองรับจึงมีจำกัด RMI และ Enterprise JavaBean เป็นสถาปัตยกรรมออบเจ็กต์แบบกระจายตามภาษา Java ซึ่งเหมาะสำหรับความต้องการข้ามแพลตฟอร์มขององค์กรขนาดใหญ่ อย่างไรก็ตาม โดยทั่วไปสภาพแวดล้อมของระบบแอปพลิเคชันจริงจะถูกสร้างขึ้นโดยภาษาการเขียนโปรแกรมที่แตกต่างกันหลายภาษา และอาศัยภาษาการเขียนโปรแกรมเพียงภาษาเดียวเท่านั้น . แอปพลิเคชันระดับองค์กรนั้นหายาก CORBA เป็นมาตรฐานออบเจ็กต์แบบกระจายที่พัฒนาโดยองค์กร OMG โดยมีส่วนร่วมของบริษัทซอฟต์แวร์และฮาร์ดแวร์ขนาดใหญ่มากกว่า 800 แห่ง ได้รับการสนับสนุนจากบริษัทขนาดใหญ่ เช่น IBM, Sun Microsystems, Oracle, Sybase, Novell และ Netscape การบูรณาการระหว่างแพลตฟอร์มต่างๆ การสื่อสารและการทำงานร่วมกันของออบเจ็กต์ ตราบใดที่ผู้จำหน่ายซอฟต์แวร์ปฏิบัติตาม IDL (Interface Definition Language) สำหรับการสื่อสารระหว่างออบเจ็กต์แอปพลิเคชันและ ORB พวกเขาสามารถให้บริการหรือรับบริการในรูปแบบของออบเจ็กต์ได้อย่างสมบูรณ์ ไม่จำเป็นต้องพิจารณาแพลตฟอร์มที่ต่างกัน โปรโตคอลการสื่อสารที่แตกต่างกันหรือภาษาการเขียนโปรแกรมที่แตกต่างกันทำให้เกิดความแตกต่าง และมุ่งเน้นไปที่การพัฒนาตรรกะของแอปพลิเคชัน จะเห็นได้ว่า CORBA มอบมาตรฐานแบบกระจายแบบเปิดและยืดหยุ่น ซึ่งเหมาะสำหรับองค์กรในการสร้างระบบแอปพลิเคชันแบบกระจายแบบหลายเลเยอร์

2. การพัฒนาแอปพลิเคชั่นแบบกระจายหลายชั้นนั้นซับซ้อนมาก

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

3. การจัดจำหน่ายและการจัดการแอปพลิเคชันแบบกระจายก็เป็นเรื่องที่ท้าทายเช่นกัน

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

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

ข้อกำหนดสำหรับแอปพลิเคชันแบบกระจายหลายระดับ

การพัฒนาแอปพลิเคชันแบบกระจายหลายระดับขององค์กรมักต้องการสิ่งต่อไปนี้:

ง่ายต่อการพัฒนา

แม้ว่าสถาปัตยกรรมแบบกระจายหลายชั้นจะต้องอาศัยความรู้ระดับระบบคอมพิวเตอร์เชิงลึกเป็นพื้นฐาน (เช่น ฐานข้อมูล การประมวลผลธุรกรรม ความปลอดภัยเครือข่าย เทคโนโลยี CORBA ฯลฯ) สำหรับนักพัฒนาไอที แต่ก็ไม่จำเป็นต้องมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับสถาปัตยกรรมพื้นฐาน ความซับซ้อนของระบบ ด้วยเทคโนโลยี ทำให้สามารถพัฒนาระบบแอปพลิเคชันแบบกระจายหลายชั้นที่มีประสิทธิภาพได้อย่างรวดเร็วและง่ายดายในสภาพแวดล้อมการพัฒนาแบบบูรณาการด้วยภาพ (IDE) ที่เป็นมิตร

ลดความซับซ้อนของงานกระจายและการจัดการ

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

ข้อกำหนดด้านความทนทานสำหรับแอปพลิเคชันระดับองค์กร

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

มีสถาปัตยกรรมแบบเปิดตามมาตรฐานอุตสาหกรรม

สิ่งที่องค์กรต้องการคือโซลูชันแบบเปิดตามมาตรฐานอุตสาหกรรมที่สามารถโต้ตอบกับระบบอื่นๆ ที่ได้มาตรฐาน

สามารถบูรณาการกับฐานข้อมูลต่างๆและระบบที่มีอยู่ได้

แอปพลิเคชันแบบกระจายระดับองค์กรจะต้องสามารถเข้าถึงทรัพยากรข้อมูลขององค์กรได้ และข้อมูลองค์กรมักจะถูกจัดเก็บไว้ในฐานข้อมูลขนาดใหญ่ที่ได้รับความนิยมในปัจจุบัน (เช่น Oracle, Sybase เป็นต้น) หรือเข้าถึงผ่าน TP Monitor (เช่น: IBM CICS, BEA Tuxedo ) ดังนั้นจึงจำเป็นต้องมีระบบแบบกระจายขององค์กรที่สามารถรวมเข้ากับฐานข้อมูลและระบบที่มีอยู่ได้

รองรับสภาพแวดล้อมแพลตฟอร์มที่แตกต่างกัน

แอปพลิเคชันแบบกระจายระดับองค์กรจำเป็นต้องรองรับสภาพแวดล้อมแพลตฟอร์มที่แตกต่างกัน ฝั่งเซิร์ฟเวอร์ควรรองรับแพลตฟอร์ม Windows NT หรือ UNIX และลูกค้าบนแพลตฟอร์มที่แตกต่างกันสามารถเข้าถึงแอปพลิเคชันบนเซิร์ฟเวอร์ รวมถึง: HTML, แอปเพล็ต Java, แอปพลิเคชัน Java, Dynamic HTML, C++ แอพพลิเคชัน ฯลฯ

เซิร์ฟเวอร์แอปพลิเคชันระดับองค์กร

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

แอปพลิเคชันเซิร์ฟเวอร์บนเว็บ

โดยทั่วไปแอปพลิเคชันเซิร์ฟเวอร์บนเว็บจะจัดเตรียมสภาพแวดล้อมการพัฒนาสำหรับแอปพลิเคชันอินเทอร์เน็ตบนเว็บ และเหมาะสำหรับการสร้างระบบแอปพลิเคชันไคลเอ็นต์/เซิร์ฟเวอร์บนเว็บ ในระบบนี้ เว็บแอปพลิเคชันเซิร์ฟเวอร์มักจะทำงานบนเว็บเซิร์ฟเวอร์เพื่อจัดการคำขอของไคลเอ็นต์ ODBC และ JDBC มักจะใช้เพื่อเชื่อมต่อกับฐานข้อมูล แอปพลิเคชันเซิร์ฟเวอร์ประเภทนี้โดยทั่วไปใช้งานง่ายและรองรับการพัฒนาแอปพลิเคชันเซิร์ฟเวอร์โดยใช้ EJB (Enterprise JavaBeans) อย่างไรก็ตาม ข้อบกพร่องของแอปพลิเคชันเซิร์ฟเวอร์ประเภทนี้ ได้แก่: มันไม่รองรับการประมวลผลธุรกรรม มีความปลอดภัยต่ำ มีการรองรับระบบการซื้อขายที่มีอยู่อย่างจำกัด และมีประสิทธิภาพต่ำ

แอปพลิเคชันเซิร์ฟเวอร์ที่ใช้มิดเดิลแวร์

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

หมายเหตุ: Load balancing คือชุดของเซิร์ฟเวอร์ที่ประกอบด้วยเซิร์ฟเวอร์หลายเครื่องในลักษณะสมมาตร แต่ละเซิร์ฟเวอร์มีสถานะเท่ากันและสามารถให้บริการภายนอกได้อย่างอิสระโดยไม่ต้องอาศัยความช่วยเหลือจากเซิร์ฟเวอร์อื่น ด้วยเทคโนโลยีการแบ่งปันโหลดบางประเภท คำขอที่ส่งจากภายนอกจะถูกกระจายอย่างเท่าเทียมกันไปยังเซิร์ฟเวอร์บางตัวในโครงสร้างสมมาตร และเซิร์ฟเวอร์ที่ได้รับคำขอจะตอบสนองต่อคำขอของลูกค้าอย่างเป็นอิสระ โหลดที่สมดุลสามารถกระจายคำขอของลูกค้าไปยังอาร์เรย์เซิร์ฟเวอร์ได้เท่าๆ กัน ซึ่งช่วยให้เข้าถึงข้อมูลสำคัญได้อย่างรวดเร็ว และแก้ปัญหาบริการการเข้าถึงพร้อมกันจำนวนมาก เทคโนโลยีคลัสเตอร์นี้สามารถบรรลุประสิทธิภาพที่ใกล้เคียงกับเมนเฟรมด้วยการลงทุนเพียงเล็กน้อย ข้อดีของการปรับสมดุลโหลดเครือข่าย: ประการแรก เทคโนโลยีการปรับสมดุลโหลดเครือข่ายช่วยให้มั่นใจได้ว่าเซิร์ฟเวอร์สามารถตอบสนองได้อย่างรวดเร็วแม้ภายใต้ภาระหนัก ประการที่สอง การปรับสมดุลโหลดเครือข่ายจำเป็นต้องระบุที่อยู่ IP (หรือชื่อโดเมน) ให้กับโลกภายนอกเท่านั้น หรือเซิร์ฟเวอร์หลายเครื่องในเครือข่ายโหลดบาลานซ์ไม่พร้อมใช้งาน บริการจะไม่ถูกขัดจังหวะ Network Load Balancing จะตรวจจับโดยอัตโนมัติเมื่อเซิร์ฟเวอร์ไม่พร้อมใช้งาน และสามารถกระจายการรับส่งข้อมูลไคลเอ็นต์ไปยังเซิร์ฟเวอร์ที่เหลือได้อย่างรวดเร็ว มาตรการป้องกันนี้สามารถช่วยให้คุณให้บริการได้อย่างต่อเนื่องสำหรับโปรแกรมธุรกิจที่สำคัญ และสามารถเพิ่มจำนวนเซิร์ฟเวอร์การปรับสมดุลโหลดเครือข่ายตามการเพิ่มขึ้นของการเข้าถึงเครือข่าย ประการที่สี่ สามารถใช้การปรับสมดุลโหลดเครือข่ายบนคอมพิวเตอร์ทั่วไปได้

บทความนี้มาจากบล็อก CSDN โปรดระบุแหล่งที่มาเมื่อพิมพ์ซ้ำ: http://blog.csdn.net/deantry119/archive/2009/12/28/5089598.aspx