ขออภัย คำนี้ไม่มีคู่ภาษารัสเซียที่ดี วิกิพีเดียให้ "ผู้เช่าหลายคน การเช่าหลายครั้ง" ซึ่งบางครั้งเรียกว่า "การเป็นเจ้าของหลายรายการ" คำศัพท์เหล่านี้อาจสร้างความสับสนได้ เนื่องจากหัวข้อนี้ไม่เกี่ยวข้องกับการเช่าหรือการเป็นเจ้าของโดยเนื้อแท้ นี่เป็นคำถามเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์และการจัดการการดำเนินงาน และอย่างหลังก็มีความสำคัญไม่น้อย
เราเริ่มสร้างความเข้าใจเกี่ยวกับการเช่าหลายพื้นที่พร้อมๆ กับที่เราเริ่มออกแบบแนวทางสำหรับรูปแบบคลาวด์ (บริการ) ของการดำเนินงาน 1C:Enterprise เมื่อหลายปีก่อน และตั้งแต่นั้นมา ความเข้าใจของเราก็เพิ่มขึ้นอย่างต่อเนื่อง เรากำลังค้นพบแง่มุมใหม่ๆ ของหัวข้อนี้มากขึ้นเรื่อยๆ (ข้อดี ข้อเสีย ความยาก คุณลักษณะ ฯลฯ)
บางครั้งนักพัฒนาเข้าใจว่าการเช่าหลายรายการเป็นหัวข้อที่ค่อนข้างง่าย: "เพื่อให้ข้อมูลของหลายองค์กรถูกจัดเก็บไว้ในฐานข้อมูลเดียว คุณต้องเพิ่มคอลัมน์ที่มี ID องค์กรลงในตารางทั้งหมดและตั้งค่าตัวกรองในนั้น" แน่นอน เราเริ่มศึกษาประเด็นนี้ตั้งแต่ตอนนั้น แต่พวกเขาก็ตระหนักได้อย่างรวดเร็วว่านี่เป็นเพียงการหักล้างเพียงครั้งเดียว (ซึ่งก็ไม่ใช่เรื่องง่ายเช่นกัน) โดยทั่วไปนี่คือ "ทั้งประเทศ"
แนวคิดพื้นฐานของการเพิ่มจำนวนสามารถอธิบายได้ดังนี้ การใช้งานทั่วไปคือกระท่อมครอบครัวเดี่ยวที่ใช้โครงสร้างพื้นฐาน (ผนัง หลังคา น้ำประปา เครื่องทำความร้อน ฯลฯ) แอปพลิเคชันหลายผู้เช่าคืออาคารอพาร์ตเมนต์ ในนั้นแต่ละครอบครัวใช้องค์ประกอบโครงสร้างพื้นฐานเดียวกัน แต่โครงสร้างพื้นฐานนั้นถูกนำไปใช้กับบ้านทั้งหลังโดยรวม
วิธีการหลายผู้เช่าดีหรือไม่ดี? มีความคิดเห็นที่แตกต่างกันมากเกี่ยวกับเรื่องนี้ ดูเหมือนว่าไม่มี "ดีหรือไม่ดี" เลย คุณต้องเปรียบเทียบข้อดีข้อเสียในบริบทของงานเฉพาะที่ต้องแก้ไข แต่นั่นมันคนละประเด็น...
ในแง่ที่ง่ายที่สุด เป้าหมายของหลายผู้เช่าคือการลดค่าใช้จ่ายในการบำรุงรักษาแอปพลิเคชันโดย "แบ่งปัน" ต้นทุนโครงสร้างพื้นฐาน นี่เป็นการเคลื่อนไหวแบบเดียวกับการลดต้นทุนของแอปพลิเคชันโดยใช้โซลูชันการหมุนเวียน (อาจด้วยการปรับแต่งและการปรับแต่ง) และไม่เขียน "ตามสั่ง" ในกรณีเดียวเท่านั้นที่การพัฒนาถูกขัดเกลาทางสังคมและในอีกกรณีหนึ่ง - การเอารัดเอาเปรียบ
และขอย้ำอีกครั้งว่าไม่มีลิงก์โดยตรงไปยังวิธีการขาย สถาปัตยกรรมแบบหลายผู้เช่ายังสามารถใช้ในโครงสร้างพื้นฐานด้านไอทีขององค์กรหรือแผนก เพื่อทำให้สาขาประเภทเดียวกันจำนวนมากเป็นระบบอัตโนมัติ
เราสามารถพูดได้ว่าการเช่าหลายพื้นที่ไม่ได้เป็นเพียงเรื่องของการจัดการพื้นที่จัดเก็บข้อมูลเท่านั้น นี่คือแบบจำลองของแอปพลิเคชันทั้งหมด (รวมถึงส่วนสำคัญของลักษณะสถาปัตยกรรม แบบจำลองการปรับใช้ และองค์กรบริการ)
สำหรับเราแล้ว สิ่งที่ยากและน่าสนใจที่สุดเกี่ยวกับโมเดลหลายผู้เช่าคือสาระสำคัญของแอปพลิเคชันคือ "แยก" ฟังก์ชันบางส่วนทำงานร่วมกับพื้นที่ข้อมูลเฉพาะ (อพาร์ตเมนต์) และ "ไม่สนใจ" เนื่องจากมีผู้เช่าในอพาร์ตเมนต์อื่น และบางคนมองว่าบ้านโดยรวมและใช้งานได้ทันทีสำหรับผู้อยู่อาศัยทุกคน ในเวลาเดียวกันหลังไม่สามารถเพิกเฉยต่อความจริงที่ว่าเหล่านี้ยังคงเป็นอพาร์ทเมนต์ที่แยกจากกันและจำเป็นต้องให้ระดับความละเอียดและความปลอดภัยที่จำเป็น
ใน 1C:Enterprise มีการใช้แบบจำลองหลายผู้เช่าที่ระดับของเทคโนโลยีต่างๆ นี่คือกลไกของแพลตฟอร์ม 1C: Enterprise ซึ่งเป็นกลไก"และ"", กลไก (ไลบรารีของระบบย่อยมาตรฐาน)
แต่ละรายการเหล่านี้มีส่วนช่วยในการก่อสร้างโครงสร้างพื้นฐานโดยรวมของอาคารอพาร์ตเมนต์ เหตุใดจึงมีการนำไปใช้ในเทคโนโลยีหลายอย่าง ไม่ใช่ในเทคโนโลยีเดียว เช่น ในแพลตฟอร์ม ประการแรก เนื่องจากในความเห็นของเรา การแก้ไขกลไกบางอย่างสำหรับตัวเลือกการปรับใช้เฉพาะนั้นค่อนข้างเหมาะสม แต่โดยทั่วไปแล้ว นี่ไม่ใช่คำถามที่ง่าย และเราต้องเผชิญกับทางเลือกอยู่ตลอดเวลา - ในระดับใดดีกว่าที่จะใช้แง่มุมใดแง่มุมหนึ่งของการเช่าหลายพื้นที่
เห็นได้ชัดว่าส่วนพื้นฐานของกลไกจำเป็นต้องนำไปใช้ในแพลตฟอร์ม ตัวอย่างเช่น การแยกข้อมูลจริง สิ่งที่มักจะเริ่มการสนทนาเกี่ยวกับการเช่าหลายรายการ แต่ท้ายที่สุด โมเดลหลายผู้เช่า "เดินทาง" ผ่านส่วนสำคัญของกลไกของแพลตฟอร์มและต้องการการปรับแต่ง และในบางกรณีก็ต้องคิดใหม่
ที่ระดับแพลตฟอร์ม เราได้ใช้กลไกพื้นฐานทุกประการ ช่วยให้คุณสร้างแอปพลิเคชันที่ทำงานในรูปแบบหลายผู้เช่า แต่เพื่อให้แอปพลิเคชัน "ใช้ชีวิตและทำงาน" ในรูปแบบดังกล่าว คุณต้องมีระบบสำหรับจัดการ "กิจกรรมชีวิต" เทคโนโลยี 1cFresh และเลเยอร์ตรรกะทางธุรกิจแบบรวมที่ระดับ BSP มีหน้าที่รับผิดชอบในเรื่องนี้ เช่นเดียวกับในอาคารอพาร์ตเมนต์ โครงสร้างพื้นฐานมอบทุกสิ่งที่ผู้อยู่อาศัยต้องการ ดังนั้นเทคโนโลยี 1cFresh จึงมอบทุกสิ่งที่จำเป็นสำหรับแอปพลิเคชันที่ทำงานในรูปแบบหลายผู้เช่า และเพื่อให้แอปพลิเคชันสามารถโต้ตอบกับโครงสร้างพื้นฐานนี้ (โดยไม่มีการดัดแปลงที่สำคัญ) จึงมีการวาง "ตัวเชื่อมต่อ" ที่เกี่ยวข้องในรูปแบบของระบบย่อย BSP
ในแง่ของกลไกแพลตฟอร์ม เป็นเรื่องง่ายที่จะเห็นว่าเมื่อเราได้รับประสบการณ์และพัฒนากรณีการใช้งานคลาวด์ 1C:Enterprise เราจะขยายรายการกลไกที่เกี่ยวข้องกับสถาปัตยกรรมนี้ ลองมาตัวอย่างหนึ่ง ในรูปแบบหลายผู้เช่า บทบาทของผู้เข้าร่วมบริการแอปพลิเคชันจะเปลี่ยนไปอย่างมาก บทบาท (ระดับความรับผิดชอบ) ของผู้ที่รับผิดชอบในการดำเนินงานของแอปพลิเคชันนั้นเพิ่มขึ้นอย่างมาก พวกเขาจำเป็นต้องมีเครื่องมือควบคุมแอปพลิเคชันที่มีประสิทธิภาพมากขึ้น เนื่องจากผู้ใช้แอปพลิเคชัน (ผู้อยู่อาศัย) ไว้วางใจผู้ให้บริการที่พวกเขาทำงานด้วยเป็นอันดับแรก ในการทำเช่นนี้ เราได้ติดตั้งเวอร์ชัน 8.3 ใหม่ . กลไกนี้ช่วยให้ผู้ดูแลระบบของผู้ให้บริการสามารถจำกัดอิสระของนักพัฒนาแอปพลิเคชันให้อยู่ในระดับความปลอดภัยที่จำเป็น ซึ่งอันที่จริงแล้ว เพื่อแยกการทำงานของแอปพลิเคชันสำหรับผู้เช่าแต่ละรายภายในแซนด์บ็อกซ์หนึ่งๆ
สิ่งที่น่าสนใจไม่น้อยคือสถาปัตยกรรมสำหรับการจัดการแอปพลิเคชันที่ทำงานในโหมดหลายผู้เช่า (สิ่งที่นำมาใช้ในเทคโนโลยี 1cFresh และ BSP) ที่นี่ เมื่อเปรียบเทียบกับโมเดลการปรับใช้แบบเดิม ข้อกำหนดสำหรับกระบวนการจัดการอัตโนมัตินั้นเพิ่มขึ้นอย่างมาก มีกระบวนการดังกล่าวมากมาย: การสร้างพื้นที่ข้อมูลใหม่ ("อพาร์ทเมนท์"), การอัปเดตแอปพลิเคชัน, การอัปเดตข้อมูลด้านกฎระเบียบ, การสำรองข้อมูล ฯลฯ และแน่นอนว่าข้อกำหนดสำหรับระดับความน่าเชื่อถือและความพร้อมใช้งานนั้นเพิ่มขึ้น ตัวอย่างเช่น เพื่อให้แน่ใจว่าการโต้ตอบที่เชื่อถือได้ระหว่างแอปพลิเคชันและส่วนประกอบของระบบควบคุม เราได้ใช้เทคโนโลยีของระบบการโทรแบบอะซิงโครนัสพร้อมการส่งมอบที่รับประกัน
จุดที่ละเอียดอ่อนมากคือวิธีการแบ่งปันข้อมูลและกระบวนการต่างๆ ดูเหมือนง่าย (ถ้าดูเหมือนกับใครบางคน) เพียงแวบแรกเท่านั้น ความยากที่สุดคือความสมดุลระหว่างการรวมศูนย์ข้อมูลและกระบวนการกับการกระจายอำนาจ ในแง่หนึ่ง การรวมศูนย์ช่วยให้คุณลดค่าใช้จ่าย (พื้นที่ดิสก์ ทรัพยากรตัวประมวลผล ความพยายามของผู้ดูแลระบบ ... ) ในทางกลับกันเป็นการจำกัดเสรีภาพของ "ผู้อยู่อาศัย" นี่เป็นเพียงช่วงเวลาหนึ่งของ "การแยกทาง" ของแอปพลิเคชัน เมื่อนักพัฒนาจำเป็นต้องคิดพร้อมกันเกี่ยวกับแอปพลิเคชันในแง่แคบ (ให้บริการ "อพาร์ทเมนต์" หนึ่งแห่ง) และในแง่กว้าง (ให้บริการ " ผู้เช่า" ในครั้งเดียว)
ตัวอย่างของ "ภาวะที่กลืนไม่เข้าคายไม่ออก" ดังกล่าว สามารถอ้างอิงข้อมูลอ้างอิงได้ แน่นอนว่ามีสิ่งล่อใจที่ดีที่จะทำให้ "ผู้อยู่อาศัย" ทุกคนในบ้านเป็นเรื่องธรรมดา สิ่งนี้ทำให้คุณสามารถจัดเก็บไว้ในสำเนาเดียวและอัปเดตให้ทุกคนในคราวเดียว แต่มันเกิดขึ้นที่ผู้เช่าบางรายต้องการการเปลี่ยนแปลงเฉพาะ ผิดปกติพอสมควร แต่ในทางปฏิบัติสิ่งนี้เกิดขึ้นแม้กระทั่งกับข้อมูลที่ระบุโดยหน่วยงานกำกับดูแล (หน่วยงานของรัฐ) กลายเป็นคำถามที่ยาก: เข้าสังคมหรือไม่เข้าสังคม? แน่นอนว่ามันเป็นเรื่องน่าดึงดูดที่จะสร้างข้อมูลทั่วไปสำหรับทุกคนและเป็นส่วนตัวสำหรับผู้ที่ต้องการ และสิ่งนี้นำไปสู่การปฏิบัติที่ยากมาก แต่เรากำลังดำเนินการอยู่...
อีกตัวอย่างหนึ่งคือการออกแบบการนำกระบวนการปกติไปใช้ (ทำงานตามกำหนดเวลา เริ่มต้นโดยระบบควบคุม ฯลฯ) ในแง่หนึ่ง สามารถนำไปใช้กับแต่ละพื้นที่ข้อมูลแยกกันได้ ง่ายและสะดวกยิ่งขึ้น แต่ในทางกลับกัน ความละเอียดที่ละเอียดเช่นนี้จะสร้างภาระให้กับระบบเป็นจำนวนมาก เพื่อลดภาระ จำเป็นต้องใช้กระบวนการทางสังคม แต่พวกเขาต้องการการศึกษาอย่างรอบคอบมากขึ้น
แน่นอนว่านี่เป็นคำถามที่สำคัญมาก และนักพัฒนาแอปพลิเคชันจะมั่นใจได้อย่างไรว่าพวกเขาทำงานในโหมดหลายผู้เช่า พวกเขาต้องทำอะไรเพื่อสิ่งนี้? แน่นอน เราพยายามอย่างหนักเพื่อให้แน่ใจว่าภาระของปัญหาด้านเทคโนโลยีและโครงสร้างพื้นฐานจะตกอยู่บนบ่าของเทคโนโลยีที่ให้มามากที่สุดเท่าที่จะเป็นไปได้ และผู้พัฒนาแอปพลิเคชันคิดเฉพาะในงานตรรกะทางธุรกิจเท่านั้น แต่เช่นเดียวกับปัญหาทางสถาปัตยกรรมที่สำคัญอื่นๆ นักพัฒนาแอปพลิเคชันจำเป็นต้องมีความเข้าใจเกี่ยวกับการทำงานในรูปแบบหลายผู้เช่า และต้องใช้ความพยายามในการพัฒนาแอปพลิเคชัน ทำไม เนื่องจากมีช่วงเวลาที่เทคโนโลยีไม่สามารถให้โดยอัตโนมัติโดยไม่คำนึงถึงความหมายของข้อมูล ตัวอย่างเช่นคำจำกัดความเดียวกันของขอบเขตของการขัดเกลาทางสังคมของข้อมูล แต่เราพยายามทำให้ปัญหาเหล่านี้เล็กลง ตัวอย่างของการใช้งานแอปพลิเคชันดังกล่าวมีอยู่แล้ว
ประเด็นสำคัญในบริบทของการปรับใช้หลายผู้เช่าใน 1C: Enterprise คือเรากำลังสร้างโมเดลไฮบริดที่แอปพลิเคชันหนึ่งสามารถทำงานได้ทั้งในโหมดหลายผู้เช่าและในโหมดปกติ นี่เป็นงานที่ยากมากและเป็นหัวข้อของการสนทนาแยกต่างหาก
ที่มา: will.com