การถ่ายโอนไฟล์ / ข้อมูลขนาดใหญ่ในสถาปัตยกรรม Microservice

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

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

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

ไม่มีใครรู้ว่ารุ้งยูนิคอร์น (Netflix, Amazon, Google, ฯลฯ ) จัดการกับไฟล์ / การแลกเปลี่ยนข้อมูลขนาดใหญ่ระหว่างบริการของพวกเขา?

ไม่มีใครรู้ว่ารุ้งยูนิคอร์น (Netflix, Amazon, Google, ฯลฯ ) จัดการกับไฟล์ / การแลกเปลี่ยนข้อมูลขนาดใหญ่ระหว่างบริการของพวกเขา?

น่าเสียดายที่ฉันไม่ทราบวิธีจัดการกับปัญหาดังกล่าว

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

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

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

• หาก "แอปพลิเคชัน" ของคุณจำเป็นต้องทำงานกับเอกสารมันจะถาม microservice ที่เกี่ยวข้องและประมวลผลผลลัพธ์

• หากบริการอื่นต้องการเอกสารจริงหรือบางส่วนของมันต้องขอบริการเอกสาร

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

นี่เป็นปัญหาทางสถาปัตยกรรม:

1. ลดความจำเป็นในการถ่ายโอนข้อมูลจำนวนมาก

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

2. ลดขนาดของข้อมูลเอง

   คิดว่าวิธีที่คุณสามารถบีบอัดข้อมูลของคุณ: เริ่มต้นด้วย algortihms การบีบอัดที่เกิดขึ้นจริงถึงโครงสร้างข้อมูลสมาร์ท ยิ่งลวดยิ่งน้อยเท่าไหร่คุณก็ยิ่งเร็วเท่านั้น

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

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

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

อย่างไรก็ตามคุณอาจต้องใช้บริการเพื่ออัปโหลดเอกสารและรับ URL

ไม่มีใครรู้ว่ารุ้งยูนิคอร์น (Netflix, Amazon, Google, ฯลฯ ) จัดการกับไฟล์ / การแลกเปลี่ยนข้อมูลขนาดใหญ่ระหว่างบริการของพวกเขา?

ชำระเงินรายละเอียดของ Amazon S3 REST API ดูเหมือนว่าพวกเขาจะส่งคืนวัตถุเต็มเป็นไบต์ ดูเหมือนว่ามีตัวเลือกไม่มากนักหากคุณกำลังออกแบบบริการไมโคร ลิงก์รูปแบบการตอบกลับของ Amazon S3