на каком компьютере происходит работа с базой данных в архитектуре клиент сервер
Клиент-серверная архитектура в картинках
Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.
На клиент-серверной архитектуре построены все сайты и интернет-сервисы. Также ее используют десктоп-программы, которые передают данные по интернету. Поэтому ИТ-специалисту нужно понимать, что это такое и как работает.
Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
Содержание
Что это и как работает
Вот есть у нас некий Вася, который решил купить машину. Такую, как в рекламе — быструю, мощную, красивую! Только стоит она как хвост самолета, у Васи таких денег нет.
Конечно, Вася может подкопить несколько лет, а потом уже покупать машину. Но ведь хочется здесь и сейчас! Да и средство передвижения нужно…
А еще Вася не умеет копить — получил зарплату, закупился основным, оплатил жилье, всё! Остальное можно потратить. Для таких людей есть банки, куда можно прийти и взять деньги в кредит.
Конечно, потом вы будете переплачивать, возвращая их назад. Проценты-то конские. Но зато уже сейчас можете позволить купить себе что-то дорогое.
Вася подумал, прикинул и сказал:
— Да, хочу именно так! 100 рублей с зарплаты платить в банк могу, а откладывать — нет. Потрачу.
Поэтому Вася идет в банк и говорит:
— Я Василий Иванов, хочу автокредит на 1000р.
У Кати есть специальная программа для проверки данных по клиентам. Эта программа может быть как web, так и desktop:
Катя вбивает в программу «Василий Иванов» и получает информацию по клиенту — есть ли он в черных списках? Была ли кредитная история раньше? И так далее. Но что происходит в потрохах приложения?
Катя ввела данные на клиенте. Но когда она нажала «проверить», клиент отправил запрос на сервер:
— Дай мне информацию по Васе Иванову!
Сервер отправил запрос в БД, базу данных:
— Select * from clients where fio = ‘Василий Иванов’. (Дай мне всю информацию по ФИО ‘Василий Иванов’)
— Вот тебе все, что нашла.
Сервер вернул эту информацию клиенту:
А клиент уже отрисовал ее для Кати:
— Ага, кредитная история хорошая.
И делает предложение Васе:
— Пожалуйста, если хотите взять кредит, то мы готовы выделить 1000р на 12 лет под 80% годовых. Устроит?
— Да, меня всё устраивает, давайте скорее деньги, и я побежал за машиной!
Все счастливы, все довольны.
Катя даже не догадывается, какой путь проделали данные в программе, когда она вбила туда ФИО своего клиента. Но мы с вами должны узнать, что же это за путь такой? И к чему все эти сложности? Почему именно такая структура? Почему есть клиент, почему есть сервер?
Зачем нужен клиент
Тут все просто — с клиентом работает пользователь. Он нужен, чтобы превратить байтики программного кода в красивую и понятную картинку. Пользователь — не программист, он не понимает язык программирования или sql. Он понимает формочки и кнопочки. Их в клиенте и рисуем.
Зачем нужен сервер
Клиентов может быть много. В примере с банком у нас может быть по 10 отделений в 10 городах России, а в каждом отделении по 10 операционисток. Тысяча Катек, и у каждой отдельный компьютер.
А мы ведь хотим, чтобы приложение работало быстро. Чтобы оно не тупило и не зависало, нервируя операциониста и заставляя клиента ждать. Значит, машина нужна мощная. Но если делать мощным каждый компьютер операциониста, денег придется вложить очень много!
Поэтому мы выносим всю основную логику на сервер. И вот его уже делаем мощным! А клиентские машины могут быть дешевыми, потому что на них остается лишь логика в стиле «запросить информацию и красиво отрисовать».
Нет дублирования кода
Если бы у нас были только клиентские машины, на каждой из них хранился бы одинаковый код по обработке логики, лежала вся база данных, все справочники террористов и прочая. Но так как сервер и БД вынесены в отдельные звенья, с клиентской машины освобождается куча места… И кода.
Не надо дублировать код, ведь вся основная логика вынесена на более мощный сервер.
На сервере и в базе хранится информация, недоступная простому операционисту. Это:
Есть операционисты, готовые за денюшку слить информацию о клиентах. Есть нечистые на руку люди, готовые невзначай заглянуть через плечо. А, может, клиент сам такой человек. Представляете, отпихивает Вася хрупкую Катю, садится за ее компьютер, и переводит себе на счет миллионы, пока его не повяжет охрана.
Зачем нужна база
При чем же тут БД? Вот у нас есть наш сервер, пусть он и хранит всю информацию. Бывает и так, иногда база просто не нужна и у нас остается двузвенная архитектура клиент-сервер.
В таком случае все данных сервер хранит в памяти. Вот только если сервер упадет, или просто перезагрузится — вся информация будет потеряна. Все, что было в памяти, стирается при выключении системы.
БД (база данных) — отдельный программный продукт, который позволяет:
Да, базы может не быть. Но когда она есть, мы уверены в сохранности данных и легко можем по ним поискать.
Плюсы архитектуры
Резюмируем плюсы архитектуры:
Минусы архитектуры
Упало одно звено — все отдыхают
Если упал сервер или отвалилась база, то есть испортилось 1 звено — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Все операционистки грустно смотрят на окно «Простите, что-то пошло не так» и разводят руками перед клиентом.
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Как в таком случае клиент понимает, куда ему отправлять запрос?
Перед серверами ставят балансировщик, и клиент шлет запрос туда. Сколько бы серверов не поставили в кластер, клиенту это не интересно. У него есть один URL — адрес балансировщика.
И вот с клиента поступает запрос:
— Дай мне всю информацию по Васе Иванову.
— Ребята, новый запрос! Кто меньше загружен?
— У меня 5 запросов в очереди стоит.
Балансировщик отправляет запрос второму серверу.
Такая схема используется для высоконагруженного приложения — когда запросов поступает так много, что один сервер с ними просто не справляется.
Facebook, amazon, google — туда заходят миллионы пользователей. Один сервер с ними не справится. Поэтому ставят кластер, а балансировщик делит между ними нагрузку. И в таком случае в кластере может быть не 2 сервера, а 10, 15, сколько нужно, столько и ставим.
При этом мы можем точно также балансировать базу данных. У нас может быть несколько копий баз данных на самых разных машинах, и балансировщик отправляет запросы то к одной, то ко второй.
Такая схема называется горячий резерв — когда у нас есть несколько серверов, работающих в параллель, и балансировщик распределяет нагрузку между ними.
При этом может быть и схема холодного резерва — когда у нас второй сервер является резервной копией «на всякий случай». Все запросы идут на первый сервер, второй отдыхает.
Но если с первым сервером что-то случится и он помрет, балансировщик перенаправит нагрузку на второй сервер:
В это время у администраторов будет время разобраться с проблемой на сервере 1.
Схема холодного резерва используется тогда, когда один сервер способен выдержать нагрузку и выдавать хорошую скорость работы. Но приложение при этом бизнес-критичное и простой неприемлем.
Простой может быть не только потому, что случилось что-то плохое. Есть еще штатное обновление приложения. Обе схемы резервирования позволяют обновляться безболезненно. Если в кластере два сервера, обновление будет выглядеть так:
Таким образом, схемы резервирования помогают нам устранить проблему «упало 1 звено — все отдыхают». Клиент никогда не узнает, что один или несколько серверов в кластере сдохли, у него всё как работало, так и работает.
Высокая стоимость оборудования
Сервера стоят дорого. Туда нельзя поставить обычный SSD как для домашнего компьютера. Почему? Потому что к железу для серверов совсем другие требования по надежности + есть поддержка специфичных функций:
— у HDD это специальная микропрограмма контроллера, которая оптимизирована для работы диска в RAID, дома это не нужно.
— у SSD это наличие группы конденсаторов, которые хранят энергию на случай отключения питания, чтобы хватило времени скинуть из DDR кэша данные в энергонезависимую память и данные не побились.
SSD — быстро работающий диск, HDD — обычный. RAID — когда мы N дисков вместе соединили, а DDR кэш — это оперативная память
Плюс у серверных решений гарантия обычно гораздо дольше: 5 лет, а не год.
По цене отличаются в 2 раза. Например, SSD:
Вроде не сильно отличается, да? Но смысл в том, что для дома 1 тб хватает за глаза — и фоточки все влезут, и кино, и куча приложений… А для базы данных иногда и 10 тб будет мало. А если делать кластер, то умножаем стоимость на 2, если не больше. Поэтому и разница в цене кажется огромная, но при пересчете на гигабайт небольшая выходит.
Не забывайте, что дома вам просто надо свои фоточки держать, да и те обычно в облаке. А на сервере бизнес-критичный функционал, который жрет дофига ресурсов и который надо дублировать на случай «вдруг первый сдохнет».
Нужно нанять сисадмина ツ
Нам нужно нанять сисадмина, который будет следить за всеми нашеми серверами приложения и БД. Добавляем его зарплату к стоимости оборудования!
Что тестировать
Чтобы понимать, что тестировать, надо понимать, с чем имеет дело человек.
Пользователь работает с клиентом. Это может быть web или desktop приложение, не суть. Операционистке Кате дали рабочее место, показали какую программу запускать и как с ней работать. Она знать не знает о наличии серверов и БД, она работает только с клиентом.
Поэтому тестировщик в первую очередь проверяет клиент! Потому что сервер может работать идеально, вы можете даже написать тесты на уровне API и они все будут зелененькие, и кажется, что все зашибись! А пользователь загрузит отчет и увидит ошибку. Ой.
Сервер работает, на клиенте ошибка. И плевать на сотни «зеленых» автотестов. У пользователя все равно ошибка. И наша задача — посмотреть с его точки зрения.
Однако, если у вас есть доступ к серверу приложения и его базе данных — стоит проверять и их тоже! Так мы можем увидеть «будущий баг». Например:
— Ну, наверное, их и не заполняли.
А их заполняли! Просто сохранение криво сработало. Поэтому, если у нас только черный ящик, то нужно проверять, «а реально ли сохранились данные?». Сохранили? Откройте карточку в новом окне или вызовете информацию через API-метод.
Если доступ к базе есть — просто проверьте по ней, что все хорошо. Если есть доступ к серверным логам — проверьте их на наличие ошибок.
Помимо простых пользователей бывают злые люди, которые пытаются встрять в наше приложение и своровать деньги / данные. Они используют не клиент или сервер — туда у них доступа нет. Они пытаются перехватить данные в пути от клиента к серверу, или от сервера к БД.
Ну а раз нехорошие люди могут это сделать, то тестировщик тоже должен это уметь! Потому что тестировщик предоставляет информацию о нашем продукте.
Тестировщик изучает уязвимости и потом рассказывает команде:
— Ребята, вот я проверил, у нас есть такие-то и такие-то потенциальные дыры. Давайте подумаем, надо нам их как-то закрывать или нет.
То есть не факт, что исправлять проблему будут. Может, у вас некритичное приложение — данные не утекут, деньги вы не храните. Тогда и заморачиваться лишний раз никто не будет, потому что тестировать на защищенность — дорого, специалистов мало.
Но какие-то базовые проверки типа sql-иньекций или XSS-атак стоит изучить и проверить на своем приложении. Хотя бы чтобы понять их критичность. Ведь если атака сломает клиент — ну и пусть, сам себе буратино. А если атака положит сервер, это уже не очень хорошо. И надо хотя бы знать, от чего это бывает.
Итого
Клиент — та программа, с которой работает пользователь. Он знать не знает, это у него на компьютере программа целиком, или где-то за ней прячутся сервер с базой, а то и целый RAID. Он работает в браузере или с desktop-приложением. И всё, что ему нужно знать — это «куда тут тыкать».
Клиенту не нужно много памяти, места на диске и других ресурсов. Поэтому рабочие места относительно дешево стоят. А это именно то, что нам нужно, особенно если нужно закупить оборудование для тысяч операционисток банка.
Сервер — компьютер, на котором хранится само приложение. Весь код, вся логика, все дополнительные материалы и справочники. Например, справочник адресов ФИАС или справочник юр лиц ЕГРЮЛ — они тоже занимают место, как сами по себе, так и в памяти приложения.
Иногда говорят «сервер приложения» и «сервер БД». Это нормально, ведь фактически сервер — это просто машина, компьютер. А базу и сервер приложения обычно хранят на разных машинах, ради безопасности. В таком случае, если говорят «сервер приложения» — речь о втором звене нашей схемы.
Приложения бывают самые разные. Есть ресурсоемкие, им нужно много памяти и места на диске. Есть «легкие», которые можно развернуть даже на домашнем компьютере.
БД (база данных) — хранилище данных. Тут вы можете легко поискать информацию + уверены в том, что она сохранится, даже если в приложении что-то сломается. Подробнее о ней — в статье «Что такое База Данных (БД)»
Сколько места нужно под базу, зависит от количества данных. Есть огромные базы в банках, где и 1тб будет мало. А есть совсем небольшие, которые вы можете установить на своей машине. Например, XAMPP можно поставить. И врядли вы напихаете туда столько данных, что у вас не останется под них место.
Отдельной базы может не быть, тогда структура станет двузвенной: клиент-сервер. И все!
Схема условная, в реальной жизни у нас как минимум будет больше клиентов. А если приложение высоконагруженное, то будет несколько серверов и несколько баз данных:
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Архитектура клиент-сервер
Веб-приложение – это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером – веб-сервер (в широком смысле).
Основная часть приложения, как правило, находится на стороне веб-сервера, который обрабатывает полученные запросы в соответствии с бизнес-логикой продукта и формирует ответ, отправляемый пользователю. На этом этапе в работу включается браузер, именно он преобразовывает полученный ответ от сервера в графический интерфейс, понятный пользователю.
Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты (потребители этих функций).
Практические реализации такой архитектуры называются клиент-серверными технологиями.
Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:
Клиент – это браузер, но встречаются и исключения (в тех случаях, когда один веб-сервер (ВС1) выполняет запрос к другому (ВС2), роль клиента играет веб-сервер ВС1). В классической ситуации (когда роль клиента выполняет браузер) для того, чтобы пользователь увидел графический интерфейс приложения в окне браузера, последний должен обработать полученный ответ веб-сервера, в котором будет содержаться информация, реализованная с применением HTML, CSS, JS (самые используемые технологии). Именно эти технологии «дают понять» браузеру, как именно необходимо «отрисовать» все, что он получил в ответе.
Веб-сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им HTTP-ответы. Веб-сервером называют как программное обеспечение, выполняющее функции веб-сервера, так и непосредственно компьютер, на котором это программное обеспечение работает. Наиболее распространенными видами ПО веб-серверов являются Apache, IIS и NGINX. На веб-сервере функционирует тестируемое приложение, которое может быть реализовано с применением самых разнообразных языков программирования: PHP, Python, Ruby, Java, Perl и пр.
База данных фактически не является частью веб-сервера, но большинство приложений просто не могут выполнять все возложенные на них функции без нее, так как именно в базе данных хранится вся динамическая информация приложения (учетные, пользовательские данные и пр).
Третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:
Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня.
Двухзвенная архитектура проще, так как все запросы обслуживаются одним сервером, но именно из-за этого она менее надежна и предъявляет повышенные требования к производительности сервера.
Трехзвенная архитектура сложнее, но, благодаря тому, что функции распределены между серверами второго и третьего уровня, эта архитектура предоставляет:
Клиент-серверные технологии
Архитектура клиент-сервер применяется в большом числе сетевых технологий, используемых для доступа к различным сетевым сервисам.
Типы сервисов:
Изначально предоставляли доступ к гипертекстовым документам по протоколу HTTP (Hyper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности, работу с бинарными файлами (изображения, мультимедиа и т.п.).
Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью.
Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом, СУБД находится на сервере, к которому и подключаются клиентские приложения.
Файл-сервер хранит информацию в виде файлов и предоставляет пользователям доступ к ней. Как правило, файл-сервер обеспечивает и определенный уровень защиты от несанкционированного доступа
Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и, при этом, обеспечивая защиту сети.
Во-вторых, сохраняет часто запрашиваемую информацию в кэш-памяти на локальном диске, быстро доставляя ее пользователям, без повторного обращения к Интернету.
Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети.
Предоставляют услуги по отправке и получению электронных почтовых сообщений.
Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.
Для доступа к тем или иным сетевым сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:
«Тонкий» клиент
Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере. Для работы тонкого клиента достаточно лишь обеспечить возможность запуска web-браузера, в окне которого и осуществляются все действия. По этой причине web-браузер часто называют «универсальным клиентом».
«Толстый» клиент
Таковым является рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и имеющие необходимый набор программного обеспечения. К сетевым серверам «толстые» клиенты обращаются, в основном, за дополнительными услугами (например, доступ к web-серверу или корпоративной базе данных).
Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).
Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.
Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:
Протокол передачи данных — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. Эти соглашения задают единообразный способ передачи сообщений и обработки ошибок при взаимодействии ПО.
Сетевой протокол — набор правил и действий (очерёдности действий), позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами.
Сетевые протоколы:
TCP/IP — набор протоколов передачи данных, получивший название от двух принадлежащих ему протоколов: TCP (англ. Transmission Control Protocol) и IP (англ. Internet Protocol).
Наиболее известные протоколы, используемые в сети Интернет:
HTTP (Hyper Text Transfer Protocol) — это протокол передачи гипертекста.
SSL ( Secure Sockets Layer — уровень защищённых cокетов) — криптографический протокол, который подразумевает более безопасную связь.
FTP (File Transfer Protocol) — это протокол передачи файлов со специального файлового сервера на компьютер пользователя.
POP3 (Post Office Protocol) — это стандартный протокол почтового соединения.
SMTP (Simple Mail Transfer Protocol) — протокол, который задает набор правил для передачи почты.
TELNET — это протокол удаленного доступа.
DTN — протокол, предназначенный для сетей дальней космической связи IPN, которые используются NASA.
Всё ПО для работы с протоколом HTTP разделяется на три большие категории: