Архитектура программного обеспечения — структура, на базе которой создается приложение, взаимодействуют модули и компоненты всей программы.
За создание хорошей архитектуры программисты взялись еще очень давно, поэтому неудивительно, что сейчас нам известно немало архитектурных шаблонов. Разбираться в них нужно: когда пишешь веб-приложение, проблема архитектуры становится острой, ведь в ней компонентов и модулей больше, чем в обычном приложении.
Архитектурный шаблон — это уже придуманный способ решения какой-то задачи по проектированию программного обеспечения.
Ты уже наверняка сталкивался с такими паттернами проектирования как фабричный метод (Factory Method), абстрактная фабрика (Abstract Factory), строитель (Builder), прототип (Prototype), одиночка (Singleton) и, возможно, другими. Они используются при простом написании кода, создании классов и планировании их взаимодействия.
Архитектурные шаблоны задействуют на более высоком уровне абстракции — при планировании взаимодействия пользователя приложения с сервером, данными и другими компонентами проекта. Давай сразу рассмотрим некоторые шаблоны и то, как их использовать.
Клиент-серверная архитектура
Из названия складывается впечатление, что с этой темой все просто и понятно. Но давай уточним кое-какие моменты, чтобы приступив к изучению условного Спринга ты точно понимал, о чем идет речь. Допустим, ты написал чат, и вы с приятелем начинаете его использовать. Здесь возможен простой вариант — вы отправляете сообщение друг другу напрямую через интернет по IP-адресам, которые вы знаете:
Поначалу может показаться, что все отлично работает, пока не появляется еще один ваш друг с вопросом: “А почему вы не добавите меня в свой чат?”.
И вот когда ты решаешь добавить общего друга в чат, ты сталкиваешься с архитектурной проблемой: каждому пользователю чата нужно обновить информацию о количестве пользователей, добавить IP-адрес нового юзера. А еще при отправке сообщения оно должно доставляться всем участникам. Это самые очевидные проблемы из тех, которые возникнут. Еще куча проблем будет спрятана в самом коде.
Чтобы избежать их, нужно использовать сервер, который будет хранить всю информацию о пользователях, знать их адреса. Сообщение нужно будет отправить только на сервер. А он, в свою очередь, разошлет сообщение всем адресатам. Когда ты решишь добавить серверную часть в свой чат, ты начнешь строить клиент-серверную архитектуру.
Составляющие клиент-серверной архитектуры
Давай разберемся, что она представляет из себя. Клиент-серверная архитектура — шаблон проектирования, основа для создания веб-приложений. Данная архитектура состоит из трех компонентов:
Клиент — из названия становится понятно, что это пользователь сервиса (веб-приложения), который обращается к серверу для получения какой-то информации.
- Сервер — место, где располагается твое веб-приложение или его серверная часть. Он владеет необходимой информацией о пользователях или может ее запрашивать. Также при обращении клиента сервер возвращает ему запрашиваемую информацию.
Сеть — все просто: обеспечивает обмен информацией между клиентом и сервером.
клиентского — содержит графический интерфейс для авторизации, отправки/получения сообщений;
серверного — веб-приложение, которое размещается на сервере и принимает сообщения от пользователей, обрабатывает их, а потом отправляет адресатам.
Когда мы хотим посмотреть полезную (или не очень полезную) информацию в интернете, мы открываем браузер, в строке поиска вводим запрос, и в ответ получаем информацию от поисковика.
В этой цепочке браузер — это наш клиент. Он отправляет запрос с информацией о том, что мы ищем, серверу. Сервер обрабатывает запрос, находит наиболее релевантные результаты, упаковывает их в понятный для браузера (клиента) формат и отправляет назад.
В таких сложных сервисах как поисковики серверов может быть много. Например, сервер авторизации, сервер для поиска информации, сервер для формирования ответа. Но клиент об этом ничего не знает: для него сервер является чем-то единым. Клиент знает только о точке входа, то есть, адресе сервера, которому нужно отправить запрос.
Вспомним о приложении, которое мы рассматривали в предыдущей части — для мониторинга средней температуры воздуха во всех странах в режиме реального времени. Его архитектура будет выглядеть примерно так:
Наше приложение располагается на сервере. Скажем, каждые пять секунд оно отправляет запросы на серверы локальных гидрометцентров, получает у них информацию о температуре в конкретной стране, сохраняет эту информацию. Когда клиент обращается к нам с запросом “посмотреть текущую температуру воздуха в мире”, мы возвращаем последнюю сохраненную информацию, рассортированную по странам.
Таким образом наше приложение одновременно и сервер (когда обрабатывает запросы юзеров), и клиент (когда получает информацию у других серверов).
| Важно: понятие сервер — не о конкретном компьютере, а о взаимоотношениях абонентов сети. |
Трехуровневая архитектура
Это архитектурный шаблон, в котором появляется третий участник — хранилище данных. При использовании этого шаблона, три уровня принято называть слоями:
Клиентский слой — интерфейс пользователя. Это может быть веб-браузер, которому отправляются HTML-страницы, или графическое приложение, написанное с помощью JavaFX. Главное, чтобы с его помощью пользователь мог отправлять запросы на сервер и обрабатывать его ответы.
Слой логики — сервер, на котором происходит обработка запросов/ответов. Часто его еще называют серверным слоем. Также здесь происходят все логические операции: математические расчеты, операции с данными, обращения к другим сервисам или хранилищам данных.
Слой данных — сервер баз данных: к нему обращается наш сервер. В этом слое сохраняется вся необходимая информация, которой пользуется приложение при работе.
Преимущества трехуровневой архитектуры
Используя такую архитектуру, мы получаем немало плюсов, среди которых:Возможность построить защиту от SQL-инъекций — это атака на сервер, при которой передается SQL-код, и при выполнении этого кода злоумышленник может воздействовать на нашу базу данных.
Разграничение данных, к которым мы хотим регулировать пользовательский доступ.
Возможность модифицировать данные перед отправкой клиенту.
Масштабируемость — возможность расширить наше приложение на несколько серверов, которые будут использовать одну и ту же базу данных.
Меньшие требования к качеству соединения пользователя. Формируя ответ на сервере, мы часто берем из базы данных много различной информации, форматируем ее, оставляя только то, что нужно юзеру. Таким образом мы сокращаем объем информации, который отправим в качестве ответа клиенту.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ