กงสุล - สถาปัตย์

แผนภาพสถาปัตยกรรมสำหรับกงสุลที่ทำงานในศูนย์ข้อมูลหนึ่งสามารถอธิบายได้ดีที่สุดดังที่แสดงด้านล่าง -

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

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

อัลกอริทึมแพ

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

ก Raft Clusterมีเซิร์ฟเวอร์หลายเครื่องโดยปกติจะอยู่ในจำนวนคี่ ตัวอย่างเช่นหากเรามีเซิร์ฟเวอร์ห้าเครื่องระบบจะยอมให้เกิดความล้มเหลวสองครั้ง ในช่วงเวลาใดก็ตามแต่ละเซิร์ฟเวอร์อยู่ในหนึ่งในสามสถานะ:Leader, Follower, หรือ Candidate. ในการทำงานปกติมีผู้นำเพียงคนเดียวและเซิร์ฟเวอร์อื่น ๆ ทั้งหมดเป็นผู้ติดตาม ผู้ติดตามเหล่านี้อยู่ในสถานะเฉยเมยกล่าวคือพวกเขาไม่ออกคำขอด้วยตนเอง แต่เพียงตอบสนองต่อคำร้องขอจากผู้นำและผู้สมัคร

ภาพประกอบต่อไปนี้อธิบายถึงโมเดลเวิร์กโฟลว์ที่ใช้อัลกอริทึมแพทำงาน -

ข้อมูลมูลค่าหลัก

ตั้งแต่รุ่น 0.7.1 ของกงสุลได้มีการแนะนำข้อมูลคีย์ค่าแยกต่างหาก คำสั่ง KV ใช้เพื่อโต้ตอบกับที่เก็บคีย์ - ค่าของกงสุลผ่านทางบรรทัดคำสั่ง มันแสดงคำสั่งระดับบนสุดสำหรับInserting, Updating, Reading และ Deletingจากร้านค้า ในการรับที่เก็บอ็อบเจ็กต์คีย์ / ค่าเราเรียกวิธี KV สำหรับไคลเอ็นต์กงสุล -

kv := consul.KV()

KVPair Structureใช้เพื่อแสดงรายการคีย์ / ค่าเดียว เราสามารถดูโครงสร้างของ Consul KV Pair ได้ในโปรแกรมต่อไปนี้

type KVPair struct {
   Key string
   CreateIndex uint64
   ModifyIndex uint64
   LockIndex uint64
   Flags uint64
   Value []byte
   Session string
}

ที่นี่โครงสร้างต่างๆที่กล่าวถึงในโค้ดข้างต้นสามารถกำหนดได้ดังนี้ -

• Key- เป็นชื่อ URL แบบทับ ตัวอย่างเช่น - sites / 1 / domain

• CreateIndex - หมายเลขดัชนีกำหนดเมื่อสร้างคีย์ครั้งแรก

• ModifyIndex - หมายเลขดัชนีกำหนดเมื่อคีย์ได้รับการอัปเดตครั้งล่าสุด

• LockIndex - หมายเลขดัชนีที่สร้างขึ้นเมื่อมีการล็อกใหม่ในรายการคีย์ / ค่า

• Flags - แอปสามารถใช้เพื่อตั้งค่าที่กำหนดเองได้

• Value - เป็นอาร์เรย์ไบต์สูงสุด 512kb

• Session - สามารถตั้งค่าได้หลังจากสร้างวัตถุเซสชัน

ประเภทของพิธีสาร

มีโปรโตคอลสองประเภทในกงสุลซึ่งเรียกว่า -

• Consensus Protocol และ
• พิธีสารซุบซิบ

ตอนนี้ให้เราเข้าใจโดยละเอียด

พิธีสารฉันทามติ

Consensus protocol ใช้โดย Consul เพื่อให้ความสอดคล้องตามที่อธิบายโดย CAP Theorem โปรโตคอลนี้ใช้ Raft Algorithm เมื่อใช้โปรโตคอล Consensus Raft Algorithm จะถูกใช้โดยที่โหนดแพจะอยู่ในสถานะใดสถานะหนึ่งในสามสถานะเสมอ: Follower, Candidate หรือ Leader

พิธีสารซุบซิบ

สามารถใช้โพรโทคอลซุบซิบเพื่อจัดการการเป็นสมาชิกส่งและรับข้อความข้ามคลัสเตอร์ ในกงสุลการใช้โปรโตคอลนินทาเกิดขึ้นได้สองวิธีคือWAN (Wireless Area Network) และ LAN(เครือข่ายท้องถิ่น). มีไลบรารีที่รู้จักสามแห่งซึ่งสามารถใช้อัลกอริทึม Gossip เพื่อค้นหาโหนดในเครือข่ายเพียร์ทูเพียร์ -

• teknek-gossip - ใช้งานได้กับ UDP และเขียนด้วย Java

• gossip-python - ใช้ TCP stack และสามารถแชร์ข้อมูลผ่านเครือข่ายที่สร้างขึ้นได้เช่นกัน

• Smudge - เขียนใน Go และใช้ UDP เพื่อแลกเปลี่ยนข้อมูลสถานะ

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

การเรียกขั้นตอนระยะไกล

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

ความงามที่แท้จริงของการใช้ RPC ในกงสุลคือช่วยให้เราหลีกเลี่ยงปัญหาเวลาแฝงซึ่งเครื่องมือบริการค้นหาส่วนใหญ่มีมาก่อนแล้ว ก่อน RPC กงสุลเคยมีเพียงTCP และ UDPตามการเชื่อมต่อซึ่งดีกับระบบส่วนใหญ่ แต่ไม่ใช่ในกรณีของระบบกระจาย RPC แก้ปัญหาดังกล่าวโดยลดระยะเวลาในการถ่ายโอนข้อมูลแพ็คเก็ตจากที่หนึ่งไปยังอีกที่หนึ่ง ในส่วนนี้GRPC by Google เป็นเครื่องมือที่ยอดเยี่ยมในการรอคอยในกรณีที่ต้องการสังเกตเกณฑ์มาตรฐานและเปรียบเทียบประสิทธิภาพ