Просто помни об этом 😉

💫 Пример C4 / Container для монолита с брокерами, БД и ФХ - проект RideFlow 💫

Рассказала теорию про основные виды архитектуры: монолиты, сервисы и микросервисы.
Показала пример схемы монолита #RideFlow без нотаций.
А теперь хочу показать этот же монолит, но уже с использованием нотации C4 / Container.


➡️ C4/Container расширяет расширяет предыдущий уровень C4/Context, на котором вид архитектуры уже точно должен быть понятен.

➡️ Основное на схеме C4 / Container для монолита (🔗ИСХОДНИК):
- Пользователи
- Внешние системы, оборудование
- Приложения с UI
- Монолитное сервер-приложение - Backend
- Базы данных - для монолита обычно одна, отдельные схемы не отражают
- Файловые хранилища
- Очереди, брокеры


Почему я подробно показываю и разбираю монолиты?

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

Монолит идеален для небольших проектов и стартапов. И можно остановиться на нём для RideFlow, но...

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

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

Дополнительно про "жесткий монолит":

В нашем проекте мы избегаем "жесткой монолитной архитектуры" — мы не будем смешивать код пользовательского интерфейса веб-приложений (UI) и Backend (серверной логики и обращений к БД), как это обычно бывает в монолитах.
Такое решение обусловлено наличием мобильных приложений, для которых потребуется разработка API.

➡️ Итого:
На схеме показана современная версия монолитной архитектуры, где монолитом является только Backend (приложение сервера).


Внутри монолитного Backend можно будет организовать функциональные модули.
Их, согласно нотации C4, показывают на следующем уровне - C4/Component.
Модульный монолит в будущем поможет легче переехать на сервисную или микросервисную архитектуру.

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

⭐ Масштабирование - что важно понимать ⭐

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


Масштабирование может быть вертикальным или горизонтальным.

⭐ Вертикальное масштабирование (scaling up/down) означает добавление ресурсов к одному серверу или экземпляру приложения. Например, увеличение объёма оперативной памяти, мощности процессора или места на диске.

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

👉 Вертикальное масштабирование имеет свои ограничения, связанные с максимально доступными ресурсами оборудования - нельзя бесконечно добавлять память и ядра процессора.


⭐ Горизонтальное масштабирование (scaling out/in) подразумевает добавление дополнительных экземпляров серверов или приложений, работающих параллельно, для распределения нагрузки. Т.е. запускаются одинаковые копии приложений.

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

👉 Горизонтальное масштабирование обычно предпочтительнее, так как оно обеспечивает более высокую доступность и устойчивость к отказам.


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


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

⚡️ Переезд на микросервисную архитектуру ⚡️

Микросервисная архитектура (MSA) - это подход к разработке, при котором система состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет определенную бизнес-функцию.

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

Такое деление позволит оптимально применять принцип горизонтального масштабирования.

👉Ситуация:
Сервис геолокации использует большой объем ресурсов сервера и из-за него тормозит всё приложение.
👉Решение для монолита:
Вертикальное масштабирование, пока это возможно, или горизонтальное - выделение мощностей для параллельно работающей копии монолита, хотя причиной проблем является только одна его часть.
👉Решение для микросервисов:
Горизонтальное масштабирование независимого сервиса геолокации - выделение мощностей для развертывания только его параллельно работающих копий.

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

Специалисты, кто имеет опыт работы c MSA, стоят на порядок дороже. Не каждый маленький проект или стартап могут себе это позволить.

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

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

⚡️ Принципы выделения микросервисов ⚡️

Первое, что нужно понять при разработке системы в MSA - как выделять микросервисы? 🧐

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

Базовые принципы выделения микросервисов:

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


2. Выделение по техническим аспектам:

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

2.2. Независимость разработки и развертывания: микросервисы выделяются так, чтобы разные команды могли разрабатывать и деплоить (выпускать обновления) сервисы независимо.
Пример: Сервис управления пользователями и сервис оплаты могут разрабатываться разными командами. Если будут выпускать обновления для сервиса пользователей и он будет на время обновления временно недоступен, то сервис оплат продолжит работать без остановки

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


3. Разделение по данным:
Каждый микросервис должен владеть своими данными об отдельных объектах.
Примеры: заказ (все о заказах), платеж (все о транзакциях), пользователи (всё о пользователях).
Результаты такого деления похожи на деление по бизнес-функциональности, но ориентированы больше на принцип управления данными об одном конкретном объекте.


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

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

🤩 5 сервисов и микросервисов, которые есть почти в каждом проекте 🤩

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

Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.


✅ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.

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

✅ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.

✅ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.

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


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

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

😎 OpenShift, Kubernetes: знакомые слова, но что это и зачем? 😎

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

Чтобы их обеспечивать, на помощь приходят инфраструктурные решения OpenShift и Kubernetes.


🔵 Kubernetes — это система, которая управляет контейнерами, в которых работают приложения.

Она позволяет запускать и обновлять их, чтобы они работали стабильно и без сбоев.

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

Ключевые функции:
1. Запуск и мониторинг контейнеров - обеспечение работы параллельно запущенных копий приложения.
2. Балансировка нагрузки - распределение запросов между запущенными копиями приложения
3. Автомасштабирование - увеличение или уменьшение запущенных копий приложения
4. Обновления без простоя - можно делать постепенный переход на новую версию, заменяя старые контейнеры новыми
5. Автовосстановление в случае сбоев


🔴 OpenShift — это улучшенная версия Kubernetes. Это платформа контейнеризации, построенная на основе Kubernetes.

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

OpenShift также добавляет дополнительные функции для обеспечения безопасности.


Kubernetes и OpenShift могут использовать как вместе, так и раздельно.

Применяются не только для систем с микросерверной архитектурой, но и для монолитов.


➡️ При работе на проектах, где используются Kubernetes и OpenShift, системный аналитик может встретиться с ситуацией, когда нужно описать поведение системы при недоступности одного из контейнеров.

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

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

🌱 Еще не микросервисы, но сильно улучшенный монолит 🌱

Или о том, как я больше года думала, что мы разрабатываем микросервисы, а потом узнала, что это модульный монолит, который легко поделится на микросервисы, и “ЯЖГОВОРИЛ” 🤣

Мы уже знаем как выглядит проект системы заказа такси #RideFlow в монолитной архитектуре. Главное, что мы из этого должны были усвоить:

➕ Единое сервер-приложение:
Все запросы и ответы от веб- и мобильных приложений направляются в одно место.

➕ Единая БД:
Все данные в одной схеме, то есть одна ER-диаграмма которую нужно знать, возможно с 100+ таблицами 🙂 Но исключения есть, бывает несколько БД.

➕ Может быть несколько API-интерфейсов:
В одном проекте может быть деление того же REST API на две и более части - public и admin, как минимум. Также нормальной практикой считается, когда у монолита поддержаны сразу несколько видов API: SOAP, REST, GraphQL и WebSocket, например.

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


В прошлом посте мы узнали про контейнеризацию приложений, OpenShift и Kubernetes. Так вот… Есть одна хитрость, которой пользуются стартаперы и молодые проекты - модульный монолит и контейнеризация модулей 🤩


👉 Модульный монолит создается по следующим правилам:
1. Монолит делят на независимые модули
2. Код поделен на части, но всё еще в одном месте - в одном репозитории
3. Зависимости между модулями остаются
4. Коммуникация между модулями по внутренним вызовам функций и методов классов
5. Общие ресурсы - БД, конфиги, библиотеки
6. Развертывание модулей может быть сделано независимо, каждый модуль можно масштабировать отдельно благодаря OpenShift и Kubernetes
7. У монолита есть счастливое микросервисное будущее 🌱

Картинку сделала чтобы максимизировать отличия и ваше понимание))

А подробнее про каждый из пунктов про модульный монолит, и особенно про 6, расскажу дальше 😉

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

👉Модульный монолит создается по следующим правилам👇

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

В приложении такси #RideFlow это управление пользователями, управление заказами, калькулятор стоимости поездки, геолокация. По сути то же, что мы прикидывали для микросервисов.


2. Код поделен на части, но все еще в одном месте
Вся кодовая база хранится всё ещё хранится в одном репозитории. Несмотря на разделение на модули, все они компилируются и деплоятся вместе как одно целое приложение.

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


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

Например, модуль "Заказы" может использовать функции модуля "Пользователи" для получения информации о нем


4. Коммуникация между модулями
В монолите модули взаимодействуют друг с другом по внутренним вызовам функций и методов классов кода.

А микросервисы общаются между собой только по сети (например, по HTTP), то есть через API.


5. Общие ресурсы
Модули разные, а вот база данных, конфигурационные файлы и библиотеки у них могут быть общие, в то время как у каждого микросервиса всё своё


6. Развертывание (релиз приложения сервера)
Та-дам 🎉 Вот тут то и ключевое преимущество!

❗️Каждый модуль монолита может быть упакован в отдельный контейнер

Это позволяет частично изолировать модули монолита, развертывать и обновлять их независимо, благодаря OpenShift и Kubernets.

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


7. Счастливое микросервисное будущее🙌
Модули в будущем могут быть значительно легче вынесены из монолита и превращены в микросервисы. Но из-за общей БД, конфигураций и других ресурсов могут быть сложности...

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

Если меня отвлечь в процессе решения сложной задачи, когда сотни деталей собраны в голове, то я буду… Злиться и отвечать “на отвали”.

Почему так и плохо ли это? 🧐

Мы, аналитики, работаем с большим объемом информации. Чтобы начать работу над задачей, нужно погрузиться в контекст и настроиться. Это может занимать от 15 минут до 2 часов, даже если задача знакомая и я возвращаюсь к её решению.

4 раза отвлечься = минимум 1 час времени в никуда 😞

Ответы на сообщения и звонки - тоже задача. Чтобы в нее погрузиться, тоже нужно время.

Итого:
⏳тут 5 минут на сообщения,
⏳тут 10 минут на поговорить,
⏳тут на 30 минут “маленькая задачка и очень срочно”,
⏳и созвон по расписанию…
⏳соцсети открывать вообще не хочется.

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

Знакомо?

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

Хочется завершать работу вовремя и выключаться после неё полноценно, а не думать о незавершенных задачах.

Чтобы жизнь не превращалась в работу 24/7, я ввела правила, которые помогают держать тишину в процессе работы.

0. О правилах сфокусированной работы знают друзья, близкие и все, кто со мной взаимодействует. Без обид.

1. Все звуковые уведомления выключены. Только баннеры на самое важное. Дозвониться можно со второго раза.

2. Временные блоки на задачи 30, 60, 90 или 120 минут. В перерывах по 10-15 минут гуляю и/или звоню и отвечаю на срочные сообщения.

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

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

5. Продуктивность в путешествиях не работает. Лучше брать отпуск на дни перемещений.

Это основные правила-спасатели 🙌


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

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

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

Уточню несколько моментов про контейнеризацию, независимые релизы, 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-кода. Кому сложно - пропускайте. Разобраны интересные практические кейсы. Большая часть книги написана простым языком. Рекомендую 😉