การครอบครองหลายครั้งหรือหลายอินสแตนซ์?

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

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

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

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

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

การครอบครองหลายแห่ง :

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

อินสแตนซ์หลาย :

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

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

ในกรณีที่จะช่วยได้ (อาจจะ?) เรากำลังใช้Laravelเป็นเฟรมเวิร์กหลักสำหรับแบ็คเอนด์ (ทั้งหมด RESTfully)

ฉันกำลังถามคำถามเดียวกันกับตัวเองในขณะนี้

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

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

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

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

• PaaS ตามคอนเทนเนอร์
• การจัดเตรียมและการปรับขนาดของคอนเทนเนอร์อัตโนมัติ (คอนเทนเนอร์ยืดหยุ่น)

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

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

ยัง:

• ระบบอัตโนมัติของการสร้างอินสแตนซ์ใหม่สามารถทำได้ผ่าน PaaS API
• การทำงานอัตโนมัติของการปรับใช้เวอร์ชันใหม่สามารถทำได้ผ่าน PaaS API โดยไม่มีการหยุดทำงาน (ทำหน้าที่แทน)
• การปรับสเกลอยู่เสมอไม่เคยขึ้น เราไม่ต้องกังวลกับชุดข้อมูลขนาดใหญ่ในระดับอินสแตนซ์

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

ซึ่งนำฉันไปสู่ข้อได้เปรียบสุดท้ายของการพัฒนาผู้เช่ารายเดียวสำหรับโครงการเริ่มต้นระยะเริ่มแรก (การลงทุนล่วงหน้า):

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

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

การสนับสนุนทั้งสองตัวเลือกเป็นไปได้เช่นกัน (กลุ่มผู้เช่าข้ามหลายอินสแตนซ์)

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

ระบบฐานผู้เช่ามาพร้อมกับความเสี่ยงด้านความปลอดภัยของข้อมูล เพียงแค่พิจารณาว่ามันง่ายแค่ไหนที่จะลืมประโยค "WHERE tenantId = x" เหตุผลหลักในการใช้ระบบที่มีความสามารถของผู้เช่าคือประสิทธิภาพการทำงานกระบวนการมีน้ำหนักมากโดยการแบ่งปันกระบวนการที่คุณอาจได้รับมากกว่าหนึ่งเครื่อง นี่เป็นความจริงมากขึ้นฉันคิดว่าในโลก 32 บิตแล้วทุกวันนี้บนเครื่อง 64 บิตที่มี RAM มากขึ้น

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

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