คุณจะจัดการความสามารถในการขยายในระบบหลายผู้เช่าของคุณได้อย่างไร?

ตอนนี้ฉันมีผลิตภัณฑ์หลายผู้เช่าบนเว็บที่ใหญ่และไม่นานฉันก็เห็นว่าจะมีการปรับแต่งมากมายที่เฉพาะเจาะจงของผู้เช่า

เขตข้อมูลพิเศษที่นี่หรือที่นั่นอาจเป็นหน้าพิเศษหรือตรรกะเพิ่มเติมบางส่วนที่อยู่ตรงกลางของเวิร์กโฟลว์ - สิ่งนั้น

การปรับแต่งเหล่านี้บางส่วนสามารถรีดเข้าสู่ผลิตภัณฑ์หลักและนั่นยอดเยี่ยม บางคนมีความเฉพาะเจาะจงสูงและจะเข้าไปในทางของคนอื่น

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

แล้วผู้คนกำลังทำอะไรเพื่อจัดการสิ่งนี้ ดูเหมือนว่า Force.com จะเป็นผู้เชี่ยวชาญด้านการเพิ่มความสามารถ เห็นได้ชัดว่าพวกเขาได้สร้างแพลตฟอร์มจากพื้นดินขึ้นมาซึ่งสามารถขยายได้อย่างมาก คุณสามารถเพิ่มเกือบทุกอย่างด้วย UI บนเว็บของพวกเขา FogBugz ทำสิ่งที่คล้ายกันซึ่งพวกเขาสร้างรูปแบบปลั๊กอินที่มีประสิทธิภาพซึ่งคิดว่าอาจได้รับแรงบันดาลใจจากแรงจริง ฉันรู้ว่าพวกเขาใช้เวลาและเงินจำนวนมากกับมันและถ้าฉันไม่เข้าใจผิดความตั้งใจที่จะใช้มันเพื่อการพัฒนาผลิตภัณฑ์ในอนาคต

ฟังดูเหมือนเป็นสิ่งที่ฉันอยากจะสร้าง แต่อาจไม่ควร :)

การลงทุนครั้งใหญ่ในสถาปัตยกรรมแบบเสียบปลั๊กเป็นหนทางเดียวที่จะไปได้หรือไม่? คุณจัดการกับปัญหาเหล่านี้อย่างไรและคุณเห็นผลลัพธ์แบบใด

แก้ไข:ดูเหมือนว่า FogBugz จัดการปัญหาด้วยการสร้างแพลตฟอร์มที่แข็งแกร่งพอสมควรแล้วใช้สิ่งนั้นเพื่อรวบรวมหน้าจอของพวกเขา เมื่อต้องการขยายให้คุณสร้าง DLL ที่มีคลาสที่ใช้อินเทอร์เฟซเช่น ISearchScreenGridColumn และกลายเป็นโมดูล ฉันแน่ใจว่ามันแพงอย่างมากในการสร้างเนื่องจากพวกเขามี devs จำนวนมากและพวกเขาทำงานกันเป็นเวลาหลายเดือนบวกกับพื้นที่ผิวของพวกเขาอาจจะ 5% ของขนาดแอปพลิเคชันของฉัน

ตอนนี้ฉันสงสัยอย่างจริงจังว่า Force.com เป็นวิธีที่เหมาะสมในการจัดการกับปัญหานี้หรือไม่ และฉันก็เป็นผู้ชายแกนแข็งของ ASP.Net ดังนั้นนี่จึงเป็นตำแหน่งที่แปลกประหลาดในการค้นหาตัวเอง

ฉันประสบปัญหาที่คล้ายกันและฉันจะบอกคุณว่าฉันไปเกี่ยวกับการแก้ไขมัน

1. ประการแรกมีห้องสมุด "แกน" หรือเครื่องมือ นี่เป็นการแสดงโดยทั่วไปแล้วเท่าที่คุณคิดได้แล้ว มันจัดการสิ่งต่าง ๆ ที่พบได้ทั่วไปในทุกระบบตั้งแต่การเรนเดอร์ฟอร์มไดนามิกการจัดการผู้ใช้และบัญชีบทบาทคุณตั้งชื่อมันทำได้

2. ทุกส่วนของระบบมีอยู่ในโมดูล โมดูลมีการพึ่งพา (โมดูลอื่น ๆ ที่มันขึ้นอยู่กับ) ตัวอย่างเช่นระบบ "แกน" มีความปลอดภัย (ผู้ใช้กลุ่มบทบาทนโยบายรหัสผ่าน) สถานที่ (แปลประเทศวัฒนธรรม) พื้นที่เก็บไฟล์อีเมล ฯลฯ ฯลฯ แต่ละโมดูลกำหนดตัวเองโดยใช้ไฟล์ xml ไฟล์ xml นั้นโดยทั่วไปจะระบุสกีมา, ตาราง, คลาสการคำนวณ, คำจำกัดความของหน้าจอและอื่น ๆ เหล่านี้จะถูกอ่านในเมื่อโปรแกรมเริ่มต้นถ้าวันที่ไฟล์ที่มีการเปลี่ยนแปลง

3. โมดูลเฉพาะลูกค้ามีไฟล์ xml และ DLL ของตัวเอง ทุกอย่างรวมเข้ากับและทำงานได้อย่างสอดคล้องและโปร่งใสกับส่วนที่เหลือของระบบ ลงไปที่การแทนที่มุมมอง MVC ที่มีอยู่ด้วยมุมมองที่กำหนดเองด้วยโค้ดที่กำหนดเองและโมเดลมุมมองที่กำหนดเอง

4. หากลูกค้าต้องการที่จะขยายฟังก์ชั่นที่มีอยู่ xml / ระบบให้วิธีการที่ฉันสามารถ "ได้รับ" หนึ่งโมดูลจากที่อื่น โมดูลใหม่มีฟังก์ชันการทำงานที่มีอยู่ทั้งหมด แต่มีความต้องการเฉพาะของลูกค้าใน DLL ใหม่และด้วยไฟล์ XML แบบขยายที่สามารถทำการแก้ไขได้ Caveat คือพวกเขาไม่สามารถลบเขตข้อมูลที่มีอยู่ในระบบนี้ได้จริง แต่เราสามารถขยายและให้วัตถุและฟังก์ชั่นใหม่ทั้งหมด

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

ฉันแนะนำแตกต่างกัน ฉันแนะนำให้ทำสิ่งที่ง่ายกว่าซับซ้อน

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

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

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

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

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

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

นี่เป็นวิธีที่ง่ายและมีประสิทธิภาพในการจัดเก็บข้อมูลเพิ่มเติมสำหรับผู้ใช้ ข้อมูลเพิ่มเติมจะต้องถูกเก็บไว้เกี่ยวกับชื่อและประเภทของเขตข้อมูลเหล่านี้

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

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

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

3) Data-wise นี่อาจเป็นหนึ่งในตัวอย่างของการจัดเก็บ schemaless ที่มีประโยชน์ หากคุณมีโมเดลข้อมูลเชิงสัมพันธ์การมีตารางที่มีคอลัมน์จำนวนมากสำหรับลูกค้าที่แตกต่างกันนั้นเป็นปัญหา (ใช่คุณท้ายด้วยคอลัมน์ nullable จำนวนมากซึ่งไม่ดีเหตุผลหนึ่งคือมันยากหรือเป็นไปไม่ได้ที่จะกำหนดข้อ จำกัด ที่ถูกต้อง [เช่น ข้อ จำกัด ที่ไม่อนุญาตให้มีการรวมค่าโมฆะที่ไม่ถูกต้องปรากฏ]) การเพิ่มตารางเฉพาะลูกค้า (เช่นusersและfoo_usersด้วยการusersถือเขตข้อมูลที่ถูกต้องสำหรับลูกค้าทั้งหมดและfoo_usersมีไฟล์ที่ระบุเฉพาะ Foo) จะดีกว่า คุณสามารถมีข้อ จำกัด ที่ถูกต้องได้อย่างง่ายดาย แต่ RDBMS ของคุณอาจไม่จัดการอย่างสง่างาม (เนื่องจากเข้าร่วมการระเบิด จำกัด จำนวนของตาราง ฯลฯ ) และอาจดูน่าเกลียดในรหัสของคุณ

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