Для чего используют многоуровневые архитектуры
Кратко о типах архитектур программного обеспечения, и какую из них выбрали мы для IaaS-провайдера
Есть множество типов архитектур ПО со своими плюсами и минусами. Далее поговорим об особенностях наиболее популярных из них и расскажем о своем переходе на микросервисы.
Типы архитектур ПО
Многоуровневая архитектура
Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI.
Система делится на уровни, каждый из которых взаимодействует лишь с двумя соседними. Поэтому запросы к БД, которая обычно располагается в самом конце цепочки взаимодействия, проходят последовательно сквозь каждый «слой».
Архитектура не подразумевает какое-то обязательное количество уровней — их может быть три, четыре, пять и больше. Чаще всего используют трехзвенные системы: с уровнем представления (клиентом), уровнем логики и уровнем данных.
О многоуровневой архитектуре написано бесчисленное количество книг и статей. И сложились разные мнения о ее достоинствах и недостатках.
Каждый уровень этой архитектуры выполняет строго ограниченный набор функций (которые не повторяются от слоя к слою) и не знает о том, как устроены остальные уровни. Поэтому «содержимое» уровней можно изменять без риска глобальных конфликтов между слоями.
В целом многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов. Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают выстраивать уровни приложения.
В программировании есть присказка, что любую проблему можно решить добавлением еще одного уровня абстракции. Однако такой подход в конечном счете может привести к плохой организации кода и запутать разработчиков.
Отсюда вытекает еще одна проблема — низкая скорость работы. Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику. Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.
Поиск багов в многоуровневых системах также может быть затруднен. Прежде чем попасть в базу данных, информация проходит через все уровни (так как БД является конечным компонентом). Если по какой-то причине эта информация повреждается (или теряется по пути), то для поиска ошибки приходится анализировать каждый уровень по отдельности.
Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).
Подобная взаимосвязь, между структурой организации и подходами к разработке приложений также продиктована законом Конвея, сформулированном еще в 1967 году. Он гласит: «Разрабатывая какую-либо систему, организации вынуждены придерживаться схемы, которая бы повторяла структуру коммуникаций внутри компании».
Событийно-ориентированная архитектура
В этом случае разработчик прописывает для программы поведение (реакции) при возникновении каких-либо событий. Событием в системе считается существенное изменение её состояния.
Можно провести аналогию с покупкой автомобиля в салоне. Когда автомобиль находит нового владельца, его состояние меняется с «продается» на «продано». Это событие запускает процесс предпродажной подготовки — установку дополнительного оборудования, проверку технического состояния, мойку и др.
Система, управляемая событиями, обычно содержит два компонента: источники событий (агенты) и их потребители (стоки). Типов событий обычно тоже два: инициализирующее событие и событие, на которое реагируют потребители.
Примером реализации такой архитектуры может служить библиотека Java Swing. Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать.
На Wiki приводится следующий код реализации этого механизма:
Так как приложения состоят из большого количества асинхронных модулей (у которых нет информации о реализации друг друга), их легко масштабировать. Такие системы собираются как конструктор — прописывать зависимости не нужно, достаточно реализовать новый модуль. Дополнительно асинхронная модель позволяет добиться высокой производительности приложений.
Асинхронная натура таких приложений усложняет отладку. Одно событие может запускать сразу несколько цепочек действий. Если таких цепочек будет много, то понять, что именно вызвало сбой, может быть затруднительно. Для решения проблемы приходится прорабатывать сложные условия обработки ошибок. Отсюда же вытекает проблема с журналированием — логи трудно структурировать.
Микроядерная архитектура
Этот тип архитектуры состоит из двух компонентов: ядра системы и плагинов. Плагины отвечают за бизнес-логику, а ядро руководит их загрузкой и выгрузкой.
Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется.
Микроядерную архитектуру в свое время использовала операционная система Symbian для мобильных устройств (разработку прекратили в 2012 году). В её микроядре находился планировщик задач, системы управления памятью и драйверы, а файловая система и компоненты, отвечающие за телефонную связь, выступали в роли плагинов.
Легко портировать приложение из одной среды в другую, поскольку модифицировать нужно только микроядро. Разделение высокоуровневых политик и низкоуровневых механизмов упрощает поддержку системы и обеспечивает её расширяемость.
Производительность приложения снижается, если подключать слишком много модулей. Однако бывает проблематично найти баланс между количеством плагинов и числом задач микроядра (обычно оно содержит лишь часто используемой код).
Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.
Хорошо подходит для:
Микросервисы
Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).
В каких пропорциях делить код, решает разработчик, но Сэм Ньюмен (Sam Newman), автор книги «Создание микросервисов», рекомендует выделять на микросервис столько строк кода, сколько команда сможет воспроизвести за две недели. По его словам, это позволит избежать излишнего «раздувания» архитектуры.
Чаще всего микросервисы запускаются в так называемых контейнерах. Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др.
Микросервисная архитектура упрощает масштабирование приложений. Чтобы внедрить новую функцию достаточно написать новый сервис. Если функция стала не нужна, микросервис можно отключить. Каждый микросервис — это отдельный проект, потому работу над ними легко распределить между командами разработчиков.
Подробнее о механизмах масштабирования микросервисных систем можно почитать в книге Мартина Эббота (Martin L. Abbott) «Искусство масштабирования» (The Art of Scalability).
Сложно искать ошибки. В отличие от монолитных систем (когда все функции находятся в одном ядре), бывает сложно определить, почему «упал» запрос. За деталями приходится идти в логи «виновного» процесса (если их несколько, то проблема усугубляется).
При этом появляются дополнительные накладные расходы на передачу сообщений между микросервисами. По нашим оценкам, рост сетевых издержек может достигать 25%.
Еще один недостаток — необходимость мириться с концепцией eventual consistency (согласованность в конечном счёте). У микросервисов есть собственные хранилища данных, к которым обращаются другие микросервисы. Информация об изменении этих данных распространяется по системе не мгновенно. Потому возникают ситуации, когда у некоторых микросервисов (пусть и на крайне короткий промежуток времени) оказываются устаревшие данные.
Почему мы в 1cloud переходим на микросервисы
Как мы уже говорили, в основе предоставляемых нами сервисов (частное облако, виртуальные серверы, объектное облачное хранилище и др.) лежит многоуровневая архитектура. Она показала себя с хорошей стороны, но теперь её возможности по масштабированию начали иссякать.
У нас становится все больше партнеров, которые предоставляют свои решения на базе нашей платформы по франшизе. Появляются удаленные площадки и сервисы, которыми становится сложно управлять из единой точки (в частности, наше оборудование находится в нескольких дата-центрах в России, Казахстане и Беларуси).
Чтобы было проще масштабировать существующие функции и внедрять новые фичи, мы в 1cloud переводим всю нашу инфраструктуру на микросервисы.
Мы хотим выделить их в отдельные модули и вместо одной сложной базы данных получить N простых. Таким образом, в новой архитектуре каждой фиче будет соответствовать отдельная БД. Это гораздо удобнее и эффективнее в поддержке и разработке.
Мы сможем разделить работу над сервисами между несколькими разработчиками (выделить специализации в компании) и эффективно масштабироваться горизонтально — когда нужно, будем просто подключать новые микросервисы.
Наши клиенты тоже получат ряд преимуществ. Поскольку микросервисы не связаны друг с другом, то при выходе из строя конкретной услуги будет недоступна только она, все остальные продолжат функционировать в штатном режиме. При этом даже если произойдет глобальное падение нашего сервиса, то панель управления продолжит работать.
Клиенты из Казахстана и Беларуси (и других стран, где мы откроем представительства) заметят существенное увеличение скорости и отзывчивости интерфейсов, так как панели управления будут размещаться локально.
Что уже сделано
Пока мы реализовали только первый пилот: «Услугу Мониторинг». Остальные сервисы переведем на новые рельсы в конце 2018 — начале 2019 года.
Начать новый переход планируем в начале 2019 года и закончить его в конце следующего года.
Используют в крупных проектах с высокой нагрузкой, которым требуется повышенная безопасность.
4 типа архитектуры программного обеспечения
Детальный обзор существующих подходов
Зачем нужна архитектура ПО
Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).
За годы развития ПО разработчикам удалось придумать надежные подходы, чтобы устранить недостатки проектирования без архитектуры. Ниже представлены некоторые из самых известных.
Подробно рассмотрим каждую из них.
Многослойная архитектура
Этот подход работает п о принципу разделения ответственностей. ПО разделено на слои, лежащие друг на друге, и каждый из них выполняет определенную обязанность.
Архитектура делит ПО на следующие слои.
Данные и элементы управления проходят через каждый слой в дизайне и передаются от одного к другому. Эта система также повышает уровень абстракции и в некоторой степени даже стабильность ПО.
Преимущества
Недостатки
Многоуровневая архитектура
Этот архитектурный подход разделяет комплекс ПО на уровни по принципу взаимодействия “клиент-сервер”. Архитектура может иметь один, два и больше уровней, разделяющих ответственности между поставщиком данных и потребителем.
Этот подход использует шаблон Request Response для связи между уровнями. В отличие от многослойной архитектуры, он предлагает масштабируемость, которая может быть как горизонтальной (масштабирование сети с помощью высокопроизводительных узлов), так и вертикальной (масштабирование каждого узла путем повышения его производительности).
Одноуровневая система
В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication — ISC).
Такая система подходит только для небольших однопользовательских приложений.
Двухуровневая система
Эта система состоит из двух физических машин в качестве сервера и клиента. Она обеспечивает изоляцию операций управления данными, обработки данных и операций представления.
Трехуровневая и n-уровневая системы
Такие архитектуры обладают высокой масштабируемостью как по горизонтали, так и по вертикали. Реализация n-уровневой системы, как правило, обходится дороже, но обеспечивает высокую производительность. Поэтому она обычно применяется в крупных и комплексных программных решениях.
Этот подход можно сочетать с современной сервис-ориентированной архитектурой, чтобы создавать сложнейшие модели. Поскольку реализация может оказаться дорогостоящей с точки зрения времени и ресурсов, рекомендуется использовать его для сложных ПО, требующих производительности и масштабируемости.
Сервис-ориентированная архитектура (SOA)
Эта архитектурная модель состоит из компонентов и приложений, которые связываются друг с другом с помощью четко определенных сервисов.
Она состоит из 5 элементов:
Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus — сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.
Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.
Как правило, сервисы делятся на два вида.
Типы сервисов
Mикросервисная архитектура
При таком подходе приложение разрабатывается как набор небольших сервисов, каждый из которых работает в собственном процессе и связывается с легковесными механизмами, обычно API для HTTP-ресурса.
Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы), каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.
Состав микросервисов
Архитектура состоит из изолированных компактных микросервисов, способных расширяться независимо друг от друга. Она включает 5 следующих компонентов:
Характеристики микросервисов
Микросервисная архитектура должна включать следующие характеристики.
Рекомендуется развивать каждый микросервис отдельно под управлением разных команд. Поскольку передача данных происходит по стандартному протоколу и формату данных, структура одного сервиса не затронет функциональность сопутствующих.
Кратко о типах архитектур программного обеспечения и переходе на микросервисы
Типы архитектур ПО
Многоуровневая архитектура
Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI. Система делится на уровни, каждый из которых взаимодействует лишь с двумя соседними. Поэтому запросы к БД, которая обычно располагается в самом конце цепочки взаимодействия, проходят последовательно сквозь каждый «слой». Архитектура не подразумевает какое-то обязательное количество уровней — их может быть три, четыре, пять и больше. Чаще всего используют трехзвенные системы: с уровнем представления (клиентом), уровнем логики и уровнем данных.
О многоуровневой архитектуре написано бесчисленное количество книг и статей. И сложились разные мнения о ее достоинствах и недостатках.
Плюсы:
Каждый уровень этой архитектуры выполняет строго ограниченный набор функций (которые не повторяются от слоя к слою) и не знает о том, как устроены остальные уровни. Поэтому «содержимое» уровней можно изменять без риска глобальных конфликтов между слоями.В целом многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов. Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают выстраивать уровни приложения.
Недостатки:
В программировании есть присказка, что любую проблему можно решить добавлением еще одного уровня абстракции. Однако такой подход в конечном счете может привести к плохой организации кода и запутать разработчиков.Отсюда вытекает еще одна проблема — низкая скорость работы. Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику. Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.Поиск багов в многоуровневых системах также может быть затруднен. Прежде чем попасть в базу данных, информация проходит через все уровни (так как БД является конечным компонентом). Если по какой-то причине эта информация повреждается (или теряется по пути), то для поиска ошибки приходится анализировать каждый уровень по отдельности.
Хорошо подходит:
Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).
Событийно-ориентированная архитектура
В этом случае разработчик прописывает для программы поведение (реакции) при возникновении каких-либо событий. Событием в системе считается существенное изменение её состояния.Можно провести аналогию с покупкой автомобиля в салоне. Когда автомобиль находит нового владельца, его состояние меняется с «продается» на «продано». Это событие запускает процесс предпродажной подготовки — установку дополнительного оборудования, проверку технического состояния, мойку и др.Система, управляемая событиями, обычно содержит два компонента: источники событий (агенты) и их потребители (стоки). Типов событий обычно тоже два: инициализирующее событие и событие, на которое реагируют потребители.Примером реализации такой архитектуры может служить библиотека Java Swing. Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать. На Wiki приводится следующий код реализации этого механизма:
Достоинства архитектуры:
Так как приложения состоят из большого количества асинхронных модулей (у которых нет информации о реализации друг друга), их легко масштабировать. Такие системы собираются как конструктор — прописывать зависимости не нужно, достаточно реализовать новый модуль. Дополнительно асинхронная модель позволяет добиться высокой производительности приложений.
Недостатки:
Микроядерная архитектура
Этот тип архитектуры состоит из двух компонентов: ядра системы и плагинов. Плагины отвечают за бизнес-логику, а ядро руководит их загрузкой и выгрузкой.
Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется. Микроядерную архитектуру в свое время использовала операционная система Symbian для мобильных устройств (разработку прекратили в 2012 году). В её микроядре находился планировщик задач, системы управления памятью и драйверы, а файловая система и компоненты, отвечающие за телефонную связь, выступали в роли плагинов.
Достоинства архитектуры:
Легко портировать приложение из одной среды в другую, поскольку модифицировать нужно только микроядро. Разделение высокоуровневых политик и низкоуровневых механизмов упрощает поддержку системы и обеспечивает её расширяемость.
Недостатки:
Производительность приложения снижается, если подключать слишком много модулей. Однако бывает проблематично найти баланс между количеством плагинов и числом задач микроядра (обычно оно содержит лишь часто используемой код).Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.
Хорошо подходит для:
Микросервисы
Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).В каких пропорциях делить код, решает разработчик, но Сэм Ньюмен (Sam Newman), автор книги «Создание микросервисов», рекомендует выделять на микросервис столько строк кода, сколько команда сможет воспроизвести за две недели. По его словам, это позволит избежать излишнего «раздувания» архитектуры.Чаще всего микросервисы запускаются в так называемых контейнерах. Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др.
Достоинства:
Почему мы в 1cloud переходим на микросервисы
Простыми словами о том, что стоит запомнить про архитектуры
Трехуровневая архитектура
Что такое трехуровневая архитектура?
Трехуровневая архитектура — это широко применяемая архитектура программного обеспечения в которой приложения разделены на три логических и физических уровня: уровень представления (пользовательский интерфейс), уровень приложения, на котором осуществляется обработка данных, и уровень данных, предназначенный для хранения и управления данными, относящимися к приложению.
Основное преимущество трехуровневой архитектуры заключается в том, что поскольку каждый уровень имеет собственную инфраструктуру, разработкой каждого уровня может заниматься отдельная команда разработчиков. Кроме того, каждый уровень можно обновлять и масштабировать по мере необходимости, не затрагивая другие уровни.
На протяжении десятилетий трехуровневая архитектура оставалась самой распространенной архитектурой для клиент-серверных приложений. Сегодня большинство трехуровневых архитектур подлежат модернизации с использованием облачных технологий, таких как контейнеры и микросервисы, а также требуют миграции в облако.
Подробное описание трех уровней
Уровень представления
На уровне представления обеспечивается взаимодействие с пользователем приложения — это пользовательский интерфейс и уровень обмена данными. Его основное предназначение состоит в отображении информации и получении информации от пользователя. Этот уровень может работать в веб-браузере или как графический пользовательский интерфейс компьютерного или мобильного приложения. Уровни представления веб-приложений обычно разрабатываются с помощью HTML, CSS и JavaScript. Компьютерные и мобильные приложения могут быть написаны на любом языке в зависимости от платформы.
Уровень приложений
Уровень приложения, также известный как логический или промежуточный уровень, является центральным звеном приложения. На этом уровне обрабатывается информация, собранная на уровне представления — иногда с учетом другой информации из уровня данных — с помощью бизнес-логики, которая представляет собой набор бизнес-правил. Кроме того, уровень приложения может добавлять, изменять и удалять данные, расположенные на уровне данных.
Как правило, уровень приложения разрабатывается с помощью Python, Java, Perl, PHP или Ruby и взаимодействует с уровнем данных посредством вызовов API.
Уровень данных
Уровень данных, который также называется уровнем базы данных, уровнем доступа к данным или базовым уровнем, предназначен для хранения и управления информацией, обработанной приложением. Его роль может выполнять реляционная система управления базами данных, такая как PostgreSQL, MySQL, MariaDB, Oracle, DB2, Informix или Microsoft SQL Server, либо сервер базы данных NoSQL, такой как Cassandra, CouchDB или MongoDB.
В трехуровневом приложении обмен данными осуществляется только через уровень приложения. Уровень представления и уровень данных не могут взаимодействовать друг с другом напрямую.
Слои и уровни
В контексте трехуровневой архитектуры термины уровень (tier) и слой (layer) часто используются как взаимозаменяемые, однако это не совсем справедливо.
Между ними следует делать различие. «Слой» разделяет части программы по функциональному признаку, а «уровни» не только имеют разный функционал, но и работают в независимой от других уровней инфраструктуре. Например, приложение Контакты на вашем телефоне представляет собой трехслойное приложение, но вместе с тем оно является одноуровневым, поскольку все три слоя работают на телефоне.
Эта разница имеет важное значение, поскольку слои не позволяют получить те преимущества, которые дает разделение по уровням.
Преимущества трехуровневой архитектуры
Итак, главным преимуществом трехуровневой архитектуры является логическое и физическое разделение функциональных возможностей. Каждый уровень можно запустить в отдельной операционной системе и серверной платформе (веб-сервер, сервер приложений, сервер базы данных), наилучшим образом соответствующей его функциональным требованиям. Поскольку каждый уровень выполняется по крайней мере на одном выделенном аппаратном или виртуальном сервере, уровни можно настраивать и оптимизировать независимо друг от друга.
Другие преимущества (по сравнению с одноуровневой и двухуровневой архитектурой):
Трехуровневое приложение в веб-разработке
В случае веб-разработки уровни называются по-другому, но выполняют аналогичные функции:
Другие многоуровневые архитектуры
Несмотря на доминирующее положение трехуровневой архитектуры, в своей работе вы можете встретиться с другими вариантами многоуровневых архитектур приложений.
Двухуровневая архитектура
Двухуровневая архитектура — это изначальный вариант клиент-серверной архитектуры, состоящей из слоя представления и слоя данных; бизнес-логика может находиться в слое представления и/или в слое данных. В случае двухуровневой архитектуры слой представления, а следовательно и конечный пользователь, обладают прямым доступом к слою данных и возможности бизнес-логики часто ограничивается. В качестве примера двухуровневого приложения можно привести простое приложение для управления контактами, в котором пользователи вводят и извлекают контактную информацию.
N-уровневая архитектура
В общем случае N-уровневая архитектура, также называемая многоуровневой архитектурой, представляет собой любую архитектуру приложений, имеющую больше одного уровня. Однако приложения более чем с тремя уровнями встречаются крайне редко, поскольку дополнительные уровни не дают существенных преимуществ и могут сделать приложение более медленным, сложным в управлении и дорогим в обслуживании. Таким образом, n-уровневая архитектура и многоуровневая архитектура обычно являются синонимами трехуровневой архитектуры.
Трехуровневая архитектура и IBM Cloud
IBM Cloud предлагает продукты и услуги, помогающие модернизировать устаревшие трехуровневые приложения в процессе перехода в облако.
Сделайте первый шаг: