Андрей ПанфиловLeonid Kudryavtsevто что я видел - было круто. Остановил микросервис на проде, залил новую версию, запустил - юзеры даже не заметили.Если что-то можно безболезненно остановить, то это что-то можно и не включать потом на самом деле у нас к примеру, много где BPM уже лет 15 используется и его можно прямо в рабочее время взять и выключить, а потом включить, однако чет этот BPM никто микросервисом не называет.
Не. Не включать было нельзя ))) Там сотни тысяч юзеров.

Скорее действовал принцип "быстро поднятое, упавшим не считается". Т.к. при ошибках шел ретрай и при повторных ошибках - переключение на резерные сервисы/серверную. Т.к. микросервисы были написаны на чистой java + apache http library, то перезапускались достаточно быстро. Ну отвлалились подписчики.... ну через пару секунд подключились обратно. Никто и не заметил, что это на проде программисты под рутовым паролем развлекаются )))

Т.е. кволити услуги наверное понижалось, но если быстро - не критично.

Basil A. SidorovГерой дняветка про масштабирование, у тебя приходится плодить монолиты при нагрузке, а это лишние расходы по памяти и тп"Вы не гугл, не фэйсбук и не амазон".
В моём случае было ~6 экземпляров (так потребовал разработчик), которые прекрасно умещались на одном физическом сервере с восемью гигабайтами памяти.

Там где я видел микросервисы, было под 50 экземпляров микросервиса на одном из серверов который получал данные с биржи. Я так понимаю, в первом приближение по экземпляру микросервису на биржу-источник информации. Это только один микросервис.

Остальные куски системы еще больше. Когда они хостились на amazon'е, говорили, что кол-во инстанцев амазона было больше 100. Они динамически их еще запускали/гасили в зависимости от нагрузки.

Alexey Tomin...и всё написано заново на другом языке с другой инфраструктурой. Но такое себе мало кто может позволить...
Если общение между микросервисами на HTTP - то язык и инфраструктура в общем-то пофиг
Хотим фигачим один из микросервисов на Java, хотим на Go, а можем и на Erlang'е ))) Нужно только, что бы язык/библиотека поддерживала базовые возможности HTTP.

Alexey Tomin....Микросервисы всегда приводят к увеличению кода....
На мой взгляд спорно.

Даже понятие "строки кода" - и то спорно. Т.к. можно написать "простыню" в 3 тысячи строк, которую потом будет никак не поддержать. Можно разбить на 10 хорошо продуманных классов по 500 строк, где все будет ясно и понятно. Строк стало больше, но суммарная сложность - меньше.

Alexey Tomin... разные профили нагрузки...

Что для современной Java (как минимум до 1G collector ) - крайне важно

Модуль обработки Web-запросов - нужно много eden области и мало old heap
Модуль кэширования, хранения данных - нужно мало eden области и много old heap.

Совершенно разные профили нагрузки. Запихивая все в "монолит", мы теряем возможность вручную управлять heap. Мало того, AFAIK для Java вполне реальны проблемы, когда ошибка в одном модуле "убила" весь heap и повесила весь сервер (или нештатное потребление heap значите выше предполагаемого, либо банальный resource leak)

IMHO & AFAIK

Alexey Tominразные циклы релизов, разные команды и прочие.

С точки зрения проектов, особенно в России. IMHO огромный плюс.

Есть микросервис, есть протокол взаимодействия, извечная проблема "кто виноват", достаточно быстро локализуется как минимум до конкретного микросервиса

Так же и низависимый деплой.

Т.к. на "монолите" наблюдал ситуацию, когда банальнейшие настройки GC, админы не могут на проде годами поставить (согласовать). Ответ один "сейчас все работает, а вдруг станет хуже", а при любых проблемах "раньше работало, а сейчас поменяли настройки GC - оно упало, т.ч. настройки откатили обратно". То, что "упало" по совершенно другим причинам - никого нафиг не волнует ))) просто откатили и доказывай, что настройки вообще не при чем )))

С микросервисами - как это этот процесс организационно должен проходить проще. Надеюсь )))

Petro123.....А например, с шиной предприятия. Оркестровкой сервисов и т.д.
Ой,ой... Вы так не пугайте (((
Нафиг, нафиг. Все эти шины, BIPL'ы, BPM'ы и прочее (((