ความสัมพันธ์แบบกลุ่มต่อกลุ่มใน microservices

ฉันมีไมโครไซต์สองรายการ เราจะเรียกพวกเขาและAB

ฐานข้อมูลภายใต้ microservice Aมีตารางต่อไปนี้:

A
|-- users

ฐานข้อมูลภายใต้ microservice Bมีตารางต่อไปนี้:

B
|-- trackers

ข้อกำหนดระบุว่าusersและtrackersมีความสัมพันธ์แบบกลุ่มต่อกลุ่ม

ฉันไม่แน่ใจว่าจะจัดการสิ่งนี้ภายในสถาปัตยกรรม microservices อย่างไร

ฉันเห็นการทำงานนี้หนึ่งในสามวิธี:

1. user_trackersตารางจะถูกเพิ่ม AMICROSERVICE นี้ทำหน้าที่คล้ายกับตารางเข้าร่วมประกอบด้วย "คีย์ต่างประเทศ" เพื่อและuserstrackers
2. ownersตารางจะถูกเพิ่ม BMICROSERVICE ตารางนี้ทำหน้าที่คล้ายกับตารางเข้าร่วม polymorphic นี่จะทำให้บริการใด ๆ สร้างการเชื่อมโยงกับตัวติดตาม สิ่งนี้อาจมีลักษณะเช่นนี้: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. เก็บบันทึกสำหรับusersและtrackersในแต่ละบริการไมโคร ทำให้พวกเขาซิงค์กับระบบ pubsub บางประเภท

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

ฉันรู้สึกว่าอาจมีรูปแบบที่ดีที่ฉันไม่ทราบ ตัวเลือกใด ๆ ที่ฉันวางไว้เหมาะสมหรือไม่ มีตัวเลือกอื่นที่เหมาะสมกว่าหรือไม่

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

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

สิ่งที่สองคือคุณอาจไม่ได้ทำงานผ่านโดเมนของคุณดีพอ แนวคิดใดที่แสดงด้วยusersตาราง เป็นregistered userข้อมูลที่จำเป็นสำหรับการลงทะเบียนหรือไม่? คุณแน่ใจหรือว่าเป็นแนวคิดที่ถูกต้องสำหรับการสื่อสารด้วยtrackers(ไม่ว่าจะเป็นอะไร) ดังนั้นถ้าฉันเข้าใจถูกต้องตัวเลือกที่ 2 ของคุณก็คือ: แนะนำownerแนวคิดที่ใกล้กับโดเมนของคุณมาก ถ้าเป็นเช่นนั้นจริง ๆ ฉันมีตัวเลือก 2 เช่นกัน

อย่างไรก็ตามดูเหมือนว่าเกินขอบเขตสำหรับ microservice B. เหตุใด microservice B จึงควรใส่ใจว่า microservice A ต้องการสร้างความสัมพันธ์?

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

เมื่อผู้ใช้ลงทะเบียนUserCreatedเหตุการณ์อาจถูกปล่อยออกมา บริการที่สองของคุณฉันคิดว่ามันน่าสนใจ ดังนั้นเมื่อได้รับมันเอนทิตีที่แตกต่างกันอย่างสมบูรณ์อาจถูกสร้างขึ้นพูดOwnerเอนทิตี (ไม่ว่าจะเป็นอะไรก็ตาม) ฉันค่อนข้างแน่ใจว่ามีความร่วมมือที่น่าสนใจมากมายระหว่างมันและtrackerเอนทิตี - เก็บไว้ในบริการเดียว

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

คำตอบของ Zapadlo มีข้อมูลที่ดีและให้เหตุผลมากมาย ฉันจะเพิ่มคำแนะนำเชิงปฏิบัติเล็กน้อยที่นี่ซึ่งอาจทำให้การทำงานผ่านปัญหาของคุณและคำแนะนำในคำตอบนั้นง่ายขึ้น

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

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

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

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

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

คำถาม: ทำไมข้อมูลของคุณจึงถูกแยกออกไปพร้อมกับ DataTables?

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

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