Step 2 (S-44767)

From Stepik Wiki
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14826/step/2

Step 2 (S-44767) 1.png

[00:00 - 00:18] на прошлом уроке мы рассмотрели устройство настройка конфигурации и принцип работы сервера и поговорили о том как сконфигурировать сервер для отдачи статических файлов


[00:18 - 00:35] однако изначально вы сами говорили что у современных приложений существуют разные типы запросов а это запросы со статическими файлами а это запросы а за динамическими страницами


[00:35 - 00:50] это запросы к api сайта то есть интерфейса для взаимодействия с другими системами а и соединения ну можно выделить 4 таких


[00:50 - 01:08] а еще аякс запросы а из всего этого а вы в сервером обслуживается самостоятельно только статические файлы то есть сервер который поговорили на прошлом уроке способен самостоятельно отдавать


[01:08 - 01:25] а статические все остальные типы запросов они так или иначе должны задействовать логику приложения то есть бизнес логику а для этого очевидно что необходим каким то образом запустить программный код


[01:25 - 01:41] которой собственно говоря генерирует ответ а вот эта связка сервера и приложение мы сейчас и займемся мы рассмотрим этот тур


[01:41 - 02:01] а в данном контексте по фронтэндом понимается ваш сервер под бы конечно понимаю что есть фронтэнд сейчас речь не идет о верстке сейчас сейчас речь идет просто итак давайте посмотрим на общую схему архитектуры у нас есть


Step 2 (S-44767) 2.png

[02:01 - 02:19] наш сайт который условно он находится в правой части рисунка а он состоит из фронтов сервера сервера и вероятно есть какие то хранилища данных либо вспомогательные сервисы это все зависит от


[02:19 - 02:35] а клиенты клиенты это браузера либо другие устройства например мобильный телефон либо это какие то


[02:35 - 02:50] вот это есть это любой веб клиент обращается с документами к нашему сайту а клиента непосредственно соединяются именно с сервером он так и называется а фронт


[02:50 - 03:08] фронта все потому что он стоит на переднем крае а он принимает соединения от клиент сервер это обычный как правило это асинхронный сервер


[03:08 - 03:27] для ясности предположим что это а рентген с определяет какого типа запрос пришел пример а если пришел запрос со статическим а каким то документом за картинкой


[03:27 - 03:45] о стиле либо javascript файлом такой запрос направляется сразу на диск то есть сервер дает этот запрос с диска и на этом история заканчивается если же пришел


[03:45 - 04:03] другой запрос например запрос за а что мы страничкой которой нет на диске либо а франция сервер сконфигурирован так что он знает что этот запрос нужно передавать продавать 10 самолетов передавать content


[04:03 - 04:21] передает запрос на бы консервов вот этот процесс называется проксировать сервер передает запрос на backend а сервере выполняется бизнес логика


[04:21 - 04:36] то здесь происходит генерация а что моей страничке либо каких то данных в формате json либо давления о каких то данных в процессе работы сервер будет


[04:36 - 04:54] общаться с кем то хранилищами со своей базой данных какой то новый сквер базы данных а потом а когда ответ будет сформирован backend возвращает его сервером


[04:54 - 05:11] обратно клиенту а вот собственно говоря такое разделение ролей называется архитектурой front end backend то есть еще раз повторю явно выделен front end сервер а сервер


[05:11 - 05:29] которого непосредственно подключаются клиенты и к а либо как его еще называют аппликейшен сервер сервер на котором выполняется бизнес логика приложения зачем такая архитектура нужна


Step 2 (S-44767) 3.png

[05:29 - 05:46] давайте посмотрим что входит в задачу фронта сервер а сервер это классический сервер в нем сосала решается множество


[05:46 - 06:02] а административных так скажем задач а 1 самое важное это отдачи статических документов то есть вся статика сайта все документы которые не меняются они отдаются фронтэнд сервером с диска а


[06:02 - 06:19] 2 роль 2 задача во 1 это проксирование то есть передача запросов на бы консерватора а почему это важно почему нельзя совмещать мы обсудили чуть позже а вместе с проксированием идет сразу балансировка нагрузки


[06:19 - 06:37] а что это значит это значит что фронтэнд выбирается тот бы консервы который в данный момент не нагружен то есть меня менее всего нагружен либо просто старается равномерно распределять нагрузку между серверами


[06:37 - 06:52] сервер может обеспечивать кэширование документов а что это значит давайте вернемся к схеме допустим франта сервер сделал некоторой запросов бы команду


Step 2 (S-44767) 4.png

[06:52 - 07:10] ему документ вот этот документ может быть закэшированы а может быть закэшированы на диске сервера и последующий запрос будет обработан из кэша то есть


[07:10 - 07:25] а уменьшается количество обращений к серверу снижается нагрузка а это тоже входят в роли сервера задачи всегда занимаются обработкой


Step 2 (S-44767) 5.png

[07:25 - 07:41] инструкция мы говорить не будем а можно сказать что эта сборка кусочков сборка вот страничка из небольших кусочков а при сборке сасай сервер


Step 2 (S-44767) 6.png

[07:41 - 07:56] сервер может делать более 1 запроса то есть а делается сначала запрос за какой то основной страницей а потом в процессе выполнения с инструкцией в коде этой страницы


[07:56 - 08:14] делаются дополнительные запросы за а с дополнительным содержимым и а содержимое целиком отдается клиенту это называется сборка сайта мы пропустим а кроме того а фронтенд сервер


Step 2 (S-44767) 7.png

[08:14 - 08:30] а дальше множество задач которые связаны с клиентским соединения а как то авторизации клиента а поддержка шифрованного соединения то есть ссср либо тела соединения а нарезка


[08:30 - 08:45] картинок то есть решения картины до нужного размера zip сжатия и тому подобное то есть а все работы которые связаны с вот этим соединениями


Step 2 (S-44767) 8.png

[08:45 - 09:00] с клиентом они естественно обрабатываются фронта от сервера за счет этого а поскольку все все все это из за 4 с до from to server interface сервер он очень простой то есть


[09:00 - 09:18] сервер не решает эти проблемы он работает очень простому интерфейсу а пока серое может сконцентрироваться на бизнес логики приложения 1 из важных задач сервера это ревешь проксирование а что такое реверс прокси


Step 2 (S-44767) 9.png

[09:18 - 09:36] зачем он нужен реверс прокси позволяет бороться с медленными клиент а когда мы обсуждали обработку стилусы дней не говорили о том что медленные клиенты представляет собой проблему они а передача данных от клиентов и обратно к нему


[09:36 - 09:53] то есть передача данных в сети занимают много времени и а занимает фактически полностью процесс либо 1 трек веб сервер а также мы говорили что асинхронные сервера то есть враг то работают по моделям например винкс


[09:53 - 10:08] такой проблемы не имеют и хорошо обрабатывают множества параллельных соединения даже если они очень медленные а что произойдет если мы напрямую пустим каждого клиента


[10:08 - 10:28] а на бы консервов без прокси произойдет следующее речь допустим у нас все клиенты медленной 1 клиент подключается к 1 серверу а сервер генерирует для него ответ и начинает возвращать но поскольку клиент медленный


Step 2 (S-44767) 10.png

[10:28 - 10:43] то сервер будет отдавать ответ долго скажем минуту в это время он не работает а понятно что у нас на 1 сервере запущенном множество там процессов аппликейшен сервер то есть или было множество


[10:43 - 11:00] потока сном для упрощения представить что он 1 2 клиент занимается 2 3 занимает 3 а если пройдет 4 клиент для него просто не будет свободного бы консервов а то не понял


[11:00 - 11:17] свободного процесса кончатся процессы обработчики плетешь серверах а при том что все они будут заняты передачи данных клиенту а вот это нежелательная ситуация что бы такую ситуацию избежать используются


[11:17 - 11:32] реверс прокси как работает ли ваш прокси а ну собственно наличие прокси сервера а перед аппликейшен вот уже и есть


Step 2 (S-44767) 11.png

[11:32 - 11:51] если а если прокси сервера достаточно а что происходит клиент подключается к прокси серверу и начинает передавать ему запрос он это может делать медленно то есть фронтэнд медленно медленно читает запросы клиентов с той скоростью с которой может ее передать да запрос прочитан


[11:51 - 12:06] фронтэнд передает а а запрос по консервов поскольку связь между front end bukan сервером быстро то есть они находятся скорее всего в 1 в дата центре вероятно в 1 стойке а то запрос предаются практически мгновенно


[12:06 - 12:23] то есть здесь и фронтально быка нам придется быстро букет генерирует страничку ну на это нужно потратить какое то время выпуская будет 150 миллисекунд на передачу


[12:23 - 12:42] 5 миллисекунд а пустая страничка сгенерированная возвращает ее заметьте что бы напрямую не взаимодействует с клиентом взаимодействует только а сервер с прокси


[12:42 - 12:59] да пусть он возвращает я за 5 секунд и того как был занят 160 миллисекунд то есть вот шаги на которой был занят а на данный момент он получил ответ а если ответ


[12:59 - 13:18] а получился большим сервер может его сложить на диск с поместить файл если он был маленьким он может держать его в памяти и после чего фронтенд сколь угодно медленно этот ответ возвращает клиенту и того у нас может быть множество медленных клиентов


[13:18 - 13:33] а в результате такого подхода занят всего 160 миллисекунд то есть минимально возможное время за которое он может отработать а и собственно благодаря риверз прокси мы спасаемся от проблем


[13:33 - 13:49] медленных клиентов что мы должны они обрабатывают бизнес логику приложения давайте еще раз повторим основные идеи архитектуры а


Step 2 (S-44767) 12.png

[13:49 - 14:05] 1 все клиенты подключаются к серверу сервер это как правило легковесный а веб сервер работающий по ивент модели и способное обслужить большое количество соединений одновременно


[14:05 - 14:24] задачи фронтэнд сервера ходит а отдачи статических документов обработка протокола шифрования сжатия документ авторизация клиентов а нарезка картинок и тому подобное противный задач


[14:24 - 14:40] сервер обрабатывает только запросы которые запросы генерация динамических страниц также а и также запросы копеек а


[14:40 - 14:57] занимается фактически только обработка бизнес логики приложения за счет механизма риверз прокси сервер работает минимально возможное время которое необходимо для генерации страницы


[14:57 - 15:10] а эта страница отдается клиенту уже сервера а с той скоростью с которой клиент готов ее принять от общем то в этом заключается архитектура сайта вк