В современных приложениях используется огромное количество разных технологий кэши брокеры сообщений микросервисы хранилище файлов и куча всего ещё Чёрт многу у сломит когда использовать одно а когда другое но сегодня я супер простыми словами расскажу Зачем нужен каждый компонент бэк энда что вообще такой этот Кэн и когда вам использовать например кафку А когда редис Привет меня Влад зовут Я разработчик в одной из лучших компаний в мире с семью годами опыта на бэнде и живу в Амстердаме на своём канале рассказываю о том как тебе стать супер мощным программистом в этом ролике мы шаг за шагом пройдёмся по род мапе развития архитектуры вашего приложения начиная от архитектуры простейшего пед проекта и переходя к системе способной выдерживать нагрузки от миллионов пользователей одновременно и при этом мы на каждом этапе будем говорить о том почему и когда конкретно вам использовать один компонент А когда другой Let's Go Давайте сначала разберёмся Что такое frontend А что такой Кэн в любом современном веб-приложений есть всегда две эти части frontend backend и FR в данном случае это всё с чем взаимодействуют именно пользователи этого приложения Да например мы с вами когда берём в руки смартфон кликаем какие-то кнопочки заполняем какие-то формочки видим какие-то анимации всё это фронтенд и в современном мире есть в основном два типа фронтенда это веб интерфейсы и мобильные приложения да те инструменты в общем-то с помощью которых Любой человек может отдать какой-либо программе какие-то команды и ему это будет удобно это будет интуитивно понятно как с таким интерфейсом взаимодействовать и именно это и называется фронтенда всё что вы видите как пользователь и с чем вы можете по взаимодействовать руками в общем-то ввести какие-то данные и так далее frontend обычно реализуется на языке JavaScript с использованием например фреймворка react Это если мы говорим про различные веб-интерфейс То есть то что вы видите в браузере Если же говорить про мобильные приложения то для разработки приложений под iOS используется язык Swift а для Android приложений в современном мире используется либо Java либо cotl который всё активнее и активнее набирает популярность теперь что такое back Дело в том что нельзя просто написать какую-то программу и сказать пользователям что давайте вы будете её в общем-то выполнять в своём браузере или на своём смартфоне программы которые мы пишем часто бывают очень требовательны к ресурсам они зачастую выполняют какие-то сложные операции Именно поэтому мы с вами ими пользуемся они значительно облегчают нам жизнь Потому что при нажатии одной кнопки могут произойти какие-то невероятные совершенно действия Да и соответственно они требуют очень-очень много ресурсов банально процессорного времени оперативной памяти хранилище на жёстком диске и так далее и так далее и поэтому мы не можем заставлять пользователей просто запускать все эти программы в их браузерах на их собственных компьютерах или на их смартфонах Потому что им просто банально может не хватить ресурсов которые находятся в их устройстве такие устройства были бы очень-очень дорогими которые были бы способны запускать все программы Поэтому вместо того чтобы запускать такие программы на устройстве каждого конкретного пользователя разработчики придумали другую концепцию они придумали кнд Они подумали Нам нужен очень мощный компьютер для каждого пользователя что если мы купим один такой очень мощный обычную железную машину но только с огромным количеством оперативной памяти с очень мощным процессором с бесконечным почти что жёстким диском и супер крутой может быть даже видео поставим этот компьютер у себя в офисе и назовём его сервером это будет всё ещё железный компьютер но он будет называться сервером просто потому что пользователи нашего приложения теперь будут С командами обращаться по Интернету к этому компьютеру чтобы он выполнил для них какие-то операции то есть они будут просить его обслужить их запросы и по-английски обслуживать это слово serve и поэтому такой компьютер назвали сервер это просто компьютер который обслуживает запросы пользователей В итоге все вот эти мощные программы которые и составляют основную логику работы вашего приложения и поместили на такие сервера и поскольку вся эта логика находится на этом сервере который находится как бы за фронт дом люди решили назвать это backend находится позади задний край всё что за тем инструментом за фронтенда за передней частью с которо который взаимодействует пользователь И поэтому это называется backend и обычно бэнды пишут на самых разнообразных языках из популярных сегодня это Java и Framework Spring например это может быть язык golang это может быть CSP это может быть Python и многие-многие другие frontend реагируя на нажатие пользователям какой-либо кнопки посылает по интернету с помощью специальных инструментов которые есть в жава скрипте и в реакте данные некоторую информацию просто банально текст и Циферки на эн на тот самый компьютер который называется сервером на котором запущена программа где написана основная логика работы вашего приложения и эта программа просто выполняет какие-то операции с этими данными которые Она получила от пользователей по интернету и затем выполнив эти операции результаты их выполнение тоже по интернету в виде набора текста в определённом формате и цифро каких-то отправляет на фронтенд где пользователь и видит какие-либо успешные результаты но всё это происходит очень-очень быстро потому что данные передаются моментально и компьютер на бэнде выполняет операции Ну просто молниеносно в идеале О'кей Но вот представим что вы разработали такое приложение У вас есть фронтенд на котором пользователи могут нажимать какие-то кнопочки отправлять команды на ваш кнд где и запущено ваше основное приложение на каком-то сервере но проблема в том что пользователи будут посылать вам постоянно какие-то кусочки да данных они в общем-то будут создавать свой профиль регистрироваться в вашем приложении сохранять своё имя имей и так далее они будут создавать какие-то сущности в вашей системе которые нужно куда-то сохранить потому что пользователи будут закрывать приложение открывать они снова хотят увидеть свои данные которые они только что туда добавили значит данные были сохранены сохранены на вашем кэндес на жёстком диске вашего сервера но затем доступ к ним был бы не очень удобен потому что они бы сохранились в беспорядочно совершенно формате который Было бы очень сложно разбирать поэтому люди решили структурировать эти данные чтобы потом когда пользователь снова попросит приложение вернуть их ему назад и показать что он там сохранял до этого чтобы приложение могло их очень легко найти и сразу в структурированном виде для этого были разработаны специальные программы которые называются базами данных база данных - это по сути просто программы которые умеют определённые данные которые вы им даёте сохранять на жёсткий диск какого-нибудь компьютера на котором эти программы базы данных запущены в определённым виде удобном для того чтобы потом эти данные получить назад и для того чтобы управлять ими взаимодействовать связывать как-то и так далее и Самыми популярными базами данных в мире на сегодняшний день на бэнде являются Разумеется SQL базы данных это база данных которые используют язык запросов SQL для формирования команд к ним на вставку данных получение их назад обновление данных удаления и так далее таким образом любое почти что современное приложение использует как минимум одну SQL базу данных для того чтобы хранить в ней огромное количество самых разнообразных данных в определённом виде и в любой момент получать к ним доступ Это значит что ваша программа которую вы на бэнде написали например на Джаве и спринг умеет посылать SQL запросы То есть фактически на другом языке в отдельную совсем другую программу Возможно даже запущенную на другом сервере на другом компьютере по интернету с тем чтобы эта база данных обработала эту команду на языке SQL которые она понимает и вернула именно те данные которые мы попросили в этом SQL запросе на ваш кнд а ваш Кэн уже вернул их на фронтенд где их и увидит пользователь Сколь баз данных много самых разнообразных это и pog SQL и mysql и Oracle db и Microsoft SQL Север и в целом для вас Если Вы только начинаете учиться различия будут минимальны в их функционале и в целом язык SQL в них работает во всех почти что без изменений поэтому вы можете выбрать любую для обучения которая вам подходит Я предпочитаю pog SQL например но mysql тоже норм различия там начинаются уже в глубине того как именно внутри работают эти программы То бишь базы данных каждая из них устроена по-разному SQL базы данных хранят все данные которые вы в них добавляете в виде таблиц соот сонно таблиц состоят из строчек это кусочки данных а колонки представляют отдельные элементы этих данных Если вы же хотите быстро и понятно разобраться что такое вообще SQL язык и как его применять какие там основные команды Что такое Join Что такое Foreign Key Что такое grb и так далее то обязательно посмотрите моё знаменитое видео SQL за 1 час где я супер простыми словами и очень подробно с примерами и практикой с анимациями рассказываю о том как в общем-то пользоваться SQL и после просмотр этого видео вы будете ну самым настоящим мастером в этом языке вперёд до этого мы сказали что фронтенд общается с бкн дом по интернету Как именно это происходит Интернет - это вообще банальная система в которой все компьютеры в мире соединены между собой можете считать что это происходит буквально проводами то есть между всеми компьютерами в мире благодаря различным технологиям есть соединение по которому вы с одного компьютера на другой можете передавать информацию это по сути самое главное что вам нужно знать про интернет Дело в том что информацию можно передавать в любом формате совершенно можно передавать её одной большой строчкой в которой написано через запятую всё что вы хотите передать с одного компьютера на другой можно передавать это в виде таблицы можно передавать целую картинку на которой вы руками напишете Что вы хотите передать и так далее и так далее Разумеется в зависимости от того как именно в какой форме вы передаёте определённую информацию На другой стороне на стороне компьютера то есть сервера например который является получателем этой информации должен быть написан определённый код в программе которая получает эти данные которая умеет вот именно этот формат данных который вы передаёте разбирать и выделять из него ту информацию которая является полезной для выполнения каких-то операций то есть программа которая работает на бэнде должна каким-то образом понимать что за информацию ей прислали и понимать что с это информации делать Что это за команда ей пришла и поскольку люди передавали данные в самых разных форматах один человек придумал что он будет Вот так передавать другой человек решил что он будет иначе это делать Это было очень неудобно все передавали по-разному и очень сложно было одно приложение связать с другим Потому что всегда одно приложение посылало одни данные в определённом виде например строчкой а другое приложение которое получало эти данные умело обрабатывать только таблично представление этих данных и в итоге приходилось дописывать логику которая обрабатывает и такой формат данных и такой и люди решили что это Ну тупо и пришли к выводу что нужно стандартизировать вот этот формат передачи данных договориться буквально Как именно мы будем располагать строчки Циферки в этом наборе данных которые мы передаём из одного приложения в другое чтобы все приложения в мире легко могли понимать что мы от них хотим и именно так появился протокол http по сути слово протокол обозначает договор контракт люди договорились что именно вот так они будут передавать данные от одной программы к другой и это и есть протокол то как люди договорились это делать по определённому протоколу мы передаём данные а http обозначает hypertext transf protoc таким образом http это всего-навсего правил которым вы должны следовать чтобы из одной программы Отправить данные в другую программу и другая программа получатель этих данных поняла что именно вы ей прислали и именно так все современные программы общаются между собой по интернету в основном все из них используют именно протокол http и в протоколе http есть два понятия запрос и ответ запрос - это та структурированная по протоколу http кою одно приложение посылает на выполнение другому приложению в данном случае frend посылает на backend backend обрабатывает запрос То есть это просто он получает данные в определённом формате смотрит что с ними можно сделать выполняет необходимые операции с этими данными и формирует так называемый http ответ это другой кусочек данных структурированный по определённым правилам Согласно протоколу http которые backend посылает по интернету обратно end и именно по протоколу http структурированный Именно таким образом чтобы frontend который тоже является программой тоже мог понять что это за данные и как с ними работать но ещё когда мы говорим о протоколе http в современном мире часто всплывает слово рест что это такое дело в том что когда мы с нашего фронтенда посылаем на кн какой-то кусочек данных мы подразумеваем что один кусочек данных предназначен для выполнение одной операции например Создать пользователя мы нам нужны определённые данные определённого вида и определённая команда на создание пользователя чтобы непосредственно его создать также в нашем приложении может быть другая команда например заблокировать пользователя это совсем другого типа команда и она ожидает совсем другой набор данных который тоже может посыла фронтенда на энд Но это приводит к совсем другому результату так вот на н существует в итоге как раз два обработчика различных типов данных первый обработчик - это обработчик данных которые используются для создания пользователя второй обработчик для обработки данных которые используются для блокировки пользователя например чем больше у вас типов данных чем больше команд может выполнять ваше приложение тем больше у него функционала тем больше таких обработчиков вы будете создавать иб такие обработчики данных получили название эндпоинты конечные точки то есть они находятся как бы на краю вашего бэнда и открыты для внешнего мира и любое приложение Зная как обратиться к этому эндпоинт может следуя определённому формату данных отдать команду вашему приложению Именно поэтому и мобильный НН и Web frontend могут посылать одни и те же команды на один и тот же сервер и получать те же самые результаты Хотя одно веб-приложение другое мобильное приложение но они используют один и тот же обработчик в одном и том же формате данных на бэнде чтобы просто отдать эту команду вне зависимости от того какое другое приложение его вызовет Вы можете думать о этих эндпоинт которым вы для выполнения определённой команды из одной программы подключаетесь к другой и туда передаёте свои данные потом отключайте может подключиться к другой розетке туда передать другие данные для выполнения другой команды это и есть эндпоинты Так вот когда мы говорим про rest то это просто специальный подход то как люди снова договорились о том как именно они будут описывать доступ к этим эндпоинт к этим розеткам что должно знать про них приложение которое хочет отправить в них данные и в каком виде оно должно к ним обратиться чтобы это было максимально удобно максимально интуитивно Понятно СТ - это просто стиль описания ваших эндпоинт стиль создания структура создания вот этих розеток чтобы к ним было удобно подключаться это тоже способ стандартизации всего-навсего люди придумали формат который удобен для описания для создания вот этих вот эндпоинт чтобы в любом приложении вы всегда могли легко разобраться А это такой endp А это такой и могли легко и интуитивно с ними взаимодействовать это всё для чего нужен рест таким образом рест - Это буквально Просто набор правил которым вы можете следовать А можете не следовать это не какая-то библиотека специальный язык или технология это то как вы как разработчик создаёте вот эти эндпоинты по каким правилам вы это делаете правила эти Вы можете очевидно найти На огромном количестве ресурсов в интернете это видео не погружается в глубины того как создавать Рен поинты но очевидно можно сделать другое Поэтому обязательно поставьте этому видео лайк и подписывайтесь на канал если вам нравится формат объяснения сложных вещей простыми словами и вы бы хотели увидеть в будущем видео посту Спасибо вам Именно таким образом как сейчас изображено на схемки выглядит обычно типичный ПД проект начинающего энд разработчика который написал например приложение на Джаве и Spring подключил какую-нибудь SQL базу данных типа pog научил их взаимодействовать сделал парочку н поинтов в своём приложении и написал какой-никакой фронтенд чтобы он взаимодействовал с его приложением и презентовал эти данные Но именно поэтому именно потому что это приложение устроено вот так вот не замысловатой всего несколько компонентов используется всего несколько простых идей Именно поэтому людей с пед проектами не так часто берут на работу джуми Именно поэтому проект должен быть гораздо более интересным и Давайте разберёмся теперь Почему Ваш проект должен быть более интересным и почему этого недостаточно обычно в реальных системах и все проблемы в реальных приложениях начинаются с того что у реального приложения появляются реальные пользователи что происходит когда в вашей системе появляются действительно реальные пользователи они начинают клацать все кнопочки которые есть в вашей системе начинают вводить всевозможные данные о которых вы даже подумать не могли Что такое можно ввести вашу систему и того Если ваше приложение становится достаточно популярным у вас становится очень много пользователей и они все одновременно будут постоянно клацать эти кнопочки а каждый Клик этой кнопочки приводит к тому что по интернету по протоколу http ваш endp на вашем бэнде передаются какие-то данные и ещё и сохраняются в базу данных или вы обращаетесь в базу данных чтобы их получить оттуда Дело в том что все ваши программы на бэнде база данных ва приложение знаменитое со всеми эндпоинт которые выполняет всю логику они всё ещё обычные программы это не какая-то магия они запущены просто на железных компьютерах которые где-то стоят Да это мощные компьютеры но у любого даже самого мощного компьютера в современном мире есть потолок его мощности у него ограниченный запас оперативной памяти у него строго определённая максимальная частота процессора и другие показатели это значит по сути что в одну единицу времени любой компьютер может принять и обработать только строго определённый набор команд не больше просто потому что у него не будет больше ресурсов на это и если в какой-то момент в вашем приложении становится достаточно много пользователей а компьютер который например держит вашу базу данных чтобы она там на нём работала Это же просто программа недостаточно мощный для такого объёма пользователей и их одновременных команд к этой базе данных через ваш backend то в какой-то момент ваша база данных начинает просто тупить под нагрузкой она начинает жёстко лагать компьютер работает на пределе и это часто происходит просто от того что огромный объём пользователей который Вы получили в вашей системе выполняют абсолютно одни и те же действия многим людям одновременно нужно выполнить одно и то же обратиться к одним и тем же данным сохранить многие данные которые очень похожи или ещё что-либо наиболее часто в вашем приложении они будут пытаться получить какие-то данные которые одни и те же для всех пользователей Ну например в социальной сети многие люди заходят в профиль каких-то знаменитостей по сути из базы данных в этот момент Они вытаскивают информацию о профиле какого-то знаменитого человека и она передаётся на фронтенд где они все её видят Но если человек популярный то туда одновременно в его профиль будет заходить много людей Они все будут одни и те же Данные постоянно получать из вашей базы данных и жёстко грузить Ваш компьютер сервер на котором запущена ваша база данных если ваша база данных выключится в какой-то момент просто потому что компьютер сгорит не знаю не сможет работать на пределе или просто будет работать очень медленно то все ваши пользователи будут в ярости они будут ненавидеть ваше приложение потому что оно не возвращает им моментальный результат и соответственно они перестанут им пользоваться современный бизнес разработка не может этого допустить приложения зарабатывают деньги только по Потому что люди ими пользуются потому что они проводят в них время и всё должно работать идеально моментально быстро пользователи должны быть счастливы но если всё работает медленно они уходят вы теряете деньги ваш бизнес закрываются люди обратили внимание на эту проблему что часто пользователи читают одни и те же данные из базы и подумали база данных хранит все свои данные на жёстком диске жёсткий диск - Это не самое быстрая память компьютера обращени к нему долгие чтение данных из них долгое Да относительно потому потому что в компьютере есть на самом деле ещё одна память оперативная память она гораздо быстрее Именно поэтому она и называется оперативное чтение с неё быстрее запись в неё быстрее и так далее и так далее и люди подумали что если мы Кроме базы данных добавим ещё одно дополнительное хранилище в нашу систему которая будет все данные которые мы в него поместим хранить не на жёстком диске А в оперативной памяти чтобы доступ к ним был гораздо быстрее так появился так называемый кэш кэш в вашем приложении это дополнительное хранилище отдельное от основной базы данных в котором вы храните все самые популярные данные в вашей системе которые ваши пользователи читают или обновляют очень-очень часто потому что кэш это специальная программа которая все эти данные хранит именно в оперативной памяти поэтому огромное количество запросов кшу которые тоже по сути программа запущена на каком-то сервере на каком-то компьютере будут гораздо быстрее чем если бы они все были направлены в базу данных и более того такая программа может их сразу обработать гораздо больше гораздо больше объём операций выполнить просто потому что она быстрее отдаёт результат и такие программы получили название Шей и Именно они позволяют в больших системах гарантировать что ваши пользователи при обращении к популярным данным могут получить результаты максимально быстро такими программами в современном мире выступают например дис один из самых известных кэше в мире или ещё есть так называемый mem cash активно используется в разработке многих современных приложений особенно на уровне н компании по сути кэш - это тоже база данных тоже программа которая хранит данные в определённом месте тоже их может получать тоже туда можно что-то сохранять и так далее но в этих программах в ris MM cash уже не используется язык SQL там используются специальные способы взаимодействия с этими программами которые сильно отличаются от SQL языка и вообще выглядит всё это по-другому Но на самом деле есть множество библиотек в разнообразных популярных языках которые очень сильно упрощают взаимодействие с такими программами как ris например куда вы буквально там вызовом одного метода можете послать все необходимые данные или получить их и таким образом Если вы хотите вывести ваш пед проект на новый уровень приблизить его к реальному приложению то Подумайте каким кусочком данных ваши потенциальные пользователи могли бы обращаться очень-очень часто к одним и тем же и если вы можете о таких подумать то добавьте в своё приложение кэш такой как redis и поместите эти данные туда и направляйте пользователей именно к данным в кэше если они там есть если их там нет направляйте их честно в базу данных Но если достали их из БД и знаете что это популярные в будущем данные поместите их в кэш чтобы все будущие запросы отправлялись именно в кэш ваше приложение благодаря не хитрому компоненту типа redis выходит уже на совершенно новый уровень вы начинаете думать как инженер вы думаете о том что в вашей системе может быть миллион пользователей и что все они могут уложить вашу базу данных и Кэш спасёт её от падения но вы думаете Это всё нет а к сожалению это не всё есть ещё огромное количество проблем которые нам предстоит решить Дело в том что Никакой магии в мире не бывает и ничего не работает Просто так и ничего не достаётся просто так та программа которую вы написали например на Джаве ваш непосредственно энд ваш ваше приложение которое выпол всю бизнес логику оно тоже просто запущено на каком-то железном компьютере Да он очень мощный потенциально но у него тоже ограниченные ресурсы Однажды ваше приложение Вашу программу на этом сервере может прилететь снова огромное количество запросов от ваших потенциальных пользователей Да вы избавили от этой проблемы вашу базу данных добавив кэш и ей стало легче но ваше приложение является таким перенаправлять команд в разные другие программы с которыми оно соединяется но тем не менее оно тоже запущено на каком-то компьютере тем не менее оно тоже требует каких-то ресурсов на выполнение всех этих операций которые вы ему поручает если их очень много ваше приложение сама программа на каком-либо языке которую вы написали начнёт тоже работать медленно начнёт лагать начнёт отвечать пользователям с задержка возвращать их данные через промежуток времени пользователи снова приходят в ярость очень-очень долго иногда Ваш компьютер вообще может просто сгореть и выключиться и тогда всё ваше приложение просто встаёт пользователи посылают куда-то данные но куда их посылать компьютер на который Вы пытаетесь обратиться просто не работает и это проблема в современном мире приложения не могут выключиться никакой бизнес не может позволить чтобы его приложение просто в какой-то момент стало недоступно для его Поль те хоть днём хоть ночью хоть в выходной хоть в Новый год Потому что всегда по всему миру есть люди которые по интернету могут с ним взаимодействовать А это и есть прибыль этих компаний которые предоставляют такие приложения и приложение должно работать в идеале всегда но поскольку оно запущено на железных машинах а они ломаются перегреваются нагружают вы не застрахованы от проблем и вам нужно что-то с этим делать вы не можете допустить чтобы всё выключилось и люди подумали и решили вот у нас есть наше огромное веб-приложение написанное например на Джаве Мы обрабатываем в нём огромное количество команд бесчисленное множество Мы в нём обрабатываем сохранение пользователей Мы в нём обрабатываем какие-то финансовые транзакции Мы в нём добавили социальные фичи что люди могут оставлять друг другу комментарии делиться какими-то постами мы можем загружать картинки и видео и всё Это умеет делать одно единственное приложение оно выполняет очень-очень много операций А у вас очень много пользователей каждый из этих пользователей хочет выполнить потенциально разные какие-то вещи один переводит деньги другой публикует какие-то посты третий обновляет свой профиль загружая в него картинку четвёртый смотрит какое-то видео в вашем приложении всё Это разное Но если все эти функции сосредоточены в одном единственном приложении Это значит что все они будут обрабатываться на одном единственном компьютере на котором и запущено это приложение потому что это одно целое приложение оно как единый кусок единый Монолит именно отсюда происходит это слово Монолит монолитное приложение - это приложение в котором сосредоточены все функции вашей системы все фичи которые у вас есть все эндпоинты все обращение к данным и так далее и так далее все процессы зашиты в одном единственном приложении в одной единственной большой программе которая отвечает за выполнение их всех и для монолитных систем когда они становятся очень большими Когда в них появляется большое количество функционала нужно выделять всё более мощные и мощные серверы но у мощности серверов всегда есть потолок и в современном мире мы уже Начали его достигать современные приложения требуют гораздо больше ресурсов Чем может предложить любой из современных железных серверов у них у всех есть ограничения и поэтому люди решили если мы так сильно можем в современном мире из-за такого объёма пользователей из-за такого обилия функционала который мы предоставляем если мы так сильно можем нагрузить один компьютер Только поэтому что если мы Разобьём один этот Монолит на несколько разных приложений которые все будут запущены каждое на отдельном сервере на отдельной железной машине но каждое это мини-приложение будет отвечать только за определённый кусок функционала всей нашей системы отвечать одно приложение отвечает только за юзеров другое отвечает за ленту новостей третье приложение отвечает например за систему отправки нотификаций в нашей системе пользователям И если мы сделаем так то получится что в каждое приложение мы отправляем только часть всех запросов пользователей к нашей общей системе Но это значит что мы снижаем количество операций которое каждая приложение выполняет в принципе а это значит что поскольку каждое приложение запущено на отдельном сервере мы как бы распределяем нагрузку по разным серверам один сервер отвечает за пользователей другой за нотификации это значит что он будет отвечать только за это если вырастает количество запросов на регистрацию пользователей то сервер нотификации продолжает работать так же как он и работал до этого для него ничего не меняется он не перегружается загружается сервер работы с пользователями Это другая проблема которую мы будем решать но сервер нотификации остаётся постоянно таким образом вы можете очень грамотно выделять ресурсы для работы определённых фичей например одна фича более высоко нагружена чем другая и под неё Вы можете выделить более дорогой сервер на котором больше ресурсов А если фича не требует большого количество операций для выполнения то ей можно поставить сервер подешевле и сэкономить денег таким образом просто разбив это приложение и вот эти маленькие приложения которые в связи все вместе формируют В итоге огромную систему называются микросервисами в микросервисной подходе Когда вы одно большое приложение делите по функционалу на множество разных приложений которые тоже по сути это всё те же самые веб-приложения всё те же самые бэнды которые вы и писали до этого но только они теперь в виде отдельных приложений например тоже на Джаве написанных на всё те технологиях на спринг например но они существуют отдельно одну программу на Джаве запустили она отвечает за это другую тоже на Джаве запустили она отвечает за это в ней другой код но она интегрируется в общую систему вы как бы собираете пазл из разных кусков несколько программ теперь запускаете и они работают в комплексе в системе почему называется микросервис микро потому что оно меньше чем весь Монолит как бы отдельный кусочек и назвали микро Оно не обязательно должно быть очень маленьким микросервис может быть на самом деле очень-очень большим и мощным просто потому что это кусочек от вашей системы сервис потому что он предоставляет услуги предоставляет сервис обслуживает какие-то запросы выполняет какие-то операции получился микросервис дело Теперь ещё и в том что не просто frontend может обращаться к разным микросервиса в зависимости от того какую операцию ему нужно выполнить но ещё и сами микросервисы могут обращаться друг к другу по всё тому же протоколу http всё также по интернету потому что это просто Две разных программы запущенные на двух разных компьютерах Я же могу из одной программы послать http запрос в другую программу я так делал с фронтенда и эндом фнн отдельная программа посылала запрос по интернету на Кэн в другую отдельную программу Почему два приложения которые на бэнде не могут сделать то же самое и вот они делают соответственно вы как пользователь посылая команду с фронтенда на Кэн можете обратиться к одному конкретному сервису к одному конкретному мини приложению из всей ваше систе например к сервису фида сервису ленты новостей вы добавляете какой-нибудь пост допустим в вашу систему Да как пользователей А все ваши подписчики должны например получить уведомление о том что вы как автор как тот на кого они подписаны опубликовали какой-то пост и в этой ситуации ФД сервис сервис ленты новостей отвечал бы за что как приложение он бы отвечал за сохранение этого поста в базу данных и публикацию этого поста в ленты новостей разных ваших подписчиков и в то же время этот сервис - это отдельное приложение отправила бы запрос отдельную команду в отдельный сервис нотификаций для того чтобы этот сервис а не сервис ленты новостей занялся отправкой нотификаций этим пользователям о том что пост был опубликован таким образом одно приложение отвечает за одни действия а одно за другие и нажатие буквально одной кнопки на фронтенде может вести к целой цепной реакции различных операций на вашем кэндес которые просто коммуницируют между друг другом по интернету и на этой схеме изображено всего три микросервиса но в современных Кэн дах в разнообразных компаниях этих микросервисов могут быть сотни и тысячи и все они организованы в единую систему которая через хитросплетение различных запросов и интеграций взаимодействует и предоставляет тот набор функционал которой мы с вами пользуемся как обычные юзеры и Именно таким образом решается проблема нагрузки вот этого огромного Монолита на сервер на котором он запущен мы просто разбиваем функционал разносим на разные машины и на разные машины теперь нагрузка гораздо гораздо ниже к сожалению микросервисы не являются панацеей мы всё ещё с вами живём в неидеальном мире всё ещё никакой магии не существует компьютеры на которых запущен каждый из микросервисов всё ещё обычные железные компьютеры обычные серверы которые где-то стоят Они перегреваются они всё также изнашиваются Они горят они выключаются из розеток и так далее и так далее благодаря микросервиса Мы конечно при условии потери одного из компьютеров Например у нас сгорел в Рандомный момент сервер на котором запущен микросервис по отправке нотификации в нашей системе он просто вался сгорел не знаю перегорел жёсткий диск материнская плата улетела и это значит что наш микросервис по нотификация Просто выключился Это значит что все запросы к нему не будут работать он просто не может выполнять никакие операции но всё остальное наше приложение продолжает функционировать в этом один из плюсов микросервисов что если один микросервис упал то вся остальная система продолжает функционировать Представьте что было бы с монолитом если у него сгорает сервер то всё ваше приложение встаёт А здесь у нас в нашей теме ещё р-сервис продолжает спокойно обрабатывать все запросы и команды сервис ленты новостей тоже Ну нотификации перестали отправлять но всё остальное работает тем не менее В современных системах гарантии того что весь функционал продолжает работать для пользователей очень важны мы не можем допустить опять же чтобы половина нашего приложения работала А половина нет Если компьютеры продолжают ломаться и гореть то кажется что это невозможно гарантировать на самом деле люди не придумали ничего гениального но смогли эту проблему решить они просто сказали если у меня есть какое-то приложение Я его поместил на какой-то сервер который потенциально может выключиться по любой причине хоть ураган будет его унесёт вообще в космос и он там очевидно не сможет работать то ёлки-палки что если я вместо того чтобы одно Моё приложение запускать на одном единственном сервере возьму это самое приложение и запущу его на де одинаковых компьютерах запущу это одно и то же приложение просто на десяти разных компах банально копии если один из этих компов ломается то у меня остаётся ещё девять точно таких же приложений запущенных просто на разных других компах которые независимо от этого первого работают которые продолжают что-то делать если я теряю один из моих компьютеров вся система продолжает функционировать и вот этот процесс копирования вашего приложения на другие компьютеры называется репликация реплика - Это копия вашего приложения запущенное просто на другом компьютере вы не пишите отдельный код на другом компьютере вы ничего подобного не делайте вы пишите код один раз и просто вот это приложение которое у вас получилось копируете на разные компьютеры и запускаете его там и всё это даёт вам огромное количество возможностей во-первых ваша система никогда не сможет упасть полностью Если у вас есть достаточно компьютеров достаточно реплик вашего приложения то очень низкая вероятность что все они вдруг сломаются одновременно если сломается одно то другие Ну скорее всего продолжат работать если конечно они не все подключены к одному тройнику и у вас произошло короткое замка но это уже дурацкая стратегии репликации то же самое ведь может произойти и с вашей базой данных это то программа запущенная на отдельном компьютере с вашим кэшем это тоже программа запущенная на сервере поэтому и для них выполняются всё те же правила вместо того чтобы потерять кэш в своём приложении и заставить пользователей ждать дольше Давайте реплицируемый компьютерах если одна сгорает У нас есть ещё куча других которые продолжают обслуживать запросы пользователей более того мы теперь данные раньше наше приложение выключалась компьютер сгорал мы могли все данные потерять Представьте это же катастрофа А когда мы их накопили на кучу компьютеров один сгорел У нас все остальные остались Мы ещё и можем новый поставить и туда данные с существующих рабочих перековать тогда мы точно не теряем данные то же самое с базой данных подумали люди ёлки-палки если у меня сгорит сервер база данных если жёсткий диск полетит Ну мне кранты Просто у меня все данные за годы которые пользователи на добавляли в Моё приложение просто исчезнут навсегда я не могу этого допустить это будет катастрофа все мои инвестиции все мои бизнес партнёры меня пошлют Просто если такое случится поэтому я пожалуй настав множество компьютеров и на всех из них реплицируемый туда все такие же данные и соединю их в единую систему и в базах данных это немножко сложнее и обычно в них остаётся один сер который принимает все запросы на запись на сохранение каких-то данных в вашу базу он называется мастер мастер сервер или мастернода также к нему подключаются другие которые реплики которые используются для дополнительного хранения данных но они также поскольку на них хранятся копии данных могут обслуживать запросы на чтение То есть вы по ним по множеству этих серверов базы данных можете распределить множество запросов на чтение данных из вашей базы таким образом вы снижается нагрузку на один сервер на чтение именно к сожалению запись обычно производится на одну машину вот эти ноды в базе данных реплики копии базы данных которые могут обслуживать только запросы на чтение называются ещё слей нодами то есть есть мастернода основная главная нода которая сохраняет данные и она ещё и копирует эти данные на все остальные машины чтобы всегда актуальные копии на всех репликах поддерживались а реплики которые обслуживают запросы на чтение называются сй нодами то есть они как бы вторичные в остальных же случаях там в работе с микросервисами нет никаких мастеров и слей Вов просто ваше приложение запускается на куче разных машин Но это одно и то же приложение одной и той же версии с одной и той же логикой с одним и тем же кодом но оно Просто там работает на разных машинах все они могут принимать и запросы на запись и запросы на чтени неважно совершенно в базах данных просто для гарантии asid Вам необходимо принимать запросы на запись только на одной машине и именно Это идея репликации Ничего гениального просто поставим больше компьютеров чтобы если сломался один все остальные поддержали его в его неудаче катастрофической И теперь когда у нас что-то ломается мы всё ещё Ок наше приложение продолжает работать полностью и это ещё не всё но вы мне скажете Влад вот я запустил мою программу мой эн например на пяти серверах Но это разные компьютеры с разными адресами в интернете и соответственно чтобы обратиться к определённому из них Мне нужно конкретно на него отправить запрос когда мой фронтенд посылает данные на мой кнд откуда он знает Например обращаясь к сервису users сес для регистрации нового пользователя какому из пяти компьютер репли какому серверу на которых запущено Моё приложение ему обратиться какому конкретно это справедливое замечание действительно если их пять я должен знать какому конкретно Я отправляю запрос Ну и люди решили эту проблему они придумали такую специальную программу которая называется балансер или балансировщик нагрузки это действительно специальная программа в которой вы можете зарегистрировать все ваши компьютеры реплики для оден сервиса и сказать когда в мой balancer приходит запрос от пользователя в этот конкретный микросервис пусть lad балансер примет решение на Какой конкретно из физических машин из реальных компьютеров серверов будет направлен этот запрос потому что они все в нём зарегистрированы lad balancer как программа внутри себя хранит информацию о том под какими IP адресами находятся в интернете те или иные компьютеры которые вы туда поместили и он соответственно может принять решение на какой из них направится запрос То есть он знает про всех и он принимает это решение таким образом ваш фронтенд например отправляя запрос больше ничего не знает про ваши микросервисы про ваш Кэн и так далее и так далее он знает что он обращается к этой программе лот балансер которая уже сама примет решение Куда дальше этот запрос направить таким образом Т балансер знает знат про эндпоинты и знает про конкретные сервера на которых запущены те или иные микросервисы мало того что baner может отправить запрос в конкретный микросервис мало того что он может принять решение на Какой конкретно компьютер на одном из которых запущен этот микросервис запрос отправить он ещё и Может между всеми этими серверами равномерно распределить нагрузку Представьте что у вас очень много запросов пользователей летит на регистрацию в шем приложении очень-очень много сейчас пик активности Все хотят зарегистрироваться в вашей системе и у вас стоит пять серверов и вы могли бы сказать Пусть один обрабатывает все запросы а четыре других на подсосе что если первый упадёт то ещё четыре в запасе есть если что они обслужат остальные запросы но это не рационально потому что все четыре остальных будут просто простаивать и вы будете за них деньги платить за эти сервера и за то что на них приложение запущено и за то что свет мотает и так далее и так далее так Почему бы пока запросы в это приложение летят все эти запросы не распределить равномерно по всем этим машинам чтобы все машины были в работе и чтобы каждая машина получала только часть из всего трафика который летит на весь этот микросервис на них ведь на всех запущена одна и та же копия одного и того же приложения соответственно Они все будут выполнять одну и ту же логику вне зависимости Какой конкретно на них запрос пришёл от этого пользователя или от этого приложение - это одно и то же просто данные другие именно это ещё и умеет делать ло балансер мало того что он знает про конкретные машины на которые нужно направить запрос Так он ещё и может равномерно эти запросы распределять по всем доступным машинам для этого микросервиса к которому он обращается есть разнообразные программы которые предоставляют Такой тип функционала самый популярный наверное из лот балансе который я знаю - это н но его настройка это обч обязанность псов например хотя вы как инженер тоже можете Однажды этим заняться если это будет необходимо Например если вы работаете в стартапе и у вас нет девопса 100% вы будете этим заниматься но вот именно для этого в ваших программах нужны балансе но опять балансер - это просто программа которая тоже запущена на каком-то сервере и очевидно если эта программа упадёт то все ваши сервисы будут недоступны для фронтенда потому что фронтенд теперь знает только прод балансер он не ходит к сервисам напрямую у него есть вот эта прослойка в виде ло балансера поэтому вы не можете допустить чтобы Т балансер был запущен тоже в единственном экземпляре на одной единственной машине Потому что если она ломается всё ломается поэтому лот балансе тоже обычно запускают хотя бы пару штук чтобы если ломается один Второй мог занять его место и работа всей системы была продолжена в штатном режиме репликация Окей теперь Представьте что в вашем приложении социальной сети появляется пользователь который является знаменитостью у него есть 10 млн подписчиков и вот Он решает опубликовать какой-нибудь пост и это значит в вашей системе что все его подписчики должны быть уведомлены о том что новый пост вышел в их ленте новостей Как это работает на нашей схеме автор поста отправляет запрос на наш сервис который называется Fit сервис тот обрабатывает эту информацию и кроме всего прочего потому что не он отвечает за нотификации отправляет Запрос к notification сервису который и должен выполнить логику отправки всем этим 10 млн подписчиков всех их нотификаций которые и отобразятся у них в браузере потом или на мобильном приложении например но Что это значит Это значит что когда автор публикует пост то при коммуникации фид сервиса и notification сервиса автор вынужден будет очень долго ждать пока все запросы от фид сервиса отправятся в notification сервис А их будет 10 млн и более того связь по интернету не надёжна сети в принципе не надёжны связь иногда прерывается падает нужно делать ещё одну попытку или всё отваливается по тайм-аут или ещё что-то это интернет ни на что нельзя рассчитывать Это значит что когда человек буквально нажимает кнопку публикации поста он видит спинер загрузки и ждёт очень долго Хотя ему нужно просто сохранить текст в базу данных пока notification сервис разберётся со всей кучей запросов которые в него летят а Fit сервис дождётся ответов на эти запросы о том что нотификация отправлены успешно и только тогда он скажет автору поста о том что пост успешно опубликован но ведь этих нотификаций нужно отправить 10 млн штук Значит нужно дождаться 10 млн ответов от нофи сервиса что очень-очень долго и медленно и тогда пользователи в вашем приложении просто ненавидят публиковать посты особенно знаменитости которым нужно отправить нотификации на 10 млн человек и тогда люди подумали и решили что если мы создадим новую просто новую программу которую тоже запустим на каком-нибудь компьютере и назовём брокер сообщений э программа будет работать следующим образом тот кто хочет отправить какой-то кусочек информации какой-то сервис помещает в эту программу этот кусочек Информации а сервис который получает эту информацию слушает ждёт этот кусочек информации на другой стороне этой программы То есть он как бы подключается к ней с другой страны соответственно эта программа будет помещать всю информацию которую в неё публикуют в очередь то есть каждое отдельное сообщение будет становиться в очередь на обработку таким образом если например notification сес Может в единицу времени обработать 10 сообщений А фид сервис может послать 10 млн то все остальные сообщения которые прямо сейчас не могут быть обработаны будут просто ожидать своей очереди внутри этой программы брокера сообщений брокер сообщений может быть например кавка Очень популярный брокер сообщений современный Что такое эти сообщения Это буквально ВС те же кусочки информации которые раньше были http запросами в виде Буково и циферов представленных в определённом формате то теперь они представлены в другом формате чтобы они могли попасть в этот брокер сообщений и суть здесь заключается в том что Т сервис после того как он сформировал одно большое сообщение содержащее всю информацию о всех необходимых получателя и всю информацию о сте по которому нужно отправить все нотификации он просто один раз публикует это в брокер сообщений и сразу забывает о нём брокер сообщений гарантирует что сообщение которое в него опубликовали не будет утеряно оно сохраняется внутри этой программы брокера сообщений и теперь фит-сервис узнав о том что сообщение точно сохранено внутри брокера может пойти и заниматься своими делами он не знает когда notification сес достанет его из этой очереди и обработать Но это ведь и неважно вы как пользователь можете получить нотификации чуть позже о том что вышел пост опыт пользователя для вас не сильно изменится в этом отношении ничего страшного не произойдёт Но это даёт возможность фид сервису Просто сразу вернуть ответ автору поста о том что его пост опубликован и не ждать пока notification сес сделает всю эту огромную работу потому что она может быть сделано асинхронно параллельно независимо от Фит сервиса это даёт вам огром количество возможностей более того брокеры сообщений дают некоторые гарантии например кавка никогда не теряет сообщения которые в неё были опубликованы Если вы что-то туда поместили вы можете быть уверены что эта информация никогда не пропадёт и Однажды тот сервис который находится на другой стороне или сервис потребитель этих сообщений заберёт эту информацию и обработает её каким-то образом Именно для этого были придуманы брокеры сообщения чтобы как бы отделить сервисы друг от друга и ослабить зависимости между ними фид сервису больше не нужно ждать долгой работы фий сервиса он может просто продолжить заниматься своими делами точно зная что команды который он отдал фике сервису Однажды будут точно доставлены благодаря например кафке это и есть брокеры сообщения Если вы уже владеете языком два и мечтаете переехать в какой-нибудь город типа Амстердама но всё никак не можете найти работу то Приходите ко мне на Java bootcamp где мы изучим и поработаем со всеми необходимыми технологиями которые нужны действительно профессиональному разработчику Европейского уровня это и Spring и кавка и redis и hibernate и pog SQL И самое главное девять микросервисов все из которых вы напишите не просто Напишите но сделайте в них действительно классные фичи вроде ленты новостей сервиса для сокращения ссылок или системы нотификаций которые будут уведомлять ваших пользователей о важных событиях в вашем приложении более того эти фичи будут зади зайне так чтобы выдерживать действительно высокие нагрузки от потенциальных пользователей вы не просто будете следовать за моими гайдами а действительно понимать Почему применяются определённые решения А почему вы будете это понимать потому что вы будете работать в реальных командах разработки с другими участниками по правилам см Пользуясь реальными инструментами которые вы будете использовать на реальной работе А ещё в вашей команде будет самый настоящий разработчик который будет помогать вам на протяжении всего бу темпа это будет человек который Реально работает в компании типа Яндекс azone или MTS вы будете созваниваться с ним несколько раз в неделю он будет постоянно отвечать на ваши вопросы Максимум в течение одного дня и регулярно ревью весь ваш код абсолютно весь код который Вы пишите на буткемпе ревью ИТ реальный разработчик и после прохождения буткемпа Вы выходите с CV и реальным проектом в своём портфолио с которыми вас Ну не могут уже не взять на работу это будет просто невозможно и все рекрутеры захотят вас к себе в компанию потому что у вас будет не просто ПД проект у вас будет опыт работы в команде с реальными инженерами над супер мощным приложением с супер классными фичами Приходите на bootcamp ссылка доступна в описании Теперь давайте представим что в вашем приложении собрались сотни миллионов пользователей которые ежедневно генерируют огромное количество данных которые вы сохраняете в свою SQL базу данных например пог и всё у вас великолепно до того момента пока пространство на жёстко диске компьютера где запущена программа pog SQL не заполняется Это же просто жёсткий диск память на нём может закончиться И что же делать в этой ситуации вы мне скажете Мы можем поставить жёсткий диск побольше у нас будет больше памяти я скажу Окей но потом она снова заполнится вам нужен будет ещё более дорогой и большой жёсткий диск и прямо сейчас если вы пойдёте искать самый большой жёсткий диск в мире вы так или иначе найдёте его но и его размер будет ограничен А размер данных которые публикуются в ваше приложение будет безграничен никогда не будет никакой остановки пользователи всегда будут генерировать всё больше и больше данных проблема SQL баз данных в том что данные которые в них хранятся очень сложно разбить на куски и распределить по разным компьютерам почему это сложно потому что это отменяет транзакцию очень сложно убеждаться В aset гарантиях Если вы про них слышали и поэтому люди придумали базы данных которые позволяют легко распределять все данные которые в них хранятся по нескольким компьютерам Объединённых в кластер и такие базы данных получили название No SQL базы данных то есть любые базы данных которые не SQL самое главное их отличие от обычных традиционных SQL баз данных в том что они не предоставляют aset гарантий то есть они не позволяют вам выполнять aset транзакции И вам всегда нужно Быть готовым что единствен ные гарантии которые эти базы вам дают это гарантии Base Basic availability Soft State и eventual consistency про них нужно Конечно говорить отдельно но так или иначе Существует бесчисленное множество разнообразных но иль баз данных разного типа для разных нужд которые вы можете использовать если вам в вашем приложении нужно хранить огромное количество данных которые не помещаются на одной единственной машине например есть такая популярная база данных как mong db она хранит все данные в виде документов которые можно легко обращаться по ключу и хранит там бесчисленное множество разнообразной информации ещё и без привязки к какой-то строгой схеме то есть там могут быть буквально самые разнообразные Данные есть Касандра колуна база данных для хранения огромного количества информации она используется например в Big Data решениях есть графовые базы данных такие как Neo FJ которые используются например в социальных сетях для быстрого поиска между сущностями например как в огромной базе пользователей найти друзей определённого пользователя Это великолепно применяется в социальных сетях но основной смысл этих баз данных в том что они распределяют все данные что в них хранятся по нескольким машин совершенно легко из коробки вам не нужно ничего делать это специальные программы которые умеют это делать за вас вы им Говорите сколько у вас есть серверов и где они находятся и они равномерно распределяют данные по ним И если новые компьютеры появляются в вашей системе то они убеждаются тоже автоматически что туда некоторая часть данных тоже будет перенаправлено но из-за своей распределённой природы нужно об этом помнить никаких aset гарантий вы не получите соответственно Когда вам использовать иль базы данных и когда вам использовать новый сль базы данных я бы сказал что вам по дефолту для своих учебных проектов для организации любого стартапа или ещё чего-то вам изначально нужно всегда использовать SQL базу данных и только потом Когда вы понимаете что вы упирается о том какую и где именно вам использовать ноль базу данных и как вы с ней в вашем приложении будете работать это не какое-то решение которое можно принять от балды вот поэтому сделайте упор на SQL база данных но SQL полезно про них знать знать Бейс гарантии чем они отличаются от SQL но использовать Вам их не обязательно в своей работе Они применяются только когда Вы точно знаете что они вам помогут более того например redis - Это распределённая база данных Ke value хранилище поэтому это тоже но SQL база данных продолжая тему SQL баз данных и их ограничений нужно сказать о том что если вы обычными данными отжигает очень много памяти то Представьте что будет если вашу SQL базу данных вы позволите пользователям сохранять обычные файлы картинки видео и так далее ведь файлы могут быть неограниченного размера и если вы позволите юзера просто банально загружать всё что угодно в вашу базу данных которая запущена на компьютере с ограниченным размером жёсткого диска то что помешает пользователю создать файл который по размеру больше чем весь ваш жёсткий диск загрузить в ваше приложение и уложить всю систему из-за этого именно никогда не позволяйте пользователям сохранять Их файлы в вашу базу данных О'кей Вы могли бы поставить ограничение Но это всё равно не решает проблему пользова будут сохранять очень много файлов и они будут очень-очень быстро заполнять ваше хранилище потому что файлы они всегда больше гораздо по размеру чем обычные там строчки или числа и в этой связи люди придумали так называемые ББ стод это хранилище файлов которые вы используете именно для того чтобы там сохранять файлы огромного размера как они работают внутри они используют распределён ную файловую систему такого рода концепции - это очень сложные вещи и они не являются темо этого видео Я лишь хотел показать что вам никогда не нужно сохранять файлы в базу данных в SQL базу данных и что Вы всегда должны сохранять Их в так называемый blop storage или Cloud storage или хранилище объектов это ещё можно назвать Какие популярные существуют например Amazon S3 Есть Угу хранилище файл Google Cloud storage minio и многие другие суть этого хранилища в том что это специальная как бы база данных именно для файлов любых совершенно картинки видео бинарные файлы архивы что угодно пользователи помещают туда а это хранилище в ответ на сохраняемый файл возвращает вам ссылку на этот файл в этом самом хранилище эту ссылку уже вы помещает в вашу основную SQL базу данных и теперь когда пользователь хочет загрузить какой-то файл он сначала получает ссылку из вашей базы данных а затем по этой ссылке напрямую обращаясь к хранилищу файлов загружает полностью этот файл и получает его на экране например картинку Вот так работают хранилище файлов и именно их Вы должны использовать для сохранения любых совершенно файлов но разумеется это не дело постоянно заставлять пользователей ходить в Ваше хранилище файлов по интернету и по интернету скачивать каждую картинку Каждый раз когда они перезагружаются страницу это огромное количество трафика это очень долго это высочайшие нагрузки на вашу систему А это банально стоит денег и поэтому люди придумали такую технологию как cdn или Content Delivery Network это банально тоже программа запущенная На огромном количестве компьютеров по всему миру не вы запускаете эти компьютеры это есть специальные организации которые предоставляют этот cdn как инструмент вы за него платите получаете доступ ко всем этим серверам которые они запустили по всему миру и вы можете их использовать как такой кэш для ваших файлов То есть когда пользователь впервые загружает какую-нибудь картинку из вашего хранилища объектов то Он загружает её из этого хранилища объектов совершенно честно но загрузив он помещает её на какой-нибудь сервер в этом сидне который географически находится рядом с этим человеком и соответственно все следующие запросы к этой же самой картинке будут уже идти не в ваше приложение А вот в этот сервер который находится в этом cdn соответственно скорость за этого файла будет гораздо быстрее потому что сервер географически находится ближе к пользователю а нагрузка на вашу систему Разумеется будет снижено потому что теперь не вы обслуживается запрос пользователя на эту картинку а какая-то трети ронне организация которая предоставляет вам услуги для пользование cdn таким образом если пользователи в вашем приложении часто загружают какие-нибудь картинки видео и так далее и так далее и взаимодействуют с ними буквально их смотрят в вашей системе то Убедитесь что вы используете cdn для того чтобы вать там эти файлы Ну а теперь давайте взглянем снова на нашу схему У нас есть огромное количество самых разнообразных программ для совершенно разных целей Но все они запущены на разных компьютерах серверах которые просто железные машины которые где-то стоят и включены в розетку как было раньше люди какие-то организации которые разрабатывают приложение покупали себе эти огромные серверы железные машины привозили в офис втыкали в розетку настраивали их и запускали на них свои приложения но Представьте вам завтра нужен новый сервер для того чтобы сделать репликацию Вы снова покупаете его приносите в свой офис включаете в розетку снова настраиваете и так далее и так далее Итак для всех программ что у вас есть потому что они должны быть запущены на разных компьютерах Потому что если один компьютер сгорит то хотя бы остальные работают да и у вас один компонент системы вываливается они все сразу поэтому их нельзя запускать все на одном компьютере это небезопасно В итоге из-за того что вам буквально приходилось раньше руками всё это настраивать привозить покупать поднимать вы не могли делать это быстро это всегда ограничение и у вас может банально Не быть ресурсов на очередной новый компьютер супер дорогой Тем более если нагрузка падает Зачем он вам нужен такой дорогой А завтра она возрастает вот он стал нужен то вы его включаете то выключайте очень неэффективно используются ресурсы которые вы тратите на серверы и поэтому компания Amazon подумала А что если мы построим один огромный до в котором поставим огромное количество железных массивных компьютеров с супер мощными ресурсами И будем сдавать их в аренду людям которым нужны сервера так появился aws облако - это не какой-то эфемерное облако Это огромный дом в котором стоит куча компьютеров куда вы можете позвонить или написать сообщение и сказать мне нужен такой компьютер с такими ресурсами чтобы я мог запустить на нём такое-то приложение и Они вам говорят окей мы сейчас его включим настроим вы просто запустите там приложение и всё у вас будет работать по интернету такие замечательно никуда не нужно ехать ничего не нужно покупать кроме подписки на этот сервис не нужно никого просить настроить они всё это обслуживают если он сгорит они дадут вам новый автоматически потому что вы платите И так появились облака облака - Это всего лишь красивое название для вот этого сервиса предоставления вам серверов в аренду и теперь все свои программы Вы можете запускать не у себя дома на куча разных железных компьютеров а просто в Google Cloud обратиться у которых своё облако есть aws heroku ажур и так далее и так далее Все они предоставляют услуги по аренде буквально серверов и разных других сервисов они предоставляют разнообразные машины но так или иначе Вы можете всю свою инфраструктуру все программы что у вас есть запустить на чужих машинах и просто платить столько сколько вы используете ресурсов именно в этот конкретный Вы можете динамически их очень быстро попросить добавить вам машины в вашу систему чтобы обработать большие нагрузки а затем динамически убрать эти машины за буквально несколько секунд у них Великолепная просто инфраструктура и великолепный сервис в итоге вы очень-очень быстро масштабируется ваш бизнес и вашу систему потому что вы банально не переживаете о том как вам настроить железные огромные сервера и всё на них установить за вас это делают сотрудники амазона вы просто платите им денежки и в итоге вся ваша инфраструктура запущена в Облаке это Cloud based архитектура когда говорят что всё просто запускается на компьютерах которые мы взяли в аренду в сервисе aws Ну ладно вы запустили вашу систему всё у вас работает великолепно Но вот в какой-то момент у кого-то из ваших пользователей выскакивает огромная Красная ошибка когда он пытается что-то сделать И он не может эту ошибку обойти она блокирует его совершенно от пользования вашей системой он пишет вам в поддержку и говорит Моё приложение не работает вы матеря с идёте в общем-то разбираться что у него случилось но как вы это делаете пользователь не скажет Вам ничего конкретно он скажет У меня красная ошибка на экране и я не знаю что у вас там сломалось на Технической стороне это может быть бухгалтер тётя Тамара которая вообще не знает что существуют языки программирования или ещё что-то она просто хочет чтобы ваши система сделала то о чём она её просит её не интересуют ваши там баги на Кэнди или ещё что-то тогда Как именно вы будете разбираться что конкретно у вас сломалось вы не сможете её допросить она вам ничего полезного даже не скажет и Именно для этого для решения этой проблемы люди придумали логи логи - Это буквально файл в который ваше приложение постоянно Когда происходит любое совершенно действие выполняется определённая строчка в вашем коде оно буквально пишет туда текст с определённым сообщением о том что конкретно в этот момент реакции на определённый запрос пользователя происходит в вашей системе На этом этапе на этом когда вызывается этот метод когда вызывается этот метод когда мы Обращаемся в это хранилище данных Когда в это что происходит для какого пользователя мы получили Какие данные У какого пользователя произошёл Exception что это за Exception что у него за к Трей это текст это просто текстовая информация которую ваше приложение каждое из ваших микросервисов публикует в один большой файл и просто сохраняет туда эту информацию чтобы затем когда возникнет какая-то проблема у пользователя вы могли этот файл открыть найти время когда была записана определённая строчка и Когда произошла определённая проблема у вашего пользователя и посмотреть что там в это время был за Exception и просто изучить его стектрейс разобраться где он в вашем коде вылетел и почему в общем-то и решить эту проблему это вся идея логов но Разумеется хранить логи в одном огромном файле неэффективно потому что они постепенно становятся очень большими по ним сложно искать затем ещё и Становится их будет очень много это будут гигабайты и терабайты логов в огромных системах Возможно даже петабайт иногда и поэтому люди просто придумали систему которая будет разбирать весь текст логов в реальном времени и позволять вам очень-очень быстро искать по любым ключевым словам в этих логах есть специальная база данных которая умеет делать полнотекстовый поиск то есть То есть вы ей скармливать строчку она разбивает её на куски и по-любому из этих кусков можно очень-очень быстро найти полную строчку в этой базе такая база данных называется elastic Search Соответственно что люди придумали они сказали а давайте все наши сервисы которые вот пишут логи вместо того чтобы писать их в один огромный файл они будут сразу писать все эти логи банально строчки с текстом в эту базу данных elastic Search она их будет индексировать то есть буквально разбивать их на вот эти множество отдель слов по которым Затем все эти строчки можно будет искать соответственно теперь все логи хранятся в этой базе данных и Когда возникает какая-то проблема вы банально можете отправить в неё запрос Не Иля на специальном языке который поддерживает эта база данных elastic Search на поиск определённых строчек например в каком-то интервале времени Потому что эти строчки содержат информацию о времени когда они были записаны туда и для удобной работы с этой базой данных был придуман ещё один инструмент kibana который предоставляет Вот как раз инженерам а удобный пользовательский интерфейс для выполнения вот этих самых запросов к этой базе данных elastic Search и поиска там соответствующей информации и Именно для этого нужны логии чаще всего вы на своих проектах реальных в профессиональной деятельности встретите систему elastic Search + kibana для сбора логов со всей вашей системы Где вы будете проводить очень много времени когда будете там дебажить какую-то прод проблему которая возникла у ваших пользователей но Разумеется кроме сбора логов Когда ваша система работает Вы ещё хотите знать Вот моя программа какое-то приложение которое я написал запущено на каком-то компьютере насколько интенсивно она использует ресурсы этого компьютера Как много пользователей обращаются в секунду к моему приложению Что будет если их станет в два раза больше упадёт Моё приложение или выдержит нагрузку сколько событий свки потребляет моя система и так далее и так далее вы всё это хотите постоянно знать чтобы всегда в любой момент времени Быть способным Взглянуть на вашу систему как бы сверху и посмотреть где проседают какие-то нагрузки слишком высокие ваша система работает медленно где всё в порядке А где вы там близки к заполнению жёсткого диска Где у вас был скачок в нагрузке почему он произошёл и так далее и так далее проанализировать это и ретроспективно и в каждый момент времени иметь возможность в общем-то ть производительность всей вашей системы вы банально хотите собирать метрики о работе вашего всего приложения всех его компонентов сервисов различных баз данных кэша и так далее для этого люди придумали ещё одну специальную базу данных которая умеет собирать метрики то есть банально какую-то информацию опять представленную в определённом виде о работе вашей системы которую каждый инструмент из вашего приложения может посылать в эту базу данных с помощью какой-нибудь специальной библиотеки такая популярная база данных например Это прометеус вы с помощью специальных опять же инструментов можете послать туда информацию о том сколько раз в вашей системе например был вызван определённый метод прямо буквально в коде сколько раз был вызван ваш метод в течение одной какой-то конкретной секунды эта база данных сохраняет эту информацию в определённом виде Так что затем по этой информации очень легко делать поиск в определённый интервал времени То есть вы хотите узнать за сегодняшний день сколько раз кто-то вызвал определённый метод в моём коде эта база данных позволяет это делать очень быстро у неё тоже есть специальный язык запросов но чтобы Вам не учить ещё один язык запросов потому что вам что ж для эластика что ли пришлось бы учить для прометеус и сколи надо знать и так далее и так далее это неудобно и люди придумали ещё один инструмент который называется графана который банально предоставляет удобный пользовательский интерфейс для того чтобы работать с этой прометеус базой данных графана умеет На основе данных которые уже хранятся в этой базе данных прометеус строить разнообразные графики по вашему запросу сразу Анализируя то как менялось количество данных в зависимости от времени строить различные диаграммы анализировать эти данные и собирать их в каком-то удобном для вас формате что вы всегда можете проанализировать что прямо сейчас происходит в моей системе вы буквально можете открыть фану у вас будет куча графиков которые вы сами сказали Как построить и они будут меняться в реальном времени на основе дан которые прямо сейчас обновляются внутри базы данных проте к которой подключена графана и вы можете просто сидеть и смотреть как прямо сейчас перформия а если что-то происходит графана ещё и отправит вам нотификации о том что например у вас критически выросла нагрузка на какой-нибудь юрсервис и вы вам нужно срочно отреагировать но вы сразу сможете зайти в фан увидеть что именно пошло не так и сбор метрик - это одна из ключевых задач в любой современной теме на бэнде и поэтому вы очевидно должны хотя бы слышать о том что существует прометеус что существует сбор метрик в эту базу данных и что существует графана для того чтобы удобно смотреть на эти данные в виде графиков диаграмм и всякого такого я надеюсь что это видео было очень ценным для вас будет здорово если поставите лайк и подпишитесь на канал также Приходите в мой Telegram Где вы найдёте огромное количество уникального контента о моей работе в бигтех компаниях технических статей и также путешествий лайфстайл много чего ещё Спасибо вам и увидимся