Як ви керуєте розширюваністю у ваших системах з кількома орендарями?

Зараз у мене є декілька великих веб-продуктів, що базуються на багато орендарів, і дуже скоро я можу побачити, що буде багато налаштувань, що відповідають специфіці орендаря.

Тут або там додаткове поле, можливо, додаткова сторінка або якась додаткова логіка посеред робочого процесу - така річ.

Деякі з цих налаштувань можна перетворити на основний продукт, і це чудово. Деякі з них відрізняються високою специфічністю та отримують у всіх інших спосіб.

Я маю на увазі кілька ідей для управління цим, але жодна з них не здається масштабною. Очевидним рішенням є введення тонни налаштувань на рівні клієнта, що дозволяє включити різні "функції" на основі кожного клієнта. Недоліком цього, звичайно, є масивна складність і безладдя. Ви можете ввести справді величезну кількість налаштувань, і з часом різні типи логіки (презентація, бізнес) можуть вийти з ладу. Тоді виникає проблема специфічних для клієнта полів, яка вимагає чогось більш чистого, ніж просто додавання кулі змінних полів до існуючих таблиць.

Отже, що люди роблять для управління цим? Force.com, здається, є майстром розширюваності; Очевидно, вони створили платформу з самого початку, яка є надзвичайно розширюваною. За допомогою веб-інтерфейсу ви можете додавати майже все, що завгодно. FogBugz зробив щось подібне, коли вони створили надійну модель плагінів, яка, подумайте над цим, могла насправді бути натхненною Force. Я знаю, що вони витратили на це багато часу і грошей, і якщо я не помиляюся, наміром було насправді використовувати їх внутрішньо для подальшої розробки товару.

Це звучить як те, що я міг би спокусити побудувати, але, мабуть, не повинен. :)

Чи єдиний шлях до масштабних інвестицій у підключається архітектуру? Як ви вирішуєте ці проблеми та які результати ви бачите?

EDIT: Це виглядає , як ніби FogBugz обробив проблему шляхом створення досить надійної платформи , а потім з допомогою, щоб з'єднати їх екрани. Щоб розширити його, ви створюєте DLL-класи, що реалізують інтерфейси, такі як ISearchScreenGridColumn, і це стає модулем. Я впевнений, що це було надзвичайно дорого, будувати, враховуючи, що у них є велика кількість розробників, і вони над цим працювали місяцями, плюс їхня поверхня становить, можливо, 5% від розміру моєї програми.

Мені зараз серйозно цікаво, чи Force.com - це правильний спосіб вирішити це. І я важкий хлопець ASP.Net, тому це дивне становище.

Я зіткнувся з подібною проблемою, і я розповім, як я вирішив її вирішити.

1. По-перше, є "основна" бібліотека, або двигун. Це в основному працює шоу, наскільки ви вже зрозуміли. Він обробляє речі, загальні для кожної системи, від динамічного відображення форм, управління користувачами та обліковими записами, ролей, ви їх називаєте, це робить.

2. Кожна частина системи міститься в модулі. Модуль має залежності (інші модулі, від яких це залежить). Наприклад, "основна" система має безпеку (користувачі, групи, ролі, політику щодо паролів), локальний каталог (переклади, країни, культури), сховище файлів, електронну пошту тощо тощо. Кожен модуль визначає себе за допомогою файлу xml. Файл xml в основному визначає схеми, таблиці, класи обчислень, визначення екрана тощо. Вони читаються, коли програма починається, якщо дата файлу змінилася .

3. Специфічні для клієнта модулі мають власні файли xml та власну DLL. Це все плюс і функціонує відповідно та прозоро з рештою системи. Праворуч до заміни існуючих представлень MVC на власні, з користувацьким кодом та моделями власного перегляду.

4. Якщо клієнт бажає розширити існуючу функціональність, xml / система надає метод, де я можу "вивести" один модуль з іншого. Новий модуль має всі існуючі функціональні можливості, але зі специфічними вимогами замовника в новій DLL та з розширеним XML-файлом, який може внести зміни. Caveat полягає в тому, що вони фактично не можуть видалити існуючі поля в цій системі, але ми можемо розширити її та забезпечити абсолютно нові об'єкти та функціональні можливості.

Маючи багато логіки версій та шарів коду для управління, це не додає значення вашому веб-додатку / сайту. Це також вимагає більшої сили мозку, щоб зрозуміти, що відбувається, і відволікає вас від ядра того, що ви робите.

Раджу по-різному. Я раджу тримати прості речі над складними.

Підтримуйте єдину базу коду, однакову для всіх. Кожна додана вами функція - це функція для всіх. Обмежуйте лише кількість предметів чи пам’яті чи якусь кількість, що можна оцінити, а не функції. Причиною цього є кількісне визначення таких речей, як зберігання, кількість записів даних тощо. Програмувати настільки просто, і це може бути застосоване до лише невеликої кількості речей, що насправді обмежує користувача не ходити на дикі у вашому додатку. Її потрібно програмувати лише після додавання елементів, а не виконувати певну логіку функції. Що робити, якщо функції пов'язані з іншими ознаками? Кодувати це стає дуже складно.

Щоб визначити свою відповідь, я створив систему електронної комерції, яку я маю для багатьох клієнтів, і навчився важкому способу намагатися підтримувати всі свої ідіосинкразії. Я врешті-решт розірвав ланцюг і створив єдиний веб-сайт адміністрації, який є багатопрофільним для електронної комерції. Потім у мене є веб-сайти, які залучають дані з дзвінків веб-служб. Це дозволяє різним командам в різних технологіях впроваджувати конкретні функції для сайтів електронної комерції, в той час як я щомісяця отримую зарплату за ту саму інфраструктуру, і мені все одно, що вони роблять. Я просто обмежую використання числом, а не функціями. Її шлях простіше. Клієнт може вибрати власного постачальника для створення свого веб-сайту, і я більше не беру участь у цих рішеннях.

У мене також є послуга підписки на управління вмістом SAAS. Це працює і за допомогою рівнів використання, і клієнти можуть додавати власні плагіни, якщо хочуть, в той час як я мою команду додаю більше функцій для всіх.

Це лише мій досвід, коли я так довго стукав головою в стіну, а потім натрапляв на щось простіше.

Якщо щось завжди буде специфічним для кожного клієнта, не робіть для нього рамки. Розбийте його на найпростіші частини, щоб частина каркаса працювала для всіх, а потім виріжте решту, щоб ви могли розширити її на окрему особу.

Програмний продукт, над яким я працюю, має додаткові поля для розширення користувачів. Кожен елемент даних для цих полів можна ввести в існуючий рядок в основних таблицях програми. Наприклад, якщо ваше програмне забезпечення містить клієнтів і кожен клієнт перелік замовлень, то в налаштованій таблиці даних буде стовпець для зовнішніх ключів до таблиці клієнтів та таблиці замовлень, лише одна з яких буде недійсною. Або це, або кілька таблиць, кожна з яких має власні поля для однієї таблиці.

Це простий та ефективний спосіб зберігання додаткових даних для користувача. Необхідно зберегти додаткову інформацію про назви та типи цих полів.

Це охоплює користувацькі поля для клієнта. Для користувацької поведінки API веб-служб передбачає розширення.

1) Запуск чужого коду на власних скриньках - досить складна проблема. Або ви можете їм довіряти, або ви можете розумно відкласти відповідальність, вам доведеться дуже сильно засипати їх код і мати більш високу середню відданість безпеці. Оскільки ваша плагінова система дозволяє отримати більше функціональних можливостей, важче зробити її безпечною. Такі речі, як відмова в обслуговуванні (плагіни споживають занадто багато ресурсів), витік інформації (плагіни можуть отримувати доступ до даних інших орендарів) тощо, можуть бути дуже реальними та клопіткими, я б не брав участі в цьому, якщо не зміг би познайомити людей дуже ці проблеми або дуже здібні люди з великою кількістю часу, щоб виправити це.

2) Так, модульність і настроюваність є жорсткими. Такі речі, як шаблон стратегії, можуть допомогти (фантазійне найменування функціональних покажчиків; на Java це зазвичай реалізується шляхом оголошення інтерфейсу, який користувачі класу можуть реалізувати, щоб налаштувати поведінку вашого коду), але ви хочете бути дуже ізольованими та роз'єднаними. код для цього.

3) З точки зору даних, це може бути одним із прикладів корисного зберігання без схем. Якщо у вас є реляційна модель даних, мати таблиці з безліччю стовпців для різних клієнтів є проблематичним (так, ви закінчуєте безліччю змінних стовпців, що погано ; одна з причин - важко або неможливо встановити правильні обмеження [тобто обмеження, які не дозволяють з'являтися недійсних комбінацій нулів]). Додавання клієнта спеціальних таблиць (тобто usersі foo_usersз usersпроведенням поля , дійсним для всіх клієнтів і foo_usersмають специфічний fileds Foo) краще; ви можете мати правильні обмеження легко, але ваші RDBMS можуть не справлятися з цим витончено (через вибух, обмеження кількості таблиць тощо) і, ймовірно, буде виглядати некрасиво у вашому коді.

Ви, можливо, зможете впровадити в RDBMS сховище ключових значень, що робить вашу модель даних менш реляційною і спричинять дискомфорт (тобто реляційні бази даних найкраще працюють із реляційними моделями). Я не впевнений, чи відповідає рішення NoSQL загалом проблемі, але безкорисливість більшості реалізацій може бути перевагою.