Microservices และการจัดเก็บข้อมูล

ฉันกำลังพิจารณาที่จะย้าย REST API แบบเสาหินไปยังสถาปัตยกรรม microservice และฉันสับสนเล็กน้อยเกี่ยวกับที่เก็บข้อมูล ตามที่ฉันเห็นประโยชน์บางประการของ microservices คือ:

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

ปัญหาของฉันอยู่ที่การจัดเก็บข้อมูล เท่าที่ฉันเห็นมันมีหลายตัวเลือก:

1. บริการฐานข้อมูลเดียวที่ใช้ร่วมกันโดย microservices ทั้งหมด - นี่ดูเหมือนจะขจัดข้อได้เปรียบของการมีเพศสัมพันธ์แบบหลวม ๆ อย่างสมบูรณ์
2. อินสแตนซ์ฐานข้อมูลที่ติดตั้งในเครื่องบนไมโครไซต์แต่ละบริการ - ฉันไม่เห็นวิธีการปรับขนาดแนวนอนดังนั้นฉันไม่คิดว่ามันจะเป็นตัวเลือก
3. microservice แต่ละตัวมีบริการฐานข้อมูลของตัวเอง - ซึ่งเป็นวิธีที่มีแนวโน้มมากที่สุดเนื่องจากจะรักษาประโยชน์ของข้อต่อหลวมและการขยายตามแนวนอน (โดยใช้สำเนาฐานข้อมูลที่ซ้ำซ้อนและ / หรือทำให้เกิดปัญหาหลายอย่าง)

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

นี่ค่อนข้างตรงไปตรงมาดูเหมือนไร้สาระเล็กน้อย เซิร์ฟเวอร์ 16-20 เครื่องใช้งาน API อย่างง่ายโดยจำไว้ว่าโครงการจริงอาจจะมีบริการมากกว่า 4-5 เครื่อง? มีแนวคิดพื้นฐานที่ฉันขาดหายไปที่จะอธิบายเรื่องนี้หรือไม่?

บางสิ่งที่อาจช่วยได้ในขณะตอบรับ:

• ฉันเป็นผู้พัฒนาเพียงผู้เดียวในโครงการนี้และจะเป็นในอนาคตอันใกล้
• ฉันใช้ Node.js และ MongoDB แต่ฉันสนใจคำตอบที่ไม่เชื่อเรื่องภาษา - คำตอบอาจเป็นได้ว่าฉันแค่ใช้เทคโนโลยีที่ผิด!

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

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

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

อย่างไรก็ตามฉันขอเสนอวิธีแก้ปัญหาระดับกลาง

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

อย่างไรก็ตามในฐานะนักพัฒนาเดี่ยวฉันจะท้าทายแนวคิดทั้งหมดของ microservices ณ เวลานี้ - Martin Fowler เขียนเกี่ยวกับMonolith FirstและMicroservice Premium , Simon Brown พูดถึงmonoliths แบบแยกส่วนและ DHH พูดถึงMajestic Monolith. ฉันไม่แน่ใจว่าเสาหินของคุณจัดระเบียบได้ดีเพียงใด แต่ปรับโครงสร้างและจัดระเบียบใหม่ ระบุส่วนประกอบและทำความสะอาดแยกชิ้นส่วนเหล่านั้นเพื่อแยกชิ้นส่วนออกเป็นบริการได้อย่างง่ายดาย เช่นเดียวกันกับโครงสร้างฐานข้อมูลของคุณ มุ่งเน้นสถาปัตยกรรมที่ดีสะอาดและอิงส่วนประกอบซึ่งสามารถรองรับการปรับโครงสร้างใหม่ในบริการ Microservices เพิ่มค่าใช้จ่ายจำนวนมากสำหรับนักพัฒนาเดียวในการสร้างและสนับสนุนในการดำเนินงาน อย่างไรก็ตามเมื่อคุณต้องการปรับขนาดส่วนหนึ่งของระบบให้ใช้ระบบการตรวจสอบและการรายงานของคุณเพื่อระบุคอขวดแยกไปยังบริการและปรับขนาดตามความจำเป็น

microservice แต่ละตัวมีบริการฐานข้อมูลของตัวเอง - ซึ่งเป็นวิธีที่มีแนวโน้มมากที่สุดเนื่องจากจะรักษาประโยชน์ของข้อต่อหลวมและการขยายตามแนวนอน (โดยใช้สำเนาฐานข้อมูลที่ซ้ำซ้อนและ / หรือทำให้เกิดปัญหาหลายอย่าง)

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

[... ] สองอินสแตนซ์ microservice จริงต่อ microservice (ในกรณีที่เซิร์ฟเวอร์ล้มเหลวและสำหรับการปรับใช้โดยไม่ต้องหยุดทำงาน) และสองอินสแตนซ์บริการฐานข้อมูลต่อ microservice สอง (ในกรณีที่เซิร์ฟเวอร์ล้มเหลว ฯลฯ ... )

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

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

นี่ค่อนข้างตรงไปตรงมาดูเหมือนไร้สาระเล็กน้อย เซิร์ฟเวอร์ 16-20 เครื่องใช้งาน API อย่างง่ายโดยจำไว้ว่าโครงการจริงอาจจะมีบริการมากกว่า 4-5 เครื่อง? มีแนวคิดพื้นฐานที่ฉันขาดหายไปที่จะอธิบายเรื่องนี้หรือไม่?

สำหรับAPI แบบง่ายตัวเลขนี้ไม่ตรงกัน ให้ความสนใจถ้าคุณไม่ได้ตกอยู่ในหนึ่งใน "MICROSERVICE ครั้งแรก" กับดัก

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

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

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

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

เมื่อใช้งาน microservices หลายตัวเรามีตัวเลือกสำหรับการนำเทคโนโลยีฐานข้อมูลกลับมาใช้ใหม่สำหรับส่วนประกอบที่เป็นประโยชน์:

• แยกฐานข้อมูลต่อ microservice
• ฐานข้อมูลที่แชร์กับ:
  • schema แยก / ส่วนตัวต่อ microservice
  • ตารางแยก / ส่วนตัวต่อไมโครบริการ

ดูเพิ่มเติมได้ที่นี่

บริการฐานข้อมูลเดียวที่ใช้ร่วมกันโดย microservices ทั้งหมด - นี่ดูเหมือนจะขจัดข้อได้เปรียบของการมีเพศสัมพันธ์แบบหลวม ๆ อย่างสมบูรณ์

เห็นด้วยถ้าคุณหมายถึงการแชร์แถวและคอลัมน์ของตารางนั่นจะไม่ใช่ microservices

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

โดยทั่วไปมีจำนวนเงินที่ยุติธรรมที่เขียนขึ้นประมาณ microservices และความเพียร stateful เห็นที่นี่

ดีฉันได้อ่านบทความทั้งหมดในกระทู้นี้และสามารถบอกคุณว่าฉันสับสนกับคำถาม: มันผสม microservice (MS) กับบริการที่มี data access service (บริการ DB) กับฐานข้อมูลและเซิร์ฟเวอร์ ...

ถ้า MS เป็นองค์ประกอบอิสระ (ที่ปรับใช้ได้) การแก้ปัญหาที่ง่ายที่สุดอย่างหนึ่งในลักษณะไร้สัญชาติฐานข้อมูลอะไรที่มันต้องการ? หากงานที่ซับซ้อนมากขึ้นที่จะต้องแก้ไขซึ่งต้องมีภารกิจย่อยที่ง่ายที่สุด (MS?) มากกว่าหนึ่งรายการเพื่อแก้ไขด้วยกันมันยังคงเป็น MS หรือไม่? ใน SOA จะเรียกว่า Orchestrating Service มันใช้ "กระบวนการ" และประสานงานการร้องขอของ MS ดังนั้นจึงจำเป็นต้องยืนยันสถานะของมัน (orchestrations / ผู้จัดงาน / ผู้แต่ง / อื่น ๆ ทั้งหมดเป็น stateful) และต้องการที่เก็บข้อมูลส่วนบุคคล: ไม่มีใครอาจทำให้สถานะของผู้ควบคุม

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

เหตุใดเราจึงผิดพลาด 'ประตู' ซึ่งเป็นที่รู้จักและเปิดกว้าง อะไรคือความแตกต่างในเรื่องนี้ระหว่าง MS และวัตถุที่ยึดติดกับตัวเองเป็นประจำ? ทำไมเราต้องใช้ฐานข้อมูลส่วนบุคคลสำหรับ MS หากต้องการ (เพื่อความยืดหยุ่นและความสามารถในการรวบรวมข้อมูล) เพื่อเชื่อมต่อ Data Access Service (DAS) อย่าลืมว่า DAS ป้องกัน MS ด้วยภารกิจทางธุรกิจจากการรับรู้เกี่ยวกับการเชื่อมต่อทางกายภาพไปยังฐานข้อมูล การมีเพศสัมพันธ์แบบหลวม ๆ และความยืดหยุ่นที่ MS ควรรักษาไว้ให้มีส่วนร่วมอย่างอิสระในแอพพลิเคชั่นหลายตัวโดยไม่มีฐานข้อมูลยึดไว้