📌 Новый проект GetTickets: распил монолита на микросервисы 📌
Проект "GetTickets" - платформа для онлайн-бронирования и покупки авиабилетов. Разрабатывался и запускался как стартап.
Функциональность платформы включает:
1. Поиск и сравнение билетов:
Пользователи могут искать подходящие авиабилеты с помощью интерфейса поиска, который позволяет фильтровать результаты по различным критериям, таким как цена, дата, время и авиакомпания.
2. Обработка транзакций:
Система обеспечивает процесс оплаты забронированных билетов банковской картой.
3. Уведомления и подтверждения:
Пользователи получают уведомления и подтверждения о бронировании на почту, телефон и push в мобильных приложениях.
4. Интеграция с различными авиакомпаниями и системами бронирования:
Платформа интегрируется с базами данных авиакомпаний и системами бронирования, чтобы предоставлять пользователям самые актуальные и полные данные о доступных билетах, позволяя найти площадку с наиболее выгодной ценой.
5. Персонализированные рекомендации и предложения:
Система использует алгоритмы машинного обучения для анализа предпочтений и истории покупок пользователей, чтобы предлагать им персонализированные рекомендации и специальные предложения.
6. Личный кабинет пользователя:
Пользователи могут просматривать историю покупок и поиска.
7. Администрирование:
Владельцы платформы могут получать доступ к аналитике по поиску, бронированиям и продажам за различные периоды, с применением различных критериев. Отчеты можно выгружать из систем в формате XLSX и PDF.
Для упрощения разработки был выбран архитектурный подход к проектированию - Монолит 🙌
На момент запуска целью было как можно скорее сделать продукт и начать привлекать пользователей, зарабатывая на комиссии с продажи билетов. Так что идея монолита на старте никого не смутила. Тестировали гипотезы быстро 👌 Но пришел этот самый момент....
#АрхитектураGA #GetTickets
Проект "GetTickets" - платформа для онлайн-бронирования и покупки авиабилетов. Разрабатывался и запускался как стартап.
Функциональность платформы включает:
1. Поиск и сравнение билетов:
Пользователи могут искать подходящие авиабилеты с помощью интерфейса поиска, который позволяет фильтровать результаты по различным критериям, таким как цена, дата, время и авиакомпания.
2. Обработка транзакций:
Система обеспечивает процесс оплаты забронированных билетов банковской картой.
3. Уведомления и подтверждения:
Пользователи получают уведомления и подтверждения о бронировании на почту, телефон и push в мобильных приложениях.
4. Интеграция с различными авиакомпаниями и системами бронирования:
Платформа интегрируется с базами данных авиакомпаний и системами бронирования, чтобы предоставлять пользователям самые актуальные и полные данные о доступных билетах, позволяя найти площадку с наиболее выгодной ценой.
5. Персонализированные рекомендации и предложения:
Система использует алгоритмы машинного обучения для анализа предпочтений и истории покупок пользователей, чтобы предлагать им персонализированные рекомендации и специальные предложения.
6. Личный кабинет пользователя:
Пользователи могут просматривать историю покупок и поиска.
7. Администрирование:
Владельцы платформы могут получать доступ к аналитике по поиску, бронированиям и продажам за различные периоды, с применением различных критериев. Отчеты можно выгружать из систем в формате XLSX и PDF.
Для упрощения разработки был выбран архитектурный подход к проектированию - Монолит 🙌
На момент запуска целью было как можно скорее сделать продукт и начать привлекать пользователей, зарабатывая на комиссии с продажи билетов. Так что идея монолита на старте никого не смутила. Тестировали гипотезы быстро 👌 Но пришел этот самый момент....
#АрхитектураGA #GetTickets
❤15👍7👏5🥰3
🙈 Монолит и его проблемы 🙈
Монолитная архитектура - это подход к разработке программного обеспечения, при котором все компоненты приложения интегрированы в единый и цельный блок, называемый монолитом.
В такой архитектуре вся функциональность приложения, включая:
- интерфейс пользователя,
- базу данных,
- и бизнес-логику,
обычно реализуется внутри одного приложения и работает как единое целое.
Так что спустя 2 года после запуска GetTickets, когда платформа по продаже билетов набрала популярность и ожидать от 1000 запросов в минуту стало обычным делом, возникли проблемы:
1. Масштабируемость
1.1. Большое количество мощностей (облачных серверов) к аренде. Высокие затраты на инфраструктуру, так как на серверах можно устанавливать только копии монолита.
1.2. Высокое время ответа на отдельные запросы к системе, которые требуют обработки большого объема данных из БД (построение отчета по продажам).
2.Сложность поддержки и развертывания
2.1. Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это становится недопустимо. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.
2.2 Тестирование перед релизом в продакшн превращается в каторгу для тестировщиков. Покрытия автотестами нет. Почти всё тестирование ведется вручную.
3. Сложность масштабирования команды разработчиков
Есть части системы, которые можно развивать и дорабатывать независимым командам разработки. Но они сильно связаны друг с другом, что делает параллельную работу над ними более сложной.
4. Единая точка отказа
Например, из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Монолит - это одна большая точка отказа в системе.
5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов. Изменения в приложении могут оказаться затруднительными из-за жестких связей между его компонентами.
Это основные проблемы монолитной архитектуры 😔
В связи с тем, что проект GetTickets успешно развивается, пришло время привлечь в него специалистов, которые пересмотрят архитектуру и помогут ему масштабироваться и начать переезд на микросервисную архитектуру.
Welcome to the New Project! 🚀
#АрхитектураGA #GetTickets
Монолитная архитектура - это подход к разработке программного обеспечения, при котором все компоненты приложения интегрированы в единый и цельный блок, называемый монолитом.
В такой архитектуре вся функциональность приложения, включая:
- интерфейс пользователя,
- базу данных,
- и бизнес-логику,
обычно реализуется внутри одного приложения и работает как единое целое.
Так что спустя 2 года после запуска GetTickets, когда платформа по продаже билетов набрала популярность и ожидать от 1000 запросов в минуту стало обычным делом, возникли проблемы:
1. Масштабируемость
1.1. Большое количество мощностей (облачных серверов) к аренде. Высокие затраты на инфраструктуру, так как на серверах можно устанавливать только копии монолита.
1.2. Высокое время ответа на отдельные запросы к системе, которые требуют обработки большого объема данных из БД (построение отчета по продажам).
2.Сложность поддержки и развертывания
2.1. Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это становится недопустимо. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.
2.2 Тестирование перед релизом в продакшн превращается в каторгу для тестировщиков. Покрытия автотестами нет. Почти всё тестирование ведется вручную.
3. Сложность масштабирования команды разработчиков
Есть части системы, которые можно развивать и дорабатывать независимым командам разработки. Но они сильно связаны друг с другом, что делает параллельную работу над ними более сложной.
4. Единая точка отказа
Например, из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Монолит - это одна большая точка отказа в системе.
5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов. Изменения в приложении могут оказаться затруднительными из-за жестких связей между его компонентами.
Это основные проблемы монолитной архитектуры 😔
В связи с тем, что проект GetTickets успешно развивается, пришло время привлечь в него специалистов, которые пересмотрят архитектуру и помогут ему масштабироваться и начать переезд на микросервисную архитектуру.
Welcome to the New Project! 🚀
#АрхитектураGA #GetTickets
🔥13👍8❤3
Уже завтра будем закреплять навык проектирования БД с нуля на новом проекте!
Онлайн-практикум
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 13 февраля, 19:00 Мск
План:
1. Определение БД и СУБД.
2. Знакомство с проектом и выделение сущностей.
3. Определение логической и физической моделей БД с разбором примеров по проекту.
4. Практика. Фокус на проектировании физической модели БД - PostgreSQL.
5. Обзор шаблона постановки задачи на разработчиков.
Эта практика полезна для тех, кто:
✔️ только начинает осваивать базы данных и переход в системный анализ,
✔️ хочет закрепить свои навыки по проектированию БД,
✔️ хочет разобраться, как требования влияют на БД системы, и почему первым делом при подключении к новому проекту опытные аналитики запрашивают доступ к БД.
Практика проводится в рамках практической программы по проектированию БД и подключиться к ней можно независимо от неё.
Следующие встречи будут на более сложные темы:
✅ Разработка требований к миграциям БД,
✅ Проектирование распределенных БД,
✅ Оптимизация БД. Работа с индексами.
и другие.
Это прекрасная возможность закрепить самую важную часть работы с БД, перед более глубоким погружением!
План работы:
1. Краткая теория по каждому уровню БД.
2. Практика с подключением участников к работе онлайн над общим проектом.
3. Выдача ДЗ.
🔗 Подробности и подключение к участию
До встречи завтра в прямом эфире! 😉
Онлайн-практикум
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 13 февраля, 19:00 Мск
План:
1. Определение БД и СУБД.
2. Знакомство с проектом и выделение сущностей.
3. Определение логической и физической моделей БД с разбором примеров по проекту.
4. Практика. Фокус на проектировании физической модели БД - PostgreSQL.
5. Обзор шаблона постановки задачи на разработчиков.
Эта практика полезна для тех, кто:
✔️ только начинает осваивать базы данных и переход в системный анализ,
✔️ хочет закрепить свои навыки по проектированию БД,
✔️ хочет разобраться, как требования влияют на БД системы, и почему первым делом при подключении к новому проекту опытные аналитики запрашивают доступ к БД.
Практика проводится в рамках практической программы по проектированию БД и подключиться к ней можно независимо от неё.
Следующие встречи будут на более сложные темы:
✅ Разработка требований к миграциям БД,
✅ Проектирование распределенных БД,
✅ Оптимизация БД. Работа с индексами.
и другие.
Это прекрасная возможность закрепить самую важную часть работы с БД, перед более глубоким погружением!
План работы:
1. Краткая теория по каждому уровню БД.
2. Практика с подключением участников к работе онлайн над общим проектом.
3. Выдача ДЗ.
До встречи завтра в прямом эфире! 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍5🔥2
🔺 Микросервисная архитектура (MSA) 🔺
Микросервисная архитектура представляет собой набор принципов разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.
Микросервисы могут существовать независимо друг от друга:
🔺1. Разрабатываться.
Разработчики могут создавать, тестировать, модифицировать и обновлять микросервисы отдельно друг от друга, без необходимости координировать эти действия с работой над другими частями системы.
Не надо думать о том, какие части будут задеты в результате изменений, как в монолите. Основное о чём думаем - сохранение способов взаимодействия с микросервисом при модификации.
Также одно из главных преимуществ - каждый микросервис можно разрабатывать на своём языке программирования, и выбирать наиболее подходящие инструменты и технологии для решения специфических задач.
🔺2. Развёртываться.
Развёртывание - процесс подготовки и настройки приложения для его работы в продуктивной (или тестовой) среде. Этот процесс включает в себя установку программного обеспечения на сервера или в облачную среду, настройку необходимых параметров, создание баз данных, настройку сетевых соединений и т.д., чтобы приложение было готово к использованию конечными пользователями.
Микросервисы могут быть развернуты независимо, что упрощает обновления и быстрое внедрение новых функций без влияния на остальные части системы.
🔺3. Масштабироваться.
Микросервисы открывают возможность дешевого горизонтального масштабирования систем. Когда можно добавлять и запускать дополнительные экземпляры приложений - микросервисов, работающие параллельно, для распределения нагрузки.
Вместо того, чтобы запускать еще один экземпляр большого приложения для распределения нагрузки, можно запустить только маленькую часть.
#АрхитектураGA
Микросервисная архитектура представляет собой набор принципов разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.
Микросервисы могут существовать независимо друг от друга:
🔺1. Разрабатываться.
Разработчики могут создавать, тестировать, модифицировать и обновлять микросервисы отдельно друг от друга, без необходимости координировать эти действия с работой над другими частями системы.
Не надо думать о том, какие части будут задеты в результате изменений, как в монолите. Основное о чём думаем - сохранение способов взаимодействия с микросервисом при модификации.
Также одно из главных преимуществ - каждый микросервис можно разрабатывать на своём языке программирования, и выбирать наиболее подходящие инструменты и технологии для решения специфических задач.
🔺2. Развёртываться.
Развёртывание - процесс подготовки и настройки приложения для его работы в продуктивной (или тестовой) среде. Этот процесс включает в себя установку программного обеспечения на сервера или в облачную среду, настройку необходимых параметров, создание баз данных, настройку сетевых соединений и т.д., чтобы приложение было готово к использованию конечными пользователями.
Микросервисы могут быть развернуты независимо, что упрощает обновления и быстрое внедрение новых функций без влияния на остальные части системы.
🔺3. Масштабироваться.
Микросервисы открывают возможность дешевого горизонтального масштабирования систем. Когда можно добавлять и запускать дополнительные экземпляры приложений - микросервисов, работающие параллельно, для распределения нагрузки.
Вместо того, чтобы запускать еще один экземпляр большого приложения для распределения нагрузки, можно запустить только маленькую часть.
#АрхитектураGA
👍20❤9🔥1
🤔 Деление монолита на микросервисы: с чего начать? 🤔
Если в проекте принято решение о переезда с монолита на микросервисы, то нужно построить план переезда. Какие есть варианты?
🔸 Вариант 1 - Переписываем с нуля
Самый простой план - разработать всё с нуля и запустить ту же самую систему на микросервисах. Но его обычно не выбирают.
1️⃣ Во-первых, в глазах заказчика (владельца продукта) это технический долг. И технический долг не должен тормозить развитие основной функциональности.
Представьте себе ситуацию:
Мы с архитектором приходим к владельцу продукта GetTickets и говорим, что ПО, которое мы разрабатывали в течение 2 лет, невозможно далее развивать и поддерживать, так как это монолит.
Нужно переписать весь код с нуля и повторить существующую систему, но по-другому - сделать микросервисы.
Чтобы это сделать надо ещё 2 года. И только после этого мы сможем взять новые задачи на новую функциональность 😁
Согласитесь, звучит так себе. Смена подхода в разработке архитектуры не должна блокировать развитие системы.
Техдолг техдолгом, а бизнес за новые фичи платит. Так что такую идею заказчику мы не продадим, и этот вариант рассматриваем только в случае, если вообще никуда не торопимся и у заказчика много денег.
2️⃣ Во-вторых, даже при таком раскладе через 2 года придётся задуматься о миграции (переносе) существующих данных из старой БД в новые БД микросервисов. Это достаточно сложная задача и её никак не избежать..
Кстати, именно перенос данных между БД одна из основных проблем в миграции с монолита на микросервисы.
3️⃣ И в-третьих, в течение двух лет разработки с нуля системы на микросервисах, оставить монолит без поддержки скорее всего не удастся. Поэтому команда будет одновременно сопровождать и разрабатывать две независимые системы.
Это может привести к тому, что если в монолите потребуются какие-то изменения в логике для исправления тех же ошибок или из-за законов (по разным причинам), то их могут упустить и не перенести в монолит по разным причинам.
#АрхитектураGA #GetTickets
Если в проекте принято решение о переезда с монолита на микросервисы, то нужно построить план переезда. Какие есть варианты?
🔸 Вариант 1 - Переписываем с нуля
Самый простой план - разработать всё с нуля и запустить ту же самую систему на микросервисах. Но его обычно не выбирают.
1️⃣ Во-первых, в глазах заказчика (владельца продукта) это технический долг. И технический долг не должен тормозить развитие основной функциональности.
Представьте себе ситуацию:
Мы с архитектором приходим к владельцу продукта GetTickets и говорим, что ПО, которое мы разрабатывали в течение 2 лет, невозможно далее развивать и поддерживать, так как это монолит.
Нужно переписать весь код с нуля и повторить существующую систему, но по-другому - сделать микросервисы.
Чтобы это сделать надо ещё 2 года. И только после этого мы сможем взять новые задачи на новую функциональность 😁
Согласитесь, звучит так себе. Смена подхода в разработке архитектуры не должна блокировать развитие системы.
Техдолг техдолгом, а бизнес за новые фичи платит. Так что такую идею заказчику мы не продадим, и этот вариант рассматриваем только в случае, если вообще никуда не торопимся и у заказчика много денег.
2️⃣ Во-вторых, даже при таком раскладе через 2 года придётся задуматься о миграции (переносе) существующих данных из старой БД в новые БД микросервисов. Это достаточно сложная задача и её никак не избежать..
Кстати, именно перенос данных между БД одна из основных проблем в миграции с монолита на микросервисы.
3️⃣ И в-третьих, в течение двух лет разработки с нуля системы на микросервисах, оставить монолит без поддержки скорее всего не удастся. Поэтому команда будет одновременно сопровождать и разрабатывать две независимые системы.
Это может привести к тому, что если в монолите потребуются какие-то изменения в логике для исправления тех же ошибок или из-за законов (по разным причинам), то их могут упустить и не перенести в монолит по разным причинам.
#АрхитектураGA #GetTickets
👍13❤9👏1
Друзья, сегодня очередной день, когда можно без стеснения признаваться в любви своим близким, семье, друзьям и коллегам!
Мы крепко обнимаем каждого из вас, а также каждого участника нашей дружной команды GetAnalyst 🫂
И, конечно, хотим признаться в любви сфере IT, которая объединяет таких потрясающих и амбициозных ребят в одно дружное комьюнити GetAnalyst!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤36😁4
🤔 Деление монолита на микросервисы: с чего начать? 🤔
🔸 Вариант 2 - новое на микросервисах, старое не трогаем
Этот вариант прекрасно работает и к нему обычно приходят, когда монолит уже показал свою непригодность для дальнейшего развития проекта, и появляется потребность делать новую функциональность.
В этом случае вводят правила развития и сопровождения проекта:
1. При добавлении новой функциональности проверь, есть ли возможность сделать её независимой от монолита, в виде сервиса или микросервиса - делай.
Для монолита будем делать интеграцию с новым микросервисом и его вызовы в тех местах, где он необходим.
Пример GetTickets:
Добавляем функциональность для обновления статуса рейса в приложение, связанного с купленным пользователем билета. Механизм обновления статусов билетов выносим в отдельный интеграционный микросервис, который будет работать с онлайн-табло аэропортов.
2. Если нужно доработать функциональность, которая уже работает в монолите, то дорабатываем код монолита, как-будто про новый подход с микросервисной архитектурой проекта ничего не слышали.
Пример GetTickets:
Сейчас поддержана продажа билетов только туда, туда-обратно. Нужно научиться делать поиск сложных маршрутов из 2-х и более сегментов. Т.к. механизм поиска уже в монолите, то продолжаем дорабатывать монолит.
Преимущества такого варианта высоки для Владельца продукта:
+ команда продолжает развивать систему и добавлять в неё новые функции;
+ команда утверждает, что все новые функции будут работать быстрее и эффективнее;
+ команда притворяется, что техдолга нет 😁
Всё хорошо, но техдолг есть. И он продолжает накапливаться со временем, т.к. мы не отказываемся от монолита, а продолжаем поддерживать его развитие.
По сути в этом варианте переезда с монолита на микросервисы нет.
Продолжение сопровождения монолита без попытки его деления на микросервисы приведёт к тому, что очень много функциональности будет дорабатываться и развиваться именно в монолите, и она никогда не будет вынесена в микросервисы.
#АрхитектураGA #GetTickets
🔸 Вариант 2 - новое на микросервисах, старое не трогаем
Этот вариант прекрасно работает и к нему обычно приходят, когда монолит уже показал свою непригодность для дальнейшего развития проекта, и появляется потребность делать новую функциональность.
В этом случае вводят правила развития и сопровождения проекта:
1. При добавлении новой функциональности проверь, есть ли возможность сделать её независимой от монолита, в виде сервиса или микросервиса - делай.
Для монолита будем делать интеграцию с новым микросервисом и его вызовы в тех местах, где он необходим.
Пример GetTickets:
Добавляем функциональность для обновления статуса рейса в приложение, связанного с купленным пользователем билета. Механизм обновления статусов билетов выносим в отдельный интеграционный микросервис, который будет работать с онлайн-табло аэропортов.
2. Если нужно доработать функциональность, которая уже работает в монолите, то дорабатываем код монолита, как-будто про новый подход с микросервисной архитектурой проекта ничего не слышали.
Пример GetTickets:
Сейчас поддержана продажа билетов только туда, туда-обратно. Нужно научиться делать поиск сложных маршрутов из 2-х и более сегментов. Т.к. механизм поиска уже в монолите, то продолжаем дорабатывать монолит.
Преимущества такого варианта высоки для Владельца продукта:
+ команда продолжает развивать систему и добавлять в неё новые функции;
+ команда утверждает, что все новые функции будут работать быстрее и эффективнее;
+ команда притворяется, что техдолга нет 😁
Всё хорошо, но техдолг есть. И он продолжает накапливаться со временем, т.к. мы не отказываемся от монолита, а продолжаем поддерживать его развитие.
По сути в этом варианте переезда с монолита на микросервисы нет.
Продолжение сопровождения монолита без попытки его деления на микросервисы приведёт к тому, что очень много функциональности будет дорабатываться и развиваться именно в монолите, и она никогда не будет вынесена в микросервисы.
#АрхитектураGA #GetTickets
👍6❤5
🤔 Деление монолита на микросервисы: с чего начать? 🤔
🔸 Вариант 3 - старое поэтапно выносим из монолита, новое сразу в микросервисы
Это лучшее и рабочее решение по переезду.
План:
1. Анализ функциональности монолита
2. Выделение микросервисов
3. Планирование работ и приоритизация
4. Исследования функциональности и её зависимостей
5. Постановка задач на разработку
6. Поддержка совместимости с монолитом: миграции и интеграции
7. Подготовка инфраструктуры
8. Разработка и тестирование
9. Запуск и переход к следующему микросервису
10. Масштабирование и оптимизация
Этот процесс требует тщательного планирования, поскольку переход от монолита к микросервисам может быть сложным и рискованным. Однако в результате вы получите более гибкое и масштабируемое приложение, которое легче поддерживать и обновлять.
Далее раскрою задачи каждого этапа подробнее 👇
#АрхитектураGA
🔸 Вариант 3 - старое поэтапно выносим из монолита, новое сразу в микросервисы
Это лучшее и рабочее решение по переезду.
План:
1. Анализ функциональности монолита
2. Выделение микросервисов
3. Планирование работ и приоритизация
4. Исследования функциональности и её зависимостей
5. Постановка задач на разработку
6. Поддержка совместимости с монолитом: миграции и интеграции
7. Подготовка инфраструктуры
8. Разработка и тестирование
9. Запуск и переход к следующему микросервису
10. Масштабирование и оптимизация
Этот процесс требует тщательного планирования, поскольку переход от монолита к микросервисам может быть сложным и рискованным. Однако в результате вы получите более гибкое и масштабируемое приложение, которое легче поддерживать и обновлять.
Далее раскрою задачи каждого этапа подробнее 👇
#АрхитектураGA
❤11🔥7👍3🥰1
📋 Подробный план переезда С МОНОЛИТА НА МИКРОСЕРВИСЫ 📋
Этап 1. Анализ функциональности монолита
Для начала системному аналитику придётся разобраться со всей функциональностью, которая уже есть в системе. Если аналитик работал с проектом с самого начала, то будет проще. А если нет, то придётся вести исследовательское тестирование, собирать список всех функций и объектов данных.
В процессе сбора этой информации предлагается сразу выделять логические модули, которые затем могут быть преобразованы в микросервисы.
Для проекта GetTickets логическими модулями могут быть:
- Поиск рейсов,
- Бронирование билетов,
- Управление пользователями,
- Уведомления,
- Оплата билетов,
- и т.д.
Этап 2. Выделение микросервисов
Решите, какие части монолита можно разделить на отдельные микросервисы. Каждый микросервис должен выполнять одну функцию или управлять одним набором данных.
Выделенные выше модули могут быть пересмотрены: поделены на более маленькие или наоборот сгруппированы.
Этап 3. Планирование работ и приоритизация
После того, как список микросервисов собран, переходят к предварительному планированию переезда: в каком порядке выносить функции из монолита.
Не все части приложения одинаково легко или полезно превращать в микросервисы. Выберите, с чего начнете, основываясь на сложности, зависимостях и потенциальной пользе.
Для принятия решений важно подключить опытных разработчиков, кто поможет с анализом зависимостей по коду и архитектора.
Потенциальная польза в первую очередь определяется тем, что за счет выделения микросервисов мы сможем обеспечить выполнение нефункциональных требований:
- производительность и отказоустойчивость - сможем обслуживать более высокие нагрузки и поднимем стабильность системы,
- масштабирование - сможем дорабатывать новую функциональность без снижения скорости работы системы,
- безопасность - в отдельных случаях сможем вынести и защитить чувствительные данные.
В системе GetTickets мне необходимо обеспечить стабильность работы поиска и платежей в первую очередь, т.к.:
+ поиском пользуются все пользователи регулярно и на эту функцию высокая нагрузка,
+ а платежи нужно сделать отказоустойчивыми и стабильными, т.к. это прибыль компании.
Продолжение 👇
#АрхитектураGA #GetTickets
Этап 1. Анализ функциональности монолита
Для начала системному аналитику придётся разобраться со всей функциональностью, которая уже есть в системе. Если аналитик работал с проектом с самого начала, то будет проще. А если нет, то придётся вести исследовательское тестирование, собирать список всех функций и объектов данных.
В процессе сбора этой информации предлагается сразу выделять логические модули, которые затем могут быть преобразованы в микросервисы.
Для проекта GetTickets логическими модулями могут быть:
- Поиск рейсов,
- Бронирование билетов,
- Управление пользователями,
- Уведомления,
- Оплата билетов,
- и т.д.
Этап 2. Выделение микросервисов
Решите, какие части монолита можно разделить на отдельные микросервисы. Каждый микросервис должен выполнять одну функцию или управлять одним набором данных.
Выделенные выше модули могут быть пересмотрены: поделены на более маленькие или наоборот сгруппированы.
Этап 3. Планирование работ и приоритизация
После того, как список микросервисов собран, переходят к предварительному планированию переезда: в каком порядке выносить функции из монолита.
Не все части приложения одинаково легко или полезно превращать в микросервисы. Выберите, с чего начнете, основываясь на сложности, зависимостях и потенциальной пользе.
Для принятия решений важно подключить опытных разработчиков, кто поможет с анализом зависимостей по коду и архитектора.
Потенциальная польза в первую очередь определяется тем, что за счет выделения микросервисов мы сможем обеспечить выполнение нефункциональных требований:
- производительность и отказоустойчивость - сможем обслуживать более высокие нагрузки и поднимем стабильность системы,
- масштабирование - сможем дорабатывать новую функциональность без снижения скорости работы системы,
- безопасность - в отдельных случаях сможем вынести и защитить чувствительные данные.
В системе GetTickets мне необходимо обеспечить стабильность работы поиска и платежей в первую очередь, т.к.:
+ поиском пользуются все пользователи регулярно и на эту функцию высокая нагрузка,
+ а платежи нужно сделать отказоустойчивыми и стабильными, т.к. это прибыль компании.
Продолжение 👇
#АрхитектураGA #GetTickets
👍13❤5🔥2
Этап 4. Исследования функциональности и её зависимостей
Самая классная часть работы, когда мы переходим к исследованиям и разработке новых требований. На этом этапе мы уже понимаем зависимости, но теперь в них нужно погрузиться глубже, с максимально детальными проверками, задокументировать и обосновать, как можем аккуратно вынести это из монолита, чтобы он не пострадал.
Я, как системный аналитик, ищу зависимости:
1. По БД - какие таблицы мне нужно будет вынести и что синхронизировать между монолитом и новым микросервисом.
2. По функциональности - какие части монолита могут использовать функции, которые я отправляю в микросервис.
Если процесс работы системы не был ранее задокументирован, то я его описываю с нуля и рассказываю, как теперь он будет реализовываться:
1. Как будет работать на микросервисе - алгоритм.
2. Как будет встроен в монолит - интеграция монолита с микросервисом.
На этом этапе появляются будущие постановки задач.
Для проекта GetTickets вы можете описать весь процесс, связанный с поиском рейсов, чтобы вынести его в отдельный микросервис.
Функции:
- работа со справочниками пунктов отправления и прибытия,
- фильтры и сортировка результатов поиска,
- интеграции с внешними системами для поиска,
- обработка ошибок и альтернативные сценарии,
- дальнейшее использование результатов поиска и требования к их хранению.
Данные:
- справочник городов,
- справочник аэропортов,
- БД рейсов,
- рейсы из внешних систем,
- и т.д.
Этап 5. Постановка задач на разработку
В результате детальной аналитики и описания бизнес-процессов создаются задачи на разработчиков:
1. Создание БД микросервиса.
2. Реализация функций микросервиса в соответствии с описанными процессами и алгоритмами - разработка API.
Для микросервиса поиска рейсов в GetTickets может быть создана БД, в которой будут таблицы справочников аэропортов и городов, а также организована система кэширования (временного хранения) результатов поиска рейсов, чтобы не ходить во внешние системы за данными, если они были получены недавно.
По функциональности: может быть разработан метод REST API для поиска рейсов GET /flights (но поиск скорее всего будет асинхронный, поэтому могут быть методы POST /flightsSearch и GET /flightsSearch/{flightsSearchId} - большая тема для обсуждения 🙂).
А также нужны методы API работы со справочниками. Хотя похоже, что их можно тоже в отдельный микросервис вынести, но мельчить и делать нано-сервисы не хочется.
Этап 6. Поддержка совместимости с монолитом: миграции и интеграции
...
Продолжение скоро👇
#АрхитектураGA #GetTickets
Самая классная часть работы, когда мы переходим к исследованиям и разработке новых требований. На этом этапе мы уже понимаем зависимости, но теперь в них нужно погрузиться глубже, с максимально детальными проверками, задокументировать и обосновать, как можем аккуратно вынести это из монолита, чтобы он не пострадал.
Я, как системный аналитик, ищу зависимости:
1. По БД - какие таблицы мне нужно будет вынести и что синхронизировать между монолитом и новым микросервисом.
2. По функциональности - какие части монолита могут использовать функции, которые я отправляю в микросервис.
Если процесс работы системы не был ранее задокументирован, то я его описываю с нуля и рассказываю, как теперь он будет реализовываться:
1. Как будет работать на микросервисе - алгоритм.
2. Как будет встроен в монолит - интеграция монолита с микросервисом.
На этом этапе появляются будущие постановки задач.
Для проекта GetTickets вы можете описать весь процесс, связанный с поиском рейсов, чтобы вынести его в отдельный микросервис.
Функции:
- работа со справочниками пунктов отправления и прибытия,
- фильтры и сортировка результатов поиска,
- интеграции с внешними системами для поиска,
- обработка ошибок и альтернативные сценарии,
- дальнейшее использование результатов поиска и требования к их хранению.
Данные:
- справочник городов,
- справочник аэропортов,
- БД рейсов,
- рейсы из внешних систем,
- и т.д.
Этап 5. Постановка задач на разработку
В результате детальной аналитики и описания бизнес-процессов создаются задачи на разработчиков:
1. Создание БД микросервиса.
2. Реализация функций микросервиса в соответствии с описанными процессами и алгоритмами - разработка API.
Для микросервиса поиска рейсов в GetTickets может быть создана БД, в которой будут таблицы справочников аэропортов и городов, а также организована система кэширования (временного хранения) результатов поиска рейсов, чтобы не ходить во внешние системы за данными, если они были получены недавно.
По функциональности: может быть разработан метод REST API для поиска рейсов GET /flights (но поиск скорее всего будет асинхронный, поэтому могут быть методы POST /flightsSearch и GET /flightsSearch/{flightsSearchId} - большая тема для обсуждения 🙂).
А также нужны методы API работы со справочниками. Хотя похоже, что их можно тоже в отдельный микросервис вынести, но мельчить и делать нано-сервисы не хочется.
Этап 6. Поддержка совместимости с монолитом: миграции и интеграции
...
Продолжение скоро👇
#АрхитектураGA #GetTickets
❤9👍7⚡3
Когда мы занимались редизайном сайта в прошлом году, у меня была идея показать путь роста в профессии системного аналитика. И в течение всего прошлого года на карте было только 4 шага. Но теперь их будет 5.
На этом полная карта развития по ключевым навыкам системного аналитика в 2024 году готова - привет "05 Архитектура" 🎉 Кстати, даже обучение искусственному интеллекту сделала и встроила по чуть-чуть в программы. Так что точно 100% покрыла.
В течение 2022-2023 года у меня было много запросов на эту программу.
Прежде чем её создать были проделаны следующие шаги:
1. Исследованы вакансии и запросы работодателей.
2. Обработана обратная связь с воркшопа по Микросервисам (август 2023) и практических программ по REST и Интеграциям. В каждом потоке был минимум один студент, кто просил дальнейшего погружения в архитектуру.
3. Исследованы программы обучения для системных архитекторов.
4. Проанализированы и прочитаны книги для системных архитекторов.
5. Проведены интервью с аналитиками, кто работает с архитектурой на своих проектах.
По моему опыту и опыту коллег собрана новая практическая программа GetAnalyst:
🌟 Проектирование архитектуры
🌟 29 февраля 2024
🌟 Подробности о программе и запись
Архитектура подойдёт только для опытных системных аналитиков (middle и выше), кто уже работал с интеграциями, и хочет расти в senior внутри компании, или переходить в интересные и сложные проекты. Мне нравится помогать опытным специалистам идти вверх, и это прям топ-топ что уже давно планировалось к релизу 🙌
🎁 С 16 до 25 февраля открыта предзапись на специальных условиях.
Для всех, кто уже нашёл программу до сегодняшнего дня, оставлял запрос до её создания, и уже связался с нами, действует аналогичное предложение🎁
2024 - год больших и крутых перемен. И я начинаю его со сложных и интересных проектов с вами ♥️
На этом полная карта развития по ключевым навыкам системного аналитика в 2024 году готова - привет "05 Архитектура" 🎉 Кстати, даже обучение искусственному интеллекту сделала и встроила по чуть-чуть в программы. Так что точно 100% покрыла.
В течение 2022-2023 года у меня было много запросов на эту программу.
Прежде чем её создать были проделаны следующие шаги:
1. Исследованы вакансии и запросы работодателей.
2. Обработана обратная связь с воркшопа по Микросервисам (август 2023) и практических программ по REST и Интеграциям. В каждом потоке был минимум один студент, кто просил дальнейшего погружения в архитектуру.
3. Исследованы программы обучения для системных архитекторов.
4. Проанализированы и прочитаны книги для системных архитекторов.
5. Проведены интервью с аналитиками, кто работает с архитектурой на своих проектах.
По моему опыту и опыту коллег собрана новая практическая программа GetAnalyst:
🌟 Проектирование архитектуры
🌟 29 февраля 2024
Архитектура подойдёт только для опытных системных аналитиков (middle и выше), кто уже работал с интеграциями, и хочет расти в senior внутри компании, или переходить в интересные и сложные проекты. Мне нравится помогать опытным специалистам идти вверх, и это прям топ-топ что уже давно планировалось к релизу 🙌
🎁 С 16 до 25 февраля открыта предзапись на специальных условиях.
Для всех, кто уже нашёл программу до сегодняшнего дня, оставлял запрос до её создания, и уже связался с нами, действует аналогичное предложение
2024 - год больших и крутых перемен. И я начинаю его со сложных и интересных проектов с вами ♥️
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥3🎉1
This media is not supported in your browser
VIEW IN TELEGRAM
Воскресный юмор. Ставим 🔥 кому знакомо состояние 😂
😁35🔥17❤4🥱1
📋 Далее по плану переезда С МОНОЛИТА НА МИКРОСЕРВИСЫ
Этап 6. Поддержка совместимости с монолитом: миграции и интеграции
Монолит остается с нами длительное время, пока всё будет постепенно переходить на микросервисы. И в нём пока продолжает работать основная часть функциональности. Необходимо разработать план миграций, итераций и релизов обновлений.
💎 Интеграция монолита с микросервисом:
Чтобы микросервис работал и выполнял свою маленькую задачу по функциональности, его временно будет вызывать монолит. До тех пор, пока вызывающая его часть функциональности также не будет вынесена в микросервис.
Поэтому, чтобы запустить микросервис нужно будет реализовать внутреннюю интеграцию монолита с микросервисом по API.
💎 Миграция данных из монолита в микросервисы и обеспечение синхронизации данных:
Работа с данными пока может оставаться в двух местах, т.к. мы делаем постепенный переход от монолита к микросервисам.
Поэтому у нас будет две задачи по базам данных:
1. Обеспечить миграцию необходимых данных из БД монолита в БД микросервисов при запуске в продакшн.
2. Обеспечить синхронизацию данных между БД монолита и БД микросервисов.
Не все пункты по миграциям и интеграциям нужны. Зависит от проекта и задачи в нем.
Пример для GetTickets 👇
#АрхитектураGA #GetTickets
Этап 6. Поддержка совместимости с монолитом: миграции и интеграции
Монолит остается с нами длительное время, пока всё будет постепенно переходить на микросервисы. И в нём пока продолжает работать основная часть функциональности. Необходимо разработать план миграций, итераций и релизов обновлений.
💎 Интеграция монолита с микросервисом:
Чтобы микросервис работал и выполнял свою маленькую задачу по функциональности, его временно будет вызывать монолит. До тех пор, пока вызывающая его часть функциональности также не будет вынесена в микросервис.
Поэтому, чтобы запустить микросервис нужно будет реализовать внутреннюю интеграцию монолита с микросервисом по API.
💎 Миграция данных из монолита в микросервисы и обеспечение синхронизации данных:
Работа с данными пока может оставаться в двух местах, т.к. мы делаем постепенный переход от монолита к микросервисам.
Поэтому у нас будет две задачи по базам данных:
1. Обеспечить миграцию необходимых данных из БД монолита в БД микросервисов при запуске в продакшн.
2. Обеспечить синхронизацию данных между БД монолита и БД микросервисов.
Не все пункты по миграциям и интеграциям нужны. Зависит от проекта и задачи в нем.
Пример для GetTickets 👇
#АрхитектураGA #GetTickets
👍5❤3
🧩 Поддержка совместимости с монолитом: пример для GetTickets 🧩
Из монолита GetTickets в отдельный микросервис выносится функциональность по управлению бронированиями (просмотр, создание, изменение, удаление - CRUD).
💎 Интеграции:
Есть старый API монолита на получений списка бронирований: GET /api-monolit//1.0/bookings. Его вызывают мобильные приложения и веб-приложение.
Есть новый API микросервиса: GET /api-new/1.0/bookings.
Чтобы работающие в продакшн мобильные приложения не пострадали, нам точно придётся сделать редирект (перенаправление вызовов) со старого API на новый.
С остальными методами по бронированиям аналогично.
Если вдруг бронирования где-то используются как вложенные объекты, то в эти места должны быть также встроены вызовы новых API.
💎 Миграция и синхронизация:
Мы полностью переносим все необходимые данные по бронированиям в новую БД.
Я понимаю, что миграция БД (перенос данных) по всем заказам с продакшн, накопившимся за 2 года, явно затянется по времени, так как заказов миллионы. Поэтому я буду прорабатывать детально сценарий переезда.
Например, я могу запустить микросервис в продакшн и в рамках релиза запустить миграцию данных до текущего дня (момента релиза), но пока не подключать новый микросервис к монолиту. Важно, чтобы копировались исторические данные, которые нельзя менять. Поэтому мигрировать буду только бронирования в статусе завершенных.
Как только миграция большого объема данных будет завершена, то я смогу следующим релизом запустить интеграцию монолита с микросервисом и догрузить самые актуальные данные в новую БД.
Это общий план. Его можно и нужно прорабатывать детальнее. Есть другие варианты переезда. Чтобы уточнить их я буду очень долго анализировать БД и функциональные зависимости с заказами внутри монолита GetTickets.
Остались этапы 7-10 плана миграции. Продолжение 👇
#АрхитектураGA #GetTickets
Из монолита GetTickets в отдельный микросервис выносится функциональность по управлению бронированиями (просмотр, создание, изменение, удаление - CRUD).
💎 Интеграции:
Есть старый API монолита на получений списка бронирований: GET /api-monolit//1.0/bookings. Его вызывают мобильные приложения и веб-приложение.
Есть новый API микросервиса: GET /api-new/1.0/bookings.
Чтобы работающие в продакшн мобильные приложения не пострадали, нам точно придётся сделать редирект (перенаправление вызовов) со старого API на новый.
С остальными методами по бронированиям аналогично.
Если вдруг бронирования где-то используются как вложенные объекты, то в эти места должны быть также встроены вызовы новых API.
💎 Миграция и синхронизация:
Мы полностью переносим все необходимые данные по бронированиям в новую БД.
Я понимаю, что миграция БД (перенос данных) по всем заказам с продакшн, накопившимся за 2 года, явно затянется по времени, так как заказов миллионы. Поэтому я буду прорабатывать детально сценарий переезда.
Например, я могу запустить микросервис в продакшн и в рамках релиза запустить миграцию данных до текущего дня (момента релиза), но пока не подключать новый микросервис к монолиту. Важно, чтобы копировались исторические данные, которые нельзя менять. Поэтому мигрировать буду только бронирования в статусе завершенных.
Как только миграция большого объема данных будет завершена, то я смогу следующим релизом запустить интеграцию монолита с микросервисом и догрузить самые актуальные данные в новую БД.
Это общий план. Его можно и нужно прорабатывать детальнее. Есть другие варианты переезда. Чтобы уточнить их я буду очень долго анализировать БД и функциональные зависимости с заказами внутри монолита GetTickets.
Остались этапы 7-10 плана миграции. Продолжение 👇
#АрхитектураGA #GetTickets
❤15👍2
📋🚀 Как быстро переехать с монолита на микросервисы?
Завершаем обсуждение плана переезда С МОНОЛИТА НА МИКРОСЕРВИСЫ
Этап 7. Подготовка инфраструктуры
Микросервисы требуют своей инфраструктуры для развертывания, мониторинга и управления. На этом этапе подключаются DevOps инженеры, которые помогут организовать тестовые, предпродуктовые и продуктовые площадки для вашего нового микросервиса.
Этап 8. Разработка и тестирование
Разработайте первый микросервис, выделив его функциональность из монолита. Тщательно протестируйте его, чтобы убедиться, что он работает в соответствии с требованиями.
Этап 9. Запуск и переход к следующему микросервису
Этапы 4-8 повторяем до тех пор, пока весь монолит не будет разделен на микросервисы.
Этап 10. Масштабирование и оптимизация системы
После того как основные микросервисы будут разработаны и запущены, вы можете масштабировать и оптимизировать их работу, добавлять новые функции и улучшать производительность.
Подводя итоги:
🚀 Как быстро переехать с монолита на микросервисы? Никак 😁
Единственный шанс, если у вас совсем маленькое приложение. Но скорее всего в этом случае монолит и сикросервисы просто не нужны.
Переезд с монолита на микросервисы это про проекты, которым 5+ лет. И сейчас такие задачи набирают обороты: старые системы нужны, и их не могут просто взять и выбросить. Поэтому делают переезд на новые технологии и новую архитектуру.
Все три варианта переезда собрала для вас здесь:
🔸 Вариант 1 - Переписываем с нуля
🔸 Вариант 2 - новое на микросервисах, старое не трогаем
🔸 Вариант 3 - старое поэтапно выносим из монолита, новое сразу в микросервисы
Если вам предстоит переезд на микросервисы или вы планируете связать свою будущую работу с задачами на архитектуру, то эта серия постов вам может пригодиться.
Пересылайте себе, чтобы сохранить в избранное ❤️
#АрхитектураGA #GetTickets
Завершаем обсуждение плана переезда С МОНОЛИТА НА МИКРОСЕРВИСЫ
Этап 7. Подготовка инфраструктуры
Микросервисы требуют своей инфраструктуры для развертывания, мониторинга и управления. На этом этапе подключаются DevOps инженеры, которые помогут организовать тестовые, предпродуктовые и продуктовые площадки для вашего нового микросервиса.
Этап 8. Разработка и тестирование
Разработайте первый микросервис, выделив его функциональность из монолита. Тщательно протестируйте его, чтобы убедиться, что он работает в соответствии с требованиями.
Этап 9. Запуск и переход к следующему микросервису
Этапы 4-8 повторяем до тех пор, пока весь монолит не будет разделен на микросервисы.
Этап 10. Масштабирование и оптимизация системы
После того как основные микросервисы будут разработаны и запущены, вы можете масштабировать и оптимизировать их работу, добавлять новые функции и улучшать производительность.
Подводя итоги:
🚀 Как быстро переехать с монолита на микросервисы? Никак 😁
Единственный шанс, если у вас совсем маленькое приложение. Но скорее всего в этом случае монолит и сикросервисы просто не нужны.
Переезд с монолита на микросервисы это про проекты, которым 5+ лет. И сейчас такие задачи набирают обороты: старые системы нужны, и их не могут просто взять и выбросить. Поэтому делают переезд на новые технологии и новую архитектуру.
Все три варианта переезда собрала для вас здесь:
🔸 Вариант 1 - Переписываем с нуля
🔸 Вариант 2 - новое на микросервисах, старое не трогаем
🔸 Вариант 3 - старое поэтапно выносим из монолита, новое сразу в микросервисы
Если вам предстоит переезд на микросервисы или вы планируете связать свою будущую работу с задачами на архитектуру, то эта серия постов вам может пригодиться.
Пересылайте себе, чтобы сохранить в избранное ❤️
#АрхитектураGA #GetTickets
❤11
Media is too big
VIEW IN TELEGRAM
На прошлой неделе у нас прошел онлайн-практикум по проектированию БД. Получилась очень крутая команда системных аналитиков ❤️ Всех удалось подключить к эфиру, чтобы дать попробовать самостоятельно поработать с задачей и получить обратную связь!
Коллеги делают ДЗ и готовятся к следующему практикуму!
Это был онлайн-практикум:
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 13 февраля
Это новый формат работы с темой по БД и SQL в GetAnalyst для тех, кто хочет закреплять теорию на практике, а также погрузиться в углубленное изучение отдельных тем, дополняющих программу по проектированию БД и SQL.
Вы можете подписаться на практикумы в любое время!
А также отписаться, если темы вам не интересны.
Следующее занятие “Разработка требований к миграциям БД” будет в марте.
💫 Для тех, кто уже подключился и будет с нами на практике доступно занятие с видео в записи (+1 бонусное по БД и SQL), по которым можно готовиться к следующему.
Сейчас работаем с одним проектом по медицинской системе, на котором отрабатываем навыки. Далее проекты будем менять. Онлайн-практикумы всегда будут уникальными и повторяться не будут!
Продолжаем активно работать и до новых встреч онлайн! 🙌
Коллеги делают ДЗ и готовятся к следующему практикуму!
Это был онлайн-практикум:
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 13 февраля
Это новый формат работы с темой по БД и SQL в GetAnalyst для тех, кто хочет закреплять теорию на практике, а также погрузиться в углубленное изучение отдельных тем, дополняющих программу по проектированию БД и SQL.
Вы можете подписаться на практикумы в любое время!
А также отписаться, если темы вам не интересны.
Следующее занятие “Разработка требований к миграциям БД” будет в марте.
💫 Для тех, кто уже подключился и будет с нами на практике доступно занятие с видео в записи (+1 бонусное по БД и SQL), по которым можно готовиться к следующему.
Сейчас работаем с одним проектом по медицинской системе, на котором отрабатываем навыки. Далее проекты будем менять. Онлайн-практикумы всегда будут уникальными и повторяться не будут!
Продолжаем активно работать и до новых встреч онлайн! 🙌
👍5❤4🥰2