Microservices ที่ไม่มีข้อมูลซ้ำซ้อน


19

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

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

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

วิธีที่ถูกต้อง / ดีที่สุดในการดำเนินการนี้คืออะไร


5
ยินดีต้อนรับสู่ความขัดแย้งของบริการไมโคร สิ่งที่ดูเหมือนจะทำให้สิ่งต่าง ๆ ง่ายขึ้นจริง ๆ แล้วสามารถทำให้สิ่งต่าง ๆ มีความซับซ้อนมากขึ้น
โรเบิร์ตฮาร์วีย์

วิธี "ถูกต้อง" นั้นเหมือนกันเสมอ: หาวิธีการทำสิ่งที่เหมาะสมกับวัตถุประสงค์เฉพาะของคุณมากที่สุด
Robert Harvey

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

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

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

คำตอบ:


10

ฉันพลาดที่คุณต้องทำซ้ำอย่างสมบูรณ์

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

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

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

ดังนั้นในทุกกรณีเมื่อคุณต้องการข้อมูลผู้ใช้ล่าสุดที่คุณถามบริการข้อมูลผู้ใช้


@Geraint: คุณสามารถเฉพาะเจาะจงมากขึ้นเกี่ยวกับชนิดของการทำซ้ำที่เกิดขึ้นในระบบของคุณ?
Robert Harvey

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

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

It seems counter-intuitive to move from a single relational database where I could get the inventory data and the user data with a joinโปรดทราบว่า "ดีเลิศ" มีหนึ่งร้านค้าต่อบริการ ดังนั้นจึงไม่มีอะไรเช่น "เข้าร่วม" ระหว่าง "ขอบเขต" เหตุผลง่าย DB สร้างการเชื่อมต่อระหว่างบริการ ต่างจาก @CandiedOrange แนะนำฉันคิดว่าเราสามารถทำซ้ำข้อมูลขั้นต่ำจากบริการหนึ่งไปอีกบริการหนึ่งได้ ฉันหมายถึงข้อมูลที่ไม่น่าจะเปลี่ยนแปลง หากอุปกรณ์เพิ่มประสิทธิภาพและประสิทธิภาพ (และจำเป็นต้องมีทั้งคู่นี้) "มืออาชีพ" อาจจะตั้งค่า "ข้อเสีย"
Laiv

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

11

ฉันพบว่ามันยากที่จะหลีกเลี่ยงการทำซ้ำข้อมูล ....

ตามที่Microsoft ebook เกี่ยวกับสถาปัตยกรรม microserviceไม่มีอะไรผิดปกติกับการทำสำเนาข้อมูล โดยทั่วไปข้อมูลที่ซ้ำกันจะเพิ่มการแยกระหว่างบริการและเสริมสร้างบทบาทของพวกเขาในฐานะหน่วยงานเดียว ข้อความที่เกี่ยวข้อง:

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


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

1
@ AlanSereb มันยากที่จะบำรุงรักษา แต่ประเด็นก็คือบางครั้งคุณก็ไม่มีทางเลือกอื่น ตัวอย่างเช่นถ้าคุณต้องการสร้าง FK ระหว่างวัตถุที่อยู่ในฐานข้อมูลสองแห่ง วิธีเดียวที่จะตรวจสอบความสอดคล้องเมื่อสร้างเคียวรีในฐานข้อมูลโลคัลคือมีการเรพลิเคทข้อมูล ลองดูที่: stackoverflow.com/a/4452586/2255491
David D.

ฉันเห็นด้วย. อีกวิธีที่ยอดเยี่ยมคือการใช้เส้นทางการจัดหากิจกรรม และมีการกลายพันธุ์ทั้งหมดที่จะดำเนินการผ่านทางท่อส่งเหตุการณ์
Alan Sereb

4

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

ใช่แล้ว

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

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

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

คำถามที่คุณต้องตอบคือเกี่ยวกับประสิทธิภาพและการบำรุงรักษาและคุณสมบัติ "อ่อน" อื่น ๆ

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

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

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

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

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

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

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

(*) ถ้ามันสมเหตุสมผลที่จะทำซ้ำข้อมูลใน microservice swarm มันอาจจะสมเหตุสมผลในฐานข้อมูลเชิงสัมพันธ์ที่เทียบเท่ากัน


3
ฉันชอบคำตอบของคุณจริง ๆ จนกระทั่งส่วน "อย่าทำซ้ำข้อมูลใน microservices" ฉันคิดว่ามีหลายกรณีที่การทำสำเนาข้อมูลเป็นแนวทางที่ถูกต้อง มันช่วยเพิ่มความทนทานต่อความผิดพลาดและความเป็นอิสระ หากบริการของผู้ใช้ลดลงบริการสินค้าคงคลังยังคงสามารถแสดงรายการของสินค้าคงคลังต่ำที่มีสต็อกพวกเขาล่าสุด
Peter Pompeii

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

@PeterPompeii หวังว่าส่วนที่เพิ่มเข้ามาเกี่ยวกับการแคชจะแก้ไขข้อกังวลของคุณ
Odalrick

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

1
@Brandon ความแตกต่างอีกประการระหว่างการจำลองแบบและการแคชคือวิธีที่คุณรู้ว่าข้อมูลใดผิดเมื่อมีความแตกต่าง การจำลองแบบกำหนดกฎบางอย่างเกี่ยวกับวิธีการรวมข้อมูล การแคชในทางกลับกันเสมอ : แคชผิด
Odalrick
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.