Microservices และการรวมฐานข้อมูล

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

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

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

ฉันเคยอ่านหนังสือ Microservices ของ Sam Newman และในบทที่เกี่ยวกับการแยก Monolith เขาได้ยกตัวอย่างของ "Breaking Foreign Key Relationships" ซึ่งเขายอมรับว่าการเข้าร่วมข้าม API นั้นจะช้าลง - แต่เขากล่าวต่อไปว่า แอปพลิเคชันของคุณเร็วพออยู่แล้วมันสำคัญหรือไม่ว่ามันจะช้ากว่าเดิม?

นี่ดูเหมือนกะล่อนไปหน่อย? ประสบการณ์ของผู้คนคืออะไร? คุณใช้เทคนิคใดเพื่อให้การรวม API ทำงานได้อย่างยอมรับ

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

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

• นอกจากนี้อย่าลืมเกี่ยวกับการแคช :) คุณสามารถใช้เครื่องมือเช่นRedisหรือMemcachedเพื่อหลีกเลี่ยงการสืบค้นฐานข้อมูลอื่นบ่อยเกินไป

เป็นเรื่องปกติที่บริการจะมีสำเนาข้อมูลอ้างอิงบางอย่างที่จำลองแบบอ่านอย่างเดียวจากบริการอื่น ๆ

ระบุว่าเมื่อพยายาม refactor ฐานข้อมูลเสาหินเป็นไมโครเซอร์วิส (ตรงข้ามกับการเขียนใหม่) ฉันจะ

• สร้างสคีมา db สำหรับบริการ
• สร้างมุมมอง * เวอร์ชัน ** ในสคีมานั้นเพื่อเปิดเผยข้อมูลจากสคีมานั้นไปยังบริการอื่น ๆ
• เข้าร่วมกับมุมมองแบบอ่านอย่างเดียวเหล่านี้

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

ฉันอาจพิจารณาใช้ทริกเกอร์เพื่อจำลองข้อมูลจากสคีมาหนึ่งไปยังอีกสคีมาหนึ่งแทนที่จะใช้มุมมอง

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

* มุมมองสามารถขยายได้ หากจำเป็นต้องมีการเปลี่ยนแปลงอย่างสิ้นเชิงให้สร้าง v2 ของมุมมองเดียวกันและลบเวอร์ชันเก่าเมื่อไม่จำเป็นอีกต่อไป ** หรือ Table-Valued-Functions หรือ Sprocs

CQRS - Command Query Aggregation Pattern เป็นคำตอบสำหรับคริสริชาร์ดสัน ให้ไมโครเซอร์วิสแต่ละตัวอัปเดตโมเดลข้อมูลของตัวเองและสร้างเหตุการณ์ที่จะอัปเดตมุมมองที่เป็นรูปธรรมโดยมีข้อมูลการรวมที่จำเป็นจากไมโครเซอร์วิสก่อนหน้านี้ MV นี้อาจเป็น NoSql DB หรือ Redis หรือ elasticsearch ใด ๆ ที่ได้รับการปรับให้เหมาะสมที่สุด เทคนิคนี้นำไปสู่ความสอดคล้องในที่สุดซึ่งไม่เลวและหลีกเลี่ยงการรวมฝั่งแอปพลิเคชันแบบเรียลไทม์ หวังว่าคำตอบนี้

ฉันจะแยกวิธีแก้ปัญหาสำหรับพื้นที่การใช้งานกล่าวคือการดำเนินงานและการรายงาน

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

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

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

ในกรณีนี้จะต้องมีพื้นที่เพิ่มขึ้น แต่ไม่จำเป็นต้องมีการรวมและไม่ต้องรวม