Как работает Backend | Архитектура приложений — Transcript

Обзор архитектуры современных веб-приложений, роли frontend и backend, типов баз данных и микросервисной архитектуры.

Key Takeaways

Frontend отвечает за пользовательский интерфейс и взаимодействие, backend — за обработку данных и бизнес-логику.
Микросервисная архитектура помогает разделить ответственность и упростить разработку и поддержку.
Выбор базы данных зависит от конкретных требований к данным и нагрузке.
Сервисы общаются друг с другом по сети, используя синхронные и асинхронные методы.
Мониторинг и логирование необходимы для своевременного выявления проблем и поддержания стабильности.

Summary

Рассмотрение архитектуры современных веб-приложений с объяснением frontend и backend частей.
Frontend — визуальная часть, с которой взаимодействует пользователь через браузер, написанная на JavaScript и популярных фреймворках.
Backend — серверные приложения, обрабатывающие запросы, реализующие логику, взаимодействующие с базами данных и внешними сервисами.
Объяснение роли различных языков программирования для backend, таких как Java, Go, C++ и Python.
Введение в микросервисную архитектуру для разделения ответственности и упрощения масштабирования.
Описание типов баз данных (SQL и NoSQL) и их особенностей в зависимости от требований к данным.
Обсуждение взаимодействия между сервисами через сеть и протоколы, включая асинхронное общение через очереди сообщений.
Роль мониторинга и логирования для отслеживания состояния и производительности системы.
Использование инструментов для непрерывной доставки и автоматизации сборок, таких как Jenkins.
Проблемы масштабирования ресурсов и важность правильного планирования для обеспечения стабильной работы приложения.

Chapters

Full Transcript — Download SRT & Markdown

Speaker A

На бкдет, когда и какую использовать, разновидности архитектур, типов баз данных — такое количество, что глаза разбегаются при их виде. В современных приложениях используются SQL базы данных, но SQL база данных, брокеры сообщений, файловые хранилища и ещё многое другое. Всем привет! Меня зовут Паша, и сегодня

Speaker A

вместе с вами я на простых и понятных примерах разберу архитектуру современно веб-приложений также затронем вопросы того как это всё работает и обслуживается и как параллельно поддерживается обработка сотен и даже тысяч пользователей одновременно Ну и Давайте то с чего мы начнём это наши

Speaker A

вместе с вами я на простых и понятных примерах разберу архитектуру современного веб-приложений. Также затронем вопросы того, как это всё работает и обслуживается, и как параллельно поддерживается обработка сотен и даже тысяч пользователей одновременно. Ну и давайте, то с чего мы начнём, это наши

Speaker A

браузер и взаимодействуем с интерфейсом нашего приложения через него А и всё что мы видим в браузере это называется frontend часть то есть передняя часть которую видит пользователь из которой он взаимодействует Давайте посмотрим из чего Она состоит А всё что вы видите это кнопки какие-то

Speaker A

пользователи. Всегда, когда мы говорим про какие-то веб-приложения, мы подразумеваем, что у этих приложений есть пользователи, то есть они написаны для кого-то, и эти пользователи взаимодействуют с нашим приложением через веб-интерфейс. Обычно это через браузер, то есть мы заходим в

Speaker A

обрабатываться то есть Вот например Здесь вы можете видеть сайты какие-то у них есть кнопочки Можно например нажать смотреть его какое-то содержимое положить его в корзину то есть как-то взаимодействовать с приложением это всё фнн и весь фнн в основном пишется на

Speaker A

браузер и взаимодействуем с интерфейсом нашего приложения через него. А всё, что мы видим в браузере, это называется frontend часть, то есть передняя часть, которую видит пользователь, из которой он взаимодействует. Давайте посмотрим, из чего она состоит. А всё, что вы видите — это кнопки, какие-то

Speaker A

когда хочет как-то по взаимодействовать с нашим приложением то есть с нашей логикой там например купить какой-то оформить какой-то заказ заказать себе продуктов покушать либо послушать свою любимую музыку или купить себе билеты куда-то оформить слетать куда-то То есть это

Speaker A

формы, анимации, переходы, может быть картинки. Это ВС ннд, то есть вся визуальная часть, с которой взаимодействует пользователь — это ннд. И на фронтенде находится вся логика по тому, как взять данные от пользователя и отправить их на сервера, на которых уже эти данные будут

Speaker A

backend - это такие приложения которые запущены на компьютерах и эти компьютеры называют серверами это может выглядеть вот таким образом то есть есть какая-то комната и в ней запущено очень много компьютеров и эти компьютеры запросы от пользователей которые подают

Speaker A

обрабатываться. То есть вот, например, здесь вы можете видеть сайты, какие-то, у них есть кнопочки. Можно, например, нажать, смотреть его какое-то содержимое, положить его в корзину, то есть как-то взаимодействовать с приложением. Это всё фнн, и весь фнн в основном пишется на

Speaker A

запрос на регистрацию пользователя то что мы с ним будем делать как мы будем эти данные обрабатывать куда мы в Какие сервисы смежные возможно сходим То есть если у нас регистрация пользователя требует например проверки его паспорта мы можем сходить в какие-нибудь сервисы

Speaker A

таком языке программирования, как JavaScript, и самые популярные на данный момент фреймворки для него — это React, Angular и Vue, которые представлены здесь. Но также важно понимать, что frontend — это лишь оболочка, то есть это то, с чем взаимодействует пользователь,

Speaker A

куда мы сохраняем В какие ба Дан свои и все приложения пишутся на каких-то языках программирования это Например могут быть такие языки как Java Go c+ и Python их логотипы Вы можете видеть здесь и при этом Также важно заметить

Speaker A

когда хочет как-то по взаимодействовать с нашим приложением, то есть с нашей логикой, там, например, купить какой-то, оформить какой-то заказ, заказать себе продуктов покушать либо послушать свою любимую музыку или купить себе билеты куда-то, оформить, слетать куда-то. То есть это

Speaker A

можем написать его на Java другой сервис у нас лучше подходит под него язык c+ Plus Мы можем написать его на языке c+ Plus и они будут общаться между собой и понимать друг друга по сети а при этом Также важно про энд сказать

Speaker A

всего лишь логика отображения. А для того, чтобы получить эти данные и отобразить пользователю, фронтенд обращается к бэкенду. Backend — это по сути такие приложения, которые крутятся на серверах. Вот, например, как вот здесь, вот на картинке, и по сути

Speaker A

регистрация пользователей авторизация пользователей приём платежей мы можем ходить в какие-то внешние системы делать вызовы там например сходить за каким-то расписанием либо сходить за погод либо сходить какие-нибудь Яндек карты госуслуги при этом это приложение Т абсолютно все запросы и содержит всю

Speaker A

backend — это такие приложения, которые запущены на компьютерах, и эти компьютеры называют серверами. Это может выглядеть вот таким образом, то есть есть какая-то комната, и в ней запущено очень много компьютеров, и эти компьютеры запросы от пользователей, которые подают

Speaker A

когда растёт количество логики и растёт количество команд разработки которые в один сервис добавляют свои изменения то Тим всем становится очень сложно следить И для этого используется микросервисная архитектура при которой выделяют разные ответственности под разные сервисы то есть Может быть

Speaker A

эти запросы к нам через фронтенд. И вся логика по обработке запросов, о том, какие запросы в принципе могут к нам приходить, какое содержимое у этих запросов, как мы будем реагировать на эти запросы. То есть если к нам приходит

Speaker A

считает например какую-нибудь статистику по всем заказам и отдаёт её менеджерам и все эти сервисы общаются между собой по сети по своим каким-то правилам и вызывают друг у друга методы которые им нужны про то Какими способами сервисы могут общаться между собой а Мы ещё

Speaker A

запрос на регистрацию пользователя, то что мы с ним будем делать, как мы будем эти данные обрабатывать, куда мы в какие сервисы смежные возможно сходим. То есть если у нас регистрация пользователя требует, например, проверки его паспорта, мы можем сходить в какие-нибудь сервисы

Speaker A

что пользователь такой-то У нас есть что у него есть такой-то заказ у него столько-то денег на счету чтобы потом пользователь зашёл в наше приложение снова и увидел что у него это всё сохранилось то есть Нам нужно где-то хранить

Speaker A

госуслуг, например, и проверить, что его паспорт действительно валидный и пользователь нас не обманывает. То есть на бэкенде содержится абсолютно вся логика по обработке запросов, о том, как мы их валидируем, что мы делаем с данными, куда мы во внешний сервисы ходим и какие данные

Speaker A

разных типов баз данных с разными требованиями и гарантиями сохранности данных и у всех этих разных баз данных есть свои преимущества и недостатки какие-то базы данных могут хорошо справляться сль параллельных операций коротких А другие базы данных могут Очень хорошо

Speaker A

куда мы сохраняем, в какие базы данных. И все приложения пишутся на каких-то языках программирования. Это, например, могут быть такие языки, как Java, Go, C++ и Python. Их логотипы вы можете видеть здесь. И при этом также важно заметить,

Speaker A

достаточно непростое решение нужно очень внимательно к этому подходить Для чего в принципе Вам эта база данных нужна будет Какие к ней нужны требования для чего она будет использоваться то есть всегда когда мы выбираем какое-то решение у него есть какие-то

Speaker A

что если у нас, например, один сервис какой-то написан на Java, то он может спокойно общаться по протоколам передачи сети с другим сервисом, который написан на Go. То есть код, что у нас, например, есть один сервис, и под него лучше подходит язык Java, и мы

Speaker A

архитектуре и базах данных эту подборку вы сможете найти у меня в Telegram канале и ссылка на Telegram канал находится в описании буду ждать вас всех там и Давайте я Вам сейчас расскажу про такие два основных типа баз данных это

Speaker A

можем написать его на Java, другой сервис у нас лучше подходит под него язык C++. Мы можем написать его на языке C++, и они будут общаться между собой и понимать друг друга по сети. А при этом также важно про бэкенд сказать,

Speaker A

какой-то у него строго определённый набор полей который у него может быть Это там айдини Логин пароль какой-нибудь mail и телефон и может ещё какая-нибудь дополнительная дополнительные данные которые пользователь указал а то есть набор данных которые хранится пользователи он строго определён и все

Speaker A

что на бэкенде есть разные архитектуры, как можно выстраивать всю логику. Например, есть такой подход, как монолитная архитектура, когда у нас весь бэкенд — это одно приложение, и это приложение содержит абсолютно всю логику нашего сервиса. То есть, например, там может быть

Speaker A

одну единицу какие операции это могут быть это могут быть например вставка данных поиск данных изменения удаление данных а и к транзакциям идёт поддержка aset acet - это аббревиатура четыре буковки а буква а - это амити то есть транзакции они являются атомарные То

Speaker A

регистрация пользователей, авторизация пользователей, приём платежей, мы можем ходить в какие-то внешние системы, делать вызовы там, например, сходить за каким-то расписанием либо сходить за погодой, либо сходить какие-нибудь Яндекс.Карты, госуслуги. При этом это приложение содержит абсолютно все запросы и всю

Speaker A

полностью накатывает либо не накатывает совсем буковка C - Это консистентность она говорит о том что транзакция должна переводить базу данных из одного корректного состояния в другое корректное состояние То есть если мы наме спи 100 руб и перевели Пети то у Пети должно

Speaker A

логику. Этот подход очень хорошо подходит для небольших приложений с маленькой нагрузкой и приложений, у которых достаточно маленькая команда разработки, чтобы можно было быстро внедрять какие-то новые фичи в один сервис и только за одним этим сервисом следить. Но

Speaker A

консистентность определяется именно бизнес требованиями а не базой данных и буковка и - это изоляция Она говорит о том что если у нас есть две параллельные транзакции которые работают с одними и теми же данными и как-то их изменяют то

Speaker A

когда растёт количество логики и растёт количество команд разработки, которые в один сервис добавляют свои изменения, то тим всем становится очень сложно следить. И для этого используется микросервисная архитектура, при которой выделяют разные ответственности под разные сервисы. То есть может быть

Speaker A

транзакцию и уровня изоляции транзакции всего и у каждого этого уровня есть свои гарантии о том какие аномалии могут происходить Какие данные транзакция может видеть из других транзакций А какие не может и буковка D - это она говорит о том что

Speaker A

например отдельный сервис для регистрации, авторизации пользователей, проверки прав и выдачи прав, отдельный сервис для приёма платежей, может быть отдельный сервис какой-нибудь для того, чтобы хранить заказы, отдельный сервис для того, чтобы планировать доставки, следить за курьерами, может быть какой-нибудь отдельный сервис, который

Speaker A

диск в память то всё равно данные должны быть сохранены и когда база данных восстановится после сбоя то она должна вернуть нам эти данные то есть должна быть строгая гарантия сохранности Ну и Также оче важно времен приложени используется не для поиска данных

Speaker A

считает, например, какую-нибудь статистику по всем заказам и отдаёт её менеджерам. И все эти сервисы общаются между собой по сети, по своим каким-то правилам и вызывают друг у друга методы, которые им нужны. Про то, какими способами сервисы могут общаться между собой, мы ещё

Speaker A

обычно это измеряется миллисекундами и в основном как бы эти базы данных используются для параллельной обработки запросов от многих пользователей То есть например Когда вы там заходите на Ozone и там очень много параллельно людей делают заказов это как раз-таки

Speaker A

поговорим попозже про все способы, какие в принципе существуют. А сейчас давайте перейдём к теме от того, как в принципе сервисы хранят какую-то информацию. То есть когда у нас регистрируется пользователь либо делает какой-то заказ, нам нужно сохранить информацию об этом,

Speaker A

порядочные основные которые чаще всего используются в веб-разработке это Ke value база данных база данных которые хранят по ключу какое-то значение при этом ключ - это какая-то строка А значение это быть любое значение которое можно представить в виде ноликов и едини

Speaker A

что пользователь такой-то, у нас есть, что у него есть такой-то заказ, у него столько-то денег на счету, чтобы потом пользователь зашёл в наше приложение снова и увидел, что у него это всё сохранилось. То есть нам нужно где-то хранить

Speaker A

используется для каширования на вме того чтобы ходить в SQL базу данных а SQL база данных за данными пойдёт на диск А в принципе чтобы сходить с диска считать что-то это достаточно долгая операция она намного дольше чем считать из

Speaker A

данные. И для этого существует база данных, и база данных — это по сути то же приложение, которое запускается на каком-то сервере, то есть на компьютере, и у этого приложения обязанность, это его ответственность — это хранение данных. А при этом есть много

Speaker A

их нет то тогда мы сходим в базу данных и запрос пойдёт чуть дольше то есть дис используется чаще всего для кэширования каких-то данных которые нужны пользователю а также мо db является новый SQL базы данных это документо ориентированная база данных в которой

Speaker A

разных типов баз данных с разными требованиями и гарантиями сохранности данных, и у всех этих разных баз данных есть свои преимущества и недостатки. Какие-то базы данных могут хорошо справляться с параллельных операций коротких, а другие базы данных могут очень хорошо

Speaker A

отличаться в зависимости от того когда и где кем сделан заказ то для этого может хорошо подойти Мон db потому что она не накладывает каких-то жёстких ограничений на то какие там нужно хранить данные то есть эти данные могут быть абсолютно с

Speaker A

справляться с тем, когда у нас есть много данных, очень большие объёмы данных, и нужно их как-то обработать, посчитать какую-то статистику, например, там заказов за 5 лет и выдать её аналитикам. То есть для этого используются разные базы данных, и выбор базы данных — это

Speaker A

данных уже не будет выдерживать столько количества данных и будет долго отвечать на наши поиска и вставки для этого применяется такой подход как шардирование то есть база данных разделяется на несколько кусочков на шарды и данные равномерно распределяются между всеми

Speaker A

достаточно непростое решение. Нужно очень внимательно к этому подходить. Для чего в принципе вам эта база данных нужна будет, какие к ней нужны требования, для чего она будет использоваться. То есть всегда, когда мы выбираем какое-то решение, у него есть какие-то

Speaker A

используется для работы над графами То есть это какие-то структуры данных Где у объекта есть связи с другими объектами и Ну например это может использоваться для соцсетей и поиска каких-то связей между людьми в этих соцсетях И эти графовые базы данных

Speaker A

преимущества и недостатки, и нужно сделать так, чтобы мы по максимуму использовали преимущества этого решения, и желательно, чтобы недостатки не так сильно аффектили. Ребята, также хочу сказать, что я сделал подборку материалов по частным вопросам, которые задают на собеседованиях о микросервисной

Speaker A

от SQL в SQL базах данных все записи хранятся в построчно То есть у нас есть например строчка пользователь и все его поля хранятся друг за другом потом новый пользователь поля хранятся друг за другом в колоночные базах данных данные хранятся по колонкам то

Speaker A

архитектуре и базах данных. Эту подборку вы сможете найти у меня в Telegram-канале, и ссылка на Telegram-канал находится в описании. Буду ждать вас всех там. И давайте я вам сейчас расскажу про такие два основных типа баз данных — это

Speaker A

колонкам таблицы и в основном колоночная база данных используется для того чтобы хранить какие-то большие объёмы данных и производить какие-то аналитические запросы над ними далее давайте я также расскажу вам про olab базы данных я уже говорил вам что есть такие базы данных

Speaker A

SQL и NoSQL база данных. Давайте поговорим.

Speaker A

используются для анализа больших объёмов данных и поддержки каких-то сложных запросов которые помогают в принятии решений для бизнеса и обычно с этими базами данных работает меньшее количества пользователей это могут быть какие-то аналитики или менеджеры которые используют их для построения каких-то

Speaker A

отчётов а графиков проводят какие-то маркетинговые исследования которые нужны для бизнеса А в принципе у этих баз данных другой вообще профиль нагрузки не такой как у oltp у них запросов очень мало параллельных но при этом запросы достаточно тяжёлые то есть

Speaker A

там может быть какой-нибудь запрос там посчитать проанализировать какие-нибудь продажи за последние 5 или 10 лет для того чтобы выявить например тенденции Как изменяется рынок и проанализировать что нам вообще нужно делать в будущем и такие базы данных это Например

Speaker A

Amazon R Shift или Google B quy сейчас мы разобрали тему баз данных посмотрели SQL базы данных и SQL базы данных но также важно отметить что не все данные обычно хранят в базах данных есть наме есть такой тип данных

Speaker A

как файлы какие-то отчёты чеки фотографии и их не хранят в базах данных их хранят в специальных файловых хранилищах и давайте мы посмотрим на это то есть эн когда ему нужно сохранить какие-то данные например там о пользователе Он сохраняет их в баз

Speaker A

данных а если нужно сохранить какие-то фа то обычно для этого используются файловые хранилища и файловые хранилища предназначены для хранения любых файлов То есть это могут быть какие-то PDF например это могут быть данные пользователи какие-то паспортные данные могут быть фотографии

Speaker A

пользователя также это могут быть какие-то большие объёмы логов которые нам нужно складывать и хранить где-то и это Например такие базы как Amazon S3 или Min iio и эти файловые хранилища поддерживают резервное копирование то есть а данные все хранятся не На одном сервере где-то в

Speaker A

одном дата-центре А эти данные они реплицируемый [музыка] вате например то есть это один из видов репликации то есть мы создаём как бы п у нас данные хранятся не в одном где-то месте а в нескольких местах и благодаря этому наша система становится

Speaker A

более отказоустойчивый Ну и как говорил один великий человек лучше мы будем иметь бэкапы чем их отсутствие будет иметь нас поэтому ребята делаем бэкапы чтобы Наш бизнес не прогорел далее Давайте перейдём к теме которую я уже Немного затрагивал это то как

Speaker A

бэнды которые могут быть написаны на разных языках программирования или на одном и том же языке программирования общаются между собой Давайте перейдём к взаимодействию между бэнда и нужно понять что общение между сервисами Оно всегда происходит через интернет То есть это сеть это происходит

Speaker A

по проводам и происходит с помощью каких-то протоколов передачи данных например есть такой тип взаимодействия как синхронный И для этого чаще всего используется http протокол и как выглядит это взаимодействие то есть представим что вот у нас есть какой-то сервер и на нём запущено

Speaker A

приложение условно это может быть какой-нибудь сервис регистрации пользователей и к нему приходит запрос извне регистрацию и пользователь присылает там ещ паспортные данные какие-то для того чтобы мы их проверили но ответственность нашего сервиса Это только лишь регистрация он не проверяет паспорта он

Speaker A

делает Запрос к другому сервису который запущен на другом сервере и послать запрос Проверь пожалуйста паспорт этого пользователя и мы ждм ответ синхронно то есть Даше не идм делать никакую логику мы ждм пока вот этот другой сервис нам ответит то

Speaker A

есть мы блокируем в ожидании ответа от другого сервера и это как раз-таки синхронный способ взаимодействия обычно для этого используется протокол http то есть мы посылаем запрос и ждём пока нам придёт ответ далее следующий способ взаимодействия который я бы те

Speaker A

рассказать это асинхронный подход он заключается в том что мы посылаем какое-то событие и уходим дальше делать свои дела то есть мы не ждём на него ответ ответ возможно потом когда-то придёт то есть там он может прийти через минуту через 5 минут через 10 через час

Speaker A

но он когда-то придёт и мы его потом когда-то обработаем то есть нам не нужно прямо сейчас в текущий момент получить этот ответ мы его потом когда-то получим потом когда-то обработаем и чаще всего Наде используется такая технология как кавка

Speaker A

кавка - это брокер сообщений в Который наш сервис посылает события и кавка его хранит у себя внутри и отдаёт всем потребителям которые хотят это событие получать то есть кавка внутри разделена на топики мы пишем в какой-то топик событие например о том что пользователь

Speaker A

совершил такой-то заказ и все другие сервисы которым это событие интересно они на него подписываются и начинают слушать эти события и обрабатывать по мере поступления событий То есть например это может быть какой-то сервис учёта баланса пользователя он слушает заказы Какие заказы совершил какой-то

Speaker A

пользователь и списывает баланс списывает деньги У пользователя за этот заказ другой сервис например он слушает заказы пользователя для того чтобы например начислить Какие бонусы пользователю за этот заказ другой сервер слушает заказы пользователя чтобы назначить доставку на этот заказ то есть

Speaker A

многим сервисам может быть интересная информация о том что пользователь совершил какую-то операцию и они все подписываются на этот топик в который публикуются эти операции также например один из способов асинхронного общение между сервисами это очереди сообщений и например это может

Speaker A

быть rit MQ и это работает Так что один сервис посылает другому сервису сообщение которое является какой-то задачей на то чтобы что-то сделать и другой сервис обрабатывает это событие считывает его из ре MQ и делает эту задачу которую Ему сказали Также

Speaker A

хочу отметить ещё такие протоколы как websocket и jpc это протоколы для двухстороннего обмена данными между клиентом и сервером через постоянное соединение то есть они могут использоваться и используются чаще всего для онлайн-чатов а или каких-то видеоконференций когда нужно обмениваться сообщениями в реальном

Speaker A

времени То есть когда вы например сидите в телеграме вам друг пишет что-то и когда он написал то вам сразу же приходит а уведомление о том что этот друг вам написал и сообщение высвечивается сразу же в чате потому что

Speaker A

там создаётся постоянное соединение долгое которое не разрывается и по которому к вам приходят обновление если они поступили на сервер сервер вам сразу же их присылает то есть не так что вы каждый раз обновляется страничку и ходите спрашиваете а появились ли там

Speaker A

новые сообщения а сервер вам сам их досылатель Как выглядят в принципе все современные веб-приложения любая работа с данными из пользователями сводится к тому что у нас есть показ данных то есть мы как-то что-то показываем далее мы эти данные

Speaker A

обрабатываем и эти данные сохраняем То есть за показ отвечает ннд часть за обработку логическую данных отвечает часть А за за Сохранение данных отвечают базы данных и файловые хранилища и при этом базы данных Могут могут быть разными и отвечать за разные

Speaker A

обязанности то есть либо там например для того чтобы хранить много данных и выполнять какие-то аналитические отчёты либо для того чтобы в онлайне обрабатывать очень много параллельных транзакций на обновление данных и при этом и бэнды могут быть разные то есть

Speaker A

есть разные архитектуры бэнда внутри это могут быть как монолиты это могут быть микросервисы эти микросервисы могут быть написаны на разных языках программирования эти микросервисы могут общаться между собой по разным протоколам передачи данных и даже может использоваться синхронное общение может

Speaker A

использоваться асинхронное общение могут быть использованы разные брокеры для обмена сообщениями и разные протоколы и ннд может быть написан на разных и выглядеть по-разному то есть Всё достаточно индивидуально и любое решение которое принимается нужно взвешивать его и понимать Действительно ли оно нам

Speaker A

здесь нужно если вот так вот посмотреть сверху на это всё то можно понять что очень много логики В современных веб-приложения получается у нас есть какие-то бэнды они крутятся на каких-то серверах это запущенные программы у нас есть и база данных при

Speaker A

этом базы данных обычно запускают на других серверах например это может могут быть даже другие дата-центры чтобы у нас не было сильных зависимостей между приложениями backend и между базами данных то есть они запускаются на разных серверах на разных машинах чтобы

Speaker A

они друг друга не афективний выделяет больше памяти и при этом получается что у нас параллельно запущено очень много приложений там у нас может быть запущено до там сотни тысячи микросервисов у нас могут быть запущены и различные база данных например SQL No SQL база данных у

Speaker A

нас могут быть запущены какие-то брокеры сообщения такие как кавка или rit MQ у нас может быть запущено ещ своё файловое хранилище и за этим за всем нужно следить получается что нужно следить за этой всей инфраструктурой чтобы ничего не упало А если у нас очень много

Speaker A

запущенных параллельных сервисов У нас очень много баз данных каких-то они может быть даже шардирование тереть чтобы у каждого микросервиса была своя строго выделенная база данных это такой хороший подход к разделению ответственности и за всем за этим Нужно следить чтобы ничего не

Speaker A

упало и давайте сейчас мы разберём подходы и принципы как за этим за всем можно следить за тем чтобы у нас была работающая постоянная инфраструктура в первую очередь это конечно же мониторинг мониторинг используется для того чтобы следить за тем как наша система работает внутри как

Speaker A

она справляется со всем для этого обычно используется графана для отображения метрик и прометеус как база данных для метрик При этом метрики могут быть абсолютно разные это могут быть какие-то бизнесов метрики например количество текущее пользователей сколько у нас на сайте сколько у нас

Speaker A

пользователей сейчас делают какой-то заказ сколько у нас пользователей собирают корзину например Сколько у нас пользователей выходит из нашей системы сколько пользователей заходит может быть например сколько пользователей совершили заказ и он у них получился неудачный и также это технические метрики например такие как

Speaker A

Загрузка процессора количество транзакций в базе данных количество транзакций успешных количество транзакций неуспешных запросов которые мы делаем к внешней системе количество запросов которые делают к нам среднее время обработки запросов и эти все метрики они выводятся на дашборды фаны и за ними можно следить

Speaker A

в реальном времене как наша система себя ведёт и настраивать какие-нибудь алерты на то что у нас если система вдруг начала вести себя не так как обычно то приходят нотификации например на почту или в Telegram ответственным людям и они смотрят что с системой

Speaker A

случилось Почему она начала себя вести по-другому например там количество запросов резко возросло или количество запросов почему-то резко упало что чего обычно не бывает для этого используется мониторинг то есть мониторинг в принципе позволяет следить за системой и понять что у нас там внутри происходит также я

Speaker A

хочу отметить далее Это ровка запросов со временем роста количества приложений которые у нас запущены то есть у нас может быть там 50 100 200 микросервисов и каждый запрос проходит начинает с какого-то первого микросервиса и заканчивает на каком-то там последнем двухсотом микросервис

Speaker A

запрос проходит по системе как-то и его путь может выглядеть вот так вот например как на этой картинке И вдруг к нам приходит какой-то пользователи говорит Ребята а у меня здесь почему-то заказ упал с ошибкой я не понимаю почему

Speaker A

Помогите мне разобраться а он вот как-то прошёл по системе и нам нужно понять как он проходил то есть нужно нам точно какой-то механизм для того чтобы отслеживать как запрос ходил по системе в Какие сервисы он зашёл Сколько времени

Speaker A

в каждом сервисе он провёл где он упал и так далее И для этого как раз таки и используется дрессировка дрессировка позволяет нам отслеживать запросы которые прошли по системе и позволяет искать узкие места в наших системах за счёт чего это происходит за

Speaker A

счёт того что каждому запросу когда он приходит в нашу систему ему назначается уникальный идентификатор так называемый трейс и каждый раз когда запрос куда-то идт дальше вго это трейс прикидывается следующему сервису следующий сервис его считывает если он куда-то идт ещ дальше то этот

Speaker A

трейс прокиды ещё дальше в следующий сервис и замеряется то сколько времени потратила на то чтобы обработать запрос в конкретном сервисе Вот так это может выглядеть Здесь вы видите что есть какой-то вот запрос основной ходил ещё в какие-то другие

Speaker A

сервисы и вот можно видеть Сколько в каждом сервисе провёл данный запрос по времени И для этого и с помощью этого можно Как раз-таки отслеживать различные узкие места в системах то есть мы можем зайти и посмотреть А почему у нас запрос

Speaker A

такой долгий В каком месте он у нас медлит то есть в каком-то сервисе Возможно есть какой-то долгий метод например там может быть долгое обращение к базе данных и нам нужно оптимизировать это место и мы сразу можем понять В

Speaker A

каком сервисе проблема если какой-то запрос тормозит и для этого обычно используется такие технологии как др или zipkin далее Давайте перейдём к такому вопросу как логирование то есть у нас со временем роста нашего наших приложений их становится очень много микросервисов

Speaker A

много И каждый сервис пишет какие-то логи это информация о том что сейчас происходит в сервисе и почему он там работает как-то обрабатывает запросы то есть приходит какой-нибудь пользователь говорит Я хочу оформить такой-то заказ и сервис пишет это всё в

Speaker A

логи для того чтобы потом разработчики могли разобраться Например если заказ Этот упал то что там было в логах Может там пользователь отправил какой-то невалидный запрос и поэтому наш сервис отказался такой запрос выполнять и логи очень важны для того чтобы понимать что

Speaker A

происходит внутри сервисов и когда сервисов становится очень много то эти логи нужно собирать как-то в одно место со всех сервисов и анализировать чтобы можно было удобно например взять и отфильтровать логи которые все относятся к одному пользователю или все логи которые

Speaker A

относятся к одному запросу то есть запрос то есть например пользователь сделал запрос на создание заказа этот запрос прошёл по системе зашёл там в 10 микросервисов подряд и нам хочется чтобы все логи с этого запроса со всех микросервисов были в одном месте То есть

Speaker A

это такой централизованный сбор логов А И для этого чаще всего используется такой СТК как elk Это связка elastic Search п пна и вот здесь вот можно посмотреть как это выглядит в интерфейсе то есть здесь вот видно что например такой-то Лог там

Speaker A

что-то произошло то есть сервис написал о том какие данные ему прислали о том что внутри произошло какой пользователь пришёл там вот следующий Лог можно искать по каким-то ключевым словам то есть sech очень хорошо индексирует данные строит по ним индексы

Speaker A

и позволяет очень быстро искать нужную информацию нам в большом объёме логов логов может быть очень много если у нас высоко нагруженный сервис и микросервисов много то Он точно будет генерировать миллионы логов в секунду и нужно как-то очень быстро искать по этим

Speaker A

логом И для этого как раз-таки используется elch потому что он классно индексирует данные далее Давайте перейдём к такой теме как CD А что она означает это Continuous integration и Continuous Delivery это достаточно обширная Тема а и для чего это вообще нужно то есть

Speaker A

когда у нас сервисов становится много у нас фичи добавляются часто то есть не может произойти такого что бизнес скажет Всё мы больше не будем добавлять новые функции в наше приложение Наше приложение полностью сделано и готово и больше в него ничего не надо добавлять

Speaker A

такого никогда не будет то есть фичи всегда добавляются всегда у пользователей есть какие-то потребности и бизнес всегда старается их выполнить чтобы побольше заработать денег и новые фичи всегда внедряются сервисы дорабатывается И их нужно выводить в эксплуатацию и поэтому у нас есть

Speaker A

потребность в том чтобы часто выводить новый функционал в прокш до пользователей то есть нам нужна непрерывная доставка кода до пользователей И для этого используются такие инструменты как например jenkins а для выполнения каких-то автоматизированных задач например для сборок Когда нам нужно собрать какой-то

Speaker A

сервис собрать исполняемый файл или собрать докер образ с нашим сервисом для этой цели также может использоваться ещё этим City ещ важно понимать что у нас сервисов достаточно много и и их все нужно запускать и как-то следить за их жизненным циклом Например

Speaker A

если какой-то сервис вдруг упал у него внутри что-то случилось какая-то ошибка его нужно перезапустить чтобы он снова поднялся и начал обрабатывать запросы может быть такое что у нас один экземпляр нашего сервиса может не выдерживать нагрузку Например если у на

Speaker A

есть какой-нибудь по созданию и обработке заказов а заказов У нас очень много спокойно может быть такая ситуация что один экземпляр этого сервиса не выдерживает всю нагрузку от пользователей и Для этого нам нужно создать несколько экземпляров сервиса этого например 10 штук или 20

Speaker A

штук и балансировать равномерно между ними всеми нагрузку на создание заказов то есть если у нас всего условно 2 создаётся в секунду и поднято 20 экземпляров то на каждый экземпляр будет приходить по 100 запросов на создания заказа и для оркестрация контейнеров и

Speaker A

для того чтобы следить за жизненным циклом контейнеров всех запущенных наших приложений используется кубернетес это такая технология которая острит запущенные сервисы следит за их жизненным циклом также балансирует нагрузку между сервисами если у нас запущено например 20 сервисов обрабатывающих заказы то он

Speaker A

будет балансировать между ними всеми нагрузку То есть он используется для горизонтального масштабирования А и для ещё также и для вертикального мы можем а выделить дополнительное количество ресурсов для какого-то контейнера и не перезапускать его Также хочу рассказать про то что такое облачные технологии и

Speaker A

почему они в принципе взялись для чего они нужны То есть если представить как раньше было у каждой компании есть свой набор серверов которые они используют для того чтобы там поднимать свои базы данных поднимать свои энд приложения брокеры сообщений файловые хранилища и это

Speaker A

какая-то отдельная выделенная комната где стоит куча серверов и эти сервера запросы от пользователей и при этом если компания растёт у неё всё хорошо с продажами с пользователями то количество запросов растёт и нужно масштабироваться нужно докупать новую технику нужно докупать новые сервера А

Speaker A

пока они приедут их нужно ещё установить это время А если у нас какой-нибудь очень бурный экспоненциальный рост то мы можем в принципе даже не успеть накинуть нужное количество ресурсов для того чтобы удовлетворить наших пользователей и наши приложения будут простаивать и

Speaker A

будут отвечать медленно пользователям нашим и они будут недовольны То есть это проблема с масштабированием ресурсов тоже не такая простая и тут можно заранее не подгадать А сколько конкретно нужно ресурсов если купить слишком много ресурсов а пользователей столько у нас

Speaker A

не будет то мы наоборот только хуже себе сделаем потому что потратим больше денег бизнес потратит больше денег и как сейчас решается эта проблема некоторые большие компании например такие как Amazon или Google Просто берут покупают очень много серверов ставят их у себя куда-нибудь

Speaker A

там в очень большой склад и предоставляют эти сервера другим компаниям за какую-то определённую плату в месяц ЕС например бизнес хочет запустить свои сервер То есть например бизнес хочет запустить свои приложения на каком-то сервере и вместо того чтобы покупать свой сервер ставить его обслужи

Speaker A

обслуживать его за ним следить он идёт в компанию например Amazon И просит выделить ему сервер с таким количеством процессоров С таким количеством оперативной памяти с таким количеством дисков столько-то памяти нужно на этих дисках и Облачный провайдер то есть Amazon

Speaker A

предоставляет такой конкретный сервер под нужды этого бизнеса и если Бизнес растёт то он просто очень быстро берёт и запрашивает ещё новый сервер и Облачный провайдер ему предоставляет буквально за секунды Этот новый сервер и бизнес масштабируется сразу же мгновенно про

Speaker A

плат чуть больше денежку Тего намер не один сервер а пять серверов он платит в пять раз больше но за это он получает очень быстрое масштабирование под его запрос а раньше ему бы Пришлось самому следить за этими всеми серверами

Speaker A

заказывать их ждать несколько недель устанавливать А сейчас можно просто купить в аренду облачные сервера и масштабироваться по потребности тогда когда получится также в этих облаках предоставляется очень много сервисов как услуга То есть например можно купить облачные сервера у Amazon и

Speaker A

сразу же поднять Там кластер кубернетес если вам это нужно или поднять например какую-нибудь базу данных постгрес и она сразу будет реплицировать в нескольких кластерах на нескольких дата-центра Можно также поднять какие-то SQL данных там мо db можем поднять кафку если вам

Speaker A

это нужно и сам этот Облачный провайдер будет следить за всем этим чтобы это не упало и чтобы это выдерживала нагрузку которая вам нужна и чтобы все эти сервера реплицировать и данные не потерялись Если вдруг один из дата-центров откажет или там произойдёт

Speaker A

какой-то пожар то есть по сути вы платите деньги и все ваши проблемы с с инфраструктурой с обслуживанием серверов решают эти облачные провайдеры Всем спасибо за просмотр этого видео сегодня мы с вами разобрали большое количество технологий и для чего

Speaker A

они все используются Надеюсь что теперь вы стали Лучше понимать как устроен энд и архитектура современных приложений Не забывайте подписываться оставлять комментарии ставить лайки и конечно же пишите пожелания к своим следующим видео виде которые вы бы хотели видеть на этом

Speaker A

канале И когда это видео наберёт 2.000 лайков то я сделаю такое же видео с разбором микросервисов и стандартных паттернов микросервисной архитектуры Всем спасибо за просмотр а

Topics:архитектура приложенийbackendfrontendмикросервисыбазы данныхSQLNoSQLJavaScriptReactмониторинг

Frequently Asked Questions

Что такое frontend и какую роль он играет в веб-приложении?

Frontend — это визуальная часть веб-приложения, с которой взаимодействует пользователь через браузер. Он отвечает за отображение интерфейса и отправку данных на backend.

Почему в современных приложениях используют микросервисную архитектуру?

Микросервисная архитектура позволяет разделить приложение на независимые сервисы с разной ответственностью, что упрощает разработку, поддержку и масштабирование системы.

Какие типы баз данных используются и как выбрать подходящую?

Используются SQL и NoSQL базы данных. Выбор зависит от требований к данным, нагрузке и гарантиям сохранности. Например, SQL хорошо подходит для сложных запросов, а NoSQL — для масштабируемости и гибкости.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →