👀 Продолжение про модульный монолит и его направленность на переход в микросервисы 👀

Получается, что если разработчики заранее позаботились об организации структуры кода в монолите - разбиении его на независимые модули, то в дальнейшем он легко “пилится” на сервисы и микросервисы. Но как?

Уточню несколько моментов про контейнеризацию, независимые релизы, Kubernetes и OpenShift.



▫️ Сервер-приложение модульного монолита по умолчанию упаковывается в один контейнер

Модульный монолит - это одна кодовая база. “По волшебству” обновлять отдельно каждый модуль, как микросервисы, не получится.

Как модульный монолит может работать на старте:

1. Пусть у нас уже есть модули кода, которые могут работать независимо. В идеале, без вызова других.

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

3. Итого, этот один контейнер будет релизиться через Kubernetes всё ещё как одно большое монолитное сервер-приложение. В консоли OpenShift мы будем видеть одно сервер-приложение, которым можно управлять - увеличивать или уменьшать количество запущенных экземпляров.

👉 Это случай, когда модульность никаких преимуществ ПОКА не даёт.

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




▫️ Далее, каждый модуль монолита может быть упакован в отдельный контейнер и работать независимо

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

Когда модуль упаковывают в отдельный контейнер, то происходит примерно следующее:

1. Берут код модуля из общего репозитория монолита.
Что касается дальнейшего хранения кода. Есть разные решения, но скорее всего код модуля будут выносить из общего репозитория.

2. Берут библиотеки, конфигурации и другие ресурсы связанные с модулем.

3. Проверяются зависимости с другими модулями:
3а. Если их не было - готово! Ваш модуль может быть вынесен из монолита и упакован в отдельный контейнер.
3б. Если они были, то тут сложнее. Надо продумывать как вынесенный модуль будет взаимодействовать с основным монолитом. Надо глубже погружаться в особенности взаимодействия подов в Kubernetes, в межсервисное взаимодействие в Kubernetes.

4. Упаковывают всё, что взяли, в отдельный контейнер от основного монолита.

5. Запускают контейнер отдельно и независимо.

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

А если ему добавить свою БД, убрать взаимодействие с общей БД, добавить API, и еще много других важных действий, то он станет микросервисом. Но это уже слишком много дополнительных действий, которые требуется сделать.




▫️ Итого:

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

Это знания, которые не требуют от аналитиков. Но они являются полезным дополнением при погружении в архитектуру систем.

❗️Коллеги аналитики, вопросами развертывания монолита и правильной упаковки модулей в контейнеры занимаются разработчики и команда инфраструктуры (DevOps специалисты, которые отвечают за релизы приложений). Это их зона ответственности и системных аналитиков сюда не допускают.

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


Для тех, кому стала интересна тема инфраструктуры, даю почитать понятные для аналитиков статьи, от которых можно далее продолжать исследования в темах инфраструктуры и DevOps для монолитов и микросервисов.

Отдельным постом 👇📚📚📚


#АрхитектураGA

📚 Подборка статей для погружения в тему инфраструктуры и релизов приложений 📚

Для тех, кому стала интересна тема инфраструктуры, даю почитать понятные для аналитиков статьи, от которых можно далее продолжать исследования в темах инфраструктуры, CI/CD, DevOps.

Читать по порядку.

📚 Модульный монолит
Пост про модульный монолит

Модульный монолит. Начало - отличная статья с картинками про принципы выделения модулей и их взаимодействия



📚 Контейнеризация приложений
Пост про контейнеры, Openshift и Kubernetes простыми словами

Что такое контейнеризация - статья написана простым языком и плавно переходит к теме Kubernetes. Рекомендую обратить внимание на разделы слева. Много хороших статей по порядку про инфраструктуру

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

Docker контейнер и 15 способов его применения (англ) - что такое Docker и его применение, про основной инструмент для создания контейнеров. Обратите внимание на доп. статьи по содержанию слева.

Перенос в Doker монолитного SAAS сервиса - история переезда, но может показаться перегруженной для аналитиков тех. детализацией (много скриптов)

Как поместить это огромное монолитное приложение в контейнер? (англ) - прекрасная статья про переезд с монолита, дополняющая техническими деталями мои посты выше.

Лучшие альтернативы для Docker - потому что есть не только Docker.



📚 Kubernetes и его устройство
K8S для начинающих - еще раз повторить основы и погрузиться в устройство.

Поды и узлы. Устройство Kubernetes - чтобы понять, куда и как устанавливают контейнеры, понять отличия в нодах, подах и узлах.

Взаимодействие сервисов развернутых внутри Kubernetes - когда выносите модуль из монолита и есть связи

Сетевое взаимодействие подов Kubernetes - еще про взаимодействие



📚 Другое
История про распил монолита и с чего начать (англ)


#АрхитектураGA

⚡️ Как выделять микросервисы ⚡️

Разделение логики приложения на независимые микросервисы или модули — важный навык для разработки современных приложений.

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


👉 Еще раз про ключевое:

✔️ Самая нагруженная логика выносится в отдельные микросервисы, которые могут быть запущены в большем количестве копий, чем остальная часть системы.

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

+ микросервис “каталог товаров” запущен в 10 параллельно-работающих экземплярах,

+ микросервис “заказы” запущен в 5 параллельно-работающих экземплярах,

+ другие микросервисы, которые будут отвечать за другие логические части работы системы.


✔️ Независимые релизы отдельных микросервисов.

Пример:
В сервис “каталог товаров” добавляют новую функцию “оставить отзыв на товар”. Нужно поменять БД - добавить таблицы и поля под хранение отзывов, и поменять саму логику сервиса.

При обновлении сервиса “каталог товаров” будет обновление кода только для него и его БД, только он может быть временно недоступен. Все остальные сервисы, которые не пользуются информацией из каталога товаров, будут работать стабильно.

Например, сервисы “управление пользователями”, “платежи за заказы” и “уведомления” продолжат работу как ни в чем не бывало. Кроме того, их функциональность и код остаются нетронутыми, то есть их не надо тестировать.


👉 Как делить:

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

А что по поводу остальных, нестандартных? Мы познакомились с базовыми принципами выделения микросервисов.


Пора применить оба этих поста на практике для проекта #RideFlow.
Подробное описание работы системы доступно по этой ссылке.

👉 В следующих буду последовательно разбирать процесс работы приложения и обосновывать выделение каждого микросервиса.

#АрхитектураGA

⚡️ Часть 1. Выделяем микросервисы: разбор примера для #RideFlow ⚡️

Делаем вычитку процесса работы системы заказа такси, выделяем микросервисы и даем обоснование.

1. Регистрация и аутентификация пользователя

Прежде чем оформить заказ, необходимо идентифицировать пользователя.

Для регистрации пользователи должны использовать email и номер телефона.
Учетная запись подтверждается кодом из СМС.

🔸 Сервис “Управление пользователями”
Стандартный сервис.

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

Функции:
- Обработка и сохранение данных о новых пользователях.
- Генерация кода подтверждения и передача его в сервис уведомлений для отправки в СМС.
- Генерация ссылки для подтверждения email и передача ее в сервис уведомлений для отправки на почту.
- Здесь же обрабатывается вся логика связанная с изменением данных о профиле пользователя, его блокировка.


🔸 Сервис “Авторизация”
Стандартный сервис.

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

Он будет проверять учетные данные, предоставленные ими при входе, и определять, имеет ли пользователь доступ к системе, его права доступа в зависимости от роли. Если да - выдавать ключи доступа для выполнения запросов к системе (токены).


🔸 Сервис “Уведомления”
Стандартный сервис.

Через него будет реализована рассылка уведомлений с использованием интеграций к внешним системам: SMS, почта, push-уведомления.

Любой сервис в системе сможет стать инициатором для отправки уведомления. Для этого он будет публиковать структурированные сообщения в брокер, с указанием каналов рассылки.

Сервис будет следить за сообщениями в брокере. При получении сообщения он будет определять каналы рассылки и отправлять уведомления через соответствующие интеграции.



Это мы только один шаг разобрали, а уже три сервиса и брокер появились 🙂

#АрхитектураGA

⚡️ Часть 2. Выделяем микросервисы: разбор примера для #RideFlow ⚡️

2. Планирование маршрута

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

🔸 Сервис “Карты”

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

Основные функции:
- Поиск пунктов отправления и прибытия по названию.
- Работа с координатами пунктов с карт.
- Определение доступных и недоступных зон посадки и высадки пассажиров.


🔸 Сервис “Геолокация”
(не из этого процесса, но сразу хочется выделить)
Сервис отвечает за работу с геопозициями пользователей и автомобилей.

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


🔸 Микросервис “Калькулятор стоимости поездки”
На основе переданных данных о пункте отправления и прибытия сервис рассчитывает актуальную стоимость поездки по всем категориям авто, до оформления заказа такси клиентом. Он делает это с учетом времени суток, доступности автомобилей и других критериев, которые собирает и анализирует.

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

3. Выбор такси, подтверждение и оплата заказа

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

🔸 Сервис “Заказы”
Отвечает за создание заказов в статусе “новый”, перевод статусов до “заказ выполнен”, контроль оплаты. Автоматически отменяет заказы, которые не были оплачены в течение определенного времени. Инициирует сбор обратной связи по заказу от водителя и клиента такси.


🔸 Микросервис “Платежи”
Стандартный сервис.

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

4. Поиск водителя

Под заданные пользователем критерии проводится поиск водителя.
Водителям в радиусе пункта отправления направляется уведомление с предложением о новом заказе.

🔸 Микросервис “Водители”
Отвечает за управление информацией о водителях, а также хранит их актуальные статусы - не работает, занят или доступен для выполнения поездок.

🔸 Микросервис “Поиск водителей для заказов”
На основе переданных данных о пункте отправления и категории авто сервис собирает данные по доступным водителям в зоне посадки (водитель свободен и в определенном радиусе от места посадки) и формирует уведомления водителям, которые свободны и могут взять заказ.

Еще сервисы, которые ранее указали:
🔸 Сервис “Заказы” - для смены статуса на “в ожидании авто”, когда заказ возьмет водитель или для отмены, если машину не найдут или пользователь сам отменит заказ, пока автомобиль будут искать.
🔸 Сервис “Уведомления” - для рассылки уведомлений.

5. Подтверждение заказа водителем и ожидание поездки

Пользователь получает информацию об автомобиле, водителе и времени ожидания до начала поездки.

Тут помогут сервисы, которые выделили ранее:
🔸 Сервис “Заказы”
🔸 Сервис “Уведомления”
🔸 Сервис “Геолокация”


Обращаем внимание, что где-то "микросервис", а где-то "сервис". Поясню в посте с оставшимися сервисами и микросервисами 😉

А если у вас есть предложения, какие еще сервисы и микросервисы можно добавить на основе этой части требований - пишите в комментарии 👍

#АрхитектураGA

Был момент, когда я решила начать смотреть на системы как архитектор, и искала, что почитать. Одна из книг, которая попалась тогда на просторах Интернета:

📚 Domain Driven Design. Предметно-ориентированное проектирование
🙏 Эрик Эванс

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

👉 Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.

Цитаты:
📝 Проект сталкивается с серьезными проблемами, когда в нем отсутствует единый язык коммуникаций. У специалистов в предметной области свой жаргон, у разработчиков - свой. Терминология повседневных дискуссий оторвана от терминологии, внедренной в код. Возникают сложности перевода.
Вывод: бизнес-сущности в реальности и в модели стоит именовать одинаково, создавать общий язык для описания предметной области между заказчиками и разработчиками

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

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

В книге есть примеры Java-кода. Кому сложно - пропускайте. Разобраны интересные практические кейсы. Большая часть книги написана простым языком. Рекомендую 😉

❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 Деление монолита на микросервисы: пошаговый план с примером
⏰ 19:00 - 22:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

Читаю отзывы к открытому вебинару и восторгаюсь! ❤️ Спасибо за ваше активное участие в практике по переходу от монолита к микросервисной архитектуре!


Что мы с коллегами успели сделать:

✅ Посмотрели на варианты монолитной архитектуры на примере проекта #RideFlow, который обсуждаем в канале. На примерах разобрали в чем преимущества, а в чем недостатки монолита.

✅ Вместе делили монолит на микросервисы и узнали способы, по какому принципу это деление происходит.

✅ Познакомились с главными принципами SOA и MSA, определили их отличия, преимущества и недостатки перед монолитом.

✅ Проработали сценарий миграции одного из модулей монолита в микросервис. Разбирали “подводные камни”, связанные с изменением схемы БД — смотрели на ER-диаграмму и определяли требования к выносу данных из монолита.

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

✅ Узнали, как аналитик может расти в направлении архитектуры. Разобрали вакансии архитекторов в IT, выделили их ключевые навыки и обязанности, сравнили с задачами системных аналитиков.

Много полезной информации, которую сразу применяли в деле.
Итог — пополнили копилку ваших знаний разбором очередного кейса! 🙌



❗️📹 Запись вебинара «Деление монолита на микросервисы: пошаговый план с примером» будет доступна с 1 по 3 сентября.
Только для зарегистрировавшихся.
Регистрация закроется завтра, 31 августа, в 12 Мск.
Письмо с доступом придет 1 сентября.

🟢 ПОЛУЧИТЬ ДОСТУП К ЗАПИСИ 🟢


Это был наш открытый урок к программе Архитектура Систем для системных аналитиков, и я рада приветствовать нашу новую команду, с которой мы продолжим дальнейшее изучение темы во всех деталях в ближайшие 3 месяца! ❤️‍🔥

🧐 Как выделять микросервисы (МС)? 🧐

1️⃣ По группам функций
Каждый МС представляет собой логически связанную группу функций или бизнес-объектов.

Функции, связанные с:
- отправкой уведомлений.
- определением геолокации такси и отображением машин на карте.
- заказом, включая оплату.


2️⃣ По доменам (Domain-driven Design, DDD)
МС отвечают за ограниченные контексты в соответствии с принципами DDD. Каждый контекст содержит свою зону ответственности или бизнес-логику.
Подробное погружение в книге Эрика Эванса “Domain Driven Design”.

В контексте "Заказы" есть объект "Заказ", который имеет свойства и методы, связанные только с ними.
В контексте "Платежи", есть объект "Счет", который не знает ничего о заказах, но отвечает за их оплату, и содержит метод "ВыставитьСчет()" для этого.
Эти два контекста - микросервисы, могут взаимодействовать, но их логика и данные разделены.


3️⃣ По данным
Каждый МС управляет одним объектом данных или небольшой логически связанной группой объектов.

Управление данными:
- об автомобилях,
- о пассажирах,
- о водителях,
- о заказах,
- о платежах.
Это 5 отдельных МС.


4️⃣ По пользовательским сценариям (User Story / Use Case)
Каждый МС обслуживает только один сценарий или ограниченный набор сценариев, минимизируя взаимодействие с другими сервисами.

Сценарии:
МС1: Начисление бонусов за поездку
МС2: Создание заказа
МС3.: Ррасчета стоимости поездки
МС4: Сценарии оплаты


5️⃣ По уровню нагрузки
Определяют части системы, которые подвержены наибольшей нагрузке. Их выделяют в отдельные МС.

- Сервис “Геолокация” нагружен получением координат от авто.
- Логика расчета стоимости поездки используется кратно больше, чем функциональность создания заказов. Лучше поделить на два отдельных микросервиса.


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

➡️ Главное, донести до команды всего проекта или продкута через архитектурную документацию, какие именно подходы действуют при создании новых микросервисов, и главное почему 🙌📝

#АрхитектураGA

🍁 В детстве мне казалось, что мы празднуем два Новых Года: 1 Сентября и 1 Января. Оба праздника и сейчас заставляют задуматься о возможных переменах в жизни, о новом этапе в развитии 🌱🙌

В недавно прочитанной книге Кармин Галло мне понравилась фраза:

“Страсть человека к собственному росту важнее всего. А мы помогаем ему искать знания — ведь никто в мире не может добиться успеха в одиночку. Человеку с идеей может недоставать каких-то знаний, но знания можно получить.”

В этот день, 1 Сентября, я хочу пожелать вам продолжать быть исследователями, любопытствовать и искать новые возможности для собственного роста 💚

👉 Вы уже с нами, в сообществе GetAnalyst, а значит по умолчанию думаете о своём развитии и растете в знаниях. А я здесь, чтобы помочь вам идти вперед и поддержать на пути, любыми способами.

У тебя всё получится, помни об этом!

Ценю вас. Верю в каждого из вас. Вы лучшие!

С Новым Годом С Днем Знаний! 📚🍁

⚡️ Часть 3. Выделяем микросервисы: разбор примера для #RideFlow ⚡️

По оставшимся требованиям с описанием процесса заказа такси видим, что мы начинаем переиспользовать сервисы и микросервисы, описанные в первой части. Это хорошо.

6. После завершения поездки
6.1. Заказ переводится в статус выполненного.
6.2. Рассчитывается сумма для выплаты водителю и переводится ему на баланс.
6.3. С пользователя собирается обратная связь - оценка поездки.

Подойдут сервисы, которые выделили ранее:
🔸 Сервис “Заказы” - для смены статуса заказа
🔸 Сервис “Уведомления” - для рассылки уведомлений о необходимости собрать отзывы по заказу
🔸 Микросервис “Калькулятор стоимости поездки” - для расчета суммы выплаты водителю

И нужен будет новый сервис
🔸 Микросервис “Выплаты водителям” - через него будут проводиться выплаты водителям, хранение информации по их банковским реквизитам и учету “ЗП”.

7. Выплаты водителям
В конце суток, раз в 24 часа, производятся выплаты водителям на их банковские счета, с формированием платежных документов, которые отправляются на email водителям и доступны для загрузки в их приложениях в формате PDF.

Здесь нужны:
🔸 Микросервис “Выплаты водителям”
🔸 Сервис “Уведомления” - для рассылки уведомлений об успешных выплатах с PDF

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


В конце описания системы такси есть дополнительные требования по администрированию системы, из которых можно выделить 🔸сервис “Админка”, 🔸сервис “Чат поддержки” и 🔸сервис “Диспетчерская”.

На этом разбор примера выделения микросервисов можно завершать. Осталось собрать полученные результаты в единую схему архитектуры 🙂🏛

#АрхитектураGA

🗡 Сервис или Микросервис? 🗡

Почему в разобранном примере (предыдущий пост + эти) в одном месте я писала “сервис”, а в других “микросервис”? Почему “Сервис уведомлений”, но “Микросервис Калькулятор стоимости поездки”?

🟪 Микросервисы (МС):
✔️ Маленькие, как правило управляют одним объектом данных (только водитель, только машина, или только пассажир), делают одну задачу или обслуживают один процесс
✔️ Своя независимая БД
При выделении микросервисов есть одна проблема - не перейти на наносервисы, которые делают одну задачу, и при этом их вызывают редко. Это не нужно.

🟪 Сервисы:
✔️ Больше, чем МС. Могут иметь много логики внутри, отвечать за разные данные (делать все сразу для данных о водителях, машинах и пассажирах), делать разные задачи и выполнять несколько схожих процессов.
✔️ Может быть своя независимая БД, а могут использовать общую на несколько сервисов.
Сервисы - это мини-монолиты 😅 Так что по сравнению с микросервисами проблема другая - вовремя остановиться и не сделать большой монолит.


Если говорить в целом о подходах микросервисной архитектуры (MSA) и сервис-ориентированной архитектуры (SOA), то отличий будет больше:
- разные шаблоны проектирования,
- организации хранения данных по отдельным БД и схемам,
- разные способы интеграции сервисов и микроервисов внутри проекта - шина, API Gateway, прямые вызовы по API и другие.


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

Считаю, что желательно стремиться к общепринятым и понятным всем именованиям компонентов в архитектуре проекта. Чтобы при подключении новых сотрудников к проекту не получать каждый раз одни и те же вопросы “А почему так?”

#АрхитектураGA

🤖 ChatGPT для проектирования БД 🤖

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

Но в то же время, если вы используете нейросети:
✔️ Умея решать задачи по аналитике самостоятельно
✔️ Зная алгоритмы работы и последовательности команд
✔️ Используя правильные связки инструментов
то нейросеть может стать вашим помощником! 🤝

Если вы умеете проектировать БД на логическом уровне, ищите возможность развиваться в темах БД и SQL, и хотите ускорять свою работу с использованием нейросетей, то приглашаю вас на онлайн-практику:

🟡 Использование ChatGPT для проектирования БД
📆 5 сентября, четверг
🕘 19:00 - 21:30 МСК
Подробности и запись

План:
1. Знакомство с ChatGPT
2. Проектирование физической модели БД PostgreSQL
3. Автоматическая отрисовка ER-модели с использованием ChatGPT и дополнительных инструментов
4. Создание реальной БД и SQL-запросы в DBeaver

Запись будет доступна по окончании занятия. А пока ждем четверга, можно посмотреть занятие в записи по написанию SQL-запросов с практикой в реальной БД через DBeaver 😎

🔆 Пример схемы архитектуры с микросервисами 🔆

Когда мы делим монолит на микросервисы, то процесс обмена данными в проекте усложняется. Другими словами: алгоритмы усложняются и простые Use Case становятся интеграционными.


1️⃣ В монолите взаимодействие разных логических частей в одном месте и API нужны только для UI, чтобы получать данные с сервера и отображать на экранах пользователей.

В микросервисах дополнительно нужны API для внутренних взаимодействий между ними. У каждого микросервиса свой API.

Для внутренних взаимодействий часто выбирают gRPC / GraphQL, оставляя для UI и других взаимодействий за пределами сервера популярный REST API.


2️⃣ Нужно выбрать подход к взаимодействию сервисов и микросервисов в проекте. Основные:

✔️ API-Gateway: единая точка входа для всех запросов от клиентов, направляет их к соответствующим микросервисам

✔️ Хореография: сервисы обмениваются событиями напрямую, принимая решения на основе полученных событий

✔️ Оркестрация: один сервис (оркестратор) управляет вызовами к другим сервисам, контролируя весь процесс выполнения задачи

✔️ Шина данных (Enterprise Service Bus, обычно для SOA): направляет сообщения между сервисами, преобразует данные и выполняет оркестрацию процессов

✔️ Очереди сообщений, как Kafka и RabbitMQ: для асинхронного взаимодействия и гарантии доставки и их обработки сервисами

Без подхода - будет паутина связей. Да и с ним тоже, честно говоря



👉 На картинке к посту:

🔸 Выбран подход с API-Gateway
Просто предствьте что будет, если убрать эти три API-Gateway в левой части. Когда приложения с UI будут сами выбирать какой микросервис вызывать и вызывать их API напрямую 🥲

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


❗️Эта реализация - общий вид, черновик. Далее нужно добавлять БД, выбирать API, делать вычитку требований и описание процессов, чтобы проверить взаимодействия. Делать C4.

Cхема показывает:
- МСА это не сложно, но трудоемко
- Чем меньше МС, тем лучше и проще 😃

#АрхитектураGA

⚡ Виды API и их назначение: когда и какой выбрать ⚡

API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.

Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface).


Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket


В деталях 👇

⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).

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

Пример документации:
Wildberries


⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.

Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.

Пример документации:
PayPal (обратите внимание, что устаревший)


Самые интересные API с примерами документации чуть позже 😉👇

#АрхитектураGA

⚡ Виды API: GraphQL, gRPC, WebSocket ⚡

⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.

Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.

Пример документации:
Contentful


⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.

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

Пример документации:
Dropbox от Google


⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.

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

Пример документации:
Binance Биржа


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

#АрхитектураGA

🤖 Интеграция по API с нейросетью или с геокодером? 🗺

Привет, коллеги! Сегодня я должна выбрать проект на ближайший месяц и опубликовать задачу на Интеграцию систем.

В очередной раз пошла смотреть свою базу открытых API, на которых можно провести демо по проверке запросов через Postman. Это важно, чтобы действия по исследованию API вы могли повторить самостоятельно. Иначе задачи на интеграции так и останутся для вас чем-то абстрактным и непонятным.

В итоге у меня возникла дилемма…


🤖 Нейросети - интеграция по REST API или gRPC
Сначала мне показалось это прекрасной идеей, пока я не поняла, что никакого бизнес-смысла у задачи не получится.

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

Так еще и сложно в тестировании местами, особенно с процессом регистрации и авторизации запросов.


🗺 Геокодер или разбор адресов по REST API
Отличная и понятная бизнес-задача, когда нам нужно превращать криво введенную строку в структурированный адрес - город, улица, дом и т.д. А потом можно показывать этот адрес в виде точки на карте.

Задача простая, но с подвохами. Кроме того, она “бытовая” - вы с такой функциональностью могли многократно встречаться в жизни и понимаете, почему она важна для внедрения в любую систему.


🧼 Интеграция по SOAP API
У меня давно просят показать особенности работы аналитика с SOAP, с форматом XML, и есть отличный демо-API для управления пользователями системы.


Хочется всё, но так не получится.
Поэтому хочу обратиться к вам за помощью в выборе 🙏

Голосование 👇