Веб-приложение — это веб система, позволяющая пользователю реализовать доступ к бизнес-логике через интернет с использованием веб-браузера. Такая система рассматривается как набор узлов с перекрестными ссылками. Программа состоит из нескольких логических частей, которые связаны между собой.
Типы веб-приложений
1. CGI приложения — приложения, работающие на сервере и передающие данные клиентам. Для работы необходимы веб-браузеры. Параметры могут передаваться через адресную строку, при помощи форм и при помощи переменных окружения;
2. Веб-сервисы — программы или программные модули, вызываемые через интернет. Отличие в том, что веб-сервис возвращает на сторону клиента конкретный результат. Для работы веб-сервисов не обязателен веб-браузер;
3. Локальные приложения с поддержкой интернета — автономные программы со встроенными механизмами доступа к различным службам через интернет, таким как регистрация, обновление, справочная системы и так далее;
4. Одноранговые приложения — автономные программы, использующие интернет для взаимодействия с другими программами того же типа (ICQ, Skype).
Архитектура Web Приложений / от простых до высоконагруженных
Классификация веб-приложений
1. По степени связанности (сопряжения) компонентов системы.
Степень связанности — это степень, в которой каждый из компонентов зависит от других модулей системы.
1.1. Слабо связанные приложения. Компоненты взаимодействуют между собой по неизменным интерфейсам и не зависят от внутренней реализации каждого из компонентов.
1.2. Сильно связанные приложения. Работа одних компонентов может зависеть от внутренней реализации других компонентов. Изменения внутри одних компонентов требует изменения остальных.
2. По количеству логических уровней в инфраструктуре приложения.
2.1. Монолитные приложения. Реализованы все три уровня;
2.2. Двухуровневые приложения. БД — отдельный уровень. Выделение второго уровня приводит к архитектуре «клиент сервер». Часть бизнес-логики может остаться на клиенте;
2.3. Многоуровневые приложения. Как правило трехуровневые. Бизнес логика выносится в отдельный уровень. Клиент остается на клиентской части с интерфейсом, который выполняет минимум функций. Обработка информации в рамках бизнес-логики.
Реализации — сервер приложений, сервер БД.
3. По виду предоставляемой пользователю информации. Любой сайт есть приложение.
3.1. Статические приложения. Содержат неизменяемое наполнение;
3.2. Динамические приложения. Содержат изменяемое наполнение.
Требования к веб-приложениям
От степени соответствия требованиям зависит качество веб-приложения.
Функциональные требования определяют функциональность системы, которую разработчики должны построить, чтобы пользователи могли выполнять свои задачи в рамках своих бизнес-процессов.
Нефункциональные требования представляют собой описание характеристик приложения, важных для пользователя при работе с системой.
1. Надежность — свойство приложения сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения;
Архитектура современных WEB приложений. Эволюция от А до Я
2. Быстродействие — среднее время обработки запроса;
3. Безопасность — приложение должно отвечать требованиям безопасности;
4. Масштабируемость — независимость характеристик приложения от количества пользователей.
Источник: studfile.net
Кирпичи для интернета: топ‑10 концепций современной веб‑архитектуры, которые вам точно нужно знать
Опытный разработчик рассказывает о десяти китах, на которых построена архитектура современного веба.
Фото: Bloomberg / Getty Images
Екатерина Степанова
Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.
Шалита Суранга
(Shalitha Suranga)
Об авторе
Программист, создатель Neutralinojs — фреймворка для разработки JS-, HTML- и CSS-приложений, постоянный автор статей о технологиях на Medium.
Источник
Переводчик
С тех пор как Тим Бернерс-Ли изобрёл World Wide Web, в облачную экосистему перешли чуть ли не все типы физических сервисов. Число веб-сайтов и веб-приложений начало расти как на дрожжах — и в архитектуре каждого современного веб-приложения есть общие компоненты облачных вычислений, которые нужно знать каждому разработчику. Провайдеры облачных сервисов могут по-разному называть эти компоненты, но их суть остаётся прежней.
Я изучил архитектуры веб-приложений нескольких современных IT-гигантов (Netflix, Medium и Airbnb) и выделил в них такие составляющие:
1. Сервер
Сервером называют компьютер, который предоставляет какой-то сервис (или несколько сервисов) в частной сети или интернете. Другие устройства — их ещё называют клиентами — могут подключаться к серверу через разные порты, чтобы получить этот сервис. Серверы обычно называют по имени сервиса, который они предоставляют. Например, если сервер принимает запросы через 80-й порт и отдаёт клиентам веб-страницы, такой сервер обычно называют веб-сервером. Также существуют файловые серверы, почтовые серверы, серверы аутентификации, серверы баз данных, серверы приложений и тому подобные.
Сейчас более популярны виртуальные, а не физические серверы. Поставщики облачных услуг создают виртуальные машины поверх своего физического оборудования с помощью гипервизоров и программного обеспечения для виртуализации. Например, некоторые популярные провайдеры используют для создания своих виртуальных машин гипервизор Xen первого типа.
2. Клиент
Клиент — это устройство, которое подключается к серверам, чтобы пользоваться их сервисами или ресурсами. Клиентом может быть компьютер, веб-сайт, ПО или встроенная система. Например, когда вы заходите на веб-сайт, ваш браузер становится клиентом. По аналогии с именованием серверов, клиенты тоже называются в зависимости от сервиса, которым они пользуются: бывают email-клиенты, веб-клиенты, клиенты баз данных или клиенты онлайн-чатов.
В клиент-серверной модели используются методы вроде аутентификации, чтобы открыть конкретный сервис только отдельным клиентам. Клиенты бывают тонкими и толстыми. Тонкий клиент полностью зависит от сервера, как обычное одностраничное приложение (SPA — Single Page Application). Толстый же клиент от сервера не зависит. Он похож на автономное приложение, которое сохраняет данные на сервере.
3. Микросервис
Монолитная клиент-серверная архитектура не лишена недостатков. Сбои в монолитных системах влияют на всю систему, а сопровождать их довольно сложно. При микросервисном подходе разработчики разбивают большую монолитную систему на небольшие сервисы — микросервисы. Так называют слабосвязанный изолированный сервис, отвечающий за какой-то процесс.
Если вы разрабатываете систему управления пользователями, микросервисы могут отвечать за регистрацию пользователей, генерацию отчёта и процесс оплаты. В реальных веб-ориентированных системах большинство микросервисов представляют собой RESTful API , работающие на виртуальной машине или в контейнере.
Примечание переводчика
REST (англ. REpresentational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль, набор принципов, по которому должны взаимодействовать компоненты распределённого приложения. Если система, веб-служба, API соответствует этим принципам, она называется RESTful.
Рой Филдинг (Roy Thomas Fielding) — американский учёный, автор термина REST, предложил шесть принципов REST-архитектуры, среди которых клиент-серверная модель, кэширование, отсутствие состояния и другие.
4. Облачная функция
С возрастанием сложности кода микросервисы могут становиться более тяжёлыми и сложными для поддержки. Кроме того, могут резко вырасти затраты на инфраструктуру, так как микросервисы будут постоянно ждать подключения клиентов к виртуальным машинам или контейнерам. Бессерверная (serverless) концепция позволяет разбить большие системы на более мелкие и удобные для поддержки функции — так называемые бессерверные, или облачные, функции.
5. Балансировщик нагрузки
Балансировкой нагрузки называют её распределение между разными вычислительными модулями. В веб‑архитектуре балансировщик нагрузки — это компонент, который перенаправляет трафик на разные серверы в зависимости от их доступности.
Есть два основных типа балансировщиков нагрузки: аппаратные (HLB — hardware‑based load balancer) и программные (software‑based). Популярнее программные, потому что HLB дорогие и для них нужны физические серверы.
Почти все поставщики облачных сервисов предлагают балансировщики нагрузки по модели «как услуга» (as-a-service).
6. API-шлюз (API gateway)
У веб-приложения может быть несколько API, и каждый нужно защитить от избыточной загрузки с помощью ограничения скорости обработки запросов (rate limiting). API-шлюз предоставляет единственную точку доступа для нескольких API и других сервисов.
Принцип его работы схож с принципом работы балансировщика нагрузки: он перенаправляет каждый клиентский запрос соответствующим сервисам. API-шлюз обычно предоставляется как часть решения по управлению API (API management solution), в которое также входит графический пользовательский интерфейс (GUI) для управления API с защищённой панели администратора.
В API-шлюзы встраивают службы мониторинга API, ограничения скорости обработки запросов, монетизации API и версионирования. Обычно API-шлюзы используются с RESTful API, но могут поддерживать протоколы SOAP, GraphQL, gRPC и TCP.
7. Очередь сообщений
Современная веб-архитектура складывается из отдельных управляемых компонентов — микросервисов. Микросервисы используют для взаимодействия друг с другом RESTful API или очереди сообщений. Очереди сообщений организуют асинхронный канал обмена сообщениями между двумя микросервисами по типу « издатель — подписчик » (pub-sub).
У очередей сообщений есть несколько преимуществ перед асинхронными RESTful-интерфейсами. Например, если во время REST-запроса происходит ошибка, инициатор запроса (клиент) должен суметь её обработать. Кроме того, некорректное REST-сообщение будет просто отклонено и никуда не сохранится. А вот очереди сообщений хранят все сообщения.
Даже если сообщение отправят в момент сбоя получателя, тот всё же получит его после перезапуска. Поэтому веб-архитекторы отдают предпочтение очередям сообщений в тех случаях, когда надёжность транзакций имеет решающее значение.
8. CDN
Сеть доставки контента (Content Delivery Network, CDN) состоит из географически распределённых серверов, которые кэшируют статический контент (например, рисунки или скрипты. — Пер.) для улучшения производительности, доступности и безопасности веб-приложений.
В типовом веб-приложении обычно есть рисунки, видео, стили и файлы JavaScript. Каждый раз, когда пользователь заходит в ваше приложение, его браузер скачивает эти ресурсы с сервера. Если пользователь живёт далеко от физического месторасположения сервера, страница будет загружаться долго. CDN кэширует статический контент на множестве серверов по всему миру и быстро доставляет его географически более близким клиентам.
Более того, CDN может смягчить ущерб от DDoS-атак, так как серверы кэширования CDN, по сути, выступают как прокси для вашего оригинального сервера.
Примечание переводчика
Атака типа «отказ в обслуживании» (DoS, Denial of Service) — попытка сделать недоступным сайт, веб‑приложение, систему. Часто при этом генерируется много запросов, которые в итоге перегружают систему. DDoS (Distributed DoS — в пер. с англ. — распределённая) — это когда атака ведётся одновременно из нескольких источников.
CDN при этой атаке становится дополнительным барьером — закрывает целевые компьютеры от прямого воздействия злоумышленников.
9. База данных
База данных — это компонент, в котором хранятся сведения различных типов. Есть разные типы баз данных: SQL, облачные, «ключ — значение» (key-value), графовые и иерархические (documented). Серверы баз данных позволяют клиентам взаимодействовать с базами данных по специальным протоколам. Например, сервер базы данных MySQL использует протокол MySQL.
Тип базы данных выбирают веб-архитекторы, исходя из реальных требований. Например, если нужно хранить много пользовательских сессий с уникальными идентификаторами, хорошим выбором будет база данных типа «ключ — значение».
10. Сервисы
Веб-приложениям необходимы аутентификация, обмен электронными письмами, логирование, мониторинг, машинное обучение, система платежей и другие сервисы. Кроме того, им нужны службы, связанные с разработкой, проектированием и развёртыванием, такие как хостинг репозиториев, непрерывная интеграция/доставка (CI/CD), база данных, хостинг приложений, поиск/индексирование и тому подобное. Ключевые требования для этих сервисов можно реализовать с помощью многих опенсорсных фреймворков. Но всё равно понадобится инфраструктура, чтобы установить и использовать эти сервисы.
Многие компании и стартапы, работающие по модели «как услуга» (as-a-service), предоставляют почти все эти облачные сервисы для веб-разработки. Кроме того, некоторые крупные технологические компании создали собственные экосистемы для разработки, в которых объединили множество облачных сервисов.
- Что такое фреймворк и как выбрать фреймворк для фронтенда: советы бывалых
- Senior iOS-разработчик из VK: «Работа в энтерпрайзе — это стабильность»
- Как работает Docker: подробный гайд от техлида
Гипервизор — программа, которая управляет виртуальными машинами и позволяет запустить несколько виртуальных машин на одном физическом сервере.
Application programming interface (API) — программный интерфейс приложения. Это своего рода контракт, который предоставляет приложению или сервису набор функций, с помощью которых они могут обмениваться данными/командами с другими приложениями и сервисами.
«Издатель — подписчик» (pub-sub) — поведенческий шаблон построения систем, при котором два типа компонентов (издатели и подписчики) вместо прямого взаимодействия друг с другом обмениваются сообщениями. Издатели создают сообщения и кладут их в очередь, а подписчики эти сообщения читают.
Такой подход уменьшает связанность компонентов и увеличивает гибкость системы.
Источник: skillbox.ru
Основные виды программ web систем
КЛАССИФИКАЦИЯ WEB -ПРИЛОЖЕНИЙ
Аскарова Д.Р., студентка, 4 курс
г.Бирск, ФГБОУ ВО Бирский филиал БашГУ,
Файрушин Е.С., студент, 4 курс
г.Бирск, ФГБОУ ВО Бирский филиал БашГУ,
Мухаметшина Г.С., к.э.н., доцент
г.Бирск, ФГБОУ ВО Бирский филиал БашГУ
Веб-приложение — это приложение, одна часть которого загружается в браузер и взаимодействует с пользователем, а другая находится на веб-сервере и выполняет запросы, поступающие от первой, а затем возвращает ответ. Часть, которая загружается в браузер и с которой взаимодействует пользователь, называется клиентской частью. На веб-сервере находится серверная часть веб-приложения [1].
Для эффективного выбора метода разработки веб-приложения требуется провести классификацию таковых. Для этого следует рассмотреть различные характеристики веб-приложений. Их можно разбить на четыре группы.
1. Характеристики программного обеспечения ПО.
2. Характеристики, связанные с характером использования.
3. Характеристики, связанные с разработкой.
4. Характеристики, связанные с развитием.
Далее будет подробно рассмотрена каждая из этих групп.
Характеристики ПО связаны непосредственно с самим веб-приложением и описывают его содержимое. Среди них можно выделить: внешний вид, гипертекст и содержимое.
Возможно разделить характеристики веб-приложения, связанные с пользователем, на естественное содержимое, социальное содержимое и техническое содержимое.
К характеристикам, связанным с разработкой, можно отнести особенности команды разработчиков, процесс разработки, техническую инфраструктуру и интеграцию.
К характеристикам, связанным с развитием, относят эволюционные характеристики. В соответствии с изменениями в требованиях происходят некоторые изменения или обновления в веб-приложении. Эта эволюция может касаться всех остальных трех категорий характеристик. Рыночная конкуренция или краткосрочное развитие могут привести к изменениям всех характеристик веб-приложения.
Учитывая выделенные характеристики, можно классифицировать веб-приложения, разбив их на следующие категории: документно-ориентированное веб-приложение; интерактивное веб-приложение; транзакционное веб-приложение; веб-приложение на основе рабочего процесса; совместное веб-приложение; портально-ориентированное веб-приложение; вездесущие веб-приложения; веб-приложение, основанное на знаниях.
Далее будет рассмотрено описание приложений, попадающих в каждую из выделенных категорий.
Документно-ориентированные веб-приложения представляют собой статические HTML-документы, хранящиеся на веб-сервере, которые отправляются непосредственно клиенту по запросу. Веб-страницы обновляются вручную с помощью соответствующих инструментов. Эти приложения статичны, просты, стабильны и требуют меньше времени для ответа.
Интерактивные веб-приложения полагаются на использование современных технологий создания интерфейса веб-приложения. Они включает в себя переключатели, меню выбора, формы т. д. Эти приложения просты и быстры. В этом типе приложений веб-страницы и ссылки генерируются в соответствии с пользовательским вводом.
Транзакционное веб-приложение имеют возможность модификации пользователем. Эти приложения более интерактивны и поддерживают структурированные запросы к базе данных.
Веб-приложение на основе рабочего процесса способны управлять рабочим процессом между компаниями, частными или государственными органами. Веб-сервисы включены для обеспечения совместимости. Они должны быть надежны и гибки, чтобы управлять рабочим процессом внутри компаний. Пример — различные решения для управления процессами «бизнес для бизнеса».
Совместные веб-приложения в основном используются в качестве групповых приложений, важной частью которых является групповое общение. Чаты, онлайн-форумы, веб-сайты электронного обучения или веб-сайты, где информация передается с возможностью редактирования, например Википедия, являются примерами таких веб-приложений.
Портально-ориентированное веб-приложение включает в себя те ресурсы, в которых есть единая точка доступа для разделения различных источников информации и услуг. Пример — поисковые системы, порталы сообществ.
Вездесущие веб-приложения предоставляют индивидуальные возможности для любого устройства из любого места в любое время. Их применение требует предварительного знания контекста, в котором веб-приложение используется для динамической настройки.
Веб-приложения, основанные на знаниях, используются для предоставления знаний как человеку, так и машине. Управление знаниями основано на семантических веб-технологиях. Майнинг в Интернете, связывание и повторное использование знаний — вот несколько примеров подобных приложений.
Из приведённого анализа и классификации можно сделать вывод о разнообразии категорий веб-приложений. Каждая категория веб-приложений накладывает свои требования к процессу разработки и предпочитаемой архитектуре.
Источник: birskin.ru