การ seed ฐานข้อมูล microservices

10

รับบริการ A (CMS) ที่ควบคุมรูปแบบ (ผลิตภัณฑ์สมมติว่ามีเพียงฟิลด์เดียวที่มี id ชื่อเรื่องราคา) และบริการ B (การจัดส่ง) และ C (อีเมล) ที่ต้องแสดงรูปแบบที่กำหนดแนวทางที่ควรจะเป็น การซิงโครไนซ์ข้อมูลโมเดลที่ได้รับจากบริการเหล่านั้นในแนวทางการจัดหากิจกรรม สมมติว่ารายการสินค้าที่ไม่ค่อยมีการเปลี่ยนแปลง ( แต่ไม่เปลี่ยนแปลง) และว่ามีผู้ดูแลระบบที่เข้าถึงข้อมูลสามารถของการจัดส่งและอีเมลบ่อยมาก (ตัวอย่างเช่นฟังก์ชันคือ: B: display titles of products the order containedและ C: display content of email about shipping that is going to be sent) แต่ละบริการมีฐานข้อมูลของตนเอง

โซลูชันที่ 1

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

{
    order_id: [guid],
    product: {
        id: [guid],
        title: 'Foo',
        price: 1000
    }
}

บริการข้อมูลผลิตภัณฑ์ B และ C จะถูกเก็บไว้ในproductแอตทริบิวต์ JSON บนordersตาราง

ดังนั้นเพื่อแสดงข้อมูลที่จำเป็นจะมีการใช้ข้อมูลที่ดึงมาจากเหตุการณ์เท่านั้น

ปัญหา : ขึ้นอยู่กับข้อมูลอื่นที่จำเป็นต้องนำเสนอใน B และ C จำนวนข้อมูลในเหตุการณ์สามารถเติบโตได้ B และ C อาจไม่ต้องการข้อมูลเดียวกันเกี่ยวกับผลิตภัณฑ์ แต่เหตุการณ์จะต้องมีทั้งสองอย่าง (ยกเว้นกรณีที่เราแยกเหตุการณ์เป็นสองเหตุการณ์) หากข้อมูลที่ให้ไว้ไม่ปรากฏในกิจกรรมที่กำหนดรหัสไม่สามารถใช้งานได้ - หากเราจะเพิ่มตัวเลือกสีให้กับผลิตภัณฑ์สำหรับคำสั่งซื้อที่มีอยู่ใน B และ C ผลิตภัณฑ์ที่ให้จะไม่มีสีเว้นแต่เราจะอัปเดตเหตุการณ์แล้วรันซ้ำอีกครั้ง .

โซลูชันที่ 2

ส่ง guid ของผลิตภัณฑ์ภายในเหตุการณ์เท่านั้นซึ่งหมายถึงโครงสร้างต่อไปนี้สำหรับorder_placed:

{
    order_id: [guid],
    product_id: [guid]
}

บนบริการข้อมูลผลิตภัณฑ์ B และ C จะถูกเก็บไว้ในproduct_idแอตทริบิวต์ในordersตาราง

ข้อมูลผลิตภัณฑ์จะถูกเรียกคืนโดยบริการ B และ C เมื่อต้องการโดยดำเนินการเรียก API ไปยังA/product/[guid]ปลายทาง

ปัญหา : สิ่งนี้ทำให้ B และ C ขึ้นอยู่กับ A (ตลอดเวลา) หากสคีมาของผลิตภัณฑ์เปลี่ยนแปลงบน A การเปลี่ยนแปลงจะต้องทำในบริการทั้งหมดที่ขึ้นอยู่กับพวกเขา (ทันใด)

โซลูชันที่ 3

ส่ง guid ของผลิตภัณฑ์ภายในเหตุการณ์เท่านั้นซึ่งหมายถึงโครงสร้างต่อไปนี้สำหรับ order_placed:

{
    order_id: [guid],
    product_id: [guid]
}

บนบริการข้อมูลผลิตภัณฑ์ B และ C จะถูกเก็บไว้ในproductsตาราง; ยังคงproduct_idอยู่บนordersโต๊ะ แต่มีการจำลองproductsข้อมูลระหว่าง A, B และ C B และ C อาจมีข้อมูลที่แตกต่างเกี่ยวกับผลิตภัณฑ์กว่า A

ข้อมูลผลิตภัณฑ์ถูกสร้างขึ้นเมื่อมีการสร้างบริการ B และ C และอัพเดททุกครั้งที่ข้อมูลเกี่ยวกับผลิตภัณฑ์เปลี่ยนแปลงโดยการโทรไปยังA/productปลายทาง (ที่แสดงข้อมูลที่ต้องการของผลิตภัณฑ์ทั้งหมด) หรือทำการเข้าถึงฐานข้อมูลโดยตรงไปยัง A และคัดลอกข้อมูลผลิตภัณฑ์ที่จำเป็น บริการ.

ปัญหา : สิ่งนี้ทำให้ B และ C ขึ้นอยู่กับ A (เมื่อทำการเพาะ) หากสคีมาของผลิตภัณฑ์เปลี่ยนแปลงบน A การเปลี่ยนแปลงจะต้องทำในบริการทั้งหมดที่ขึ้นอยู่กับพวกเขา (เมื่อเริ่มต้น)

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

microservices event-sourcing

— eithed
แหล่งที่มา

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

— Nope

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

— Nope

@ ไม่updating event historyฉันหมายถึง: ไปที่เหตุการณ์ทั้งหมดคัดลอกจากสตรีมหนึ่ง (v1) ไปยังสตรีมอื่น (v2) เพื่อรักษาสคีมาเหตุการณ์ที่สอดคล้องกัน

— eithed

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

— CPerson

@ CPerson yup - ราคาอาจเป็นหนึ่งในแอตทริบิวต์ที่ส่งผ่านภายในเหตุการณ์เอง ในทางกลับกัน URL สำหรับภาพสามารถมีอยู่ในเหตุการณ์ (แสดงถึงเจตนาdisplay image at the point when purchase was made) หรือไม่ (แสดงถึงเจตนาdisplay current image as it within catalog)

— eithed

3

โซลูชัน # 3 ใกล้เคียงกับแนวคิดที่ถูกต้องจริงๆ

วิธีคิดเกี่ยวกับสิ่งนี้: B และ C คือสำเนาของข้อมูลที่พวกเขาต้องการ " แคช " ในแต่ละแคช ข้อความที่ประมวลผลที่ B (และเช่นเดียวกันกับที่ C) ใช้ข้อมูลแคชในเครื่อง รายงานจะถูกจัดทำขึ้นโดยใช้ข้อมูลแคชในเครื่อง

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

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

สิ่งนี้ช่วยให้คุณ "อิสระ" ในแง่ที่ว่า B และ C สามารถส่งมอบมูลค่าทางธุรกิจอย่างต่อเนื่องเมื่อ A ไม่สามารถใช้งานได้ชั่วคราว

การอ่านที่แนะนำ: ข้อมูลจากด้านนอก, ข้อมูลด้านใน , Pat Helland 2005

— VoiceOfUnreason
แหล่งที่มา

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

— eithed

1

ฉันคิดว่าคุณได้รับมันด้วยคำตอบ # 3 หากคุณต้องการเล่นซ้ำความสอดคล้องกับแคตตาล็อกแหล่งเหตุการณ์ที่เกินไป คุณจะต้องเล่นซ้ำเมื่อคุณเริ่มต้นใหม่ซึ่งอาจเป็นตอนเริ่มต้น - เมื่อคุณพร้อมที่จะดูเหตุการณ์ใหม่ ๆ เท่านั้นดังนั้นปริมาณข้อมูลอาจไม่เป็นปัญหาจริง อย่างไรก็ตามแม้ว่าคุณจะมีตัวเลือก (ถ้าจำเป็น) ในการใช้จุดตรวจสอบคือ "นี่คือสถานะณ เหตุการณ์ 1,000" ดังนั้นคุณจึงทำเช่นนั้นและตอนนี้คุณต้องเล่นซ้ำเหตุการณ์ 1,001 ต่อปัจจุบันแทนประวัติทั้งหมด .

— Mike B.

2

มีสองสิ่งที่ยากในวิทยาศาสตร์คอมพิวเตอร์และหนึ่งในนั้นคือการทำให้แคชใช้ไม่ได้

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

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

ปัญหาด้านประสิทธิภาพเป็นตัวขับเคลื่อนหลัก มีหลายวิธีในการแก้ปัญหา # 2 ที่ไม่เกี่ยวข้องกับการแคชเช่นการทำให้มั่นใจว่า Service A พร้อมใช้งานสูง

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

จากบทความที่ยอดเยี่ยมนี้โดย Udi Dahan:

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

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

— ฟิลแซนด์เลอร์
แหล่งที่มา

1

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

— Phil Sandler

1

@SavvasKleanthous ยังพิจารณา (ตามที่ผมกล่าวถึงในคำตอบของฉัน) ที่กลับมาข้อมูลเก่าในหลายกรณีสามารถมากเลวร้ายยิ่งกว่าการขว้างปาข้อผิดพลาด

— Phil Sandler

1

@eithed ฉันหมายถึงความคิดเห็นนี้: "ถ้า แต่เราต้องการติดตามการเปลี่ยนแปลงแคตตาล็อกที่ต้องมีการจัดหากิจกรรมเหล่านั้นเช่นกัน" ไม่ว่าในกรณีใดคุณมีความคิดที่ถูกต้อง - บริการผลิตภัณฑ์ควรรับผิดชอบในการติดตามการเปลี่ยนแปลงเมื่อเวลาผ่านไปไม่ใช่บริการดาวน์สตรีม

— Phil Sandler

1

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

— Savvas Kleanthous

1

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

— Phil Sandler

2

มันยากมากที่จะพูดว่าวิธีหนึ่งดีกว่าอีกวิธีหนึ่ง การเลือกหนึ่งในโซลูชัน # 2 และ # 3 ขึ้นอยู่กับปัจจัยอื่น (ระยะเวลาแคชการยอมรับอย่างต่อเนื่อง ... )

2 เซนต์ของฉัน:

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

โซลูชัน # 1 (NOK)

ข้อมูลซ้ำซ้อนในหลายระบบ

โซลูชัน # 2 (ตกลง)

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

โซลูชัน # 3 (ซับซ้อน แต่ต้องการ)

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

— Sudhir
แหล่งที่มา

1

โดยทั่วไปฉันขอแนะนำอย่างยิ่งกับตัวเลือก 2 เนื่องจากการมีเพศสัมพันธ์ชั่วคราวระหว่างบริการทั้งสองนั้น (ยกเว้นกรณีที่การสื่อสารระหว่างบริการเหล่านี้มีความเสถียรมากและไม่บ่อยมาก) การมีเพศสัมพันธ์ชั่วคราวเป็นสิ่งที่คุณอธิบายว่าthis makes B and C dependant upon A (at all times)และหมายความว่าหาก A ไม่สามารถเข้าถึงได้จาก B หรือ C B และ C จะไม่สามารถใช้งานได้

ฉันเองเชื่อว่าทั้งสองตัวเลือกที่ 1 และ 3 มีสถานการณ์ที่พวกเขาเป็นตัวเลือกที่ถูกต้อง

หากการสื่อสารระหว่าง A และ B & C สูงมากหรือจำนวนข้อมูลที่จำเป็นสำหรับการเข้าร่วมกิจกรรมมีขนาดใหญ่พอที่จะทำให้เกิดความกังวลตัวเลือกที่ 3 เป็นตัวเลือกที่ดีที่สุดเนื่องจากภาระบนเครือข่ายต่ำกว่ามาก และความล่าช้าของการดำเนินการจะลดลงเมื่อขนาดข้อความลดลง ข้อกังวลอื่น ๆ ที่ควรพิจารณาที่นี่คือ:

ความมั่นคงของสัญญา: หากสัญญาที่ปล่อยให้ข้อความเปลี่ยนแปลงบ่อยครั้งการใส่คุณสมบัติจำนวนมากลงในข้อความจะส่งผลให้ผู้บริโภคเปลี่ยนแปลงไปอย่างมาก อย่างไรก็ตามในกรณีนี้ฉันเชื่อว่านี่ไม่ใช่ปัญหาใหญ่เพราะ:
1. คุณพูดถึงว่าระบบ A เป็น CMS หมายความว่าคุณกำลังทำงานในโดเมนที่มั่นคงและฉันไม่เชื่อว่าคุณจะเห็นการเปลี่ยนแปลงบ่อยครั้ง
2. เนื่องจาก B และ C เป็นการจัดส่งและอีเมลและคุณได้รับข้อมูลจาก A ฉันเชื่อว่าคุณจะพบกับการเปลี่ยนแปลงที่เพิ่มเข้ามาแทนที่การทำลายซึ่งจะปลอดภัยเมื่อใดก็ตามที่คุณค้นพบพวกเขาโดยไม่ต้องทำใหม่
คลัป: มีน้อยมากที่จะไม่มีการแต่งงานกันที่นี่ ประการแรกเนื่องจากการสื่อสารผ่านข้อความไม่มีบริการเชื่อมต่อระหว่างบริการอื่นนอกเหนือจากบริการชั่วคราวระหว่างการสร้างข้อมูลและสัญญาของการดำเนินการนั้น (ซึ่งไม่ใช่การเชื่อมต่อที่คุณสามารถทำได้หรือควรพยายามหลีกเลี่ยง)

ตัวเลือกที่ 1 ไม่ใช่สิ่งที่ฉันจะยกเลิก การแต่งงานกันมีจำนวนเท่ากัน แต่การพัฒนาที่ชาญฉลาดควรง่าย (ไม่จำเป็นต้องมีการกระทำพิเศษ) และความมั่นคงของโดเมนควรหมายความว่าสิ่งเหล่านี้จะไม่เปลี่ยนแปลงบ่อยครั้ง (ดังที่ฉันได้กล่าวไปแล้ว)

ตัวเลือกอื่นที่ฉันขอแนะนำคือการเปลี่ยนแปลงเล็กน้อยเป็น 3 ซึ่งไม่ได้เรียกใช้กระบวนการในช่วงเริ่มต้น แต่ให้สังเกตเหตุการณ์ "ProductAdded และ" ProductDetailsChanged "แทนใน B และ C เมื่อใดก็ตามที่มีการเปลี่ยนแปลงในแค็ตตาล็อกผลิตภัณฑ์ ใน A. สิ่งนี้จะทำให้การปรับใช้ของคุณเร็วขึ้น (และง่ายกว่ามากในการแก้ไขปัญหา / ข้อบกพร่องหากคุณพบสิ่งใด)

แก้ไข 2020-03-03

ฉันมีลำดับความสำคัญที่เฉพาะเจาะจงเมื่อพิจารณาวิธีการรวม:

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

หากค่าใช้จ่ายของความไม่สอดคล้องสูง (โดยทั่วไปข้อมูลผลิตภัณฑ์ใน A จะต้องสอดคล้องโดยเร็วที่สุดเท่าที่เป็นไปได้กับผลิตภัณฑ์ที่แคชใน B และ C) จากนั้น youb ไม่สามารถหลีกเลี่ยงที่จะต้องยอมรับการไม่เข้ากันได้และทำการร้องขอแบบซิงโครนัส / คำขอส่วนที่เหลือ) จาก B & C ถึง A เพื่อดึงข้อมูล ระวัง! สิ่งนี้ยังไม่ได้หมายถึงความสอดคล้องในการทำธุรกรรม แต่เพียงลดขนาดหน้าต่างให้เล็กลงเพื่อความไม่สอดคล้องกัน หากคุณแน่นอนต้องมีความสอดคล้องในเชิงบวกคุณจะต้องสร้างขอบเขตการให้บริการของคุณอีกครั้ง แต่ผมมากเชื่อนี้ไม่ควรจะมีปัญหา จากประสบการณ์จริง ๆ แล้วเป็นเรื่องยากมากที่ บริษัท ไม่สามารถยอมรับความไม่สอดคล้องกันได้ในเวลาไม่กี่วินาทีดังนั้นคุณไม่จำเป็นต้องทำการร้องขอแบบซิงโครนัส

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

หากคุณไม่ต้องการเวลาและไม่มีข้อมูลเจ้าของเดียวที่ชัดเจน (ซึ่งในคำตอบเริ่มต้นของฉันฉันได้ถือว่าสิ่งนี้ขึ้นอยู่กับคำถามของคุณ) จากนั้นรูปแบบที่สมเหตุสมผลมากก็คือการเป็นตัวแทน ของผลิตภัณฑ์ในแต่ละบริการแยกจากกัน เมื่อคุณอัปเดตข้อมูลสำหรับผลิตภัณฑ์คุณอัปเดต A, B และ C ในแบบคู่ขนานโดยการร้องขอเว็บแบบขนานไปยังแต่ละรายการหรือคุณมี API คำสั่งที่ส่งคำสั่งหลายคำสั่งไปยังแต่ละ A, B และ C B & C ข้อมูลในท้องที่เพื่อทำงานของพวกเขาซึ่งอาจจะใช่หรือไม่ก็ได้ นี่ไม่ใช่ตัวเลือกใด ๆ ด้านบน (แม้ว่าจะสามารถทำให้ใกล้กับตัวเลือก 3) เนื่องจากข้อมูลใน A, B และ C อาจแตกต่างกันและ "ทั้งหมด" ของผลิตภัณฑ์อาจเป็นองค์ประกอบของข้อมูลทั้งสาม แหล่งที่มา

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

หากคุณมีเจ้าของที่ชัดเจนโดยมี contrac ที่คาดว่าจะมีเสถียรภาพตัวเลือกที่ดีที่สุดจะเป็นตัวเลือกที่ 1 คำสั่งซื้อจะมีข้อมูลที่จำเป็นทั้งหมดจากนั้น B และ C จะทำหน้าที่ของพวกเขาโดยใช้ข้อมูลในเหตุการณ์

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

— Savvas Kleanthous
แหล่งที่มา

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

— eithed

@eithed ฉันอัปเดตคำตอบเพื่อขยายในบางสมมติฐานที่ฉันทำ

— Savvas Kleanthous