วิธีใช้ Redis ในโครงสร้างพื้นฐานไมโครเซอร์วิส

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

ภาพรวมอย่างรวดเร็วของไมโครเซอร์วิส บริการโครงสร้างพื้นฐาน และระบบแบบกระจาย

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

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

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

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

(สำหรับข้อมูลเพิ่มเติม โปรดดูโพสต์ของเราเกี่ยวกับสิ่งที่ควรเลือกสำหรับความต้องการด้านการสื่อสารแบบซิงโครนัสและอะซิงโครนัส—สตรีม Redis, Redis Pub/Sub, Kafka ฯลฯ)

OrderShop:ตัวอย่างการใช้งานอีคอมเมิร์ซ

“Hello World” ของสถาปัตยกรรมไมโครเซอร์วิสคือ OrderShop ซึ่งเป็นการใช้งานระบบอีคอมเมิร์ซอย่างง่ายโดยใช้วิธีการแบบอิงตามเหตุการณ์ แอปพลิเคชันตัวอย่างนี้ใช้โมเดลโดเมนอย่างง่าย แต่ตรงตามวัตถุประสงค์ของแอปพลิเคชัน

OrderShop ได้รับการจัดการโดยใช้ Docker Compose การสื่อสารเครือข่ายทั้งหมดดำเนินการผ่าน gRPC ส่วนประกอบส่วนกลางคือที่เก็บเหตุการณ์และคิวข้อความ:แต่ละบริการและทุกบริการเชื่อมต่อและเชื่อมต่อผ่าน gRPC เท่านั้น OrderShop คือตัวอย่างการใช้งานใน Python คุณดูซอร์สโค้ดของ OrderShop ได้ใน GitHub

(หมายเหตุ: รหัสนี้คือ ไม่ใช่ พร้อมสำหรับการผลิตและมีวัตถุประสงค์เพื่อการสาธิตเท่านั้น!)

วิ่งสนุก

• โคลนที่เก็บ GitHub:https://github.com/redis-demos/ordershop-v2
• เรียกใช้ OrderShop v2 ในกระบวนการห้าขั้นตอนง่ายๆ:

1. เริ่มแอปพลิเคชันด้วย docker-compose up
2. เปิดเบราว์เซอร์ของคุณและไปที่ https://localhost:5000/
   1. ดูเหตุการณ์และสถานะการเรียกดู
3. เรียกใช้ไคลเอ็นต์ด้วย python -m unittest tests/unit.py
4. เปิดแท็บอื่นในเบราว์เซอร์ของคุณเพื่อ https://localhost:8001/
   1. ใช้ redis:6379 เพื่อเชื่อมต่อกับฐานข้อมูลทดสอบ
5. หยุดแอปพลิเคชันด้วย docker-compose down

สถาปัตยกรรม OrderShop v2

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

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

บริการโครงสร้างพื้นฐาน

ใน OrderShop v2 การสื่อสารแบบ unicast ทั้งหมดจะเกิดขึ้นบน คิวข้อความ ส่วนประกอบ. สำหรับสิ่งนี้ ฉันจะใช้ Redis Lists และโดยเฉพาะอย่างยิ่ง สองรายการรวมกันเป็น "คิวที่เชื่อถือได้" มันประมวลผลคำสั่งง่ายๆ (เช่น การดำเนินการของเอนทิตีเดี่ยว) แบบซิงโครนัส แต่คำสั่งที่ใช้เวลานาน (เช่น แบทช์ อีเมล) แบบอะซิงโครนัส และรองรับการตอบสนองต่อข้อความแบบซิงโครนัสตั้งแต่แกะกล่อง

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

บริการสมัคร

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

เกตเวย์ API ไร้สัญชาติเช่นกัน และให้บริการ REST-API บนพอร์ต 5000 โดยจะยุติการเชื่อมต่อ HTTP และกำหนดเส้นทางไปยังโมเดลการอ่านสำหรับสถานะการอ่าน (การสืบค้น) หรือบริการโดเมนเฉพาะสำหรับสถานะการเขียน (คำสั่ง) การแยกแนวคิดระหว่างการดำเนินการอ่านและเขียนเป็นรูปแบบที่เรียกว่า Command Query Responsibility Segregation (CQRS)

บริการโดเมน

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

บริการ CRM (บริการจัดการลูกค้าสัมพันธ์) ไม่มีสถานะ—สมัครใช้งานกิจกรรมโดเมนจากร้านกิจกรรมและส่งอีเมลไปยังลูกค้าโดยใช้บริการอีเมล .

เอนทิตีโดเมนกลางคือคำสั่ง มีฟิลด์ที่เรียกว่า 'สถานะ' ซึ่งดำเนินการเปลี่ยนโดยใช้เครื่องสถานะดังแสดงในแผนภาพด้านล่าง

การเปลี่ยนเหล่านี้ดำเนินการในตัวจัดการเหตุการณ์หลายตัว ซึ่งสมัครรับข้อมูลจากเหตุการณ์ของโดเมน (รูปแบบ SAGA) ตัวอย่างเช่น:

ลูกค้า

ไคลเอนต์ถูกจำลองโดยใช้เฟรมเวิร์กการทดสอบหน่วยจาก Python ขณะนี้มีการดำเนินการทดสอบ 10 หน่วย ลองดูที่ tests/unit.py สำหรับรายละเอียดเพิ่มเติม

UI แบบธรรมดาให้บริการบนพอร์ต 5000 เพื่อดูเหตุการณ์และสถานะการเรียกดู (โดยใช้ WebSockets)

คอนเทนเนอร์ RedisInsight ยังพร้อมใช้งานเพื่อตรวจสอบอินสแตนซ์ Redis เปิดเว็บเบราว์เซอร์ไปที่ https://localhost:8001/ และใช้ redis:6379 เพื่อเชื่อมต่อกับฐานข้อมูลทดสอบ

บทสรุป

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

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

แจ้งให้เราทราบว่าเกิดอะไรขึ้นบน Twitter:@martinez099