ใน microservice เป็นฐานข้อมูลเดียวหรือฐานข้อมูลเดียวสำหรับแต่ละบริการหรือไม่

ฉันเข้าใจว่าแต่ละบริการในสถาปัตยกรรม microservice ควรมีฐานข้อมูลของตัวเอง อย่างไรก็ตามด้วยการมีฐานข้อมูลของตัวเองมันหมายถึงการมีฐานข้อมูลอื่นในอินสแตนซ์ฐานข้อมูลเดียวกันหรือมีอินสแตนซ์ฐานข้อมูลอื่นอยู่ใช่หรือไม่

โดยสิ่งนี้ฉันไม่ได้หมายถึงการแชร์ฐานข้อมูลซึ่งไม่ใช่ข้อยกเว้น แต่เป็นอินสแตนซ์ฐานข้อมูล

ตัวอย่างเช่นถ้าฉันใช้ AWS และมีบริการ 3 รายการฉันจะสร้างฐานข้อมูล 3 รายการสำหรับบริการแต่ละรายการในอินสแตนซ์ RDS เดียวหรือฉันจะสร้างอินสแตนซ์ RDS 3 รายการแต่ละรายการมีฐานข้อมูลซึ่งใช้บริการแต่ละบริการอย่างอิสระหรือไม่

หากการใช้ฐานข้อมูลหลาย ๆ ตัวบนอินสแตนซ์ RDS เดียวเป็นความคิดที่ดีกว่ามันจะเอาชนะวัตถุประสงค์ของการมีบริการที่เป็นอิสระเพราะ:

1. ทรัพยากรของอินสแตนซ์ RDS จะถูกแชร์ระหว่างบริการต่างๆ Service A ซึ่งอาจมีการใช้งานฐานข้อมูลจำนวนมากในบางช่วงเวลาจะส่งผลกระทบต่อบริการ B ซึ่งใช้ฐานข้อมูลอื่น แต่ในอินสแตนซ์ RDS เดียวกันหรือไม่

2. บริการทั้งหมดจะขึ้นอยู่กับรุ่นฐานข้อมูลของอินสแตนซ์ RDS นั้น

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

เก็บทุกอย่างไว้ในฐานข้อมูลเดียว

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

การแยกฐานข้อมูลออกจากกัน

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

คุณกำลังแก้ไขปัญหาอะไร

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

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

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

หลักคำสอนและความจริง

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

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

ความจริงก็คือความต้องการเฉพาะของโครงการของคุณจะต้องมีชุดของการประนีประนอมที่แตกต่างกันเพื่อให้งานเสร็จในเวลาที่เหมาะสมและจัดการกับภาระของระบบที่คุณวัด (บวกอีกเล็กน้อย) พิจารณา front-end, microsrervice และ data tier trio ที่แยกได้อย่างสมบูรณ์เพื่อเป้าหมายที่สูงส่ง ยิ่งคุณมีความต้องการระบบของคุณมากเท่าใดก็ยิ่งใกล้ถึงเป้าหมายนั้นมากขึ้นเท่านั้น เราไม่ได้ทั้งหมด[insert name of highly successful web entity here]และพวกเขาไม่ได้เริ่มต้นที่พวกเขาอยู่ตอนนี้ บางครั้งคุณต้องเริ่มต้นด้วยสถานการณ์ที่ไม่สมบูรณ์แบบและมีความสุขกับมัน

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

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

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

มันไม่สำคัญ

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

อินสแตนซ์ RDS เป็นกล่องเดียว หากคุณมีหลายฐานข้อมูลในอินสแตนซ์เดียวจากนั้นพวกเขาแบ่งปัน CPU / หน่วยความจำ ฯลฯ

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

อย่างไรก็ตามฉันจะบอกว่า microservice ซึ่งผูกพันกับประสิทธิภาพของฐานข้อมูลนั้นผิดปกติ

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

ในกรณีนี้คุณสามารถแบ่งปันฐานข้อมูลเดียวกันกับทุกบริการ microservice ของคุณ

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

มีสองระนาบที่ encapsulation นี้ทำงาน:

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

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

ฉันคิดว่ามันอาจช่วยให้ทฤษฎีมากกว่านี้อีกเล็กน้อย หนึ่งในแนวคิดที่สร้างแรงบันดาลใจเบื้องหลังไมโครเซอร์วิซคือกระบวนการแบ่งปันข้อความ บริการไมโครเป็นเหมือนนักแสดงในโมเดลนักแสดง ซึ่งหมายความว่าแต่ละกระบวนการรักษาสถานะท้องถิ่นของตนเองและวิธีเดียวสำหรับกระบวนการหนึ่งในการเข้าถึงสถานะของกระบวนการอื่นคือการส่งข้อความ (และแม้กระทั่งกระบวนการอื่น ๆ สามารถตอบสนองได้ อะไรคือความหมายโดย "ทุก MICROSERVICE มีฐานข้อมูลของตัวเอง" เป็นจริงว่าสถานะของกระบวนการ (เช่น MICROSERVICE) เป็นท้องถิ่นและภาคเอกชน ในระดับใหญ่สิ่งนี้ชี้ให้เห็นว่า "ฐานข้อมูล" ควรจะจัดวางด้วย microservice นั่นคือ "ฐานข้อมูล" ควรจัดเก็บและดำเนินการบนโลจิคัลโหนดเดียวกันกับ microservice "อินสแตนซ์" ที่แตกต่างกันของบริการไมโครเป็นกระบวนการที่แยกกันดังนั้นแต่ละรายการควรมี "ฐานข้อมูล" ของตัวเอง

ฐานข้อมูลส่วนกลางหรือฐานข้อมูลที่ใช้ร่วมกันระหว่าง microservices หรือแม้กระทั่งอินสแตนซ์ของ microservice จะจากมุมมองนี้จะเป็นสถานะที่ใช้ร่วมกัน วิธี "ที่เหมาะสม" ในการจัดการสิ่งนี้จากเปอร์สเปคทีฟ microservices คือการมีฐานข้อมูลที่ใช้ร่วมกันเป็นสื่อกลางโดย microservice microservices อื่น ๆ ที่ต้องการทราบเกี่ยวกับเนื้อหาของฐานข้อมูลจะส่งข้อความไปยัง "microservice ฐานข้อมูล" นั้น โดยทั่วไปแล้วสิ่งนี้จะไม่ขจัดความต้องการสถานะท้องถิ่น (เช่นต่อ "ฐานข้อมูล" อินสแตนซ์ microservice) สำหรับไมโครไซต์ดั้งเดิม! การเปลี่ยนแปลงคือสิ่งที่สถานะท้องถิ่นแสดงให้เห็น แทนที่จะเก็บ "User Sally เป็นผู้ดูแลระบบ" ก็จะเก็บ "microservice ฐานข้อมูลกล่าวว่า 'User Sally เป็นผู้ดูแลระบบ' เมื่อห้านาทีก่อน" ในคำอื่น ๆ เกี่ยวกับสถานะของ microservices อื่น ๆ

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

แน่นอนว่าข้อเสนอแนะไม่ควรติดอินสแตนซ์ของ Oracle ลงในคอนเทนเนอร์ Docker ทุกตัว ก่อนอื่นไม่จำเป็นต้องมีไมโครบริการทุกตัวที่จะต้องมี "ฐานข้อมูล" กระบวนการบางอย่างไม่ต้องการสถานะถาวรใด ๆ ให้ทำงานอย่างถูกต้อง ตัวอย่างเช่น microservice ที่แปลระหว่างสองโปรโตคอลไม่จำเป็นต้องมีสถานะถาวรใด ๆ สำหรับเมื่อต้องการสถานะถาวรคำว่า "ฐานข้อมูล" เป็นเพียงคำสำหรับ "สถานะถาวร" สามารถเป็นไฟล์ที่มี JSON อยู่ในนั้นหรือฐานข้อมูล Sqlite หรือสำเนา Oracle ที่ทำงานอยู่ภายในเครื่องหากคุณต้องการหรือวิธีการอื่นใดของเครื่องภายในจัดเก็บข้อมูลอย่างต่อเนื่อง หาก "ฐานข้อมูล" ไม่ได้อยู่ในพื้นที่จากมุมมองของ microservices แท้ๆควรได้รับการปฏิบัติเหมือนบริการ (micro) ที่แยกต่างหาก ด้วยเหตุนี้จึงไม่มีเหตุผลที่จะมีอินสแตนซ์ RDS เป็น "ฐานข้อมูล" สำหรับ microservice อีกครั้งมุมมองไม่ใช่ "microservices จำนวนมากที่มีฐานข้อมูล RDS ของตัวเอง" แต่ "microservices จำนวนมากที่สื่อสารกับฐานข้อมูล RDS" ณ จุดนี้มันไม่สร้างความแตกต่างว่าข้อมูลจะถูกเก็บไว้ในอินสแตนซ์ฐานข้อมูลเดียวกันหรือไม่

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