โลกไม่หยุดนิ่ง ความก้าวหน้าก่อให้เกิดความท้าทายทางเทคโนโลยีใหม่ๆ เพื่อให้สอดคล้องกับข้อกำหนดที่เปลี่ยนแปลง สถาปัตยกรรมของระบบสารสนเทศจึงต้องมีการพัฒนา วันนี้เราจะพูดถึงสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ ภาวะพร้อมกัน ภาวะพร้อมกัน ความไม่ตรงกัน และวิธีที่คุณสามารถใช้ชีวิตอย่างสงบสุขกับทั้งหมดนี้ใน Erlang
การแนะนำ
เราซึ่งเป็นผู้พัฒนาเลือกวิธีการแลกเปลี่ยนข้อมูลในระบบทั้งนี้ขึ้นอยู่กับขนาดของระบบที่ออกแบบและข้อกำหนด ในกรณีส่วนใหญ่ เพื่อจัดระเบียบปฏิสัมพันธ์ของบริการ ตัวเลือกการทำงานอาจเป็นโครงการกับนายหน้า ตัวอย่างเช่น ตาม RabbitMQ หรือ kafka แต่บางครั้งกระแสของเหตุการณ์ SLA และระดับการควบคุมระบบทำให้การส่งข้อความสำเร็จรูปไม่เหมาะกับเรา แน่นอน คุณสามารถทำให้ระบบซับซ้อนได้เล็กน้อยโดยรับผิดชอบต่อเลเยอร์การขนส่งและการสร้างคลัสเตอร์ เช่น การใช้ ZeroMQ หรือ nanomsg แต่หากระบบมีปริมาณงานและความสามารถของคลัสเตอร์ Erlang มาตรฐานเพียงพอ ปัญหาในการแนะนำเอนทิตีเพิ่มเติมจำเป็นต้องมีการศึกษาโดยละเอียดและเหตุผลทางเศรษฐกิจ
หัวข้อของแอปพลิเคชันแบบกระจายเชิงโต้ตอบค่อนข้างกว้าง เพื่อให้อยู่ในรูปแบบของบทความ หัวข้อของการสนทนาในวันนี้จะเป็นสภาพแวดล้อมที่เป็นเนื้อเดียวกันที่สร้างขึ้นบน Erlang/Elixir เท่านั้น ระบบนิเวศ Erlang/OTP ช่วยให้คุณสามารถนำสถาปัตยกรรมเชิงโต้ตอบไปใช้โดยใช้ความพยายามน้อยที่สุด แต่ไม่ว่าในกรณีใด เราจะต้องมีเลเยอร์ข้อความ
พื้นฐานทางทฤษฎี
การออกแบบเริ่มต้นด้วยการกำหนดเป้าหมายและข้อจำกัด เป้าหมายหลักไม่ใช่การพัฒนาเพื่อประโยชน์ในการพัฒนา เราจำเป็นต้องได้รับเครื่องมือที่ปลอดภัยและปรับขนาดได้บนพื้นฐานที่เราสามารถสร้างได้ และที่สำคัญที่สุดคือพัฒนาแอปพลิเคชันสมัยใหม่ในระดับต่างๆ โดยเริ่มจากแอปพลิเคชันเซิร์ฟเวอร์เดียวที่ให้บริการผู้ชมกลุ่มเล็กๆ ซึ่งต่อมาสามารถพัฒนาเป็นคลัสเตอร์ได้ถึง 50 รายการ -60 โหนด ซึ่งลงท้ายด้วยการรวมคลัสเตอร์ ดังนั้นเป้าหมายหลักคือการเพิ่มผลกำไรสูงสุดโดยการลดต้นทุนในการพัฒนาและการเป็นเจ้าของระบบขั้นสุดท้าย
ให้เราเน้นข้อกำหนดหลัก 4 ประการสำหรับระบบขั้นสุดท้าย:
- Сมุ่งเน้นเหตุการณ์
ระบบพร้อมเสมอที่จะส่งผ่านเหตุการณ์และดำเนินการที่จำเป็น - Мความสามารถในการขยายขนาด
แต่ละบล็อกสามารถปรับขนาดได้ทั้งแนวตั้งและแนวนอน ระบบทั้งหมดจะต้องมีความสามารถในการเติบโตในแนวนอนอย่างไม่มีที่สิ้นสุด - Оความอดทนต่อความผิดพลาด
ทุกระดับและบริการทั้งหมดควรสามารถกู้คืนจากความล้มเหลวได้โดยอัตโนมัติ - Гรับประกันเวลาตอบสนอง
เวลาเป็นสิ่งมีค่าและผู้ใช้ไม่ควรรอนานเกินไป
จำเทพนิยายเก่าๆ เกี่ยวกับ “เครื่องยนต์เล็กๆ ที่ทำได้” ได้ไหม? เพื่อให้ระบบที่ออกแบบสามารถออกจากขั้นตอนต้นแบบได้สำเร็จและมีความก้าวหน้า รากฐานของระบบจะต้องเป็นไปตามข้อกำหนดขั้นต่ำ หมอกควัน.
มีการเพิ่มอีกประเด็นหนึ่งในการส่งข้อความในฐานะเครื่องมือโครงสร้างพื้นฐานและเป็นพื้นฐานสำหรับบริการทั้งหมด: ความสะดวกในการใช้งานสำหรับโปรแกรมเมอร์
มุ่งเน้นเหตุการณ์
เพื่อให้แอปพลิเคชันขยายจากเซิร์ฟเวอร์เดียวไปสู่คลัสเตอร์ สถาปัตยกรรมของแอปพลิเคชันจะต้องรองรับการเชื่อมต่อแบบหลวมๆ โมเดลอะซิงโครนัสตรงตามข้อกำหนดนี้ โดยผู้ส่งและผู้รับจะใส่ใจกับการโหลดข้อมูลของข้อความ และไม่ต้องกังวลกับการส่งและกำหนดเส้นทางภายในระบบ
ความสามารถในการปรับขนาด
ความสามารถในการปรับขนาดและประสิทธิภาพของระบบอยู่ติดกัน ส่วนประกอบของแอปพลิเคชันจะต้องสามารถใช้ทรัพยากรที่มีอยู่ทั้งหมดได้ ยิ่งเราสามารถใช้กำลังการผลิตได้อย่างมีประสิทธิภาพและวิธีการประมวลผลของเราอย่างเหมาะสมมากขึ้นเท่าไร เราก็จะเสียเงินไปกับอุปกรณ์น้อยลงเท่านั้น
Erlang สร้างสภาพแวดล้อมที่มีการแข่งขันสูงภายในเครื่องเดียว สามารถตั้งค่าสมดุลระหว่างการทำงานพร้อมกันและความขนานได้โดยเลือกจำนวนเธรดระบบปฏิบัติการที่พร้อมใช้งานสำหรับ Erlang VM และจำนวนตัวกำหนดเวลาที่ใช้เธรดเหล่านี้
กระบวนการ Erlang ไม่แชร์สถานะและทำงานในโหมดไม่บล็อก ซึ่งให้เวลาแฝงค่อนข้างต่ำและมีปริมาณงานสูงกว่าแอปพลิเคชันที่ใช้การบล็อกแบบดั้งเดิม ตัวกำหนดเวลาของ Erlang ช่วยให้มั่นใจได้ถึงการจัดสรร CPU และ IO อย่างยุติธรรม และการไม่มีการบล็อกทำให้แอปพลิเคชันสามารถตอบสนองแม้ในช่วงที่มีการใช้งานสูงสุดหรือเกิดความล้มเหลว
ในระดับคลัสเตอร์ ปัญหาในการกำจัดก็มีอยู่เช่นกัน สิ่งสำคัญคือเครื่องทั้งหมดในคลัสเตอร์จะต้องโหลดเท่ากัน และเครือข่ายต้องไม่โอเวอร์โหลด ลองจินตนาการถึงสถานการณ์: ปริมาณการใช้งานของผู้ใช้จะเข้าสู่ Balancer ขาเข้า (haproxy, nginx ฯลฯ) โดยจะกระจายคำขอการประมวลผลเท่าๆ กันที่สุดเท่าที่จะเป็นไปได้ระหว่างชุดแบ็กเอนด์ที่มีอยู่ ภายในโครงสร้างพื้นฐานของแอปพลิเคชัน บริการที่ใช้อินเทอร์เฟซที่จำเป็นนั้นเป็นเพียงไมล์สุดท้ายเท่านั้น และจะต้องขอบริการอื่น ๆ มากมายเพื่อตอบสนองคำขอเริ่มแรก คำขอภายในยังต้องมีการกำหนดเส้นทางและการปรับสมดุลด้วย
เพื่อจัดการกระแสข้อมูลอย่างมีประสิทธิภาพ การส่งข้อความจะต้องจัดเตรียมอินเทอร์เฟซให้นักพัฒนาเพื่อจัดการการกำหนดเส้นทางและการทำโหลดบาลานซ์ ด้วยเหตุนี้ นักพัฒนาจะสามารถใช้รูปแบบไมโครเซอร์วิส (ตัวรวบรวม พร็อกซี เชน สาขา ฯลฯ) เพื่อแก้ปัญหาทั้งปัญหามาตรฐานและปัญหาที่ไม่ค่อยเกิดขึ้น
จากมุมมองทางธุรกิจ ความสามารถในการปรับขนาดเป็นหนึ่งในเครื่องมือการจัดการความเสี่ยง สิ่งสำคัญคือการตอบสนองคำขอของลูกค้าโดยใช้อุปกรณ์อย่างเหมาะสมที่สุด:
- เมื่อพลังของอุปกรณ์เพิ่มขึ้นตามความก้าวหน้า จะไม่ถูกใช้งานเนื่องจากซอฟต์แวร์ที่ไม่สมบูรณ์ Erlang ปรับขนาดในแนวตั้งได้ดีและจะสามารถใช้แกน CPU และหน่วยความจำที่มีอยู่ทั้งหมดได้เสมอ
- ในสภาพแวดล้อมคลาวด์ เราสามารถจัดการจำนวนอุปกรณ์โดยขึ้นอยู่กับปริมาณงานในปัจจุบันหรือที่คาดการณ์ไว้ และ SLA ที่รับประกัน
ความอดทนต่อความผิดพลาด
ลองพิจารณาสัจพจน์สองข้อ: “ความล้มเหลวเป็นสิ่งที่ยอมรับไม่ได้” และ “จะมีความล้มเหลวอยู่เสมอ” สำหรับธุรกิจ ความล้มเหลวของซอฟต์แวร์หมายถึงการสูญเสียเงิน และที่แย่กว่านั้นคือการสูญเสียชื่อเสียง การสร้างสมดุลระหว่างการสูญเสียที่เป็นไปได้และต้นทุนในการพัฒนาซอฟต์แวร์ที่ทนทานต่อข้อผิดพลาด มักพบการประนีประนอม
ในระยะสั้น สถาปัตยกรรมที่รวมความทนทานต่อข้อผิดพลาดช่วยประหยัดเงินในการซื้อโซลูชันการจัดกลุ่มที่มีจำหน่ายทั่วไป พวกมันมีราคาแพงและมีข้อบกพร่องด้วย
ในระยะยาว สถาปัตยกรรมที่ทนทานต่อข้อผิดพลาดจะคุ้มค่ากับตัวมันเองหลายเท่าในทุกขั้นตอนของการพัฒนา
การส่งข้อความภายในฐานโค้ดทำให้คุณสามารถดูรายละเอียดการโต้ตอบของส่วนประกอบต่างๆ ภายในระบบในขั้นตอนการพัฒนาได้ สิ่งนี้ช่วยลดความยุ่งยากในการตอบสนองและจัดการความล้มเหลว เนื่องจากส่วนประกอบที่สำคัญทั้งหมดจัดการกับความล้มเหลว และระบบผลลัพธ์จะรู้วิธีกลับสู่ภาวะปกติโดยอัตโนมัติหลังจากความล้มเหลวโดยการออกแบบ
การตอบสนอง
แอปพลิเคชันจะต้องตอบสนองต่อคำขอและปฏิบัติตาม SLA โดยไม่คำนึงถึงความล้มเหลว ความจริงก็คือคนไม่อยากรอ ธุรกิจจึงต้องปรับตัวตามนั้น คาดว่าแอปพลิเคชันจะมีการตอบสนองสูงมากขึ้นเรื่อยๆ
แอปพลิเคชันที่ตอบสนองจะทำงานในเวลาใกล้เคียงเรียลไทม์ Erlang VM ทำงานในโหมดเรียลไทม์แบบซอฟต์ สำหรับบางพื้นที่ เช่น การซื้อขายหุ้น การแพทย์ และการควบคุมอุปกรณ์อุตสาหกรรม โหมดเรียลไทม์แบบฮาร์ดเป็นสิ่งสำคัญ
ระบบตอบสนองช่วยปรับปรุง UX และเป็นประโยชน์ต่อธุรกิจ
สรุปเบื้องต้น
เมื่อวางแผนบทความนี้ ฉันต้องการแบ่งปันประสบการณ์ของฉันในการสร้างนายหน้ารับส่งข้อความและสร้างระบบที่ซับซ้อนตามนั้น แต่ส่วนทางทฤษฎีและแรงบันดาลใจกลับกลายเป็นว่าค่อนข้างกว้างขวาง
ในส่วนที่สองของบทความ ฉันจะพูดถึงความแตกต่างของการใช้จุดแลกเปลี่ยน รูปแบบการส่งข้อความ และการใช้งาน
ในส่วนที่สาม เราจะพิจารณาประเด็นทั่วไปของการจัดระเบียบบริการ การกำหนดเส้นทาง และความสมดุล เรามาพูดถึงด้านปฏิบัติของความสามารถในการขยายขนาดและความทนทานต่อข้อผิดพลาดของระบบกัน
จบภาคแรก.
Фото .
ที่มา: will.com