RFC с внедрением модульной архитектуры

Question

Ищем мнения о модульности веб-приложений. Уже большинство приложений, независимо от языка, имеют внутреннюю базу данных и поддерживают привязки к соответствующим серверам веб-приложений (Apache, IIS, Lighttp и т. Д.), Но многие разработчики, с которыми я сталкивался, сталкиваются с проблемами при использовании Memcached или чего-либо еще вне непосредственного пространства процесса веб-приложения.

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

Например, несколько лет назад меня подстрелили на совещании по разработке проекта для сайта с очень высоким трафиком, когда я предложил вырвать логику ACL с интенсивным процессом из среды интерфейса и превратить ее в полукластеризованный сервис. приложение в бэкэнде. Для меня преимуществами стали более четкое разделение кода и возможность многократного использования логики ACL с использованием REST / JSON в качестве моста между, скажем, PHP и Python.

Разработчики, которые не согласились с моей идеей, утверждали, что это "слишком сложно", но я просто не мог понять, как? Мои аргументы состоят в том, что так же, как может существовать суп тегов для уровня представления, может существовать и часто есть логический суппорт кода, который настолько сплетен, что в случае возникновения проблемы может быть почти невозможно выполнить «хирургическое» исправление.

Таким образом, чтобы сократить это, каковы преимущества и недостатки разделения больших приложений на независимые, но совместные процессы (не потоки или подзапросы). MySQL, Memcache, похожий сервисный процесс - это здорово ... но почему не что-то еще? Как идти по этому пути "слишком сложно"?

Answer 1

Я сторонник отделения функциональности основного сервера / бизнес-логики от кода веб-приложения. Это по нескольким причинам:

1. Вы можете лучше контролировать бизнес-логику. Не будет никакого способа смешать это с кодом GUI и создать беспорядок. Вы хотите разделить всю бизнес-логику, чтобы впоследствии можно было создать API для вызова функциональности кода, и не надеяться, что никакая бизнес-логика не дойдет до кода GUI.
2. С самого начала вы должны разработать хороший API, который вы должны использовать сами для связи с вашим сервером с клиента. Клиент может быть веб-интерфейсом или удаленным пользователем.
3. Стабильность. Веб-код графического интерфейса пользователя может быть написан неправильно и потреблять слишком много памяти, тем самым уничтожая все приложение.
4. Для масштабирования вы можете переместить эти отдельные компоненты на разные серверы. Если вы используете систему кэширования, которая уже позволяет масштабировать кластеризацию, это может быть так просто, как просто добавить больше серверов кэширования.
5. Я обнаружил, что обновления приложений чаще всего выполняются в коде графического интерфейса, поэтому основную службу не нужно отключать большую часть времени.
6. Security. Вы можете быть уверены, что код безопасности реализован в коде сервера, поэтому, если кто-то использует ваш API, он не сможет обойти любой код безопасности, попавший в код GUI.

Наша система имеет базовую службу 'engine', реализованную в виде приложения Java. Веб-приложение также написано на Java, и (в настоящее время) связь осуществляется через RMI. Наш сайт / приложение растет, и нам еще не приходилось использовать сервис кэширования, такой как memcached или JCS.

Answer 2

Ну, иногда «слишком сложный» означает «я не хочу думать за пределами моей зоны конфорт».

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

Теперь, что касается плюсов и минусов, первое, против чего стоит то, что вы делаете действительно должны заставить людей думать за пределами их зон комфорта. Более технический недостаток заключается в том, что вам необходимо сохранить то, что фактически является состоянием сеанса. Скажем, вы берете токен аутентификации из своей службы аутентификации; как этот токен останется связанным с правильным сеансом пользователя.

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

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