Speaker A
Меня зовут Сергей Соловьёв. Я занимаюсь бэкэндом порядка 10 лет. Порядка 2 лет я провожу в крупную IT-компанию. Часто, когда речь заходит про бэкэнд, люди не очень понимают, что там делали, какой был размер команды для того, чтобы
Обзор архитектуры бэкенда от микросервиса до маркетплейса с примерами и объяснением командной работы.
Key Takeaways
- Микросервисная архитектура требует разделения сервисов и баз данных для независимости и масштабируемости.
- API Gateway упрощает взаимодействие фронтенда с множеством микросервисов, выступая единым входом.
- Балансировщик нагрузки скрывает внутреннюю структуру сервисов и обеспечивает распределение трафика.
- Команда разработки для среднего микросервисного проекта обычно состоит из нескольких специалистов с разными ролями.
- Важно абстрагироваться от конкретных технологий при проектировании системы, фокусируясь на функциональных требованиях.
Summary
- Сергей Соловьёв делится опытом работы с бэкендом более 10 лет, в том числе в крупной IT-компании.
- Рассматривается развитие системы на примере интернет-магазина от одного микросервиса до сложной архитектуры.
- Объясняется роль базы данных и абстрагирование от конкретных технологий при проектировании.
- Показано, как фронтенд взаимодействует с бэкендом через API и балансировщик нагрузки (например, Nginx).
- Вводится понятие микросервисов Orders и Customer с отдельными базами данных для каждого.
- Обсуждается паттерн API Gateway для упрощения взаимодействия фронтенда с множеством микросервисов.
- Рассматривается состав команды разработки для такой системы — от 2 до 4 человек с QA и продуктовым владельцем.
- Подчеркивается важность разделения ответственности между сервисами для независимого развития и масштабирования.
- Обсуждаются нюансы инфраструктуры, включая использование одного инстанса Postgres с несколькими базами.
- Дается понимание сложности и этапов развития backend-архитектуры в реальных бизнес-сценариях.
Chapters
Full Transcript — Download SRT & Markdown
Speaker A
сделать такой функционал и вообще какой был функционал, в конце концов. Для примера мы возьмём с тобой интернет-магазин, начнём с маленького микросервиса, а потом вырастим одну большую огромную систему, как это происходит в большом бизнесе.
Speaker A
Для того, чтобы понять пошагово, как развивается такая система, чтобы ты ориентировался по некоторому описанию вакансии, ну, либо описанию своего резюме, что конкретно придётся делать в такой команде, какие будут задачи, какова будет сложность у этих задач, ну, и как это будет примерно выглядеть на
Speaker A
архитектуре. Итак, это самый маленький размер команды. Один сервис, один контейнер. Всё это крутится и сделано одним человеком. Никакой здесь Rocket Science нет, потому что даже нет базы данных. Что бы я добавил здесь? Ну, наверное, хочется добавить базу данных, в которой мы будем с тобой
Speaker A
хранить какую-то информацию. Когда мы с тобой говорим про такой некоторый system дизайн, нужно абстрагироваться от конкретных технологий. Нам не важно, какая база под капотом будет. Нам важно, что это хранилище наших данных, что мы понимаем, что это будет хранить наши
Speaker A
записи в каком-то виде или какую-то информацию. Но абсолютно без разницы, Postgres — это Монга или MySQL, пофиг.
Speaker A
База данных. Ну и мы делаем просто связь по сети, то есть сетевая связанность. Наш сервис умеет ходить в базу. Всё, теперь мы научились с тобой ходить и по API отвечать на какие-то запросы. То есть мы можем послать HTTP-запрос,
Speaker A
например, get Order, который вернёт нам список товаров. Также мы можем, например, сделать с тобой HTTP-запрос get orders ID, то есть конкретную информацию о конкретном товаре. То есть это просто какой-то эндпойнт, который без авторизации, без всего. Вот просто два метода, два
Speaker A
эндпойнта торчит наружу, и их можно позвать. Для этого нам потребуется с тобой база данных и вот такой сетевой доступ. Перед тем, как мы с тобой начнём добавлять дальше какие-то микросервисы либо ещё что-то усложнять, давай поговорим, как устроена вообще
Speaker A
коммуникация наших с тобой компонентов большой системы. Сейчас для нашей с тобой схемы, которую там мы пытаемся понять в легенде и так далее, нам будет достаточно каких-то базовых поверхностных знаний. Клиентом нашего приложения может быть любой фронт. Это честный какой-то там веб-сайт или это
Speaker A
может быть мобильное приложение или это может быть твой умный холодильник или пылесос, который умеет ходить по API. В целом неважно. Поэтому давай нарисуем просто прямоугольник, который будет отвечать за фронт. Мы его назовём frontend и в скобочках напишем client. И неважно, что
Speaker A
это на самом деле. Для того, чтобы наш фронтенд не думал о том, где находится этот сервис, да? Или если у нас таких сервисов может быть несколько и чтобы фронт не держал в голове, да, ну, то есть не знал точные адреса, куда ему
Speaker A
надо ходить и так далее, обычно используются некоторые разные механизмы. Самый простой базовый механизм, который мы можем встретить, вообще-то, это Nginx, то есть тот самый балансировщик нагрузки.
Speaker A
Вот так вот он будет выглядеть. Nginx, да, и он занимается тем, что он перенаправляет запросы, которые к нему приходят внутри своей сети. То есть на самом деле наши с тобой микросервисы, они недоступны из вне, они не торчат наружу. Ещё говорят обычно на сленге
Speaker A
торчать жопой наружу. Ну то есть наш микросервис, он не торчит жопой наружу, он скрыт где-то. И у нас есть только одна входная дверь, как в квартиру, и только через неё можно попасть в другие комнаты. Тут то же самое. По
Speaker A
сути, ну либо любой другой какой-то балансировщик нагрузки, является входной дверью в наше закулисье бэкэнда.
Speaker A
По-честному, если то фронтенд тоже живёт там, он тоже спрятан за этой дверкой. И когда наш с тобой клиент хочет сделать запрос, например, заходит на какой-то сайт, он попадает в какую-то штуку, которая уже распределяет этот трафик дальше. Обычно это называют load
Speaker A
balancer, но это не обязательно Nginx, это может быть что-то другое, может быть что-то самописное, неважно. На схеме дальше я не буду рисовать Nginx, потому что это будет просто усложнять нашу систему. Я нарисую фронтенд, как будто бы он ходит напрямую в наши
Speaker A
сервисы. Но ещё раз, ты должен понимать, что на самом деле здесь где-то под капотом спрятан балансировщик. Хорошо, давай вернём обратно, уберём нашего Чубрика, он нам уже не нужен.
Speaker A
Оставим frontend, уберём балансировщик и сделаем с тобой вот такую вот штуковину. Ну раз мы с тобой начали делать всё тут про интернет-магазин, то давай назовём наш микросервис Orders, сервис Orders и добавим ещё какой-нибудь микросервис для того, чтобы у нас было
Speaker A
две логики. Если у нас есть заказы, то, наверное, у нас должны быть ещё и покупатели, да, так называемые кастомеры. Customer сервис.
Speaker A
Смотри, здесь может быть по-разному организовано. Customer сервис может уметь ходить в базу данных в общую, да, в DB Orders, и там будут как-то таблички у них и так далее. Это может быть отдельная база данных. И так, и так
Speaker A
существует. Но если мы говорим про честную микросервисную архитектуру, то каждый микросервис должен ходить в свою базу данных. Почему? Потому что, вообще-то, микросервис — это некоторая атомарная штука, которую можно убрать, добавить, и это никак не будет влиять на другие сервисы. То есть Order сервис, он
Speaker A
никак не должен зависеть от customer сервиса. Поэтому Order сервис живёт своей жизнью. И самое логичное — это разделить их полностью, не давать им одну общую базу данных, да. Поэтому здесь давай ДБ, ну, там ДБ кастомер. Понятно.
Speaker A
Смотри, что ещё. Это может быть неочевидно, но на самом деле эти базы могут жить на одном инстансе Postgres.
Speaker A
То есть Postgres позволяет поднять несколько баз данных в рамках одной большой инфраструктуры своей Postgres, да. Поэтому это не то, чтобы прямо разные серверы подняты с базой, это на одном сервере может быть просто две логические единицы, там DB1, DB2,
Speaker A
DB3 и так далее. Поэтому это не очень сложно организовать. Нам нужно сделать так, чтобы фронтенд ходил всё время в одно приложение, в какое-то. И после этого уже запросы будут разваливаться. Это вообще-то ответственность бэкэндеров предоставить удобный API для фронтенда.
Speaker A
У нас внутри может быть много разных каких-то ручек, эндпоинтов, как хочешь называй. А наружу для фронтенда мы должны предоставить только то, что ему нужно, только то, что удобно использовать. Поэтому мы не будем с тобой мудрить, что-то сложное делать. Я
Speaker A
предлагаю просто применить обычный паттерн, так называемый API gateway, который будет просто выступать как прокси для нашего фронтенда. Ну, то есть кто-то называет это proxy service, кто-то называет это front to back service, я назову его API Gateway. Front to back service. Вот сейчас
Speaker A
мы сейчас поправим картинку, чтобы было удобно всё. Стало гораздо лучше. Фронтенд начал ходить в одну точку, а все плоские линии — это будут наши с тобой внутренние связи какие-то, то есть мы ими будем управлять. Все пунктирные линии — это к
Speaker A
нам будут приходить. Вот так будет нам удобнее с тобой коммуницировать. Возможно, здесь где-то появится легенда рядом. Да, давай даже мы сами её сделаем. Пусть это будет нам в помощь. То есть, а, [музыка] для внешних и внутренних запросов. Вот. И
Speaker A
сейчас я нарисую эти стрелочки. Так. Так. И мы договорились, что внешние у нас запросы пунктирные. Окей. Смотри.
Speaker A
О, стало очень удобно, всё стало сразу же. Окей. Погнали дальше. Вот такую уже систему один человек навряд ли будет разрабатывать, если мы говорим про какую-то команду. Скорее всего, здесь должно быть два человека, и было бы круто, если бы был хотя бы один QA,
Speaker A
который позволяет всё это покрыть тестированием. Возможно, один аналитик. Ну и вообще это выглядит как некоторый продукт, поэтому здесь мог бы быть уже и product owner появиться. То есть это схема для команды там от двух до четырёх человек. В принципе, окей. Но как-то
Speaker A
выглядит маловато, да?
Speaker A
что-то. То есть точно ли это тот покупатель или точно ли это там тот магазин, который разместил заявку. Ну то есть нам бы было бы круто добавить какой-то ещё сервис для авторизации.
Speaker A
есть сервис, и каждый запрос, который требует авторизации, будет ходить сюда, получать информацию о том, действительно ли это пользователь наш, и есть ли у него доступ к это к этому запросу. Так называемая авторизация, да? Давай проверим. Значит, здесь мыт, а здесь, ну, либо 200, либо 400,
Speaker A
да? То есть либо 200 получаем, это хорошо. 200 - это HTP ответ, который говорит о том, что есть доступ. Ну давай окей или Error. Так будет удобнее.
Speaker A
О'кей. Скобочках 200, error 400. То есть нет доступа. 401 обычно дают. Супер. Хорошо. Стало гораздо лучше. Здесь этот A севиice, он может быть реализован по-разному. Здесь может быть своя база. Это может бытькock сервис, да?
Speaker A
Илики. Ну давай вот так вот запишем. Или киклок. Каждый раз путаю, как писать. Вот. Ну это либо может быть самописный какой-то сервис, который там как-то работает с GVT, либокlog - это по сути тоже сервис.
Speaker A
Ну так же как погрес, да? То есть ты можешь установить у себя там докер зависимость, как угодно, и пользоваться.
Speaker A
Там внутри своя база, API для того, чтобы проверять, валидировать токены, разные виды авторизации ССО и так далее.
Speaker A
Кстати, если тебе интересно про это более подробно узнать, обязательно пиши коммент. Я разберу эту тему максимально подробно. Мы напишем в фостапе приложение и обязательно попрактикуемся с разными видами авторизации, как это работает, понастраиваем киклок. В общем, должно быть интересно. Обязательно пиши
Speaker A
коммент. Я буду рад тебе помочь. О'кей, давай двигаться дальше. Перед тем, как запрос пойдёт в какой-то сервис, мы хотим его провалидировать на наличие прав, да? Вот. То есть наш запрос попадёт в IP Gway.
Speaker A
Там мы выдим требование, что этот запрос должен пройти верификацию. Мы сходим в наш сервис, получим пользователя из этого сервиса и уже с этим пользователем пойдём дальше в этот сервис или в этот сервис или без него пойдём. Ну, важно, что мы проверим,
Speaker A
что у нас есть доступ сюда. О'кей. Это всё тоже ещё пока про команду из двух тиречетырёх человек, не более. Ну, такое вот как бы небольшое приложение. Дальше здесь может появиться разного рода кэширующие штуки для того, чтобы снизить нагрузку на наше приложение.
Speaker A
Представь себе, один популярный блогер на своём YouTube канале начинает рекламировать товары из нашего интернет-магазина. Ну, предположим, он рекомендует нам купить вот этот вот прекрасный товар. И к нам приходит очень много трафика. Кстати, ссылка на этот товар будет в описании. К нам приходит
Speaker A
очень много трафика. И эта нагрузка большая на базу данных, да. И нам такая нагрузка не нужна, потому что товар, он редко меняется. То есть карточка товара не будет изменяться постоянно, в зависимости от того, кто зашёл. И мы можем закшировать это. То есть мы можем
Speaker A
запомнить состояние карточки на какой-то момент времени. То есть всю информацию, которую нам нужно для фронтенда показать, мы можем запомнить. Мы можем кэшировать на разных уровнях. Это разные методики. Сегодня мы поговорим про каширование на бэкэнде с помощью Редиса.
Speaker A
Давай прикрутим readyс. Для того, чтобы снизить нагрузку на нашу базу, мы будем просто запоминать нашу карточку, данные для нашей карточки. И при каждом запросе мы будем ходить в этот редис и спрашивать сначала, есть ли у тебя информация для этого. Мы можем
Speaker A
прикрутить дис на разных уровнях. То есть, смотри, мы можем его прикрутить здесь. Да, давай дис. Тогда наш запрос будет попадать сюда, проходить авторизацию, потом попадать сюда, потом попадать сюда. В целом это звучит логично. Неплохо. Но зачем нам делать
Speaker A
вот запрос сюда, если мы можем как бы проверить авторизацию и попасть вот сюда сразу же? То есть мы можем readyс поднять на уровень выше. Тем самым мы снизим с тобой нагрузку на наш order севиice. То есть запрос просто не пойдёт
Speaker A
туда, потому что мы с тобой вызываем наш endpoint, попадаем в AP gгateway, проверяем авторизацию и потом идём в readyс и получаем информацию о том, что у нас с тобой есть такой товар, и просто скачиваем его. То есть мы не нагружаем
Speaker A
базу. Супер, мы с тобой уменьшили нагрузку, кайф, все дела. О'кей, стало гораздо лучше, да? То есть у нас с тобой появились разные какие-то уже базворды, про которые ты видел в своём резюме, но не понимал, как они работают. Вот они и
Speaker A
ready, и база данных, и какой-то IP gгateway, и авторизация. Всё появилось. Теперь мы хотим предоставить интеграцию нашим заказчикам, да? То есть раньше мы продавали только свои товары, и здесь как-то через админку это делали. Кстати, мы можем её нарисовать, да, админ
Speaker A
панель. Она не будет торчать наружу, мы будем на неё подключаться сами откуда-то. Вот мы наполняли товары из админ-панели. Опять напоминаю, это может быть Джанга, это может быть фаста, это неважно. О'кей. Для того, чтобы дальше нам идти, нам нужно с тобой развивать
Speaker A
наш продукт. И мы хотим добавить интеграцию внешних магазинов для того, чтобы они продавали свои товары у нас.
Speaker A
Правильно. Для этой интеграции нам потребуется какой-то новый сервис. Давай сделаем его и назовём его storeссевиice. Сервис для то Да, что ты будешь делать? Storeсвиice. Сервис для интеграции наших с тобой магазинов. Сейчас мы не будем вдаваться в подробности то, каким образом у нас
Speaker A
связаны там товары и магазины. Как-то мы это проинтегрировали, это неважно. Админ-панель давай уберём сюда, чтобы она нам не мешала. Сейчас мы будем налаживать с тобой связь.
Speaker A
DB Store. Смотри, как связать наш storeсевиice с order. То есть мы теперь должны как-то размещать товары магазина в нашем сервисе товаров. Как мы это можем сделать? Мы можем тупо напрямую, на самом деле, ходить, но тогда у нас может получиться каша. То
Speaker A
есть мы начнём с тобой как-то очень сложно за за ветеевато вот так вот коммуницировать между сервисами. Куча стрелочек появится. Это белиберда. Но такое может быть. Ты можешь это встретить в своей команде или своей новой команде, в которой ты устроишься
Speaker A
буквально завтра. Поэтому не пугайся такого. Также мы можем наоборот пойти задом наперёд, пойти из-сервиса в AP gгateway, так как он знает, где кто живёт.
Speaker A
Да, ну, имеется в виду доменные адреса внутри нашей сети. И, соответственно, он пойдёт назад и сделает запрос и всё сделает. Так тоже можно сделать, но это не очень хорошо, потому что у нас и в эту сторону запросы есть, и наоборот
Speaker A
есть запросы. Ну, что-то согласись, как-то не очень выглядит. Ещё один из вариантов - это предоставить сервис. То есть у нас есть сервис хранения данных по магазинам наш внутренний, и мы можем как бы все эти изменения осуществлять из вне. То есть
Speaker A
мы можем ходить вот таким образом, да, то есть интеграция с магазином, это он, например, по апе приходит наш IP gitway, попадает storeсервис, и этот же запрос может пойти сюда что-то сделать. Уже лучше, уже стало гораздо лучше, но всё
Speaker A
равно нам как будто бы это как-то выглядит сложновато, да. Вот. Да, ещё у нас тут свой фрон.
Speaker A
Тут какой-то будет тоже доступ. Не очень удобно. Давай мы сделаем с тобой integration се, то есть store integration service. Этот сервис будет торчать наружу. Точно так же, как и FRНENД. наш с тобой клиент в виде магазина будет ходить сюда также авторизовываться, то
Speaker A
есть у него будет своя какая-то роль другая и так далее, и потом уже попадать в Torсвиice либо Worder севиice. То есть он может посмотреть свои товары, он может посмотреть кастомеров, которые у него там как-то зарегистрированы или как-то там взаимодействуют, причастны к
Speaker A
его магазину, и он может посмотреть информацию про себя, про свой магазин. Вот это более классический подход, но здесь появляется некоторая проблема.
Speaker A
Смотри, если вдруг магазин хочет выгрузить очень много данных каких-то по А, то он даёт большую нагрузку на IP Gateway, а отсюда ещё могут множиться запросы. То есть они могут быть сюда, сюда большие. Это будет прям очень тяжело для
Speaker A
нашего сервиса. Поэтому мы можем подумать, как-то по-другому интегрироваться с этим сервисом. Давай подумаем, как это можно сделать. Вот если что, то вот этот проект, он в принципе достаточно жизнеспособен. Это возможно такая реализация. Возможно, ты знаешь такие интернет-магазины или сам
Speaker A
работаешь в таком месте. Я буду рад, если ты мне это расскажешь. Это уже больше про команду из там трёх человек минимум. То есть два девелопера, 1 QA или 2 QA, потому что здесь достаточно много функционала, зависит от автоматизации ещё этого функционала. То
Speaker A
есть есть ли здесь какие-нибуд скрипты для интеграции. или вытягивание. То есть мы можем сами вытягивать у них данные из их какой-то бухгалтерии или откуда там с их складов. Либо мы можем как-то интегрироваться по апе с ними, либо ещё
Speaker A
по-другому можно как-то интегрироваться. Здесь много всякой логики, всякой авторизации. ФронтEND, скорее всего, у нас уже очень большое приложение стало, потому что есть и такой кабинет, и секой кабинет, и товары, и прочее. Это всё достаточно сложно, поэтому команда должна расти.
Speaker A
Здесь, на мой взгляд, оптимально будет там два-три разработчика, 2 QA бизнес-анаaltтик, потому что любая интеграция требует много коммуникации с внешним миром, поэтому здесь лучше предоставить хотя бы одного аналитика. Ну либо продакт может эту тему закрывать. И команда уже
Speaker A
получается больше пяти человек. Как будто бы здесь нужен для того, чтобы помогать управлять этой командой. Это может быть разработчик, это может быть product, это может быть lead QA, неважно. Он может быть по совместительству этим рядом, потому что у него не так много коммуникации с
Speaker A
персоналом, но как бы уже нужен ответственный человек, кто будет всем этим командовать. И ещё что здесь нужно уже добавить. Мне кажется, без этого уже очень трудно жить. Особенно когда мы говорим про внешние интеграции, мы несём ответственность. То есть мы, скорее
Speaker A
всего, берём деньги за это уже с реальных как бы клиентов бизнесовых B2B. И здесь мы несём ответственность, мы подписываем контракты с ними на такие понятия, как SL, возможно, Latency и так далее. Это метрики длительности работы наших запросов. То есть, ну или SL - это
Speaker A
доступность нашего сайта для внешнего подключения. Ну, то есть, грубо говоря, мы обещаем нашему клиенту, что наш интернет-магазин будет работать 99,999% времени в течение месяца. То есть максимум он будет не работать там 5 секунд. Для расчёта SL есть специальный
Speaker A
калькулятор. Вот его пример. Если нужна будет ссылка, скину тебе. Ну это вообще первая строчка Гугла. Как работает этот калькулятор? Мы вбиваем процент, о котором договорились, что наш сайт будет активен в это время, и получаем, сколько времени простое может быть доступно по
Speaker A
этому договору. Ну то есть, если мы подписали 99.9, Это значит, что за целый день наш сайт может не работать 1 минуту 26 секунд.
Speaker A
Обычно подписывают 99. Давай посмотрим. Угу. Ну, в день 8 секунд простое доступно. Вот в неделю одну минуту может не работать наш сайт. То есть это достаточно большие цифры, да? Ну, точнее наоборот, достаточно маленькие цифры для того, чтобы так рисковать контрактом.
Speaker A
Поэтому мы должны с тобой обмазаться метриками. Что такое обмазаться метриками? Для этого используется Прометеус и графана. Обычно это стандарт дефакто на рынке ты можешь встретить что-то другое, но базово почти все используют именно примете и графана. Это штука, которая собирает метрики. Ну давай,
Speaker A
давай, ладно, по-честному нарисуем, как это выглядит, чтобы не путаться. Вот смотри, Прометей собирает метрики со всех сервисов. То есть он сам, по сути, ходит на каждый сервис и спрашивает метрики у него. Я эти стрелочки сейчас уберу либо сделаю супер-пупер пунктирными,
Speaker A
тоненькими, чтобы мы их не видели, они нам, чтобы не мешали. Вот. А его суть в чём заключается? в том, чтобы сходить и каждый какой-то период времени, например, каждые 5 секунд спрашивать у сервиса: "Как у тебя дела?" И сервис
Speaker A
предоставляет ему в текстовом виде всю информацию о том, как у него дела, сколько, какую ручку вызывают, какая длительность запросов и так далее. И на основе этого мы можем построить какие-то графики в графане. Я думаю, что мы обязательно разберём эту тему более подробно. Сейчас
Speaker A
нам это не важно. Но нам важно просто понимать, что такая штука должна быть уже в этот момент. Это не совсем наша работа, это скорее уже работа девопсера.
Speaker A
То есть это не чистый ээкэнд. Но может быть такое, что девопсер поднял графану Прометей, настроил вот скрапметрик, то есть сбор этих метрик с наших сервисов, но сами дэшборды рисуем мы. Такое бывает. Я советую тебе для этого посмотреть сайт графана. Там всё
Speaker A
рассказано, как это рисовать. Ну, либо можешь написать комменты, мы обсудим, как нарисовать обычный дэшборд на обычное приложение, попрактикуемся, и ты попробуешь всё это своими руками и поймёшь, что особо сильно сложного чего-то нет. Что-то очень сложное обычно делают ребята, кто занимается этим
Speaker A
профессионально. SRE, DevOps и так далее. Бэкэндром обычно достаточно какие-то базовые вещи. RPS, latency SLA Aviability да например ну, вот CPU, RAM, количество подов, если мы говорим про кубер и так далее. Да, кстати, если мы говорим про Kuber, мне
Speaker A
кажется, здесь уже пора появляться Куберу, потому что если мы будем перекатывать наши сервисы, то есть останавливать и закатывать новую версию, новый функционал, то у нас с тобой будет отваливаться всё это просто-напросто, да, и мы не выдержим свой SL.
Speaker A
Поэтому мы сверху накидываем магический кластер Кубера и начинаем реплики делать. То есть у каждого сервиса будет по несколько реплик. И когда мы будем перекатывать, мы будем перекатывать их по одному контейнеру. В общем, здесь мы можем уже организовать деплой таким
Speaker A
образом, что у нас как-то перекатываются контейнеры, не роняя весь функционал сразу. Это может быть и blue green deploлоймент, и конареечный плой, и любой другой плой, который ты слышал.
Speaker A
Вот это уже команда достаточно зрелая. Она предоставляет неплохой сервис. Здесь могут быть ещё какие-то микросервисы различные, либо на самом деле это не обязательно должен быть микросервис.
Speaker A
Вполне вероятно, ты можешь встретить такую штуку в виде одного большого распределённого монолита. Выглядеть это будет так. То есть нет никакого апеateвея, он находится тут. Давай вот так вот это удалим пока. И это всё один большой монолит. Обычно такое можно
Speaker A
встретить на джанго. То есть каждый микросервис внутри - это как бы проект, да? А наружу торчит один джанга. Ну мы будем говорить про микросервисную архитектуру. Просто на схеме это гораздо удобнее смотреть, чем один большой квадрат. Обычно мы целимся в более
Speaker A
большую компанию, поэтому у нас может быть ситуация, что вот это всё разрабатывает одна команда, которая занимается интернет-магазином.
Speaker A
Есть другая команда, которая занимается доставкой товаров из этого интернет-магазина, так называемый Delivery сервис, да, пускай будет. Я его нарисую таким образом. И это будет просто большой большой квадрат. Под капотом этого квадрата может быть абсолютно такой же схематоз. И для нас наружу будет торчать
Speaker A
просто IP gгateway. Это может быть внутренняя авторизация, это может быть их внутренняя авторизация, это может быть кросссервисная авторизация для связи между нами. Неважно, как-то это сделано. Нам неважно. Мы просто знаем, что некоторые наши сервисы умеют ходить вот в этот delivy сервис. Давай его
Speaker A
покрасим в какой-нибудь интересный цвет для того, чтобы его отличать от других. Вот так вот. У нас может быть с тобой ещё какой-нибудь сервис. Я не знаю. Давай, давай назовём его севис или warehouse как хотите. House севис. Это будет склад. И
Speaker A
как-то мы умеем туда ходить. Ну давай, вот наш внутренний запрос мы умеем делать, а вот сюда, например, из ор из Delivery, например, customer сервис умеет ходить.
Speaker A
Всё это может разъезжаться. То есть нам на самом деле сейчас уже не так важно становится. У нас с тобой большая интеграция, сложная система. И здесь мы будем ходить по апе, например, да? То есть HTTP запросы по апе и так далее. Но
Speaker A
что если мы, например, хотим как-то асинхронно взаимодействовать? Я не хочу дёргать, вызывать хендлеры для того, чтобы узнать там как моя доставка поживает или ещё что-то. Ну, это выглядит сложно и как будто бы это какой-то оверхд. Поэтому давай мы всё
Speaker A
вот это откинем пониже. по Прометею графани, я надеюсь понятно. Я их убрал вниз, потому что мы всё это обсудили. Смотри, для того, чтобы мы начали коммуницировать с этими командами, либо даже сами с собой в асинхронной манере, то есть не вызывая
Speaker A
хендлер и дожидаясь ответа, а мы просто можем бросить какую-то штуку, и она потом как-то будет обработана. Так называемое сообщение. Для этого мы используем шину данных. Обычно шина данных в больших компаниях это Кавка. Ты можешь встретить ещё Rabit. Nats набирает популярность.
Speaker A
Тут может быть что угодно. Ну мы будем разбирать на основе кавки. Вот я нарисую синенький. Синенький - это такой как бы техническая штука, да, через которую мы взаимодействуем. То есть мы её не разрабатываем, мы её просто подключаем. Вот. И наши с тобой сервисы
Speaker A
могут посылать ивенты в Кавку. Вот. А да, да. Ну давай сделаем так. там send event. Также мы можем читать эти ивенты. То есть обычно посылаем ивенты мы либо из такого сервиса напрямую можем посылать, либо мы пользуемся специальными трюками. Если ты
Speaker A
хочешь узнать эту тему получше, то обязательно пиши комменты, и мы поговорим с тобой пробоtern, про transactional outbox pattern и вот про все эти штуки, которые требуются для того, чтобы гарантировать доставку ивентов и гарантировать обработку этих ивентов. Ну и раз я говорю про Outbox
Speaker A
Pattern, то у нас должен появиться где-то такая штука, как конюр, штука, которая умеет читать искавки сообщения и обрабатывать. Это не может быть наш с тобой ээкэнд-сервис, потому что это как бы отдельный процесс. Мы можем сделать так, чтобы это был отдельный сервис, но
Speaker A
в общем случае более надёжно принято поднимать отдельный какой-то контейнер. Это может быть в одном репозитории сервис и просто другая команда для запуска другого скрипта. По сути, этот скрипт делает что? Он делает while true, а, получает искавкие сообщения, обрабатывает, как-то может что-то
Speaker A
сложить в базу. Обычно консюмеры никак никому там ничего не посылают, никакому клиенту ничего не посылают. То есть как-то клиент через сервис только взаимодействует. Консюмер - это для того, чтобы реагировать на внешние ивенты в нашей системе и делать какие-то
Speaker A
действия. Например, давай представим с тобой ситуацию, что у нас есть вот складской какой-то сервис. И этот сервис он посылает ивент о том, что в магазине один кончились товары, да? То есть он event там store houseй, предположим такое название. Так,
Speaker A
я на не влезло в камеру. Вот оно. Store House Empy посылает такой ивент. Наш с тобой конюмер должен услышать этот ивент. То есть он его прочитает из кавки. Как это делается сейчас не имеет никакого смысла понимать. Просто поверь на слово, что
Speaker A
когда сообщение попадает в кавку, мы можем написать консюмер, то есть потребитель ивентов, который будет читать эти ивенты и скавки по определённому топику, по определённому названию. Вот мы с тобой по этому названию прочитаем. Давай мы его скопируем, чтобы точно не перепутать, и
Speaker A
напишем read. Э, вот такой вот ивент. Наш консюмер с тобой получил этот ивент о том, что у нас кончилось в магазине определённом кончились товары, мы сохранили это в базу, да, что у нас какая-то проблема случилась и так далее. И мы хотели бы
Speaker A
уведомить, смотри, мы можем переиспользовать вот этот integration сервис для того, чтобы наружу сходить. Либо наш консюмер сам может уметь ходить наружу, посылать запросы в магазины наши, да, алерт какой-то им послать, либо мы ещё можем с тобой воспользоваться нашим внутренним
Speaker A
сервисом. Ну, у нас же большая компания с тобой уже, поэтому у нас наверняка должен быть такой сервис, который делает notification сес. Этот сервис умеет нотифицировать внешние какие-то компании или ещё как-то там по имейлам, по апи, как угодно. Можем туда вот таким образом
Speaker A
проинтегрироваться. Или мы можем с тобой реализовать отправку имейлов либо других каких-то нотификаций, отложено каким-то образом. Обычно для этого используют серии и SMTP сервер, либо ещё какие-то штуки. Я просто нарисую сери, потому что очень часто в вашем резюме вы можете
Speaker A
встретить именно этот пункт сери либо другой какой-то асинхронную штуку для выполнения каких-то задач. Кронджбы те же самые. Это всё нужно для того, чтобы выполнить асинхронну задачу.
Speaker A
Смотри, как это будет выглядеть. Наш консюмер прочитал ивент, и его задача только читать эти ивенты и создавать какое-то следующее действие. То есть мы передаём дальше эту горячую картошку, чтобы следующий сервис выполнил свою работу. Мы не делаем один большой
Speaker A
комбайн, который делает всю логику. Мы делаем атомарные какие-то кусочки. Ну, это по принципу Solid, буква S, single responsibility. Я надеюсь, ты понимаешь, о чём я говорю. Поэтому давай мы сделаем здесь к этому консюмеру ещё notification, да? И получается наш с
Speaker A
тобой консюмер в сере ставит задачу для того, чтобы потом сери отправил сообщение. Сери в качестве брокера может использовать redis, и тогда связь будет выглядеть таким образом. Это может быть отдельный редис поднятый чисто для этого. Это может быть переиспользование
Speaker A
редиса. Тут как будет организовано. Конкретного правильного решения, конечно же, нет. Везде у всех всё по-разному.
Speaker A
Плюс ещё бывает такая вещь, как исторически сложилась. Поэтому не стоит настаивать, что мой рисунок неправильный. Я могу придумать 10 аргументов, почему это правильно. О'кей.
Speaker A
Вот появился наш с тобой селари, который умеет отправлять уведомления. Появился консюмер, который умеет читать из Кавки.
Speaker A
Появились продюсеры, которые посылают в Кавку ивенты. Появились сторонние сервисы, с которыми мы интегрируемся по апе. И появилось очень-очень много разной логики. Вот смотри, вот такую штуку уже могут разрабатывать три-четыре девелопера и больше. В какой-то момент команда может разрастись так сильно,
Speaker A
например, там семь девелоперов, 3 QA, два аналитика, Prodct, Teamle, и команда будет слишком большая, слишком будет много контекста. То есть тут и какие-то интеграции, и у нас какие-то там API наружу и для этих, и для тех, и магазины, и товары, и
Speaker A
кастомеры, и ещё какие-то разные уведомления, и ещё что-то. То есть может бизнес дорасти до такого состояния, что команда будет слишком большая и будет проще её разделить пополам и сделать две маленькие команды опять и поделить между ними логику пополам. Это тоже частая
Speaker A
практика. Получается, мы дошли с тобой до, наверное, максимально большого состояния команды. Это там 4 5ше девелоперов, 3 2 3 4 QA, несколько бизнес-аналитиков. Это уже достаточно большая система. И скорее всего, если ты проходишь собеседование сейчас в крупную компанию, ты, скорее всего, попадёшь во
Speaker A
что-то такое, какой-то примерно такого формата, где ты будешь отвечать за разные микросервисы. То есть у тебя будет один большой бизнес-домен.
Speaker A
Бизнес-домен в нашем случае - это интернет-магазин. И мы отвечаем за всё, что касается именно витрины данных, да, товаров, которые у нас здесь где-то находятся, как с нами интегрируются разные поставщики и так далее. Но мы не отвечаем за склад. Вот он. Мы не
Speaker A
отвечаем за доставку, мы не отвечаем там ещё за какие-то вещи. То есть мы как бы у нас свой бизнес-домен небольшой. В целом вот так выглядит примерно среднего уровня, который мы будем работать.
Speaker A
Дальше будет просто добавление каких-то новых контейнеров, новых каких-то сущностей, новых интеграций. Возможно, может появиться, например, такая штука, как витрины данных для аналитики.
Speaker A
Например, тот же Клихаус может для этого использоваться, да, и там как-то ордера будут туда отсылать свои данные. Мы будем анализировать, как нас покупают, с какой частотой, с какой ценой и так далее. Либо может появиться ещё такая штука, как Elastic Search. Это
Speaker A
штуковина, которая пользуются для полнотекстового поиска. Ну, когда ты вбиваешь, например, iPhone, ты же можешь написать просто там ph3 и найдётся iPhone 13. Вот для того, чтобы организовать такую систему, нужно настроить search. Это отдельный сервис. Вот. Давай покрасим их в синие,
Speaker A
так же, как мы договорились с тобой до этого. Также здесь могут появиться различные скрипты, которые будут что-то пересчитывать. Может появиться сервис. L команда, да, которая будет заниматься выставлением, динамическими ценообразованием или ещё чем-то. Что ещё может появиться? У тебя может появиться
Speaker A
и пайплайны всякие airflow и так далее для того, чтобы прокачивать большой объём данных и как-то его обрабатывать.
Speaker A
Давай составим список того, что нужно уметь для того, чтобы работать с такой большой легендой, для того, чтобы написать всё это в резюме или для того, чтобы уверенно рассказывать про это.
Speaker A
Первое, что должно быть в твоём списке - это, конечно, фреймворки. Здесь однозначно фастапи и джанга. Больше думать не надо. Никакие добавлять фласки, торнадо и прочее не надо.
Speaker A
Фастапи - это очень популярный современный фреймворк. Джанга - это тоже популярный фреймворк, но просто он уже немножечко устаревает. Эти два фреймворка позволяют закрыть тебе воронку больше 90% вакансий. Дальше думать не надо. Следующий шаг. Тебе нужно добавить SQL. Добавь просто погре
Speaker A
SQL. Пагрес - это стандарт индустрия. Де-факто почти все используют позгрес. Если где-то будет другая база данных, им подойдёт твой опыт с пасгресом. А вот наоборот, не факт. Если ты напишешь Мария DB или там MySQL, MSSQL, то ребята с позгресом могут на тебя криво
Speaker A
посмотреть и не позвать даже к себе на собеседование. Поэтому посгрес достаточно. Также стоит добавить какой-нибудь, э, фреймворк ORM для взаимодействия с базой данных. Если мы говорим фастапе, то это SQL Алхимия.
Speaker A
Если мы говорим Jungo, то это Jungo Orm. Выбери что-то одно. Я советую ориентироваться на фостапе. Следующая штука, которая должна быть в стеке твоих технологий - это сеary. Сери - это вещь, которая позволяет нам асинхронно выполнять какие-то задачи. На нашей
Speaker A
схеме это микросервис, который отвечает за отправку уведомлений. Это может быть ещё какие-нибудь outбоксы решения и так далее. Ну, в общем, сери - это очень простой инструмент. Ты можешь его изучить очень быстро, поэтому обязательно добавляй его в своё резюме.
Speaker A
Если появляется сери, то рядом где-то должен быть дис, потому что дис может использоваться как брокер для селари, то есть хранилка очереди, куда мы закидываем эти задачи для того, чтобы наш с тобой сериал. Так-то ещё Rabit MQ используется. Ну неважно. А ещё дис
Speaker A
используется для кэширования, так же как мы делали сегодня в нашей схеме. Следующая большая штука, которую желательно добавить в своё резюме - это Кавка. Эта вещь помогает нам интегрироваться с другими командами для event system, да, то есть для систем,
Speaker A
которые построены на базе ивентов или шины данных. Здесь никакого рокетса особо нет. Просто ты должен разобраться, как работает кавка. Ты можешь попрактиковаться локально, поднять у себя локально кавку прямо из докера и побликовать сообщение и почитать сообщения. И, в принципе, ты поймёшь,
Speaker A
как это работает. Но обязательно не забудь добавить в свой список вещи для того, чтобы настроить обзервабилити своей системы, то есть возможность наблюдать за ней. Это графана для сбора метрик и отображения этих метрик. Ну и селлеры для того, чтобы собирать ошибки.
Speaker A
Это такой сервис, который позволяет нам собирать ошибки с сервиса и показывать, если вдруг что-то пошло не так. Вот стандартный набор джентльмена для того, чтобы стать бэкэндером, ну либо чтобы работать бэкэндером. Всё остальное, что можно прикрутить сверху, слева, справа,
Speaker A
уже не несёт такой большой ценности, как вот этот костяк знаний. То есть Click House, Machine Learning, Elastic Search, Rabbit MQ, я не знаю, какие-то другие вещи, какие-то другие фреймворки, другие языки программирования и так далее, и так далее, и так далее. Они все дают очень
Speaker A
мало буста по сравнению с тем, как дают вот эти главные базворды всего бэкэнда. Это самые конверсионные вещи, которые могут быть. То есть, добавляя их в резюме и разбираясь с этим стеком технологий, ты увеличиваешь свою возможность устроиться на работу
Speaker A
кратно. Поэтому я советую сфокусироваться только на этих знаниях. Ну, то есть это достаточно большой путь, достаточно сложный путь, но в целом я думаю, что после такого видео стало гораздо понятнее, чем вообще занимается бэкэндер, что за сервисы такие, как всё
Speaker A
это выстраивается, как это всё взаимодействует. Дальше ты уже должен точечно копать в каждую дырочку и понимать, как с чем взаимодействовать.
Speaker A
Ну а эту схему и список того, что нужно знать для неё, я выложил в свой Telegram-канал. Ссылка будет в описании.
Speaker A
Я надеюсь, тебе было интересно это видео и очень полезно. Сегодня мы узнали много новой информации, ну либо не новой, просто освежили её. Важно, чтобы ты понимал, в какую команду ты идёшь. И обязательно нарисуй такую же схему для своей легенды, потому что если ты не
Speaker A
разбираешься в том, что ты делал, то, наверное, тебя не наймут. А так до встречи на созвоне. Пока. M.
Topics:бэкендмикросервисыархитектураинтернет-магазинAPI Gatewayбалансировщик нагрузкиPostgresразработкаbackendкоманда
