Сервер (программное обеспечение)
Се́рверное программное обеспечение (англ. server от англ. to serve — служить) (множественное число серверá) — в информационных технологиях — программный компонент вычислительной системы, выполняющий сервисные (обслуживающие) функции по запросу клиента, предоставляя ему доступ к определённым ресурсам или услугам.
Содержание
Роль сервера
Понятия сервер и клиент и закрепленные за ними роли образуют программную концепцию «клиент-сервер».
Для взаимодействия с клиентом (или клиентами, если поддерживается одновременная работа с несколькими клиентами) сервер выделяет необходимые ресурсы межпроцессного взаимодействия (разделяемая память, пайп, сокет, и т. п.) и ожидает запросы на открытие соединения (или, собственно, запросы на предоставляемый сервис). В зависимости от типа такого ресурса, сервер может обслуживать процессы в пределах одной компьютерной системы или процессы на других машинах через каналы передачи данных (например, COM-порт) или сетевые соединения.
Формат запросов клиента и ответов сервера определяется протоколом. Спецификации открытых протоколов описываются открытыми стандартами, например протоколы Интернета определяются в документах RFC.
В зависимости от выполняемых задач одни серверы, при отсутствии запросов на обслуживание, могут простаивать в ожидании. Другие могут выполнять какую-то работу (например, работу по сбору информации), у таких серверов работа с клиентами может быть второстепенной задачей.
Аппаратное обеспечение
У слова «сервер», также есть второе значение — (персональный или иной) компьютер, выполняющий только серверные задачи, или компьютер (или иное аппаратное обеспечение), специализированный (по форм-фактору и/или ресурсам) для использования в качестве аппаратной базы для серверов услуг (иногда — услуг определенного направления).
Аппаратными серверами (аппаратное обеспечение) называются узкоспециализированные решения со встроенным программным обеспечением (англ. firmware ; в отличие от компьютеров, где программное обеспечение необходимо устанавливать), определяющим специализацию и возможные предоставляемые услуги. Аппаратные серверы, как правило, более просты и надежны в эксплуатации, потребляют меньше электроэнергии и, иногда, более дешевы. Но вместе с тем они менее гибки (так как изначально ограничены в выполняемых задачах) и, часто, ограничены в ресурсах.
Важно понимать что сервер, в том значении как его понимает эта статья (то есть сервер, предоставляющий какой-либо сервис, например прокси-сервер), всегда является программой (или программным модулем), выполняющейся на каком-то аппаратном обеспечении. Без этой программы аппаратное обеспечение не может ничего предоставлять. Даже «аппаратные серверы» (или роутеры) не исключение, потому что в них сервис, также, предоставляется (встроенным) программным обеспечением. Иногда, для простоты, сервером услуги (например тем же прокси-сервером) называют программное и аппаратное обеспечение в целом, в особенности если этот программно-аппаратный комплекс выполняет только одну задачу.
Теоретически, на одной единице аппаратного обеспечения, может одновременно выполняться произвольное количество серверов (за исключением серверов конфликтующих между собой по ресурсам или их количеству), они будут делить между собой аппаратные ресурсы. Практически, между крайностями «один компьютер — одна услуга» и «один компьютер — все услуги» каждый находит свой компромисс.
Серверы услуг можно запускать на рабочей станции, чтобы они работали в фоне разделяя ресурсы компьютера с программами, запускаемыми пользователем. Такой режим работы называется «невыделенным», в отличие от «выделенного» (англ. dedicated ), когда компьютер выполняет только сервисные функции. Строго говоря, на рабочей станции (для примера, под управлением Windows XP) и без того, всегда работает несколько серверов — сервер удаленного доступа (терминальный сервер), сервер удаленного доступа к файловой системе и системе печати, и прочие удаленные и внутренние серверы.
Классификация стандартных серверов
Как правило, каждый сервер обслуживает один (или несколько схожих) протоколов и серверы можно классифицировать по типу услуг которые они предоставляют.
Универсальные серверы
Универсальные серверы — особый вид серверной программы, не предоставляющий никаких услуг самостоятельно. Вместо этого универсальные серверы предоставляют серверам услуг упрощенный интерфейс к ресурсам межпроцессного взаимодействия и/или унифицированный доступ клиентов к различным услугам. Существуют несколько видов таких серверов:
- inetd от англ. internet super-server daemonдемон сервисов IP — стандартное средство UNIX-систем — программа, позволяющая писать серверы TCP/IP (и сетевых протоколов других семейств), работающие с клиентом через перенаправленные inetd потоки стандартного ввода и вывода (stdin и stdout).
- RPC от англ. Remote Procedure Call удаленный вызов процедур — система интеграции серверов в виде процедур доступных для вызова удаленным пользователем через унифицированный интерфейс. Интерфейс изобретенный Sun Microsystems для своей операционной системы (SunOS, Solaris; Unix-система), в настоящее время используетстся как в большинстве Unix-систем, так и в Windows.
- Прикладные клиент-серверные технологии Windows:
- (D-)COM (англ. (Distributed) Component Object Model — модель составных объектов) и др. — Позволяет одним программам выполнять операции над объектами данных используя процедуры других программ. Изначально данная технология предназначена для их «внедрения и связывания объектов» (OLE англ. Object Linking and Embedding ), но в общем позволяет писать широкий спектр различных прикладных серверов. COM работает только в пределах одного компьютера, DCOM доступна удаленно через RPC.
- Active-X — Расширение COM и DCOM для создания мультимедиа-приложений.
Универсальные серверы часто используются для написания всевозможных информационных серверов, серверов, которым не нужна какая-то специфическая работа с сетью, серверов не имеющих никаких задач, кроме обслуживания клиентов. Например в роли серверов для inetd могут выступать обычные консольные программы и скрипты.
Большинство внутренних и сетевых специфических серверов Windows работают через универсальные серверы (RPC, (D-)COM).
Маршрутизация
Строго говоря, сервис маршрутизации не является сервером в классическом смысле, а является базовой функцией поддержки сети операционной системой.
Для TCP/IP, маршрутизация является базовой функцией стека IP (кода поддержки TCP/IP). Маршрутизацию своих пакетов к месту назначения выполняет любая система в сети, маршрутизацию же чужих пакетов (форвардинг) выполняют только маршрутизаторы (также известные как роутеры или шлюзы). Задачи маршрутизатора при форвардинге пакета:
- принять пакет
- найти машину на которую следует этот пакет или следующий маршрутизатор по маршруту к ней (в таблице маршрутов)
- передать пакет или вернуть ICMP-сообщение о невозможности его доставки по причинам:
- Назначение недостижимо (Destination unreachable) — у пакета кончилось «время жизни» прежде чем он достиг места назначения
- Хост недостижим (Host unreachable) — компьютер или следующий маршрутизатор выключен или не существует
- Сеть недостижима (Network unreachable) — маршрутизатор не имеет маршрута в сеть назначения
Динамическая маршрутизация
Решения динамической маршрутизации призваны собирать информацию о текущем состоянии сложной сети и поддерживать таблицу маршрутов через эту сеть, чтобы обеспечить доставку пакета по кратчайшему и самому эффективному маршруту.
Из этих решений клиент-серверную модель использует только BGP (англ. Border Gateway Protocol — протокол пограничного шлюза), применяемый для глобальной маршрутизации. Локальные решения (RIP, OSPF) используют в своей работе бродкастовые и мультикастовые рассылки.
Сетевые службы
Сетевые службы обеспечивают функционирование сети, например серверы DHCP и BOOTP обеспечивают стартовую инициализацию серверов и рабочих станций, DNS — трансляцию имен в адреса и наоборот.
Серверы туннелирования (например, различные VPN-серверы) и прокси-серверы обеспечивают связь с сетью, недоступной роутингом.
Серверы AAA и Radius обеспечивают в сети единую аутентификацию, авторизацию и ведение логов доступа.
Информационные службы
К информационным службам можно отнести как простейшие серверы сообщающие информацию о хосте (time, daytime, motd), пользователях (finger, ident), так и серверы для мониторинга, например SNMP. Большинство информационных служб работают через универсальные серверы.
Особым видом информационных служб являются серверы синхронизации времени — NTP, кроме информировании клиента о точном времени NTP-сервер периодически опрашивает несколько других серверов на предмет коррекции собственного времени. Кроме коррекции времени анализируется и корректируется скорость хода системных часов. Коррекция времени осуществляется ускорением или замедлением хода системных часов (в зависимости от направления коррекции), чтобы избежать проблем возможных при простой перестановке времени.
Файл-серверы
Файл-серверы представляют собой серверы для обеспечения доступа к файлам на диске сервера.
Прежде всего это серверы передачи файлов по заказу, по протоколам FTP, TFTP, SFTP и HTTP. Протокол HTTP ориентирован на передачу текстовых файлов, но серверы могут отдавать в качестве запрошенных файлов и произвольные данные, например динамически созданные веб-страницы, картинки, музыку и т. п.
Другие серверы позволяют монтировать дисковые разделы сервера в дисковое пространство клиента и полноценно работать с файлами на них. Это позволяют серверы протоколов NFS и SMB. Серверы NFS и SMB работают через интерфейс RPC.
Недостатки файл-серверной системы:
- Очень большая нагрузка на сеть, повышенные требования к пропускной способности. На практике это делает практически невозможной одновременную работу большого числа пользователей с большими объемами данных.
- Обработка данных осуществляется на компьютере пользователей. Это влечет повышенные требования к аппаратному обеспечению каждого пользователя. Чем больше пользователей, тем больше денег придется потратить на оснащение их компьютеров.
- Блокировка данных при редактировании одним пользователем делает невозможной работу с этими данными других пользователей.
- Безопасность. Для обеспечения возможности работы с такой системой Вам будет необходимо дать каждому пользователю полный доступ к целому файлу, в котором его может интересовать только одно поле
Сервера доступа к данным
Серверы доступа к данным обслуживают базу данных и отдают данные по запросам. Один из самых простых серверов подобного типа — LDAP (англ. Lightweight Directory Access Protocol — облегчённый протокол доступа к спискам).
Для доступа к серверам баз данных единого протокола не существует, однако все серверы баз данных объединяет использование единых правил формирования запросов — язык SQL (англ. Structured Query Language — язык структурированных запросов).
Службы обмена сообщениями
Службы обмена сообщениями позволяют пользователю передавать и получать сообщения (обычно — текстовые).
В первую очередь это серверы электронной почты работающие по протоколу SMTP. SMTP-сервер принимает сообщение и доставляет его в локальный почтовый ящик пользователя или на другой SMTP-сервер (сервер назначения или промежуточный). На многопользовательских компьютерах, пользователи работают с почтой прямо на терминале (или веб-интерфейсе). Для работы с почтой на персональном компьютере, почта забирается из почтового ящика через серверы, работающие по протоколам POP3 или IMAP.
Для организации конференций существует серверы новостей, работающие по протоколу NNTP.
Для обмена сообщениями в реальном времени существуют серверы чатов, стандартный чат-сервер работает по протоколу IRC — распределенный чат для интернета. Существует большое количество других чат-протоколов, например ICQ или Jabber.
Сервера удалённого доступа
Серверы удалённого доступа, через соответствующую клиентскую программу, обеспечивают пользователя консольным доступом к удалённой системе.
Для обеспечения доступа к командной строке служат серверы telnet, RSH, SSH.
Графический интерфейс для Unix-систем — X Window System, имеет встроенный сервер удалённого доступа, так как с такой возможностью разрабатывался изначально. Иногда возможность удалённого доступа к интерфейсу Х-Window неправильно называют «X-Server» (этим термином в X-Window называется видеодрайвер).
Стандартный сервер удалённого доступа к графическому интерфейсу Microsoft Windows называется терминальный сервер.
Некоторую разновидность управления (точнее мониторинга и конфигурирования), также, предоставляет протокол SNMP. Компьютер или аппаратное устройство для этого должно иметь SNMP-сервер.
Игровые сервера
Игровые серверы служат для одновременной игры нескольких пользователей в единой игровой ситуации. Некоторые игры имеют сервер в основной поставке и позволяют запускать его в невыделенном режиме (то есть позволяют играть на машине, на которой запущен сервер).
Серверные решения
Серверные решения — операционные системы и/или пакеты программ оптимизированные под выполнение компьютером функций сервера и/или содержащие в своем составе комплект программ для реализации типичного набора сервисов.
Примером серверных решений можно привести Unix-системы, изначально предназначенные для реализации серверной инфраструктуры.
Также необходимо выделить пакеты серверов и сопутствующих программ (например комплект веб-сервер/PHP/MySQL для быстрой развертки хостинга) для установки под Windows (для Unix свойственна модульная или «пакетная» установка каждого компонента, поэтому такие решения редки, но они существуют. Наиболее известное — LAMP).
В интегрированных серверных решениях установка всех компонентов выполняется единовременно, все компоненты в той или иной мере тесно интегрированы и предварительно настроены друг на друга. Однако в этом случае, замена одного из серверов или вторичных приложений (если их возможности не удовлетворяют потребностям) может представлять проблему.
Серверные решения служат для упрощения организации базовой ИТ-инфраструктуры компаний, то есть для оперативного построения полноценной сети в компании в том числе и «с нуля». Компоновка отдельных серверных приложений в решение подразумевает, что решение предназначено для выполнения большинства типовых задач; при этом значительно снижается сложность развертывания и общая стоимость владения ИТ-инфраструктурой, построенной на таких решениях.
Сервер приложений и веб-сервер
Сервер приложений (Application Sever) – это сервер промежуточного программного обеспечения (ПО, middleware). Это системное ПО, которое располагается между операционной системой (ОС) с одной стороны, внешними ресурсами, например, системой управления базами данных СУБД (DBMS, Database Management System) или Интернет-сервисами, с другой стороны, и приложениями пользователя.
Сервер приложений действует как хост для бизнес-логики пользователя, он также обеспечивает доступ к бизнес-приложениям и задаёт их параметры для пользователя. Сервер приложений должен устойчиво работать независимо от изменений трафика клиентских запросов, отказов оборудования и ПО, распределённого характера масштабных приложений, а также возможной разнородности форматов данных и ресурсов их обработки.
Внешние ресурсы, например, СУБД и Интернет-сервисы, предоставляют веб-серверы (Web Server). Они отвечает на запросы пользователя по доставке контента.
Серверы приложений иногда путают с веб-серверами. У них есть общие функции, но есть и много различий. Понимание этих различий поможет правильно сконфигурировать программное обеспечение и инфраструктуру оборудования для нужд предприятия.
Различия между серверами приложений и веб-серверами
Параметр сравнения
Веб-сервер
Сервер приложений
Основная цель
Хостинг сайтов и ответы на простые веб-запросы
Хостинг приложений и обеспечение сложных взаимосвязей бизнес-логики
Тип контента
Доставка только статического контента HTML
Доставка как статического, так и динамического контента
Протоколы
HTTP/HTTPS и другие протоколы
Соединение с приложениями
Подключения к базами данных
К статическим базам данных
К базам данных приложений
Типичные клиенты
Веб- и мобильные приложения, а также веб-браузеры
Многопотоковая обработка
Поддерживается параллельная обработка многих запросов
Потребление ресурсов
Трафик не потребляет много ресурсов
Процессы с интенсивным потреблением ресурсов
Контейнеры
Веб-контейнеры (сервлеты, JSP, JSF, веб-сервисы), контейнеры клиентских приложений (DI, безопасность)
Ёмкость
Результат запроса
Гипертекстовый документ, отображающий информацию в браузере
Файлы, содержащие данные, по требованию клиента
Что такое веб-сервер?
Веб-сервер – это компьютерная система, которая хранит, обрабатывает и доставляет веб-страницы для клиента. Клиентом в этом случае является веб-браузер на компьютере пользователя или мобильное приложение на его смартфоне или планшете. В зависимости от настроек, веб-сервер может хранить один или множество веб-сайтов. Веб-серверы доставляют клиенту только статический HTML-контент, такой как документы, изображения, видео, шрифты и пр.
Обычно веб-серверы не обрабатывают динамический контент и не позволяют программировать свои программы. Веб-серверы работают по протоколу передачи гипертекста HTTP (Hypertext Transfer Protocol) или HTTPS (Hypertext Transfer Protocol Secure). Однако, опционально, некоторые веб-серверы позволяют добавлять компоненты, позволяющие работать с динамическим контентом.
Что такое сервер приложений?
Сервер приложений (Application Server, App-Server) – это программный комплекс, предназначенный для доставки контента и средств его представления для клиентских приложений. Клиентами могут быть веб-приложения, браузеры или мобильные приложения.
Серверы приложений предоставляют для клиентов бизнес-логику, то есть, преобразуют данные в динамический контент и обеспечивают функционал приложений. Примеры такого контента:
- Результаты транзакций;
- Поддержка принятия решений;
- Аналитика в реальном времени, и др.
Сервер приложений – это связующее звено между клиентом и программным кодом физического сервера. Типичные задачи сервера приложений:
- Управление транзакциями;
- Безопасность;
- Внедрение зависимости DI (Dependency injection);
- Одновременность исполнения процессов (Concurrency).
Серверы приложений также обрабатывают такие процессы, как кластеризация, исправление отказов и балансировка нагрузки.
Рис. 2. Сервер приложений.
Что общего у веб-сервера и сервера приложений
Если в качестве основного приложения клиента выступает веб-браузер, то различия между двумя типами серверов размываются. Большинство веб-серверов имеют плагины на основе скриптов (ASP, JSP, JSF, PHP, Perl, и пр.), которые позволяют генерировать динамический контент.
Поскольку в сценариях применения у веб-серверов и серверов приложений много общего, то наиболее популярные серверы являются гибридами этих двух типов. Гибридное решение, совмещающее свойства обеих серверов, обеспечивает максимальную скорость и функциональность системы.
Для хостинга веб-сайта со статическим контентом лучше всего подходят объектные СХД.
Наиболее популярные веб-серверы
- Nginx
Nginx – веб-сервер с открытым кодом, который может работать как обратный прокси-сервер (reverse proxy). Обратный прокси-сервер работает не в сторону клиента, фильтруя контент и обеспечивая безопасность, а в сторону веб-сервера. Nginx имеет архитектуру, управляемую событиями EDA (event-driven architecture), позволяющую создавать и определять события, реагировать на события, измерять потребление ресурсов реакции на событие. Кроме того, он может выполнять функции прокси-сервера электронной почты и балансировщика нагрузки и может выполнять одновременно множество запросов.
- Apache HTTP
HTTP-сервер Apache – популярный веб-сервер на ОС Linux, который входит с стек LAMP (Linux, Apache, MySQL, PHP). На этом веб-сервере работает около 40% Интернет-сайтов. Apache имеет богатый выбор функций, включая htaccess, FTP, HTTP/2, ограничение полосы пропускания для определённых клиентов (throttling), балансировку нагрузки и пр.
- Microsoft IIS
Microsoft IIS (Internet Information Services) – свободно распространяемый пакет серверного ПО, представляющий собой проприетарный набор служб от компании Microsoft. IIS распространяется с пакетом Windows NT. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.
- Jetty
Jetty – проект свободного ПО, который может обеспечивать функции НТТР-сервера, НТТР-клиента и контейнера javax.servlet. Хотя Jetty разрабатывался как веб-сервер, он также может служить платформой для межмашинных коммуникаций (М2М).
- LiteSpeed
LiteSpeed имеет хорошую производительность и масштабируемость, широкий диапазон функций и простую в использовании консоль администратора. Это четвёртый по популярности веб-сервер, который, по состоянию на декабрь 2020 года, использовался для 8.1% веб-сайтов.
Наиболее популярные серверы приложений
- Apache Tomcat
Apache Tomcat – контейнер сервлетов с открытым исходным кодом на языке Java. Tomcat позволяет запускать веб-приложения и содержит ряд программ для автоматического конфигурирования и часто используется вместе с конфигурационным файлом Apache HTTPD (Apache Hypertext Transfer Protocol Server daemon). Tomcat может исполнять Java-сервлеты, доставлять клиентам страницы в кодах Java Server Page, и может обслуживать приложения Java EE (Java Enterprise Edition).
- Oracle WebLogic
Сервер Oracle WebLogic – сервер для распределённых приложений с использованием стандартов Java EE. Он полностью интегрирован с продуктами и облачными сервисами Oracle.
- Glassfish
Glassfish – сервер приложений с открытым кодом на Java EE, который поддерживает Java-сервлеты, а также спецификацию написания и поддержки серверных компонентов с бизнес-логикой EJB (Enterprise JavaBeans).
- JBoss
JBoss – сервер приложений с открытым кодом для создания, развёртывания и хостинга приложений на языке Java. JBoss может работать на разных платформах и в любой операционной системе с поддержкой Java.
Какой сервер приложений будет наиболее подходящим?
Знание различий между сервером приложений и веб-сервером помогает выбрать сервер для того или иного использования.
- Если нужно обслуживать только веб-страницы со статическим контентом, то лучше использовать веб-сервер;
- Если приложения требуют наличия JSP (JavaServer Pages) и сервлетов, лучше использовать простой сервер приложений, типа Jetty или Apache Tomcat;
- Если приложения содержат много сложных функций, таких как распределённые транзакции и мессенджеры, то лучше использовать полнофункциональные серверы приложений, такие как JBoss или Oracle WebLogic.
Другим подходом может быть добавление функционала в веб-сервер при помощи плагинов. В этом случает, веб-сервер может использовать технологию программирования на стороне сервера (server-side), такую как скрипты CGI, JSP, сервлеты, ASP (Active Server Pages) или JavaScript на стороне сервера.
Использование обоих типов сервера в одной системе
Часто и веб-сервер, и сервер приложений, развёртывают в одной системе. Это даёт возможность предоставлять клиентам как статический, так и динамический контент. В этом случае, веб-сервер становится подсистемой сервера приложений и все их сервисы работают на одной и той же программно-аппаратной платформе.
Преимуществом такого подхода является более высокая производительность системы. В каждом типе сервера максимально используются их преимущества. Простые веб-запросы будут сразу же обрабатываться веб-сервером и при этом не будет снижаться производительность сервера приложений.
Например, на сайте Интернет-магазина должна предоставляться информация о ценах в реальном времени. Обычно на сайте также есть форма для приобретения товара. Когда пользователь посылает запрос, веб-страница магазина ищет актуальную цену и выдаёт результат в виде HTML-страницы. Эту функциональность можно обеспечить как при помощи сервера приложений, так и при помощи веб-сервера с соответствующими плагинами. Возможно несколько сценариев.
Сценарий 1. Использование только веб-сервера с плагинами
Веб-сервер предоставляет функционал Интернет-магазина:
- Сервер получает запрос и передаёт его в соответствующую программу на стороне сервера;
- Эта программа ищет актуальные цены в базе данных или в обычном файле;
- Программа формулирует ответ в форме HTML;
- Веб-сервер посылает запрос обратно в веб-браузер клиента.
Сценарий 2. Использование как веб-сервера, так и сервера приложений
Сервер приложений хранит бизнес-логику для поиска цены. Веб-сервер делегирует ему генерацию ответа, скрипт вызывает сервис поиска в сервере приложений, и затем формулирует ответ HTML.
Размещение логики поиска цены в сервере приложений позволяет использовать её различными частями приложения. В первом сценарии сервис поиска цены не может повторно использоваться, поскольку данные встроены в HTML-страницу.
Рис. 3. Использование как веб-сервера, так и сервера приложений.
Заключение
Пересечение функций веб-сервера и сервера приложений означает, что каждый сценарий применения может иметь несколько решений. Можно применять веб-серверы и серверы приложений отдельно, а можно использовать их комбинацию.
Однако, не каждая конфигурация будет равноценной по параметрам работы и потреблению ресурсов, хотя и будет выполнять возложенные на неё функции. Знание различий между двумя типами серверов поможет сэкономить средства, облегчить масштабирование системы и повысить производительность.
Что такое сервер приложения
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Поднять его на сервере приложения
Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.
Что это такое и зачем он нужен
Жила была Анечка. Она пекла вкусные кексики и тортики на заказ. Чтобы удобнее было делать заказ, решила Анечка сделать свой интернет-магазин. И обратилась за помощью к брату, разработчику Ване.
Ваня говорит:
— Да не вопрос!Он как раз занимается фриланс-заказами с простыми системами типа интернет-магазинчиков. Поэтому он быстренько написал код на php. Но код — это просто набор файликов с расширением .php.
А как сделать так, чтобы у нас в интернете появилась страничка? Для этого нужен сервер приложения. Ваня для магазинчика выбирает apache (Apache HTTP Server), как наиболее популярный.
Мои тестовые системы:
— Users
— ShopТоже подняты на Apache. И написаны на php, то есть не требуют сборки))
Сервер обеспечивает возможность обращаться с приложением по HTTP-протоколу. Вы, конечно, можете и сами написать такой код, но зачем? Когда для этого уже есть готовая система. Причем бесплатная и open-source.
Положили код PHP в сервер. Запустили — вуаля, оно работает! Теперь у Анечки есть свой интернет-магазин, доступный извне, с любого устройства.
Если бы код был не на PHP, а на Java, у нас добавился бы шаг «собрать проект» — из набора текстовых файликов получить приложение. Обычно это архив, например, test.war. И уже его мы подкладываем в сервер. Ну а PHP — интерпретируемый язык. Ему не нужен сборщик.
Конечно, пока сайт доступен только по его IP. Чтобы это исправить, Анечке нужно выбрать доменное имя и купить домен. И тогда уже будет красивое название:
Вот теперь точно все готово!
Использование сервера приложений помогло Ване сконцентрироваться именно на бизнес-логике программы, не отвлекаясь на детали обеспечения транспортного пути. Ведь сервер приложения — это подобранный набор согласованных по версиям инфраструктурных библиотек. Например, http-сервер, который умеет принимать запросы.
Преимущества серверов приложений
Готовый HTTP-сервер
Пожалуй, самая важная и популярная функция сервера приложений — поддержка HTTP-сервисов и текущих HTTP-стандартов. Зайдите на любой сайт в интернете — фактически вы отправляете HTTP-запрос в приложение:
Открой мне страницу гугла
Покажи еще больше видео с котиками
Да, можно написать обработку запросов самостоятельно. И следить за стандартами, постоянно обновлять код. Но зачем, когда есть готовый сервер?
Для небольших проектов хватает HTTP-сервера, без дополнительных функций и плюшек. На текущий момент самый популярный сервер — Apache HTTP Server. Есть и более сложные сервера, например, Wildfly. Они имеют больше функций и используются в энтерпрайз системах.
Систему Users мне делал фриланс разработчик. Она написана на PHP и поднята на сервере Apache.
А на работе у меня на одном из проектов был enterprise продукт.. Написан на Java, поднимается на сервере Wildfly.
Поддержка горячего резерва
Если упал сервер, то есть испортилось 1 звено в клиент-серверной архитектуре — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Открываешь сайт в интернете и грустно смотришь на окно «Простите, что-то пошло не так»
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Сервера в кластере называются нодами. На каждой ноде (железке) стоит свой wildfly (или аналог). Когда приходит запрос на одну ноду, она оповещает об этом вторую, третью, четвертую, или сколько их там будет.
Каждая нода может обработать запрос независимо. Если приложение имеет какое-либо состояние, то оно может быть сохранено в общую БД. А также ноды могут оповещать другие ноды об изменении состояния через очереди/топики.
Такая схема называется горячим резервом — когда у нас есть несколько работающих в параллели серверов. Может быть и схема холодного резерва, когда второй сервер у нас «на всякий случай», а не для постоянного использования.
Но какой бы ни был резерв, фишка в том, что синхронизацией занимается сервер приложения, а не разработчик. У разработчика не болит голова о том, как бы данные на разных серверах не разъехались. Он может сосредоточиться на бизнес-логике системы.
Централизованная настройка и управление
В сервере приложений обычно есть админка. Заходишь по специальному URL — и у тебя есть доступ к настройкам приложения. Вот так выглядит приветственная страница админки wildfly:
Если у вас несколько серверов приложения, то изменение настроек может быть опасным занятием. Одну ноду (сервер) обновили, вторую забыли, а потом ловим баг.
Но так как сервер поддерживает работу в кластере, то все упрощается:Мы меняем настройки в админке.
Они сами расползаются по всем нодам.
Безопасность
В больших бюрократических компаниях разделяют разных админов:
админ физического сервера (железка, на которой установлено ПО)
админ сервера приложений (например, wildfly)
Так вот, админу приложения дают доступ только в админку wildfly. Физически на сервер он зайти не может, или может, но на птичьих правах, логи почитать. А если нужно параметры системы изменить — извольте заводить заявку для админа железяки.
Так безопаснее, когда у тебя нет лишних прав. Иначе неопытный админ системы может наворотить дел, разгребай потом за ним. Поэтому чем больше контора, тем важнее иметь возможность разделить права. Сервер приложения позволяет это сделать: OS отдельно, приложение отдельно.
Поддержка транзакций
Сервер поддерживает поддержку XA транзакций — когда несколько транзакционных источников поддерживают распределенную спецификацию, и сервер ее координирует.
Например, что-то записали в БД и послали сообщение по JMS, всё в одной транзакции, вот сервер приложений предоставляет в том числе менеджера распределенных транзакций.
Фишка всё та же — пока сервер приложений выполняет массу инфраструктурного кода, разработчики могут сфокусироваться на бизнес-логике.
И наверняка есть что-то еще
Я честно пыталась выведать у знакомых разработчиков, зачем вообще сервер приложения нужен.
Оказалось, что он, в общем-то, и не особо нужен. Ну разве что как HTTP-сервер, хотя и для этого уже есть готовые библиотеки, можно в коде это все делать и запускать условный Main.java, без всякого дополнительного сервера.
На работе в одном из проектов мы использовали wildfly. Он дает кучу возможностей, но по факту мы использовали:
• HTTP-сервер — а куда же без него?
• Datasource — файл, где прописывается соединение с БД
• MQ-очереди — для горячего резерва, синхронизация нод между собой. Один сервер уведомляет другой об изменениях. Если другой сервер пока занят, то это сообщение встает в очередь.Вот и всё!
Иногда сервер приложений используется просто потому, что так принято. Например, все старые приложения поднимались на Jboss, ну и новые тоже требуют делать на нем же. Потому что админы умеют работать именно с ним.
Или безопасники требуют разграничить доступ. Или по другим причинам используется именно этот сервер приложения, а не какой-то другой.
При этом я уверена, что в каких-то компаниях используют сервер приложения на полную катушку. И что в разных серверах есть еще куча разного полезного функционала, который вы могли бы написать сами в коде, но. Зачем? Когда вот оно, готовое.
Можно обойтись и без сервера. Да. Но с ним удобнее =)
Другие определения сервера
Когда вы разговариваете с коллегами, очень важно, чтобы вы говорили на одном языке!
Поэтому учтите, что под сервером приложений могут понимать разные вещи:
Сервер приложения как ПО — Apache, Wildfly, и другие. Та программа, которая запускает ваше приложение.
Физический сервер — компьютер, на котором установлен wildfly
Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено в трехуровневой клиент-серверной архитектуре (3-tier)
Тут сервером называется именно программа. А вот другое определение:
Сервер приложений это набор физического и программного обеспечения, которое способно обеспечить доступ клиентов к программам, выполняющихся непосредственно на серверном оборудовании.
Тут уже сервером называют не только программное обеспечение, но и физический сервер.
Так что если сомневаетесь, что вы с собеседником говорите об одном и том же, лучше уточнить, что он имеет в виду!
Дополнительные материалы
Итого
Сервер приложения — это ПО, которое запускает ваше приложение. Сначала разработчик пишет код, потом собирает билд сборщиком. Но это просто некий архив с кодом. А вот чтобы это стало доступной в интернете ссылочкой, и нужен сервер приложения.
Сервер берет на себя скучную инфраструктурную работу. Например, организацию HTTP-уровня OSI. Он принимает запросы и обрабатывает их по всем стандартам. А разработчик может сконцентрироваться на бизнес-логике, не отвлекаясь на детали обеспечения транспортного пути.
Что такое сервер приложения?
Из всего прочитанного в интернете мне удалось понять, что существуют 2 вида серверов: статические и динамические. Статические сервера включают в себя "сервер-железо" и "сервер-ПО", которое работает с HTTP и URL. Динамические сервера содержат все то, что содержат статические + сервер приложения и базу данных. Вся инфа отсюда.
То есть по сути динамический сервер называется таким из-за работы сервер приложения, который может изменять файлы, передаваемые по HTTP, налету.
У меня возник вопрос. Получается, что сервер приложения — это какой-то код, который позволяет обрабатывать файлы. Но судя по этой цитате, это не совсем так (вряд ли код может содержать веб-сервер):
Сервер приложений может содержать веб-серверы, поэтому он считается более мощным, чем веб-сервер.
Здесь мне скорее всего не понятно само строение или структура этого сервера приложения. Для чего и каким образом он содержит этот веб-сервер?
Также не понятна эта фраза:
Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (интерфейс прикладного программирования), определённый самой платформой.
Получается, что если API поддерживает взаимодействие 2-ух программ, то в этом случае API может поддерживать взаимодействие между сервером приложения и какой-то любой другой программой. А всегда ли API поддерживает работу с сервером приложений, API работает только с сервером приложений?
я рискну ответить на вопрос, хотя, скорее всего, это не будет полным и законеченым ответом.
Мне кажется, что то непонимание, которое у Вас есть, происходит от обилия терминов и их "исторического напластования"
То, что Вы называете "статическиие и динамические сервера" — обычно, мне кажется, называется "статическим контентом" и "динамическим контентом".
то, что в тексте назывется серверами приложений — нужно понимать просто как "веб сервер без морды", как бы грубо это ни звучало. Это — программа, которая по HTTP принимает запросы и по HTTP же отвечает. Обычно это называют REST — протоколом (Representational state transfer)
Еще один распространённый термин для "серверов приложений" — это "веб-служба".
А всегда ли API поддерживает работу с сервером приложений?
Сам термин "сервер приложений" — это некая историческая шелуха.
Поясню свою мысль. На этапе зарождения WEB’а возможности написать файл с гиперссылками и отдавать его в примитивный браузер типа мозаики в общем всем хватало.
Но хотелось "динамики" например, счетчика числа посетителей на странице. Для этого использовался CGI (Common Gateway Interface).
Фактически, это означало, что в ответ на запрос из браузера на сервере выполнится программа, и результат её выполнения будет показан в браузере.
Чтобы "хорошо продавать" эту возможность ( а веб-сервера были не только бесплатными open source, но иногда и очень даже платными, типа Microsoft IIS и IBM WebSphere ) — был придуман маркетинговый термин "сервер приложений".
Который означал не более и не менее, чем возможность в ответ на запрос пользователя выполнить некий код, который на этот запрос ответит. В этом была разница с сервером, который умеет только "тупо хостить файлы"
Далее — под API, наверное, следует понимать "взаимодействие по заранее согласованному протоколу", но применительно к HTTP — серверам это в 99% случаев следует читать как REST API.
Объясню на примере. Пускай у меня есть база данных с ценной информацией.
Я могу сделать веб — сервер, который на своих страницах будет показывать эту информацию по запросам пользователя.
А могу предоставить интерфейс к своей базе данных, и многие — многие сервера в интернете начнут показывать эту информацию на своих страницах, обращаясь за самой информацией ко мне. По API. При этом у меня может вообще не быть "веб сервера, на котором есть страницы для просмотра посетителями".
Я надеюсь, что я смог — в этом коротком ответе — помочь Вам разобраться в терминах. Но если есть уточняющие вопросы — пишите!
Дополнение
я перечитал Ваш вопрос, и решил немного дополнить ответ вот в какой части:
Сервер приложений может содержать веб-серверы, поэтому он считается более мощным, чем веб-сервер.
Здесь мне скорее всего не понятно само строение или структура этого сервера приложения. Для чего и каким образом он содержит этот веб-сервер?
Я попытаюсь "на пальцах" рассказать, что имется в виду. Для этого посмотрим на стуктуру того, что вообще есть во всех этих серверах.
Есть программа, которая реализует HTTP — протокол. Она просто умеет получать HTTP-запрос и в ней есть модуль, который пытается на это запрос ответить.
Обычно эту программу просто "привязывают" к файловой системе WEB-сервера, и "модуль отвечания" работает по такому алгоритму: "К тебе пришел запрос? Посмотри, есть ли на диске файл, название которого соответствует запросу. Если есть — выдай этот файл в ответ на запрос, если нет — покажи страницу с 404-й ошибкой". Это — то что называется "статический контент", или "статический сервер" (как бы не передёргивало меня от этого термина)
Что такое "динамический сервер"? Это когда "модуль отвечания" в программе, которая обслуживает запросы, учат еще одному фокусу: ". а вот если к тееб придёт запрос определенного вида — то вместо отдачи файла пользователю выполни вот эту программу, и отдай пользоваетлю результаты её выполнения".
вот именно в этом смысле "Сервер приложений может содержать веб-серверы" — они имеют в виду, что, для того, чтобы принять запрос и отправить ответ — нужен модуль работы с HTTP протоколом, и называют его "веб-сервер". В этом смысле "динамический сервер" собержит "веб-сервер" в своём составе.
англ: serve — служить; +er —> server — тот, кто обслуживает.
Простыми словами "сервер" это то, что обслуживает (исполняет) запросы. Исполнитель.
Исполнитель (сервер) — это приложение. Однако этим же "словом" также называют железо на котором работает это приложение(-я). Да, на одном железе (сервере) могут быть запущены несколько приложений (серверов).
Деды от "айти" не перевели, в своё время, теперь вот такие вопросы.
Далее по наследию от дедов.
"Статичный, статический"
англ (прил): static — неподвижный.
"Динамичный, динамический и прочее динамо-"
англ (прил): dynamic — действующий, работающий, живой.
англ: web — паутина, сеть.
Соединяем всё до кучи.
Веб-сервер — исполнитель, который обрабатывает сетевые запросы, созданные по тем или иным правилам (договорённостям) (англ: protocol): TCP/IP, HTTP и т.д.
Сервер-приложений — исполнитель, на котором выполняется какое-либо прикладное приложение.
Статический-сервер — исполнитель, который также является ещё и веб-сервером, в задачи которого входит выдать те или иные данные, которые уже имеются у него. Т.е. ничего нового он при обращении к нему не создаёт. Например, у него есть набор изображений, вот, при обращении к нему, он и будет выдавать лишь эти изображения.
Динамический-сервер — исполнитель, который может быть веб-сервером, а может и не быть им, но в любом случае он является сервером-приложений. Если с ним можно общаться по сети, то значит это веб-сервер, если его задача, например, просто вычислять простые числа, то для этого никакой веб не нужен.
Ну и несколько слов про API исполнителя приложений.
К примеру, возьмём самовоз (англ: auto- (само-); mobile (подвижный)). У него есть рычаг переключения передач. Так вот допустимые положения для этого рычага являются API, т.е. способами для переключения передач, которые предоставлены разработчиками самовоза для этих нужд.
Наглядно положения передач можно описать так:
- 1-я: /влево/вверх
- 2-я: /влево/вниз
- ..
- 5-я: /вправо/вверх
- Задняя: /вправо/вниз
Для исполнителя приложений всё тоже самое. Есть набор мест (положений) при обращении к которым (с указанием дополнительных данных, если это необходимо) будет выполнено то или иное действие этим самым приложением. Например:
создать заметку: /createArticle, /create-article, /создатьЗаметку, /заметку-создать (выбор названия всецело зависит от разработчиков приложений).