บริการไมโครและการจำลองข้อมูล

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

ตัวอย่างเช่นฉันมี 2 แอพ - พูดแอปขายและแอปจองตั๋ว สมมติว่าแอพทั้งสองนี้สร้างขึ้นเป็นบริการไมโครของตัวเอง อย่างไรก็ตามแอพทั้งสองนี้เมื่อมีการใช้งาน (สมมติว่ามีการใช้งานแยกกันว่า Sales ใช้ MongoDB และ Ticketing ใช้ MariaDB) จะต้องมีการเข้าถึงอินสแตนซ์ข้อมูลหลักเดียวกันเช่นบัญชีผลิตภัณฑ์ ซึ่งหมายความว่าจะมีแอปสำหรับเจ้าของข้อมูลเอนทิตีหลักที่กำหนด (เช่นบัญชีที่อาจเป็นแอปขาย) และผู้มีส่วนได้เสีย (เช่นแอปออกบัตรจะต้องมีข้อมูลเกี่ยวกับบัญชี)

มีหลายวิธีที่สามารถทำได้: - การจำลองข้อมูลจากต้นแบบไปยังผู้มีส่วนร่วม - อ่านแบบซิงโครนัสจากฝ่ายที่สนใจไปที่ต้นแบบ (การพึ่งพาการซิงค์ไม่แนะนำโดยกระบวนทัศน์สถาปัตยกรรมไมโครบริการ) - พื้นที่เก็บข้อมูลส่วนกลาง

แม้แต่ในบัญชีก็สามารถมีส่วนหลักซึ่งเป็นเรื่องปกติสำหรับทั้งการขายและการออกตั๋ว (เช่นชื่อบัญชีที่อยู่ ฯลฯ ) อย่างไรก็ตามบางแง่มุมของบัญชีอาจเกี่ยวข้องกับการขายเท่านั้นและอื่น ๆ ที่เกี่ยวข้องกับการออกตั๋วเท่านั้น

ความคิด / แนวปฏิบัติที่ดีที่สุด / ความคิดเห็นเกี่ยวกับตัวเลือกใด ๆ ที่กล่าวถึงข้างต้น?

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

ในตอนแรกเราเชื่อว่าไมโครไซต์และสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์จะช่วยให้เราสามารถแก้ไขฐานข้อมูล ball-of-โคลนข้อมูลที่ใช้ร่วมกัน

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

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

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

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

ถ้าเจ้าของต้องการเก็บข้อมูลในรูปแบบอื่นจะคงอยู่? จากนั้นทุกบริการผู้อ่านจะต้องมีการปรับปรุง นั่นเป็นฝันร้ายในการบำรุงรักษา

ทางออกที่ดีที่สุดที่เรามีคือการทำซ้ำและการลดความสำคัญของข้อมูลของเรา บริการไมโครเก็บรักษาสำเนาข้อมูลที่พวกเขาสนใจ

ข้อความถูกเผยแพร่บ่อยครั้งและมีข้อมูลประกอบเพียงพอที่จะประมวลผล

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

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

ดังนั้นเมื่อลูกค้าอัปเดตที่อยู่ของพวกเขาบริการที่อยู่จะประมวลผลคำสั่งเริ่มต้นจาก UI เมื่อข้อมูลถูกต้องแล้วจะมีการเผยแพร่กิจกรรมเพื่อแจ้งบริการที่สนใจอื่น ๆ ทั้งหมด "ที่อยู่ลูกค้าที่อัปเดตแล้ว" - โดยมีที่อยู่ที่สมบูรณ์เป็นข้อมูล บริการเหล่านั้นจะอัปเดตที่เก็บข้อมูลของตนเองด้วยส่วนต่างๆของข้อมูลที่พวกเขาสนใจ

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

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

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

จะต้องมีการเข้าถึงอินสแตนซ์ข้อมูลหลักเดียวกันเช่นบัญชีผลิตภัณฑ์

ไม่เหมือนกัน. แต่ละบริการไมโครควรทำแผนที่ของตนเองสำหรับบัญชีผลิตภัณฑ์และอื่น ๆ เราคาดว่าแต่ละบริการไมโครจะมีวิธีที่แตกต่างในการทำงานกับเอนทิตี

ในการออกแบบการขับเคลื่อนด้วยโดเมนนี่เป็นเรื่องปกติที่บริบทแต่ละขอบเขต (ในแอพเดียวกัน!) สามารถแมปเอนทิตีเดียวกันในวิธีที่ต่างกัน

หากคุณต้องการข้อมูลเพิ่มเติมฉันแนะนำหนังสือMicroservices การสร้าง: การออกแบบระบบที่ละเอียด

คุณได้พิจารณาแนวคิดของบันทึกโครงกระดูกตามชุดต้นแบบหรือไม่?

ตัวอย่างเช่น microservice หนึ่งจัดการบัญชีและผลิตภัณฑ์อื่น ๆ จัดการ ที่สามอาจเก็บบันทึกจากทั้งสองเพื่อวัตถุประสงค์เฉพาะของโดเมน