เชี่ยวชาญ Redis: ปรับปรุงโครงสร้างพื้นฐานไมโครเซอร์วิสด้วยการส่งข้อความขั้นสูง

กลับใน 2019 ผมเขียนเกี่ยวกับวิธีสร้าง event store ใน Redis ผมอธิบายว่า Redis Streams เหมาะสำหรับ event store เพราะให้คุณเก็บ events ใน immutable append-only mechanism เหมือน transaction log ตอนนี้ ด้วยการอัปเดตแอปพลิเคชัน OrderShop ตัวอย่างที่แนะนำในบล็อกนั้น ผมจะสาธิตวิธีใช้ Redis เป็น message queue เพิ่มเติมการสาธิต use cases หลายอย่างของ Redis Enterprise นอกเหนือจาก caching

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

Redis เป็นโซลูชันที่ดีสำหรับสร้าง infrastructure services เช่น message queues และ event stores แต่มีบางอย่างที่ต้องคิดถึงเมื่อใช้สถาปัตยกรรมไมโครเซอร์วิสสร้าง distributed system ฐานข้อมูลเชิงสัมพันธ์ (Relational databases) มักดีสำหรับ monolithic applications แต่เฉพาะ NoSQL databases เช่น Redis ที่ให้ scalability และ availability requirements ที่จำเป็นสำหรับสถาปัตยกรรมไมโครเซอร์วิส

Distributed systems implies distributed state ตาม CAP theorem การ implement ซอฟต์แวร์สามารถส่งมอบได้เพียง 2 ใน 3 คุณลักษณะ: consistency, availability, และ partition tolerance (ดังนั้น CAP) ดังนั้น เพื่อทำให้ implementation fault tolerant คุณต้องเลือกระหว่าง availability และ consistency หากเลือก availability คุณจะได้ eventual consistency หมายถึงข้อมูลจะ consistent แต่หลังจากผ่านช่วงเวลาหนึ่ง หากเลือก consistency ส่งผลต่อ performance เพราะต้อง synchronize และ isolate write operations ทั่ว distributed system

Event sourcing ซึ่ง persist state ของ business entity เช่น order หรือ customer เป็น sequence ของ state-changing events เลือก availability แทน consistency มันอนุญาตให้ write operations เหลือเพียง trivial แต่ read operations แพงกว่า เพราะถ้าครอบคลุมหลายบริการ อาจต้องการ additional mechanism เช่น read model

Communication ใน distributed system สามารถเป็น brokered หรือ brokerless Brokerless styles รู้จักดี โดย HTTP เป็นตัวอย่าง nổiดที่สุด แนวทาง brokered มี broker ระหว่าง sender และ receiver ของ message ตามที่ชื่อบ่งชี้ มัน decouples sender และ receiver เปิดใช้งาน synchronous และ asynchronous communication สิ่งนี้ทำให้พฤติกรรม resilient มากขึ้น เพราะ message consumer ไม่ต้อง available ณ ขณะที่ message ถูกส่ง Brokered communication ยังอนุญาต independent scaling ของ sender และ receiver

(สำหรับข้อมูลเพิ่มเติม ดูโพสต์ของเรา What to Choose for Your Synchronous and Asynchronous Communication Needs—Redis Streams, Redis Pub/Sub, Kafka, etc.)

OrderShop: การ implement e-commerce ตัวอย่าง

"Hello World" ของสถาปัตยกรรมไมโครเซอร์วิสคือ OrderShop การ implement 简单的 e-commerce system ใช้ event-based approach แอปพลิเคชันตัวอย่างนี้ใช้ domain model 简单 แต่ตอบสนองวัตถุประสงค์ของแอปพลิเคชัน

OrderShop orchestrated โดยใช้ Docker Compose การสื่อสารเครือข่ายทั้งหมดทำผ่าน gRPC คอมโพเนนต์หลักคือ event store และ message queue: ทุกบริการเชื่อมต่อกับและเฉพาะพวกเขาเท่านั้น ผ่าน gRPC OrderShop เป็นตัวอย่าง implementation ใน Python คุณเห็น OrderShop source code บน GitHub

(หมายเหตุ: โค้ดนี้ ไม่ production-ready และเพื่อ demo purposes เท่านั้น!)

Run and fun

• Clone GitHub repository: https://github.com/redis-demos/ordershop-v2
• รัน OrderShop v2 ในกระบวนการ 5 ขั้นตอนง่ายๆ:

1. เริ่มแอปพลิเคชันด้วย docker-compose up
2. เปิด browser ไปที่ https://localhost:5000/
   1. ดู events และ browse state
3. รัน client ด้วย python -m unittest tests/unit.py
4. เปิด tab ใหม่ใน browser ไปที่ https://localhost:8001/
   1. ใช้ redis:6379 เพื่อเชื่อมต่อกับ test database
5. หยุดแอปพลิเคชันด้วย docker-compose down

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

ในกรณีนี้ server architecture ประกอบด้วยหลายบริการ State แบ่งกระจาย (distributed) ข้าม domain services หลายตัว แต่เก็บใน event store เดียว คอมโพเนนต์ Read model รวม logic สำหรับ reading และ caching state ตามที่แสดง:

Commands และ queries สื่อสารผ่านคอมโพเนนต์ Message queue ในขณะที่ events สื่อสารผ่านคอมโพเนนต์ Event store ซึ่งยังทำหน้าที่เป็น event bus

บริการโครงสร้างพื้นฐาน (Infrastructure services)

ใน OrderShop v2 ทุก unicast communication เกิดขึ้นผ่านคอมโพเนนต์ Message queue สำหรับนี้ ผมจะใช้ Redis Lists โดยเฉพาะ 2 lists รวมเป็น "reliable queue" มันประมวลผล simple commands (เช่น single entity operations) แบบ synchronous แต่ long-running ones (เช่น batches, mails) แบบ asynchronous และรองรับ responses สำหรับ synchronous messages out of the box

Event store พัฒนาจาก Redis Streams Domain services (ซึ่งเป็น dummies เพื่อสาธิตฟังก์ชัน OrderShop) subscribed ไปที่ event streams ที่ชื่อตาม event topic (คือ entity name) และ publish events ลงบน streams เหล่านี้ แต่ละ event เป็น stream-entry ด้วย event timestamp เป็น ID ผลรวมของ published events ใน streams ทำให้ได้ state ของระบบทั้งหมด

บริการแอปพลิเคชัน (Application services)

คอมโพเนนต์ Read model cache deduced entities จาก Event store ใน Redis โดยใช้ domain model โดยไม่สนใจ cache มัน stateless

คอมโพเนนต์ API gateway stateless เช่นกัน และ serve REST-API บน port 5000 มัน terminate HTTP connections และ route พวกเขาไปยัง read model สำหรับ reading state (queries) หรือไปยัง dedicated domain service สำหรับ writing state (commands) การแยกแยะทาง概念ระหว่าง read และ write operations เรียกว่า Command Query Responsibility Segregation (CQRS)

บริการโดเมน (Domain services)

Domain services รับ write operations ผ่าน Message queue จาก API gateway หลัง execute สำเร็จ พวกเขา publish event สำหรับแต่ละอันไปที่ Event store ในทางกลับกัน read operations ทั้งหมดจัดการโดย Read model ซึ่งได้ state จาก Event store

คอมโพเนนต์ CRM service (Customer Relation Management service) เป็น stateless—มัน subscribed ไปที่ domain events จาก event store และส่งอีเมลให้ลูกค้าโดยใช้ Mail service

Entity โดเมนกลางคือ order มี field เรียกว่า 'status' ซึ่ง transitions ทำโดย state machine ตามแผนภาพด้านล่าง

Transitions เหล่านี้ทำใน event handlers หลายตัว ซึ่ง subscribed ไปที่ domain events (SAGA pattern) ตัวอย่างเช่น:

Clients

Clients จำลองโดยใช้ Unit testing framework จาก Python มี unit tests 10 ตัว implemented ดู tests/unit.py สำหรับรายละเอียดเพิ่มเติม

Simple UI served บน port 5000 สำหรับดู events และ browse state (ใช้ WebSockets)

RedisInsight container พร้อมใช้งานสำหรับ inspect Redis instance เปิด web browser ไป https://localhost:8001/ และใช้ redis:6379 เพื่อเชื่อมต่อกับ test database

สรุป

Redis ไม่ได้เป็นเครื่องมือทรงพลังใน domain layer (เช่น catalog search) และ application layer (เช่น HTTP session store) เท่านั้น แต่ยังใน infrastructure layer (เช่น event store หรือ message queue) การใช้ Redis ทั่ว layers เหล่านี้ลด operational overhead และให้นักพัฒนา reuse เทคโนโลยีที่รู้จักแล้ว

ลองดูโค้ดและลอง implement ดู ผมหวังว่านี้ช่วยสาธิตความหลากหลายและความยืดหยุ่นของ Redis ใน domain และ infrastructure services และพิสูจน์ว่ามันใช้ได้นอกเหนือจาก caching

บอกผมว่าเป็นยังไงบน Twitter: @martinez099