Преимущества использования отдельных серверов API и UI для веб-приложений

На работе у нас есть большое внутреннее приложение, которое разрабатывалось почти 2 года; Я только недавно присоединился к проекту, и некоторые из архитектур меня немного озадачили, поэтому я надеюсь, что кто-то здесь может дать какой-то совет, прежде чем я выйду, чтобы задать архитекторам те же вопросы (так что я смогу провести с ними информированное обсуждение ).

Мои извинения, если ниже немного, я просто хочу попытаться нарисовать хорошую картину того, что система, прежде чем я задам свой вопрос :)

• Система настроена так, что у нас есть одно основное веб-приложение (asp.net, AngularJS), которое в основном просто собирает данные из различных других сервисов. Так что в основном это хост для приложения AngularJS; буквально один MVC-контроллер загружает клиентскую часть, а затем любой другой контроллер является контроллером WebAPI.

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

• Однако затем вызовы в конечном итоге перенаправляются в еще один набор приложений WebAPI (обычно это для каждой бизнес-сферы, такой как безопасность, данные клиента, данные о продукте и т. Д.). Все эти WebAPI также развернуты в выделенных блоках; у нас также есть 4 из этих коробок.

• За одним исключением, эти WebAPI не используются никакими другими частями нашей организации.

• Наконец, эти WebAPI делают еще один набор вызовов к «внутренним» службам, которые обычно являются устаревшими службами asmx или wcf, накладываемыми поверх различных систем ERP и хранилищ данных (над которыми мы не имеем никакого контроля).

• Большая часть бизнес-логики нашего приложения находится в этих WebApis, таких как преобразование устаревших данных, их агрегация, выполнение бизнес-правил, обычные вещи.

Что меня смущает, так это то, что возможное преимущество заключается в таком разделении между WebApplication и WebAPI, которые его обслуживают. Поскольку никто другой не использует их, я не вижу никаких преимуществ в плане масштабируемости (то есть нет смысла вставлять еще 4 блока API для обработки увеличенной нагрузки, поскольку увеличение нагрузки на серверы API должно означать увеличение нагрузки на веб-серверы - поэтому соотношение веб-сервера и сервера Api должно составлять 1: 1)

• Я также не вижу никакой пользы от необходимости делать дополнительный HTTP-вызов Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => Backend services. (что HTTP-вызов между WebApp и WebAPI - моя проблема)

• Поэтому в настоящее время я стремлюсь перевести текущие WebAPI из отдельных решений в отдельные проекты в рамках решения WebApplication с простыми ссылками на проекты между ними и единой моделью развертывания. Таким образом, они в конечном итоге просто станут библиотеками классов.

• С точки зрения развертывания это означает, что у нас будет 8 веб-блоков "с полным стеком", а не 4 + 4.

Я вижу преимущества нового подхода

• Повышение производительности благодаря сокращению цикла сериализации / десериализации между веб-приложением и серверами WebAPI
• Тонны кода, которые можно удалить (т.е. не нужно обслуживать / тестировать) с точки зрения DTO и сопоставителей на исходящих и входящих границах серверов веб-приложений и WebApi соответственно.
• Лучшая способность создавать осмысленные автоматизированные интеграционные тесты, потому что я могу просто издеваться над серверными службами и избегать путаницы при переходах HTTP промежуточного уровня.

Итак, вопрос: я ошибаюсь? Я пропустил фундаментальную «магию» разделения ящиков WebApplication и WebAPI?

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

А также, что бы я потерял с точки зрения преимуществ, если бы я реорганизовал систему в соответствии с моей предполагаемой установкой?

Одной из причин является безопасность - если (хаха! Когда ) хакер получает доступ к вашему интерфейсному веб-серверу, он получает доступ ко всему, к чему у него есть доступ. Если вы разместили свой средний уровень на веб-сервере, то у него есть доступ ко всему, что у него есть - например, к вашей БД, а затем, что вы знаете, он просто запустил «выбрать * из пользователей» в вашей БД и забрал его из офлайн взлом пароля

Еще одна причина - масштабирование - веб-уровень, где страницы создаются и деформируются, а XML обрабатывается, и все это требует гораздо больше ресурсов, чем средний уровень, который часто является эффективным методом передачи данных из БД на веб-уровень. Не говоря уже о передаче всех этих статических данных, которые находятся (или кэшируются) на веб-сервере. Добавление большего количества веб-серверов - простая задача после того, как вы пройдете 1. Не должно быть соотношения 1: 1 между веб-уровнями и уровнями логики - я уже видел 8: 1 до этого (и соотношение 4: 1 между логикой уровень и БД). Однако все зависит от того, что делают ваши уровни и сколько в них кэширования.

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

Еще одна причина, по которой было бы хорошо иметь эти уровни, заключается в том, что это требует большей дисциплины в разработке, когда разрабатывается API (и его легко тестировать, поскольку он является автономным), а затем разрабатывается пользовательский интерфейс для его использования. Я работал в месте, где это делалось - разные команды разрабатывали разные уровни, и это работало хорошо, поскольку у них были специалисты для каждого уровня, которые могли бы действительно быстро вносить изменения, потому что им не нужно было беспокоиться о других уровнях - например, пользовательский интерфейс javscript dev может добавить новый раздел на сайт, просто потребляя новый веб-сервис, разработанный кем-то другим.

Я думаю, что здесь нет правильного / неправильного ответа. Вы спрашивали своих коллег о назначении этой архитектуры?

Из того, как я понимаю ваши описания, « WebAPI » в вашей архитектуре служит своего рода самодельным промежуточным программным обеспечением. Теперь вы можете исследовать, какие преимущества есть в использовании Middleware. По сути, ваше Webapp никогда не нужно будет принимать, если вы изменили свою бэк-офисную систему (если интерфейс WebAPI остается прежним).

Чтобы пойти дальше: представьте, что у вас есть база данных клиентов (бэкэнд-сервис) и у вас есть 5 веб-приложений, взаимодействующих с этой базой данных. Если вы замените систему базы данных клиентов новой системой (например, от другого поставщика и не сможете повлиять на интерфейсы веб-сервиса), вам, скорее всего, потребуется изменить уровень связи всех 5 веб-приложений. Если вы общаетесь через WebAPI , вам просто нужно изменить уровень связи WebAPI .

В основном, Layer Architecture в настоящее время рассматривается как: Pattern и Anti-Pattern. (См .: Лазанья-код ). Если у вас есть только одна система без планов дальнейшего расширения в ближайшие несколько лет, я бы предпочел считать это анти-паттерном. Но это будет нереалистично, так как я не знаю точных обстоятельств / ситуации :)