Максимизируйте данные, сверните код - каковы пределы и проблемы? - PullRequest
1 голос
/ 13 ноября 2008

Я хотел бы разработать приложение с высокой доступностью (никогда не отключать сервер, развертывать функции без перезапуска и т. Д.) С использованием как клиентских (возможно, C # gui), так и серверных компонентов (Java, C ++, Perl).

Я получил несколько советов от ( minimal-code-maximize-data.html и Yegge ), и я хотел бы сделать большую логику динамически читаемой из базы данных, чтобы вся конфигурация (включая все конфигурации графического интерфейса, перевод текста и т. д., бизнес-правила, а также данные) будут находиться на сервере в базе данных, а не в коде, который требует перезапуска для чтения в исполняемую память.

Я бы хотел иметь возможность настраивать любой аспект приложения без перезапуска клиента или сервера, чтобы приложение отражало изменения с максимально короткой задержкой (динамическая загрузка классов и т. Д.).

Каковы производительность и другие ограничения при разработке такой системы, которая никогда не убивает? Кому-нибудь удалось создать такое приложение? Каковы были основные уроки? Когда это не является экономически эффективным, и требуются более традиционные подходы к простоям сборки, выпуска, тестирования, паре часов?

Ответы [ 2 ]

3 голосов
/ 13 ноября 2008

Я работал на игровом сервере MUD, который выполнял динамическую компиляцию сценариев, так что почти все в игре было изменяемым и перекомпилируемым во время выполнения без необходимости отключать пользователей.

Возможно, самый большой урок, который я извлек из этого проекта, состоял в том, что когда вы пишете такой гибкий код, что он может делать что угодно, он фактически ничего не делает.

В конечном счете, пользователи системы больше не вводили данные - они писали загадочный код, который был уникальным для моей системы.

Будьте осторожны с гибкостью - добавление гибкости к коду подобно добавлению локтей в руку. Хорошо иметь пару суставов, чтобы добраться туда, куда вы хотите, но если у вас слишком много локтей, они становятся слабыми и их трудно направлять.

1 голос
/ 13 ноября 2008

Что-то не слишком отличное для рассмотрения - использование сильно статичной и небольшой базы кода вокруг интерпретатора сценариев, например Rhino:

http://www.mozilla.org/rhino/ScriptingJava.html

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

Это определенно плохо для производительности, я думаю, что это само собой разумеющееся.

Если я правильно помню, Йегге однажды опубликовал нечто подобное в своем блоге, поэтому, если вам удастся поговорить с ним снова, можете спросить его об этом.

...