Друзья, сегодня очередной день, когда можно без стеснения признаваться в любви своим близким, семье, друзьям и коллегам!
Мы крепко обнимаем каждого из вас, а также каждого участника нашей дружной команды 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
🌟 Пример: список микросервисов для банковской системы по работе с корпоративными клиентами 🌟
Система банка по работе с корпоративными клиентами может включать в себя ряд микросервисов, каждый из которых обеспечивает выполнение конкретной функции или набора функций. Есть разные варианты реализации, и чтобы вы поняли принципы деления, я хочу показать этот пример.
Пример списка микросервисов
для банковской системы по работе с корпоративными клиентами:
▫️ Микросервис управления корпоративными аккаунтами: управление учетными записями пользователей, включая создание, изменение, активацию и деактивацию аккаунтов.
▫️ Микросервис управления балансами счетов: изменение баланса счета после выполнения банковских операций, проверка баланса.
▫️ Микросервис управления кредитами: обрабатывает заявки на кредиты, управляет кредитными счетами, расчетами по кредитам и предоставляет информацию о статусе кредитов.
▫️ Микросервис платежей: Отвечает за обработку входящих и исходящих платежей, автоматических платежей.
▫️ Микросервис переводов: Отвечает за обработку входящих и исходящих переводов, включая международные переводы.
▫️ Микросервис управления корпоративными картами: Управляет выпуском, активацией, блокировкой и закрытием корпоративных карт, а также мониторингом транзакций.
▫️ Микросервис аутентификации и авторизации: Обеспечивает безопасный доступ к системе, управляет правами доступа пользователей и регистрирует сессии входа в систему.
▫️ Микросервис уведомлений: Отправляет уведомления о транзакциях, изменениях ставок, сроках платежей и другой важной информации через электронную почту, СМС или push-уведомления.
▫️ Микросервис API для интеграции: Предоставляет API для интеграции банковских сервисов с внешними системами корпоративных клиентов, такими как ERP-системы, бухгалтерский учет и другие финансовые системы.
▫️и др.
Каждый из микросервисов может разрабатываться независимо, что дает банку гибкость в управлении ИТ-инфраструктурой и способность быстро адаптироваться к изменяющимся требованиям.
#АрхитектураGA
Система банка по работе с корпоративными клиентами может включать в себя ряд микросервисов, каждый из которых обеспечивает выполнение конкретной функции или набора функций. Есть разные варианты реализации, и чтобы вы поняли принципы деления, я хочу показать этот пример.
Пример списка микросервисов
для банковской системы по работе с корпоративными клиентами:
▫️ Микросервис управления корпоративными аккаунтами: управление учетными записями пользователей, включая создание, изменение, активацию и деактивацию аккаунтов.
▫️ Микросервис управления балансами счетов: изменение баланса счета после выполнения банковских операций, проверка баланса.
▫️ Микросервис управления кредитами: обрабатывает заявки на кредиты, управляет кредитными счетами, расчетами по кредитам и предоставляет информацию о статусе кредитов.
▫️ Микросервис платежей: Отвечает за обработку входящих и исходящих платежей, автоматических платежей.
▫️ Микросервис переводов: Отвечает за обработку входящих и исходящих переводов, включая международные переводы.
▫️ Микросервис управления корпоративными картами: Управляет выпуском, активацией, блокировкой и закрытием корпоративных карт, а также мониторингом транзакций.
▫️ Микросервис аутентификации и авторизации: Обеспечивает безопасный доступ к системе, управляет правами доступа пользователей и регистрирует сессии входа в систему.
▫️ Микросервис уведомлений: Отправляет уведомления о транзакциях, изменениях ставок, сроках платежей и другой важной информации через электронную почту, СМС или push-уведомления.
▫️ Микросервис API для интеграции: Предоставляет API для интеграции банковских сервисов с внешними системами корпоративных клиентов, такими как ERP-системы, бухгалтерский учет и другие финансовые системы.
▫️и др.
Каждый из микросервисов может разрабатываться независимо, что дает банку гибкость в управлении ИТ-инфраструктурой и способность быстро адаптироваться к изменяющимся требованиям.
#АрхитектураGA
❤7👍5🔥3
🌟 Пример: список микросервисов для системы страхования автомобилей 🌟
Система по страхованию автомобилей, включая ОСАГО и КАСКО, может быть разработана с использованием архитектуры микросервисов для повышения ее масштабируемости, гибкости и надежности. Это еще
Пример списка микросервисов
для системы страхования автомобилей:
🌟 Микросервис управления клиентами:
Управляет информацией о клиентах, включая регистрацию, аутентификацию, профили клиентов и историю общения.
🌟 Микросервис котировок страхования:
Предоставляет расчет стоимости страховки на основе введенных данных о клиенте и автомобиле, включая модель, год выпуска, регион регистрации и другие параметры.
🌟 Микросервис полисов:
Управляет созданием, хранением и обновлением полисов страхования, а также обеспечивает доступ к электронным копиям полисов.
🌟 Микросервис входящих платежей:
Обрабатывает транзакции по приему платежей от клиентов, включая интеграцию с платежными системами и управление финансовыми отчетами.
🌟 Микросервис урегулирования убытков:
Обрабатывает заявки на страховые выплаты, включая прием заявлений о страховом случае, документацию, оценку ущерба и формирует запросы на выплаты по страховым случаям.
🌟 Микросервис исходящих платежей:
Обрабатывает транзакции по оплате страховых выплат по результатам страховых случаев, включая интеграцию с платежными системами и управление финансовыми операциями.
🌟 Микросервис проверки истории автомобиля:
Интегрируется с внешними базами данных для проверки истории автомобиля, включая прошлые ДТП, страховые выплаты и техническое состояние.
Продолжение 👇
#АрхитектураGA
Система по страхованию автомобилей, включая ОСАГО и КАСКО, может быть разработана с использованием архитектуры микросервисов для повышения ее масштабируемости, гибкости и надежности. Это еще
Пример списка микросервисов
для системы страхования автомобилей:
Управляет информацией о клиентах, включая регистрацию, аутентификацию, профили клиентов и историю общения.
Предоставляет расчет стоимости страховки на основе введенных данных о клиенте и автомобиле, включая модель, год выпуска, регион регистрации и другие параметры.
Управляет созданием, хранением и обновлением полисов страхования, а также обеспечивает доступ к электронным копиям полисов.
Обрабатывает транзакции по приему платежей от клиентов, включая интеграцию с платежными системами и управление финансовыми отчетами.
Обрабатывает заявки на страховые выплаты, включая прием заявлений о страховом случае, документацию, оценку ущерба и формирует запросы на выплаты по страховым случаям.
Обрабатывает транзакции по оплате страховых выплат по результатам страховых случаев, включая интеграцию с платежными системами и управление финансовыми операциями.
Интегрируется с внешними базами данных для проверки истории автомобиля, включая прошлые ДТП, страховые выплаты и техническое состояние.
Продолжение 👇
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍1🔥1
🌟 Пример: список микросервисов для системы страхования автомобилей - часть 2 🌟
🌟 Микросервис уведомлений:
Отправляет клиентам уведомления о сроках оплаты, изменениях в полисе, напоминания о продлении полиса и другие важные сообщения.
🌟 Микросервис аналитики и отчетности:
Собирает и анализирует данные о продажах полисов, страховых случаях, клиентских обращениях для формирования отчетов и помощи в принятии решений.
🌟 Микросервис подписания документов:
Управляет выпуском электронных подписей для страховых договоров и связанных документов.
🌟 Микросервис поддержки клиентов:
Предоставляет функциональность для общения с клиентами через различные каналы связи, включая чат, электронную почту и голосовые вызовы.
🌟 Микросервис “Чистильщик мусора”:
Удаляет ненужную информацию из системы. Например, данные неактивных аккаунтов (пользователей, кто не подтвердил учетную запись по почте в течение месяца).
Могут быть выделены и другие наборы микросервисов, можно их сделать более маленькими.
Готовы переходить к выделению микросервисов из монолита в GetTickets? Ставим 🔥
#АрхитектураGA
Отправляет клиентам уведомления о сроках оплаты, изменениях в полисе, напоминания о продлении полиса и другие важные сообщения.
Собирает и анализирует данные о продажах полисов, страховых случаях, клиентских обращениях для формирования отчетов и помощи в принятии решений.
Управляет выпуском электронных подписей для страховых договоров и связанных документов.
Предоставляет функциональность для общения с клиентами через различные каналы связи, включая чат, электронную почту и голосовые вызовы.
Удаляет ненужную информацию из системы. Например, данные неактивных аккаунтов (пользователей, кто не подтвердил учетную запись по почте в течение месяца).
Могут быть выделены и другие наборы микросервисов, можно их сделать более маленькими.
Готовы переходить к выделению микросервисов из монолита в GetTickets? Ставим 🔥
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
🎁 Дарю книгу “От монолита к микросервисам” Сэма Ньюмана 🎁
Чтобы получить книгу, нужно:
1. Выделить список микросервисов для нашего проекта GetTickets.
2. Прислать его в комментарий к этому посту.
Проект "GetTickets" - платформа для онлайн-бронирования и покупки авиабилетов.
Материалы:
🔗 Описание проекта GetTickets
🔗 Определение микросервисов
🔗 Примеры микросервисов для банка и страховой компании были сегодня выше.
🎁 Итоги подведу в пятницу.
За самый полный и развернутый ответ подарю сертификат на Литрес для приобретения книги “От монолита к микросервисам” Сэма Ньюмана. А также дам обратную связь по нему и предложения по улучшению.
Жду ваши ответы! Это ваш шанс попробовать себя в задаче проектирование архитектуры и получить обратную связь!
#АрхитектураGA #GetTickets
Чтобы получить книгу, нужно:
1. Выделить список микросервисов для нашего проекта GetTickets.
2. Прислать его в комментарий к этому посту.
Проект "GetTickets" - платформа для онлайн-бронирования и покупки авиабилетов.
Материалы:
🔗 Описание проекта GetTickets
🔗 Определение микросервисов
🔗 Примеры микросервисов для банка и страховой компании были сегодня выше.
🎁 Итоги подведу в пятницу.
За самый полный и развернутый ответ подарю сертификат на Литрес для приобретения книги “От монолита к микросервисам” Сэма Ньюмана. А также дам обратную связь по нему и предложения по улучшению.
Жду ваши ответы! Это ваш шанс попробовать себя в задаче проектирование архитектуры и получить обратную связь!
#АрхитектураGA #GetTickets
❤7🤩3
❌🙅♀️🙅 Когда микросервисы не подойдут 🙅🙅♀️❌
Я рассказываю про переезд с монолита на микросервисы. О том, что это поможет в улучшении производительности и в масштабировании системы. Но не всегда микросервисы являются идеальным решением для проекта.
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
Продолжение 👇
#АрхитектураGA
Я рассказываю про переезд с монолита на микросервисы. О том, что это поможет в улучшении производительности и в масштабировании системы. Но не всегда микросервисы являются идеальным решением для проекта.
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
Продолжение 👇
#АрхитектураGA
🔥7❤4👍3🥰1
❌🙅♀️🙅 Когда микросервисы не подойдут - продолжение 🙅🙅♀️❌
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
👍9🔥4❤3