Пример архитектуры 4-го уровня (для N-уровня)?

Недавно мой друг спросил меня о архитектурах N-Tier, и я смог объяснить ему около 1, 2 и 3 уровня архитектуры с примерами. Но я застрял, когда хотел привести примеры более чем на 3 уровня. Я googled и binged для помощи, но не мог найти приличные примеры.

Тот факт, что он называется N-уровень, заставляет меня думать, что "N" может быть любым числом, начиная с 1. Но я не мог найти примеров для 4 или 5 уровней.

Может ли кто-нибудь поделиться некоторыми примерами N-уровневых архитектур, которые содержат более трех уровней?

Ответ 1

Основные услуги: например, База данных, службы каталогов, файлы и файлы Полиграфические услуги, Аппаратная абстракция. Этот уровень все чаще называют платформой.
Уровень бизнес-домена: сервер приложений, такой как JavaEE, включая объекты служб EJB, DCOM или CORBA. Обеспечение функциональности бизнеса, расширение с использованием SOA и микро-сервисов.
Уровень представления: например, Сервлеты Java/JSP, ASP, PHP. Этот уровень будет все чаще включать WebServices в качестве прокси-серверов и адаптеров для служб бизнес-уровня.
Уровень клиента. Тонкие клиенты, такие как HTML-страницы в браузерах, и клиенты с расширенными возможностями, такие как Java WebStart & Вспышка.
- В Java EE принято делить уровень Business Domain на Data-Access (Entity Bean) и Бизнес-сервисы (Session Beans).
- В корпоративной SOA (сервис-ориентированная архитектура) ESB обычно существует в качестве дополнительного уровня между уровнями 1 & 2. Это может быть частью предоставления платформы.
- В Mashups у вас может быть уровень агрегации между уровнем 3 & 4.

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

Ответ 2

Пять минут назад я прочитал статью этого https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture

Клиент там, где вы его читаете Api или ваш прикладной сервер, где вы его собираете. Агрегация данных. Либо проходит через jsons/xmls из сторонних вещей или запросов в вашей базе данных, и, наконец, уровень обслуживания - это то, где вы действительно выполняете запрос в базе данных или запускаете функцию на больших данных или читаете местоположения GPS и карты из Google... Это как я вижу это в этом случае. Он просто разделил слой данных с трех уровней.

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

Ответ 3

Я склоняюсь к менее абстрактному и более практическому объяснению, которое отвечает на вопрос: "Как и почему я хочу разделить мою систему на уровни и где я могу разместить их на серверах?"

По сути, когда вы создаете простой веб-сайт, который использует базу данных, у вас уже есть 3 уровня "из коробки":

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

Теперь, как мы получаем 4-й уровень?

Скорее всего, нет необходимости разделять клиентский уровень. Это на клиентском устройстве, и мы хотим сделать его максимально простым и эффективным.

Можем ли мы разделить уровень данных? Я видел некоторые системы с API-интерфейсами вокруг баз данных, BLOB-объектов Azure, файловых систем и т.д., В которых создавалась подсистема, которую можно было бы рассматривать как уровень. Но это все тот же уровень данных (например, базовый уровень услуг) или мы можем считать его отдельным объектом? И если мы выделим его, будет ли он находиться на том же физическом (или виртуальном) сервере, что и наша база данных, чтобы мы могли защитить данные от прямого доступа?

Однако в большинстве случаев именно прикладной уровень разделяется.

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

Другая часть становится потребителем API уровня приложения через какое-то соединение (HTTP-клиент и т.д.). Потребителя можно назвать уровнем представления (сбивает с толку - разве это не то же самое, что уровень клиента?), Даже если он сам имеет только API-интерфейсы JSON и никаких удобных для пользователя форматов.

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

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

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

Ответ 4

Архитектура с четырьмя уровнями состоит из следующих

а. клиентский уровень - node.js angularJs и т.д., в основном независимо от серверной и пользовательской команды, работают на клиентском артефакте независимо.

б. Уровень агрегирования --- сети доставки контента (akamai)

с. api tier - шлюз для всех вызовов на стороне сервера и может иметь собственное кэширование

д. сервисный уровень - включает внутренние или внешние службы...