📋 Подробный план переезда С МОНОЛИТА НА МИКРОСЕРВИСЫ 📋
Этап 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
К 19 годам я поняла, что меня всю жизнь учили работать с наставниками.
В детском саду у меня был воспитатель, в школе - учитель, в университете - преподаватель. Это были мои наставники и эксперты, к кому я обращалась за помощью.
Если раньше я сильно зажмуривалась, чтобы желания и цели исполнялись и думала “наверное я во всем сама разобралась, должно повезти”, то сейчас подход изменился. Я нахожу людей, которые уже реализовали похожие цели и мечты, и спрашиваю их, как они это сделали.
Я понимаю, что если хочу быстро добиться очередной личной или карьерной цели, то мне нужен наставник, который покажет мне, как это сделать. Я хочу учиться у тех, кто разбирается лучше меня.
Когда я пришла на первое место работы стажером-аналитиком, мне дали в наставники старшего аналитика, от которого я перенимала опыт и фишки по работе с задачами. Для обучению архитектуре - опытные разработчики и архитекторы. Для бизнеса - предприниматели с крупными компаниями.
👇👇👇
Все, что у меня есть сегодня, я обязана подходу - смотри на лучших в своей области, работай с ними и копируй.
Работа с наставниками и книгами в дополнение - это самый быстрый личностный рост.
Я точно знаю, что через год у меня появятся новые желания, и уже работаю над подготовкой к ним с наставниками, чтобы процесс их реализации в будущем был сразу правильным и давался легко.
Согласитесь, что приятнее получать желаемое с пониманием что и как делать, благодаря раскрытым тебе секретам от наставника, а не в попытках угадывать правильно я делаю или нет 🤷♀️
И конечно личностный рост, потому что ты в окружении крутых людей, которым близка твоя цель или они уже до неё дошли. Без роста личности вообще вряд ли что-то получится достичь, придется зажмуриваться до конца жизни и мечты так и останутся мечтами.
И пока твои глаза будут закрыты, кто-то другой прямо сейчас реализует твои мечты и желания. Я выбираю не зажмуриваться, а работать, чтобы исполнять свои мечты 🙌
В детском саду у меня был воспитатель, в школе - учитель, в университете - преподаватель. Это были мои наставники и эксперты, к кому я обращалась за помощью.
Если раньше я сильно зажмуривалась, чтобы желания и цели исполнялись и думала “наверное я во всем сама разобралась, должно повезти”, то сейчас подход изменился. Я нахожу людей, которые уже реализовали похожие цели и мечты, и спрашиваю их, как они это сделали.
Я понимаю, что если хочу быстро добиться очередной личной или карьерной цели, то мне нужен наставник, который покажет мне, как это сделать. Я хочу учиться у тех, кто разбирается лучше меня.
Когда я пришла на первое место работы стажером-аналитиком, мне дали в наставники старшего аналитика, от которого я перенимала опыт и фишки по работе с задачами. Для обучению архитектуре - опытные разработчики и архитекторы. Для бизнеса - предприниматели с крупными компаниями.
👇👇👇
Все, что у меня есть сегодня, я обязана подходу - смотри на лучших в своей области, работай с ними и копируй.
Работа с наставниками и книгами в дополнение - это самый быстрый личностный рост.
Я точно знаю, что через год у меня появятся новые желания, и уже работаю над подготовкой к ним с наставниками, чтобы процесс их реализации в будущем был сразу правильным и давался легко.
Согласитесь, что приятнее получать желаемое с пониманием что и как делать, благодаря раскрытым тебе секретам от наставника, а не в попытках угадывать правильно я делаю или нет 🤷♀️
И конечно личностный рост, потому что ты в окружении крутых людей, которым близка твоя цель или они уже до неё дошли. Без роста личности вообще вряд ли что-то получится достичь, придется зажмуриваться до конца жизни и мечты так и останутся мечтами.
И пока твои глаза будут закрыты, кто-то другой прямо сейчас реализует твои мечты и желания. Я выбираю не зажмуриваться, а работать, чтобы исполнять свои мечты 🙌
❤🔥19👍5❤2
Важное напоминание для системных аналитиков, которые хотят расти в Senior и работать со сложными проектами, которыми пользуются миллионы пользователей:
Уже совсем скоро стартует практическая программа:
🌟 Проектирование архитектуры
🗓 Старт 29 февраля 2024
🔗 Подробности о программе и заявка на предзапись
🎁 С 16 до 25 февраля открыта предзапись на специальных условиях.
Программа подойдёт только для опытных системных аналитиков (middle и выше).
Уже совсем скоро стартует практическая программа:
🌟 Проектирование архитектуры
🗓 Старт 29 февраля 2024
🔗 Подробности о программе и заявка на предзапись
🎁 С 16 до 25 февраля открыта предзапись на специальных условиях.
Программа подойдёт только для опытных системных аналитиков (middle и выше).
❤1
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
💫 ПОРТФОЛИО СИСТЕМНОГО АНАЛИТИКА 💫
В новом выпуске подкаста мы углубляемся в тему создания портфолио для системных аналитиков. В эпизоде подробно разбирается, почему портфолио является неотъемлемой частью карьерного роста аналитика, как начать его формировать, особенно если вы только начинаете карьеру системного аналитика, и какие инструменты могут помочь в этом.
Екатерина Ананьева делится советами по демонстрации портфолио работодателям и объясняет, в каких случаях оно может стать ключевым фактором при устройстве на работу. Подкаст включает примеры артефактов, которые можно включить в портфолио, и подчеркивает важность подхода к его созданию для презентации себя как специалиста.
Обсуждение вдохновлено вопросом из Telegram-чата сообщества GetAnalyst и будет полезно как для начинающих, так и для опытных системных аналитиков, стремящихся продемонстрировать свой профессионализм и навыки потенциальным работодателям.
00:20 - Введение и предыстория выбора темы
2:32 - Определение портфолио
5:22 - Примеры портфолио для разных специалистов и его назначение
10:45 - Что входит в портфолио системного аналитика
15:47 - Когда и для чего системному аналитику нужно портфолио, соблюдение корпоративной тайны
23:33 - Опыт использования портфолио и как оно помогло устроиться на позицию стажера системного аналитика
25:57 - Что можно использовать для портфолио системного аналитика - итоги
31:01 - С помощью каких инструментов и ресурсов формировать портфолио
35:20 - Обязательно ли наличие портфолио для системного аналитика
37:11 - Рекомендации слушателям
Эпизод доступен в:
⏯ Apple Podcast
⏯ YouTube
⏯ Telegram
⏯ Spotify
⏯ Amazon Music
*Яндекс.Музыка в процессе. Ссылку добавим.
Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!
В новом выпуске подкаста мы углубляемся в тему создания портфолио для системных аналитиков. В эпизоде подробно разбирается, почему портфолио является неотъемлемой частью карьерного роста аналитика, как начать его формировать, особенно если вы только начинаете карьеру системного аналитика, и какие инструменты могут помочь в этом.
Екатерина Ананьева делится советами по демонстрации портфолио работодателям и объясняет, в каких случаях оно может стать ключевым фактором при устройстве на работу. Подкаст включает примеры артефактов, которые можно включить в портфолио, и подчеркивает важность подхода к его созданию для презентации себя как специалиста.
Обсуждение вдохновлено вопросом из Telegram-чата сообщества GetAnalyst и будет полезно как для начинающих, так и для опытных системных аналитиков, стремящихся продемонстрировать свой профессионализм и навыки потенциальным работодателям.
00:20 - Введение и предыстория выбора темы
2:32 - Определение портфолио
5:22 - Примеры портфолио для разных специалистов и его назначение
10:45 - Что входит в портфолио системного аналитика
15:47 - Когда и для чего системному аналитику нужно портфолио, соблюдение корпоративной тайны
23:33 - Опыт использования портфолио и как оно помогло устроиться на позицию стажера системного аналитика
25:57 - Что можно использовать для портфолио системного аналитика - итоги
31:01 - С помощью каких инструментов и ресурсов формировать портфолио
35:20 - Обязательно ли наличие портфолио для системного аналитика
37:11 - Рекомендации слушателям
Эпизод доступен в:
⏯ Apple Podcast
⏯ YouTube
⏯ Telegram
⏯ Spotify
⏯ Amazon Music
*Яндекс.Музыка в процессе. Ссылку добавим.
Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!
❤11👍4🥰1🤩1
🗓 Вебинар по архитектуре 29 февраля 🗓
Работа с задачами на Backend может стать настоящим испытанием для системного аналитика: интеграции, API, архитектура. Без глубокого понимания этих тем работа может казаться игрой в "Повезёт - Не Повезёт".
Получаете вопросы от разработчиков Backend из набора непонятных терминов, которые заставляют вас обращаться к Google?
На командных встречах сложно уловить суть происходящего, а перспектива работы на новом проекте с системным архитектором кажется пугающей? Давайте это менять.
Практический вебинар, чтобы разобраться с темой:
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
План
1. Роль системного аналитика в проектировании архитектуры
2. Знакомство с проектом
3. Проектирование монолита
4. Переход к сервисам (SOA) и микросервисам (MSA)
5. Проблемы разделения монолита на микросервисы
6. Что нужно знать системному аналитику про работу с архитектурой
Эти навыки по проектированию архитектуры помогут перейти на новый уровень в системном анализе, и стать более ценным специалистом для вашей компании.
Готовы освоить новый навык?
До встречи в прямом эфире!
Работа с задачами на Backend может стать настоящим испытанием для системного аналитика: интеграции, API, архитектура. Без глубокого понимания этих тем работа может казаться игрой в "Повезёт - Не Повезёт".
Получаете вопросы от разработчиков Backend из набора непонятных терминов, которые заставляют вас обращаться к Google?
На командных встречах сложно уловить суть происходящего, а перспектива работы на новом проекте с системным архитектором кажется пугающей? Давайте это менять.
Практический вебинар, чтобы разобраться с темой:
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
План
1. Роль системного аналитика в проектировании архитектуры
2. Знакомство с проектом
3. Проектирование монолита
4. Переход к сервисам (SOA) и микросервисам (MSA)
5. Проблемы разделения монолита на микросервисы
6. Что нужно знать системному аналитику про работу с архитектурой
Эти навыки по проектированию архитектуры помогут перейти на новый уровень в системном анализе, и стать более ценным специалистом для вашей компании.
Готовы освоить новый навык?
До встречи в прямом эфире!
👍23❤8🥰2
Привет! Начнем неделю с обзора исходной схемы архитектуры по проекту GtTickets - монолит.
Что мы видим на схеме архитектуры:
🔸 Сервер (Backend)
Единое приложение, которое обеспечивает всех хранение данных в БД и реализацию всех функциональных возможностей приложения.
При разработке использовали принцип модульной архитектуры, поэтому уже сейчас можно детализировать схему Backend и показать модули: поиск рейсов, бронирования, платежи, пользователи, отчеты, уведомления.
🔸🔸 Одна база данных, без делений на схемы. Внутри более 100 таблиц.
🔸🔸 REST API для обеспечения работы пользовательских приложений. Все, что отображается на экранах пользовательских приложений, получается ими через разработанный внутренний REST API. который при желании можно сделать публичным (открытым, с публичной API-документацией)
🔸 МП пользователя Android
Приложение пользователя для обеспечения функциональности поиска и бронирования билетов.
Приложение запрашивает и получает данные только от сервера Backend GetTickets. Среди внешних интеграций можно выделить только интеграцию с системой уведомлений Firebase Cloud Messaging.
🔸 МП пользователя iOS
Аналогично Android. Но интеграция.с Firebase иным способом.
🔸 Веб-приложение пользователя
Аналогично Android, но внешние интеграции для уведомлений не предусмотрены.
🔸 Веб-приложение администратора
Это самый неприятный вариант монолитного фронтенда, когда код бэкенда и фронтенда в одном месте, и данные для приложения администратора получаются не через API, а напрямую из БД с помощью SQL-запросов (frontend - веб-приложение, пользовательское приложение, пользовательский интерфейс работы с системой).
Почему могло быть принято решение разработать монолитный фронтенд без API, как для пользовательских приложений? Не было необходимости повторять функциональность для трех разных клиентов, как это есть для пользовательских приложений iOS, Android, Web. А также это внутреннее приложение, для сотрудников. Решили упростить реализацию.
Продолжение 👇
#АрхитектураGA #GetTickets
Что мы видим на схеме архитектуры:
🔸 Сервер (Backend)
Единое приложение, которое обеспечивает всех хранение данных в БД и реализацию всех функциональных возможностей приложения.
При разработке использовали принцип модульной архитектуры, поэтому уже сейчас можно детализировать схему Backend и показать модули: поиск рейсов, бронирования, платежи, пользователи, отчеты, уведомления.
🔸🔸 Одна база данных, без делений на схемы. Внутри более 100 таблиц.
🔸🔸 REST API для обеспечения работы пользовательских приложений. Все, что отображается на экранах пользовательских приложений, получается ими через разработанный внутренний REST API. который при желании можно сделать публичным (открытым, с публичной API-документацией)
🔸 МП пользователя Android
Приложение пользователя для обеспечения функциональности поиска и бронирования билетов.
Приложение запрашивает и получает данные только от сервера Backend GetTickets. Среди внешних интеграций можно выделить только интеграцию с системой уведомлений Firebase Cloud Messaging.
🔸 МП пользователя iOS
Аналогично Android. Но интеграция.с Firebase иным способом.
🔸 Веб-приложение пользователя
Аналогично Android, но внешние интеграции для уведомлений не предусмотрены.
🔸 Веб-приложение администратора
Это самый неприятный вариант монолитного фронтенда, когда код бэкенда и фронтенда в одном месте, и данные для приложения администратора получаются не через API, а напрямую из БД с помощью SQL-запросов (frontend - веб-приложение, пользовательское приложение, пользовательский интерфейс работы с системой).
Почему могло быть принято решение разработать монолитный фронтенд без API, как для пользовательских приложений? Не было необходимости повторять функциональность для трех разных клиентов, как это есть для пользовательских приложений iOS, Android, Web. А также это внутреннее приложение, для сотрудников. Решили упростить реализацию.
Продолжение 👇
#АрхитектураGA #GetTickets
👍11❤5🔥2
🧩 Внешние системы - интеграции с GetTickets:
🔸 Группа систем для поиска рейсов и бронирования авиабилетов
С каждой из внешних систем интеграция по API (это могут быть REST, SOAP, GraphQL и другие). Из схемы видно, что для интеграций используется API внешних систем.
На основании схемы архитектуры я могу описать, что для поиска рейсов в приложении Android будет выполняться последовательность шагов:
1. Отправить запрос на поиск в REST API GetTickets, используя интеграционный метод.
2. REST API GetTickets принимает запрос и выполняет его обработку.
В процессе обработки запроса выполняется вызов внешних систем поиска рейсов и бронирований по API (АвиаСэйлс, СкайСканер, Аэрофлот и другие).
3. Полученный ответ от внешней системы по API обрабатывается в соответствии с маппингом данных (таблицей сопоставления).
Все необходимые данные могут быть записаны в единую БД системы (если запрос реализуется асинхронно - в два вызова отдельных метода, с созданием отложенной задачи POST и получением ответа GET, то это актуально).
4. Итоговый результат возвращается в ответе от REST API GetTickets на приложение Android.
🔸 Платежная система ЮКасса
Используется для получения оплаты от пользователей за бронирования. Интеграция реализована в модуле приема и обработки платежей. После каждой транзакции в единую БД системы записываются данные по платежам (id, параметры чеков и другие).
🔸 Система отправки СМС
Используется для отправки подтверждения аккаунта пользователя (модуль управления пользователями) и информации о бронировании после успешной оплаты (модуль бронирований).
🔸 Система отправки push-уведомлений
Используется для информирования пользователей об изменениях цен и событиях по оплаченным бронированиям.
#АрхитектураGA #GetTickets
🔸 Группа систем для поиска рейсов и бронирования авиабилетов
С каждой из внешних систем интеграция по API (это могут быть REST, SOAP, GraphQL и другие). Из схемы видно, что для интеграций используется API внешних систем.
На основании схемы архитектуры я могу описать, что для поиска рейсов в приложении Android будет выполняться последовательность шагов:
1. Отправить запрос на поиск в REST API GetTickets, используя интеграционный метод.
2. REST API GetTickets принимает запрос и выполняет его обработку.
В процессе обработки запроса выполняется вызов внешних систем поиска рейсов и бронирований по API (АвиаСэйлс, СкайСканер, Аэрофлот и другие).
3. Полученный ответ от внешней системы по API обрабатывается в соответствии с маппингом данных (таблицей сопоставления).
Все необходимые данные могут быть записаны в единую БД системы (если запрос реализуется асинхронно - в два вызова отдельных метода, с созданием отложенной задачи POST и получением ответа GET, то это актуально).
4. Итоговый результат возвращается в ответе от REST API GetTickets на приложение Android.
🔸 Платежная система ЮКасса
Используется для получения оплаты от пользователей за бронирования. Интеграция реализована в модуле приема и обработки платежей. После каждой транзакции в единую БД системы записываются данные по платежам (id, параметры чеков и другие).
🔸 Система отправки СМС
Используется для отправки подтверждения аккаунта пользователя (модуль управления пользователями) и информации о бронировании после успешной оплаты (модуль бронирований).
🔸 Система отправки push-уведомлений
Используется для информирования пользователей об изменениях цен и событиях по оплаченным бронированиям.
#АрхитектураGA #GetTickets
👍4
В GetAnalyst мне удалось поработать со специалистами в системном и бизнес-анализе разного уровня. У многих на старте работы со мной жалобы на хаотичностью в знаниях. При этом неважно с какой темой специалист хочет разобраться.
Думаю это происходит по 2-м причинам ⤵️
▪️ Навыки есть, но используются бессистемно.
Если выражаться метафорой, то это напоминает огромный пазл, который собрали по частям, но их ещё не скрепили вместе, чтобы увидеть картинку целиком.
▪️ Желание получить быстрые результаты
Специалист стремится к мгновенным результатам и порой не уделяет должного внимания структуре - не погружаются углублённо в предмет.
Кусочки знаний не помогут. В любой области надо: увидеть картину целиком, познать нюансы и копать в глубину. Именно глубокое понимание предмета и позволяет расти на долгосрочной основе ☝️
❌️ Сила не в том, чтобы хватать знания хаотично время от времени.
✅️ Сила в умении поддерживать крутой результат снова и снова, используя полученные структурно знания.
Моя цель в GetAnalyst обеспечить вас самой важной экспертной информацией и практикой в системном анализе. При этом “самое важное” не значит бегло пройтись по верхам. Это значит последовательно и глубоко осваивать ровно те знания и навыки, которые ежедневно приносят результаты в работе, используются постоянно.
Я хочу превратить сложное в понятное, объяснить всё при помощи простых бытовых и наглядных примеров, чтобы вы могли сделать ассоциации в своей памяти, и знать как ходить "влево" и "право" за пределы базовой теории.
Для меня важно построить для вас структурированную теоретическую базу связанную с применением в реальной практике. Чтобы из проекта в проект вы самостоятельно видели и разбирались как работают системы “от” и “до”: видели «глубину», а не только верхушку айсберга.
Что ещё могу гарантировать - команда GetAnalyst всегда поддержит и направит, подскажет пути роста и даст инструменты для этого.
И помните: вы уже крутые и опытные специалисты, а мы лишь помогаем усиливать ваши навыки 🤝❤️
Думаю это происходит по 2-м причинам ⤵️
▪️ Навыки есть, но используются бессистемно.
Если выражаться метафорой, то это напоминает огромный пазл, который собрали по частям, но их ещё не скрепили вместе, чтобы увидеть картинку целиком.
▪️ Желание получить быстрые результаты
Специалист стремится к мгновенным результатам и порой не уделяет должного внимания структуре - не погружаются углублённо в предмет.
Кусочки знаний не помогут. В любой области надо: увидеть картину целиком, познать нюансы и копать в глубину. Именно глубокое понимание предмета и позволяет расти на долгосрочной основе ☝️
❌️ Сила не в том, чтобы хватать знания хаотично время от времени.
✅️ Сила в умении поддерживать крутой результат снова и снова, используя полученные структурно знания.
Моя цель в GetAnalyst обеспечить вас самой важной экспертной информацией и практикой в системном анализе. При этом “самое важное” не значит бегло пройтись по верхам. Это значит последовательно и глубоко осваивать ровно те знания и навыки, которые ежедневно приносят результаты в работе, используются постоянно.
Я хочу превратить сложное в понятное, объяснить всё при помощи простых бытовых и наглядных примеров, чтобы вы могли сделать ассоциации в своей памяти, и знать как ходить "влево" и "право" за пределы базовой теории.
Для меня важно построить для вас структурированную теоретическую базу связанную с применением в реальной практике. Чтобы из проекта в проект вы самостоятельно видели и разбирались как работают системы “от” и “до”: видели «глубину», а не только верхушку айсберга.
Что ещё могу гарантировать - команда GetAnalyst всегда поддержит и направит, подскажет пути роста и даст инструменты для этого.
И помните: вы уже крутые и опытные специалисты, а мы лишь помогаем усиливать ваши навыки 🤝❤️
❤30👍7