![](https://habrastorage.org/getpro/habr/upload_files/2e5/bf4/dfb/2e5bf4dfb2e9342cd6e0edca0eb8596e.jpg)
Lyosik | Ведущий системный аналитик (SA Lead)
Добро пожаловать в блок статей для начинающих системных/бизнес аналитиков. Здесь мы готовимся к получению заветного оффера вместе
Сперва давайте обратимся к всея знаний - великому Интернету и узнаем, что за зверь такой эта клиент-серверная архитектура.
Итак, как гласит гугл
Клиент-серверная архитектура — это модель взаимодействия в компьютерной сети, где задачи распределены между двумя основными компонентами: клиентами и серверами.
Отсюда понятно, что нам надо разобраться с двумя новыми понятиями: клиент и сервер. Let's go.
Клиент - это устройство на стороне пользователя, которое отправляет запрос к серверу для предоставления информации или выполнения определенных действий.
Сервер - это более мощный компьютер или оборудование, предназначенное для решения определенных задач по выполнению программного кода, сервисных функций по запросу клиентов, предоставления пользователям доступа к определенным ресурсам, хранения информации и баз данных.
Двухуровневая архитектура
Самый простой пример клиент-серверной архитектуры — Двухуровневая архитектура. Схематично такая архитектура представлена ниже.
![](https://habrastorage.org/getpro/habr/upload_files/117/7f0/3b8/1177f03b84a1b8e1a078c7bf5a1b4ac0.png)
Особенность такой архитектуры в том, что сервер хранит все данные в памяти. Но если сервер упадет или просто перезагрузится, вся информация будет потеряна. Все, что было в памяти, стирается при выключении системы. А это является недопустимым с точки зрения бизнеса.
![](https://habrastorage.org/getpro/habr/upload_files/6a8/429/8a5/6a84298a564cbf23642f7bd257070bcc.png)
Трехуровневая архитектура
На текущий момент все же больше распространена трехуровневая или многоуровневая архитектура. *Перемещаем взгляд на картиночку ниже*
![](https://habrastorage.org/getpro/habr/upload_files/dd0/e30/e15/dd0e30e159518bb40451632c67980df9.png)
Плюсы и минусы клиент-серверной архитектуры
Плюсы
Мощный сервер дешевле 100+ мощных клиентских машин.
Нет дублирования кода. Основной код хранится на сервере.
Персональные данные в безопасности. Простой пользователь не видит лишнего.
Минусы
Упало одно звено - ничего не работает. Если упал сервер или отвалилась база данных, то есть поломалось 1 звено, все клиенты отдыхают.
Но решение этой проблемы существует.
В бизнес-критичном ПО архитектуру усложняют и даже дублируют. Крупная компания не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
![](https://habrastorage.org/getpro/habr/upload_files/fbe/b51/f28/fbeb51f28fee0efca205becdd2ea8b92.jpg)
Итак, мы подошли к важной теме. Запасаемся горячим чаем и поехали.
Распределение трафика
Сервер может обрабатывать огромное количество запросов от разных пользователей. То есть клиентов может быть много, а если им нужно обменяться информацией между собой, делать это придется через сервер. Таким образом, сервер получает еще одну дополнительную функцию - контроль трафика.
Запоминаем новое понятие:
Балансировщик нагрузки — это специальное устройство или программа, которая распределяет входящий трафик (запросы) между несколькими серверами.
Балансировщик может быть размещен до (на фронтэнде) или после (на бэкенде) серверов в зависимости от архитектуры системы.
![](https://habrastorage.org/getpro/habr/upload_files/211/ba7/4c6/211ba74c6893c3da6733d69b6eb8833b.png)
Для балансировщика на серверах существуют такие понятия как горячий и холодный резерв.
Горячий резерв — когда у нас есть несколько серверов, работающих в параллель, и балансировщик распределяет нагрузку между ними.
![Пример горячего резерва Пример горячего резерва](https://habrastorage.org/getpro/habr/upload_files/9ec/385/d61/9ec385d61a2c144497302267b61d995e.png)
Холодный резерв — когда у нас второй сервер является резервной копией первого. Все запросы идут на первый сервер, второй в ожидании.
![Пример холодного резерва Пример холодного резерва](https://habrastorage.org/getpro/habr/upload_files/5e5/cad/d7f/5e5cadd7f72e33c7faf052ac0ff58c93.png)
Такс, с распределением трафика разобрались, делаем глоток чая *можно и свежего воздуха* и переходим к следующему разделу.
Толстый и тонкий клиент
В мире информационных технологий существует два основных подхода к построению архитектуры приложений — толстый клиент (Fat Client) и тонкий клиент (Thin Client). Оба подхода имеют свои уникальные характеристики, преимущества и недостатки, и их выбор зависит от конкретных требований и задач.
Для самых нетерпеливых суть этих клиентов такова:
В толстом клиенте основной функционал лежит на пользователе, в тонком — на сервере.
Ну а теперь разберем оба типа подробнее.
Тонкий клиент – это клиентское приложение, которое минимизирует логику и функциональность на стороне пользователя, делегируя большинство задач серверу. Он зависит от сервера для предоставления большей части функциональности.
![Иллюстрация тонкого клиента Иллюстрация тонкого клиента](https://habrastorage.org/getpro/habr/upload_files/e78/fc9/130/e78fc91301fc1e541a555c78b9cb0443.png)
Плюсы тонкого клиента:
Простота обновлений.
Легкость в управлении.
Разработка в приложении не нужна, достаточно бэкенда.
Минусы тонкого клиента:
Зависимость от сети.
Ограниченные возможности без подключения.
Толстый клиент представляет собой клиентское приложение, которое содержит значительную часть логики и функциональности непосредственно на стороне пользователя. Этот тип клиента активно взаимодействует с сервером, но при этом обладает значительной автономностью.
![Иллюстрация толстого клиента Иллюстрация толстого клиента](https://habrastorage.org/getpro/habr/upload_files/41d/068/0b1/41d0680b143bb9fb8c55f9f3b7eeb55f.png)
Плюсы толстого клиента:
Высокая производительность.
Возможность работы в автономном режиме.
Минусы толстого клиента:
Требует установки.
Обновления сложны.
Двойной объем разработки: и на бэкенде, и в приложении.
Нельзя реализовать ресурсоемкие вычисления.
Не все данные можно открыто передавать на клиент.
На практике, на самом деле, так же встречается еще один подход к построению архитектуры приложений – гибрид.
Гибрид – бэкенд может присылать на клиент и данные, и алгоритм, действий. Этот способ позволяет совместить достоинства обоих подходов за счёт добавления ещё одного слоя абстракции. Можно передавать с бэкенда и необходимые данные, и сам алгоритм вычисления нужных величин в некотором виде.
![Иллюстрация гибридного способа Иллюстрация гибридного способа](https://habrastorage.org/getpro/habr/upload_files/f4d/b5a/996/f4db5a996f4c1cb12d9cf255b55c3415.png)
А теперь пришло время поговорить про способы вызова сервера.
Асинхронные и синхронные вызовы
Но для начала капелька теории из нашего любимого гугла:
Вызов сервера — это процесс отправки запроса к серверу для получения данных или выполнения определенной операции.
Итак, существуют 2 способа вызова сервера:
Синхронный вызов. При синхронном вызове сервера, пока выполняется серверная функция, работа на клиенте останавливается. Как только она завершилась, продолжается выполнение работы на клиенте.
Асинхронный вызов. При асинхронном вызове работа идет параллельно.
Как мы понимаем, клиент и сервер должны как-то между собой взаимодействовать. Здесь перед нами возникнут новые понятия, такие как протоколы взаимодействия, интеграции, потоки данных. Но это достаточно объемный блок информации, который заслуживает отдельной статьи. К слову, в этой же отдельной статье мы разберем синхронные и асинхронные вызовы более подробно.
Ну и в завершение попробуйте ответить на следующие вопросы:
Какой клиент на ваш взгляд предпочтительней и почему?
Какой клиент выбрать для игры, соц.сети, банковского приложения?
Подсказка
В толстом клиенте много лишних форм. Элемент создается, даже если он не виден.
Ответы можете написать в комментарии, вместе обсудим :)
Limansky
Интересно было освежить память. Что касается вопроса, то отвечу так, как я это вижу.
1. Это в большей степени зависит от той задачи, которую будет выполнять и клиент и сервер.
2. Тут выберу так. Для игры - толстый клиент (хотя сейчас в природе есть и сервера с GPU то можно и гибрид выбирать). Соц.сетей - толстый клиент. Банковского приложения - тонкий ( но тут нужно уточнять для какого именно и что от него требуется, если автономность (когда нет сети) то гибрид или толстый клиент.