การสร้างแอปพลิเคชันแบบหลายผู้เช่าอาจซับซ้อน บทความนี้รวบรวมบทความที่เราเคยโพสต์เกี่ยวกับกลยุทธ์ของผู้เช่าและองค์กร เราหวังว่ามันจะช่วยคุณประหยัดเวลาและเริ่มต้นได้ง่ายขึ้น
การสร้างแอปพลิเคชันแบบหลายผู้เช่าอาจมีความท้าทาย โดยมีหลายแง่มุมที่ต้องพิจารณา บทความนี้รวบรวมโพสต์บล็อกก่อนหน้าที่เราได้เคยพูดถึงกรอบการทำความเข้าใจของผู้เช่าและองค์กร สำหรับการเริ่มต้นอย่างรวดเร็วและเพื่อประหยัดเวลา เพียงแค่ดูบทความนี้ ซึ่งรวมทุกสิ่งที่คุณต้องการ!
แนวทางทั่วไปมีการระบุไว้ในขั้นตอนต่อไปนี้:
ซอฟต์แวร์ multi-tenancy คือ สถาปัตยกรรมซอฟต์แวร์ ที่มี อินสแตนซ์ เดียวของ ซอฟต์แวร์ รันบนเซิร์ฟเวอร์และให้บริการผู้เช่าหลายราย ระบบที่ออกแบบในลักษณะนี้จะเป็น "แชร์" (แทนที่จะเป็น "เฉพาะ" หรือ "แยก")
ผู้เช่าคือกลุ่มผู้ใช้ที่แชร์การเข้าถึงร่วมกันด้วยสิทธิพิเศษเฉพาะเจาะจงกับอินสแตนซ์ซอฟต์แวร์
หนึ่งในกรอบความคิดของการมีผู้เช่าหลายรายคือ "การแชร์" ในคำจำกัดความที่กว้างขึ้นของการมีผู้เช่าหลายราย การมีแอปพลิเคชันแบบหลายผู้เช่าไม่ได้หมายความว่า ทุก ส่วนประกอบในโซลูชันนั้นมีส่วนแบ่งกัน แต่หมายความว่าอย่างน้อย บาง ส่วนประกอบของโซลูชันถูกนำไปใช้ซ้ำกับผู้เช่าหลายราย การเข้าใจคำศัพท์นี้ในวงกว้างจะช่วยให้คุณเข้าใจความต้องการของลูกค้าของคุณและแหล่งที่มาได้ดียิ่งขึ้น
เมื่อคุณเข้าใจสถาปัตยกรรมแบบหลายผู้เช่าได้แล้ว ขั้นตอนต่อไปคือการประยุกต์ใช้แอปของคุณกับสถานการณ์ในโลกจริง โดยเน้นที่ความต้องการของผลิตภัณฑ์และธุรกิจที่เฉพาะเจาะจง
แอปพลิเคชันแบบหลายผู้เช่ามักพบที่ของพวกเขาในโซลูชันแบบธุรกิจกับธุรกิจ (B2B) เช่น เครื่องมือเพิ่มประสิทธิภาพ ซอฟต์แวร์การทำงานร่วมกัน และผลิตภัณฑ์ซอฟต์แวร์ในรูปแบบบริการ (SaaS) อื่น ๆ ในบริบทนี้ "ผู้เช่า" แต่ละรายมักจะเป็นลูกค้าธุรกิจ ซึ่งอาจมีผู้ใช้หลายราย (พนักงานของพวกเขา) นอกจากนี้ ลูกค้าธุรกิจหนึ่งรายอาจมีผู้เช่าหลายรายเพื่อแสดงถึงองค์กรหรือหน่วยธุรกิจที่แตกต่างกัน
แอปพลิเคชัน B2B ไปไกลกว่าแค่ผลิตภัณฑ์ SaaS และมักเกี่ยวข้องกับการใช้แอปพลิเคชันแบบหลายผู้เช่า ในบริบทของ B2B แอปเหล่านี้ให้บริการเป็นแพลตฟอร์มทั่วไปสำหรับทีม ผู้ใช้ธุรกิจ และบริษัทคู่ค้าต่าง ๆ ที่จะเข้าถึงแอปพลิเคชันของคุณ
ตัวอย่างเช่น ลองพิจารณาบริษัทให้บริการรถเช่าที่ให้บริการทั้งแอปพลิเคชันแบบ B2C และ B2B แอปพลิเคชัน B2B ให้บริการธุรกิจลูกค้าหลายรายและการใช้สถาปัตยกรรมแบบหลายผู้เช่าสามารถช่วยในการจัดการพนักงานและทรัพยากรของพวกเขาได้ อย่างไรก็ตาม หากบริษัทต้องการรักษาระบบตัวตนผู้ใช้ที่เป็นหนึ่งเดียวกัน พวกเขาสามารถออกแบบสถาปัตยกรรมดังนี้:
ซาร่าห์มีทั้งตัวตนส่วนบุคคลและตัวตนธุรกิจ เธอใช้บริการรถเช่าเป็นผู้โดยสารและยังทำงานเป็นคนขับในช่วงเวลาว่างอีกด้วย ในบทบาทมืออาชีพของเธอ เธอยังจัดการธุรกิจของเธอและใช้ตัวตนธุรกิจนี้เพื่อเป็นพันธมิตรกับ Business 1
สำหรับธุรกิจขนาดใหญ่ ผู้เช่าหลายรายเป็นกุญแจสำคัญที่ช่วยให้การจัดการความต้องการทางด้านความพร้อมใช้งาน การจัดการทรัพยากร การจัดการต้นทุน และความปลอดภัยของข้อมูลได้อย่างมีประสิทธิภาพ บนระดับเทคนิค การใช้แนวทางแบบหลายผู้เช่าสามารถทำให้ง่าย กระชับ และส่งเสริมการขยายได้อย่างราบรื่น
เมื่อพิจารณาผลิตภัณฑ์ SaaS ซึ่งมีลักษณะคล้ายคลึงกับตึกอพาร์ตเมนต์ที่มีหลายห้อง ทั้งหมดในนั้นแชร์ฟังก์ชันการใช้งานทั่วไป เช่น น้ำ ไฟฟ้า และแก๊ส แต่ยังคงมีการควบคุมการจัดการพื้นที่และทรัพยากรของตนเอง นี่คือแนวทางที่ง่ายต่อการจัดการทรัพย์สิน
ในสถาปัตยกรรมแบบหลายผู้เช่า คำว่า "ผู้เช่า" ถูกนำมาใช้เพื่อสร้างขอบเขตที่แยกและรักษาความปลอดภัยทรัพยากรและข้อมูลของผู้เช่าต่าง ๆ ภายในอินสแตนซ์เดียวกัน ที่ใช้ร่วมกัน วิธีนี้ทำให้แน่ใจได้ว่าข้อมูลและการดำเนินงานของแต่ละผู้เช่าจะถูกแยกและปลอดภัย แม้ว่าพวกเขาจะใช้ทรัพยากรพื้นฐานเดียวกันก็ตาม
เมื่อพูดถึงแอปพลิเคชันแบบหลายผู้เช่า เป็นสิ่งจำเป็นเสมอที่จะบรรลุ การแยกผู้เช่า นี้หมายถึงการแยกและรักษาความปลอดภัยข้อมูลและทรัพยากรของผู้เช่าต่าง ๆ ภายในระบบที่แชร์ (เช่น โครงสร้างพื้นฐานของคลาวด์หรือแอปพลิเคชันแบบหลายผู้เช่า) วิธีนี้ช่วยป้องกันความพยายามเข้าถึงทรัพยากรของผู้เช่าอื่นโดยไม่ได้รับอนุญาต
แม้ว่าการอธิบายอาจดูเป็นนามธรรม เราจะใช้ตัวอย่างและรายละเอียดสำคัญเพื่ออธิบายความคิดของการแยกและแนวทางที่ดีที่สุดในการบรรลุการแยกผู้เช่าให้ชัดเจนขึ้น
นั่นเป็นเพราะการแยกผู้เช่าไม่จำเป็นต้องเป็นการสร้างระดับทรัพยากรในโครงสร้างพื้นฐาน ในอาณาจักรของการมีผู้ใช้หลายคนและการแยก การแยกบางคนมองว่าเป็นการแบ่งทรัพยากรโครงสร้างพื้นฐานที่แท้จริงออกจากกัน แนวทางนี้มักนำไปสูรุปแบบที่แต่ละผู้เช่ามีฐานข้อมูล อินสแตนซ์การคำนวณ บัญชี หรือคลาวด์ส่วนตัวแยกต่างหาก ในสถานการณ์ที่ใช้ทรัพยากรร่วมกัน เช่น แอปพลิเคชันหลายผู้เช่า วิธีการบรรลุการแยกอาจเป็นโครงสร้างทางตรรกศาสตร์
การแยกผู้เช่ามุ่งเน้นเฉพาะการใช้บริบทของ "ผู้เช่า" เพื่อจำกัดการเข้าถึงทรัพยากร วิธีนี้จะประเมินบริบทของผู้เช่าปัจจุบันและใช้บริบทดังกล่าวในการตัดสินใจว่าผู้เช่านั้นสามารถเข้าถึงทรัพยากรอะไรได้บ้าง
การใช้การตรวจสอบและการอนุญาตเพื่อควบคุมการเข้าถึงสภาพแวดล้อม SaaS ของคุณเป็นสิ่งสำคัญ แต่ไม่เพียงพอสำหรับการแยกอย่างสมบูรณ์ กลไกเหล่านี้เป็นเพียงส่วนหนึ่งของปริศนาความปลอดภัย
ผู้คนมักถามคำถามว่า สามารถใช้โซลูชั่นการอนุญาตทั่วไปและการควบคุมการเข้าถึงตามบทบาทเพื่อบรรลุการแยกผู้เช่าได้ไหม?
สิ่งนี้คือ คุณสามารถสร้างแอปพลิเคชันแบบหลายผู้เช่าได้ แต่คุณไม่สามารถบอกว่าได้บรรลุและใช้กลยุทธ์การแยกผู้เช่าเป็นแนวทางปฏิบัติที่ดีที่สุด เราไม่ค่อยแนะนำเพราะ
เพื่ออธิบายเพิ่มเติม ลองพิจารณาสถานการณ์ที่คุณได้ตั้งค่าการตรวจสอบและการอนุญาตสำหรับระบบ SaaS ของคุณ เมื่อผู้ใช้ลงชื่อเข้าใช้ พวกเขาจะได้รับโทเค็นที่มีข้อมูลเกี่ยวกับบทบาทของพวกเขา ระบุสิ่งที่พวกเขาสามารถทำได้ในแอปพลิเคชัน แม้ว่าวิธีนี้จะเพิ่มความปลอดภัย แต่มันไม่รับประกันการแยก
การพึ่งพาการตรวจสอบและการอนุญาตอย่างเดียวจะไม่ป้องกันผู้ใช้ที่มีบทบาทที่ถูกต้องจากการเข้าถึงทรัพยากรของผู้เช่าอื่น ดังนั้นเราจำเป็นต้องรวมบริบท "ผู้เช่า" เช่น ID ผู้เช่า เพื่อจำกัดการเข้าถึงทรัพยากร
นี่เป็นที่มาของการแยกผู้เช่า มันใช้การระบุเฉพาะของผู้เช่าเพื่อตั้งกำแพง เช่น กำแพง ประตู และล็อค เพื่อให้เกิดการแยกที่ชัดเจนระหว่างผู้เช่าต่าง ๆ
เราได้พูดถึงการแยกผู้เช่าแล้ว แต่ตัวตนล่ะ? คุณจะตัดสินใจอย่างไรว่าตัวตนของคุณควรเป็น "แยก" หรือไม่?
มีความสับสนบ่อย ๆ เกี่ยวกับแนวคิดของ "การแยกตัวตน" มันอาจหมายถึงสถานการณ์ที่ผู้ใช้ในโลกจริงมีตัวตนสองตัวในความเข้าใจทั่วไปของผู้คน
บางครั้งซาริโอเหล่านี้ถูกเรียกว่า "การแยกตัวตน" จึงอาจไม่ช่วยในการตัดสินใจ
แทนที่จะตัดสินใจว่าคุณต้องการ "การแยกตัวตน" หรือไม่ ให้พิจารณา
คำตอบนี้สามารถนำแนวทางการออกแบบระบบของคุณได้ สำหรับคำตอบสั้น ๆ เกี่ยวกับแอปพลิเคชันแบบหลายผู้เช่า
ในแอปพลิเคชันแบบหลายผู้เช่า ตัวตน ซึ่งต่างจากทรัพยากรและข้อมูลที่เฉพาะเจาะจงต่อผู้เช่า จะแชร์ระหว่างผู้เช่าหลายราย ลองนึกภาพว่าคุณเป็นผู้ดูแลอาคาร คุณไม่ต้องการรักษาเอกสารชื่อที่แยกต่างหากสองเอกสารเพื่อจัดการตัวตนของผู้เช่าของคุณ
เมื่อมุ่งหวังถึงการแยกผู้เช่า คุณอาจสังเกตเห็นการเน้นที่ซ้ำ ๆ เกี่ยวกับคำว่า "องค์กร" ซึ่งมักถือเป็นวิธีปฏิบัติที่ดีที่สุดในการสร้างแอปพลิเคชันแบบหลายผู้เช่า
ด้วยการใช้แนวคิดของ "องค์กร" คุณสามารถบรรลุการแยกผู้เช่าในแอปพลิเคชันแบบหลายผู้เช่าของคุณ ในขณะที่รักษาระบบตัวตนที่เป็นหนึ่งเดียว
เมื่อเลือกรูปแบบการอนุญาตที่เหมาะสม ให้พิจารณาคำถามเหล่านี้:
RBAC (การควบคุมการเข้าถึงตามบทบาท) เป็นวิธีการเพื่อให้สิทธิ์ผู้ใช้ตามบทบาทของพวกเขา ช่วยให้สามารถจัดการการเข้าถึงทรัพยากรได้อย่างมีประสิทธิภาพ
เทคนิคทั่วไปนี้เป็นเทคนิคการควบคุมการเข้าถึงและเป็นองค์ประกอบสำคัญของคุณลักษณะการอนุญาตของ Logto ในฐานะแพลตฟอร์มการจัดการตัวตนที่ครอบคลุม Logto มีโซลูชันที่ปรับแต่งได้สำหรับหลายเลเยอร์และเอนทิตี รองรับนักพัฒนาและธุรกิจสำหรับอลเจอร์ผลิตภัณฑ์ที่หลากหลาย
เพื่อปกป้องทรัพยากร API ทั่วไปที่ไม่เฉพาะเจาะจงกับองค์กรใดๆ และไม่ต้องการข้อจำกัดบริบท ฟีเจอร์ API RBAC เหมาะสมอย่างยิ่ง
เพียงแค่ลงทะเบียน API และกำหนดสิทธิ์ให้กับแต่ละทรัพยากร จากนั้นควบคุมการเข้าถึงผ่านความสัมพันธ์ระหว่างบทบาทและผู้ใช้
ทรัพยากร API บทบาทและสิทธิ์ที่นี่เป็น "สาธารณะ" ภายใต้ระบบตัวตนที่เป็นหนึ่งเดียว นี่เป็นสิ่งที่พบบ่อยในผลิตภัณฑ์ B2C ซึ่งมีความลำดับขั้นที่น้อยและไม่ต้องการการแยกที่ลึกเกินไป
ในสภาพแวดล้อม B2B และแบบหลายผู้เช่า การแยกผู้เช่าเป็นสิ่งจำเป็น เพื่อบรรลุสิ่งนี้ องค์กรถูกใช้เป็นบริบทสำหรับการแยก หมายความว่า RBAC มีผลบังคับใช้ก็ต่อเมื่อผู้ใช้เป็นเจ้าของสิทธิ์ในองค์กรเฉพาะ
Organizational RBAC มุ่งเน้นไปที่การควบคุมการเข้าถึงในระดับองค์กรแทนที่จะเป็นระดับ API วิธีนี้ให้ความยืดหยุ่นที่สำคัญในการจัดการตนเองในระดับองค์กรระยะยาวแต่ยังอยู่ภายในระบบตัวตนที่เป็นหนึ่งเดียว
คุณสมบัติสำคัญของ Organizational RBAC คือบทบาทและสิทธิ์นั้นเหมือนกันระหว่างองค์กรทั้งหมดโดยปกติ ทำให้ "เทมเพลตองค์กร Logto" มีความหมายอย่างยิ่งในการปรับประสิทธิภาพการพัฒนา นี่สอดคล้องกับปรัชญาที่แชริ่งของแอปพลิเคชันหลายผู้เช่า ซึ่งแนวคิดการควบคุมการเข้าถึงและตัวตนนั้นเป็นส่วนประกอบโครงสร้างพื้นฐานทั่วไปในหมู่ผู้เช่าทั้งหมด (ผู้เช่าในแอป) สิ่งนี้ถือเป็นวิธีการทั่วไปในผลิตภัณฑ์ SaaS
บทความนี้ให้ทุกสิ่งที่คุณต้องการเพื่อเริ่มต้นในการเตรียมและกำหนดค่าแอปพลิเคชันแบบหลายผู้เช่า ลองใช้ Logto วันนี้และเริ่มใช้แนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนาแอปพลิเคชันแบบหลายผู้เช่าด้วยองค์กร