[Анализ и проектирование систем, Проектирование и рефакторинг, Микросервисы] Хватит везде делать микросервисы
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Микросервисы — это не всегда хорошо и не нужно их применять бездумно. Меня бомбит от того, что все хотят себе микросервисы. Не понимают зачем, но хотят. Даже в компаниях из двух человек многие разработчики хотят втянуть раздробить свой продукт на десяток микросервисов. Не надо.
Микросервисы — это плохо, и вот почему
Микросервисы затрудняют разработку
Это всегда источник геморроя. Ну серьёзно, помимо функциональности сервиса, нам приходится разрабатывать протоколы общения микросервисов, а составить хороший протокол — это отдельная сложная задача. Потом этот протокол ещё и нужно поддерживать. А это сложно и дорого. А ещё вам придётся на каждый чих делать отдельный сервис, регулярно обновлять в нём библиотеки, иначе он перестанет развиваться и превратится в легаси.
Если у нас совсем новый продукт, который ещё не прошёл проверку временем, и мы собираемся выпустить MVP, просто нет никакого смысла городить микросервисную архитектуру, берём готовый фреймворк, делаем монолит и проверяем идею — взлетела или нет. А уже потом думаем, переписывать на микросервисы или нет.
Микросервисы требовательны к инфраструктуре
Когда у нас монолит, мы просто можем вызвать функцию и тут же получить результат. На вызов функции накладных расходов нет. А с микросервисами — мы должны отправить запрос, принять его, распарсить. Это лишние накладные расходы на сеть, память и CPU. А накладные расходы — это лишняя трата денег.
Микросервисы затрудняют развёртывание
Вот представьте себе, вам нужно выкатить на продакшен какую-то новую фичу. Окей, вы готовите репозиторий, собираете контейнеры (у вас ведь Docker, правда?). И наступает время деплоя. И тут, вам придётся аккуратно последовательно отключать все ваши микросервисы и накатывать новые версии. Процесс долгий, многое может пойти не так. Монолит — если запустился, уже хорошо. А с микросервисами — что-то запустилось, что-то нет — и придётся откатывать всё к предыдущей версии. А если уже миграции базы применились — то вообще пиши пропало.
А когда микросервисы — это хорошо?
Когда у вас несколько команд, которые независимо делают разные компоненты сервиса.
Тогда команды не будут мешать друг другу и могут пилить и выкатывать эти микросервисы в своём темпе.
Когда нам нужно масштабировать сервисы по-разному
Например, когда на них разная нагрузка. Скажем, у нас есть api, веб-интерфейс и какая-нибудь штука, которая долго обрабатывает данные. Нейросети, например, обучает в фоне. Так вот, на каждый микросервис мы можем отдельно замерить нагрузку и настроить масштабирование так, чтобы ресурсы сервера расходовались оптимально.
Когда сервис должен выжить, при падении какой-то функциональности
Тогда разделяем продукт на критичные микросервисы и на некритичные. И при падении каких-то некриртичных микросервисов, работа всего продукта не останавливается, просто некоторая функциональность временно блокируется. Например, на сайте интернет-магазина может отвалиться чат с техподдержкой или личный кабинет, но точно должна работать витрина и приём платежей. Потому что конверсия — это самое важное (ща меня заклюют за эту фразу).
Когда у вас в компании уже давно сложившийся зоопарк технологий
Когда половина бекендеров пишут на Python, половина на PHP, а ещё 46% на Perl, то без микросервисов тут не обойтись. Языки, особенно, скриптовые, слабо умеют интегрироваться между собой.
Разработчики, тимлиды, архитекторы, перед тем, как принимать решение об архитектуре, лишний раз перечитайте этот текст и взвесьте все за и против. Помните, что в ряде случаев монолит сильно выигрывает у микросервисов.
И менеджеры, отдельно вас прошу, если вы это читаете, не навязывайте микросервисную архитектуру в своих проектах. Это серьёзное техническое решение и подходить к нему должны ваши технические специалисты.
А ещё этот пост доступен в формате видео на моём YouTube-канале.
Видеоверсия
SPL
Извините, данный ресурс не поддреживается. :(
===========
Источник:
habr.com
===========
Похожие новости:
- [Анализ и проектирование систем, Работа с 3D-графикой, CAD/CAM, Графический дизайн] Советы и трюки SOLIDWORKS
- [Микросервисы] Архитектура микросервисов: Разрушение монолита (перевод)
- [PHP, Программирование, Анализ и проектирование систем] Модульный PHP монолит: рецепт приготовления
- [Управление продуктом, Финансы в IT, Микросервисы] Fintech на практике: как Quadcode технологии для трейдинга и банкинга разрабатывает
- [Анализ и проектирование систем, Управление проектами] Платформа управления бизнес-процессами: практика внедрения
- [Разработка веб-сайтов, Проектирование и рефакторинг, ReactJS, TypeScript] Пишем переиспользуемые компоненты, соблюдая SOLID
- [Анализ и проектирование систем, Big Data, Хранилища данных, Управление проектами] Создаём компанию мечты: нет хайпу
- [PHP, Я пиарюсь, Проектирование и рефакторинг] Чистим пхпшный код с помощью DTO
- [Анализ и проектирование систем, CAD/CAM, Производство и разработка электроники, Электроника для начинающих] Ускорение проектирования РЧ-, СВЧ-устройств (2/5)
- [Высокая производительность, Java, Анализ и проектирование систем, Алгоритмы] Развеиваем мифы об управлении памятью в JVM (перевод)
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_mikroservisy (Микросервисы), #_mikroservisy (микросервисы), #_mikroservisnaja_arhitektura (микросервисная архитектура), #_otchajanie (отчаяние), #_hvatit_eto_terpet (хватит это терпеть), #_tegi_vse_chitajut (теги все читают), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 05:48
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Микросервисы — это не всегда хорошо и не нужно их применять бездумно. Меня бомбит от того, что все хотят себе микросервисы. Не понимают зачем, но хотят. Даже в компаниях из двух человек многие разработчики хотят втянуть раздробить свой продукт на десяток микросервисов. Не надо.  Микросервисы — это плохо, и вот почему Микросервисы затрудняют разработку Это всегда источник геморроя. Ну серьёзно, помимо функциональности сервиса, нам приходится разрабатывать протоколы общения микросервисов, а составить хороший протокол — это отдельная сложная задача. Потом этот протокол ещё и нужно поддерживать. А это сложно и дорого. А ещё вам придётся на каждый чих делать отдельный сервис, регулярно обновлять в нём библиотеки, иначе он перестанет развиваться и превратится в легаси. Если у нас совсем новый продукт, который ещё не прошёл проверку временем, и мы собираемся выпустить MVP, просто нет никакого смысла городить микросервисную архитектуру, берём готовый фреймворк, делаем монолит и проверяем идею — взлетела или нет. А уже потом думаем, переписывать на микросервисы или нет. Микросервисы требовательны к инфраструктуре Когда у нас монолит, мы просто можем вызвать функцию и тут же получить результат. На вызов функции накладных расходов нет. А с микросервисами — мы должны отправить запрос, принять его, распарсить. Это лишние накладные расходы на сеть, память и CPU. А накладные расходы — это лишняя трата денег. Микросервисы затрудняют развёртывание Вот представьте себе, вам нужно выкатить на продакшен какую-то новую фичу. Окей, вы готовите репозиторий, собираете контейнеры (у вас ведь Docker, правда?). И наступает время деплоя. И тут, вам придётся аккуратно последовательно отключать все ваши микросервисы и накатывать новые версии. Процесс долгий, многое может пойти не так. Монолит — если запустился, уже хорошо. А с микросервисами — что-то запустилось, что-то нет — и придётся откатывать всё к предыдущей версии. А если уже миграции базы применились — то вообще пиши пропало. А когда микросервисы — это хорошо? Когда у вас несколько команд, которые независимо делают разные компоненты сервиса. Тогда команды не будут мешать друг другу и могут пилить и выкатывать эти микросервисы в своём темпе. Когда нам нужно масштабировать сервисы по-разному Например, когда на них разная нагрузка. Скажем, у нас есть api, веб-интерфейс и какая-нибудь штука, которая долго обрабатывает данные. Нейросети, например, обучает в фоне. Так вот, на каждый микросервис мы можем отдельно замерить нагрузку и настроить масштабирование так, чтобы ресурсы сервера расходовались оптимально. Когда сервис должен выжить, при падении какой-то функциональности Тогда разделяем продукт на критичные микросервисы и на некритичные. И при падении каких-то некриртичных микросервисов, работа всего продукта не останавливается, просто некоторая функциональность временно блокируется. Например, на сайте интернет-магазина может отвалиться чат с техподдержкой или личный кабинет, но точно должна работать витрина и приём платежей. Потому что конверсия — это самое важное (ща меня заклюют за эту фразу). Когда у вас в компании уже давно сложившийся зоопарк технологий Когда половина бекендеров пишут на Python, половина на PHP, а ещё 46% на Perl, то без микросервисов тут не обойтись. Языки, особенно, скриптовые, слабо умеют интегрироваться между собой. Разработчики, тимлиды, архитекторы, перед тем, как принимать решение об архитектуре, лишний раз перечитайте этот текст и взвесьте все за и против. Помните, что в ряде случаев монолит сильно выигрывает у микросервисов. И менеджеры, отдельно вас прошу, если вы это читаете, не навязывайте микросервисную архитектуру в своих проектах. Это серьёзное техническое решение и подходить к нему должны ваши технические специалисты. А ещё этот пост доступен в формате видео на моём YouTube-канале. ВидеоверсияSPLИзвините, данный ресурс не поддреживается. :(
=========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 05:48
Часовой пояс: UTC + 5