Качество может не соответствовать всяким stackoverflow, но мне всё равно. Итак, начнём с некоторых личных вещей, а именно: 1 — Данный материал написан трукодером, он сам вникает в эту архитектуру и собственно пытается донести что-то до аудитории.
2 — Здесь не будет примеров с конкретными ЯП.
3 — Если кто-то дочитал до этого пункта, благодарствую, надеюсь вам понравится. Визуализация «клиент-серверной» архитектуры С вашего позволения, я нарисую её в программе Adobe Photoshop(нам заплатили за рекламу)...
9 подписчиков
Сегодня речь пойдет об архитектуре клиент-сервер. С ней сталкивался каждый человек, использующий интернет.
Очевидно, что когда при нажатии на кнопку на условном сайте, ему приходит нужный ответ, то приходит он не сам, а кто-то его отправляет. Этот кто-то - сервер, а тот, кто кликнул по кнопке - клиент.
Теперь о том, что делает клиент. Все просто, отправляет запросы серверу, ждёт ответа, а как только ответ приходит, отображает его. Клиенты есть разные и функции у них различные, но об этом в следующем посте.
Кто такой сервер? Тот, кто обрабатывает запрос клиента. Хотя может работать не один, а в связке с базой данных(о том, что это и с чем её едят было рассказано в предыдущих постах). Сервер получает запрос клиента, отправляет запрос в базу данных, получает ответ оттуда, преобразовывает его, отправляет клиенту.
В нашей модели может быть несколько серверов или несколько баз данных. А на какой сервер отправлять запрос клиента мы узнаем от балансировщика, задача которого распределять нагрузку в зависимости от схемы. Есть две схемы: "холодный резерв" и "горячий".
Начнём с горячего. Допустим, у нас есть несколько клиентов, 2 сервера и балансировщик. Клиент отправляет запрос, балансировщик его получает, спрашивает у каждого сервера, у кого сколько задач и отдает запрос наименее загруженному.
С холодным ситуация та же, но в балансировщик всегда отдает запрос 1 серверу, а второй подключается, когда первый не работает или на обновлении.
Из всех этих частей и строится вся архитектура.
На сегодня всё, в следующий постах рассмотрим, какие виды клиентов существуют и чем они отличаются.
9 подписчиков
Продолжаем тему об архитектуре клиент-сервер.
Сегодня мы разберём такие понятия, как тонкий и толстый клиенты.
Начнём с теории.
Тонкий клиент - это такой вид клиентов, вычисления которого выполняются на сервере. Разберём на примере.
Допустим, вы заходите на страницу сайта, используя браузер. Без соединения с интернетом, она представляет из себя только текст и не способна включить музыку, видео, скачать файл или изображение и, даже не может перейти на другую страницу или обновиться.
Так вот, наш сайт - это тонкий клиент и без подключения к серверу он не способен на какое-либо взаимодействие.
Что такое толстый клиент?
Это вид клиентов, который способен выполнять вычисления на локальном устройстве пользователя.
В качестве примера можно привести игру, где однопользовательский режим(с ботом) доступен без интернета. Мы можем совершать какие-то действия, просматривать свои сохранения, а когда появится связь действия будут синхронизированы с сервером.
Плюсы и минусы.
Давайте рассмотрим плюсы и минусы тонкого клиента.
Плюсы:
• Минимальная нагрузка на клиента, а значит сможет работать на старых и слабых устройствах
• Простое обслуживание, так как на стороне клиента минимальная возможность ошибок
• Простота в внедрении обновлений. Достаточно обновить сервер и все клиенты сразу же получат все обновления
• Независимость от платформы
• Защита данных, так как на клиент поступают только "итоговые" данные
Минусы:
• Высокая нагрузка на сеть, так как вынуждены передавать много данных
• При ошибке или сбое сервера страдают все пользователи
• Не может работать без подключения к сети
• Стоимость сервера, качество оборудования должно быть высоким, так как все расчёты проходят на нём
А теперь рассмотрим сильные и слабые стороны толстого клиента.
Преимущества:
• Низкая нагрузка на сеть
• Более высокая скорость работы, так как вычисления проходят локально
• Возможность работаты без подключения к серверу
• Низкая нагрузка на сервер
Недостатки:
• Требования к железу у клиента
• Сложные обновления.
Необходимость в персональном обновлении для каждого клиента
• Зависимость от типа устройства и платформы
• Необходимость в техническом обслуживании для каждого клиента
• Устройство клиента имеет доступ к большому количеству данных, что может быть небезопасно.
Также существует третий тип, гибридный.
В нём вычисления лежат на клиенте и сервере равномерно.
Каждый из видов имеет свои области применения в зависимости от задачи.
отличаются.