Микросервисы = плохой код? Главные проблемы Микросервисов
HTML-код
- Опубликовано: 20 окт 2024
- Мой курс по Крипто разработке: codecrypto.dev... Микросервисы = плохой код? Главные проблемы Микросервисов в IT проектах
Андрей Иванов | Python
Чек лист по Микросервисам: t.me/iv_andrew...
Используйте мою ссылку в криптобирже OKEX: www.okx.com/jo...
Мои курсы на UDEMY: www.udemy.com/...
Пожертвования: www.donational...
Github: github.com/knu...
Telegram канал: t.me/pypapyrus_ru
Другие Видео по Python: • Python, Питон
Канал на английском языке: / @pythononpapyrus
Поставьте лайк и подпишитесь!
#Python #Питон #программирование #programming
Чек лист по микросервисам вы можете найти совершенно бесплатно в моем новом телеграм боте!
t.me/iv_andrewpy_bot
Не могут просто быть все сервисы гугл в одном репозитории. Гугл: у нас монорепа на все что есть в Гугле)
Спасибо за видео
Всё правильно
Сейчас всё больше от программистов требуют сокращения времени на разработку. Требуют в короткие сроки выкатить MVP
Для стартапа, для небольших команд - только монолит. Тут можно монолит на модули со слабой связью порезать. Короче, нужно посидеть и подумать как команде из 2+ человек одновременно развивать его и не тратить время на решение конфликтов при коммите.
С микросервисами не работал. Всё теоритически. Но уже почитав и послушав выступления, приходит осознание насколько это сложняет бекенд. Насколько разработка бекенда зависит от грамотного архитектора и аналитиков.
Google испольщует монорепу )
Да, честно привел пример не зная, интересное у них решение! Спасибо!
Во-первых за такую архитектуру, которую ты показал, разработчиков нужно жёстко бить. Ногами и по голове. Разделять то, что называется сервисами, поднимать для каждой сущности отдельную бд, а потом думать, как сделать простой join при запросе... В микросервисе выносят задачи, которые долго играющие. К примеру, парсинг данных, вебсокет. Но уж явно не то, что ты показал.
Во-вторых, никакой проблемы нет сделать три репозитория, залить код в репо, подготовить докер файлы, а дальше девопс задеплоит и настроит мониторинги(это как раз его компетенция). Вряд-ли для пет проектов кто-то будет заморачиваться с мониторингами. Максимум какой деплой а-ля хероку.
В-третьих, по взаимодействию микросервисов. Есть ещё брокеры сообщений как рэббит и кафка. И если сервис упал, он не прочитает сообщение и оно будет хранится в очереди. Поднялся, прочитал. Не вижу тут проблемы.
В-четвертых, Андрей, меня мучает до сих пор вопрос, где ты работал, если все свои видео показываешь на ос windows?)
Может у него wsl?
А так, да, в целом с вашими словами согласен
@@seregeyvladimirov7065 может:))
1) Это простой пример чтобы люди поняли суть, я не говорил что их нужно обязательно так разделять
2) Да, согласен что девопс может настроить мониторинг, я это и сказал.
3) Да, конечно это можно сделать брокеры, но чтобы это правильно работало нужно знать как писать для этого код
4) Что плохого в windows? Мне не нужно работать с линуксом если я могу открыть консоль и подключиться куда угодно
@@PythononPapyrusRU
1. Канал, как понимаю, рассчитан на аудиторию, которая только начинает погружаться в программирование. И изначально неверное понимание о микросервисах - это предпосылки в будущем проблемам в большем количестве.
2. Мне скорее запомнились слова, что настройка на трех микросервисах мониторингов это проблематично:) то есть, перефразируя, можно сказать, ребята, мониторинги сложно настраивать, а потому, даже по этой причине, лучше отказываться от микросервисов.
3. Так с любой реализацией. Даже hello world, чтобы написать, нужно знать как. Довольно очевидный аргумент. Но взаимодействие между микросервисами строиться как раз под средством брокеров.
4. Скорее вопрос звучит иначе - что хорошего в windows для разработки на python? Ровным счётом - ничего. От администрирования системы, обновления пакетов, удалённым подключениям и пр. На *nix системах это делается куда проще.
И выделю 5 пункт. Я в корне не согласен с утверждением, что микросервисы пишут от безысходности. Типо что наш монолит/распределеный монолит перестал удовлетворять неким требованиям и все выхода нет, терять нечего, давайте писать микросервисы, а там что будет, то будет. Такой подход - неверный. Изначально архитектура планируется исходя из задач. И если задачи предполагают микросервисы в той интерпретации, которую описал я, то они выделяются. Либо, изначально на ранних этапах, проектируется монолит по гексагональной архитектуре, а затем легко выносятся определённые компоненты в микросервисы. И написать конфигурацию для нового приложения это вообще не проблема:) задача микросервисов - отказоустойчивость всей инфраструктуры и снижение нагрузки на определённые компоненты. Но не на product или order:))) а, к примеру, на основной бэк в целом. И тут, вопрос стоит как раз в том, что нужно уметь проектировать отказоустойчивые микросервисы. Если какой-то из узлов системы будет недоступен, чтобы второй мог работать и без него.
Первый?