3-уровневая веб-архитектура: полезны ли слои на отдельных машинах?

Question

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

• Вызывает гораздо больше трафика / процессорного времени - генерация мыльных запросов / ответов XML вместо прямого подключения к базе данных
• Сложно отлаживать - необходимо отлаживать два отдельных проекта, а не один

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

Я что-то упустил?

Answer 1

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

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

Answer 2

Как и многие архитектурные вопросы, это может быть уравновешивающим действием.

Конечно, одно из преимуществ трехуровневого веб-приложения, состоящего в том, что каждый уровень размещается на отдельных машинах, заключается в том, что теперь вы можете потенциально распределять нагрузку по отдельности между различными частями приложения. Например, у вас может быть 3 веб-сервера, обслуживающих только графический интерфейс пользователя, этот «кластер» будет подключаться к «кластеру» из 3 серверов приложений, все из которых прекрасно сбалансированы по нагрузке и рассматриваются как один «экземпляр» для веб-серверов. Аналогично, аналогичная ситуация с DAL (уровень доступа к данным).

Разделение уровней таким способом также позволяет на определенном уровне «разъединять» слои общего приложения. Это позволяет настраивать каждый уровень по-разному (т. Е. Может использовать другое оборудование или другую ОС и т. Д.), И, пока интерфейс остается согласованным, не должно быть проблем, если какой-либо из отдельных уровней будет изменен.

Это неизменно будет влиять на разработку программного обеспечения, поскольку DAL / BLL / UI теперь будет представлять собой отдельные сборки (вероятно, отдельно скомпилированные библиотеки DLL или эквивалентные) и действительно отдельные уровни , а не просто структурировать код в отдельные слои внутри одного приложения / проекта.

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

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

В зависимости от того, что в действительности подвергается пользователям всего приложения, безопасность на «нижних» уровнях может или не может требоваться. Если вы открываете только веб-интерфейс, нижние уровни должны быть настроены как недоступные (кроме как через веб-сервер), однако, если вы выставляете «бизнес-уровень», а также уровень веб-интерфейса, вы будете у вас есть дополнительное бремя защиты "потенциальных" областей атаки вашего приложения.

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

Answer 3

Да, это обычный шаблон для защищенных приложений.

  - Database Node
        | (database access protocol)
  - Data Access Layer/Business Logic Layer Node
        | (web services/RMI/CORBA/other protocol)
  - Presentation Layer Node     

Обычно веб-сервер выставляется в DMZ, поэтому BLL / DAL необходимо разместить на другом компьютере (узле). Веб-сервисы используются как «протокол соединения». Сложно взломать сервер DAL с помощью веб-служб, а данные защищены другим узлом. С помощью предоставляемых веб-сервисов уровень представления может быть реализован в свободной форме (Java, .NET, веб-клиент или настольное приложение).

Answer 4

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

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

Посмотрите на банковскую индустрию, ваш веб-доступ к информации об аккаунте все еще происходит из системы COBOL.

Answer 5

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

1. Существуют установленные стандарты для доступа к базе данных (я полагаю, вы имеете в виду базу данных, если говорите о слое данных), которая также обращается к удаленным базам данных (например, JDBC, ODBC, ...). Поэтому нет необходимости использовать веб-сервисы.

2. Если вы используете веб-сервисы, вы получаете массу новых проблем, например, тайм-ауты, целостность сообщений, безопасность сообщений или надежные сообщения, с которыми вам приходится иметь дело. Это все потенциальные источники ошибок.

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

Так что я бы действительно пошел на связь JDBC / ODBC с уровнем данных. Веб-сервисы могут иметь больше смысла между бизнес-уровнем и уровнем представления или сторонними приложениями (интеграция приложений).

Answer 6

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