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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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