o
Микросервисы можно делать и внутри монолита, если продумать интерфейс, чего обычно ен наблюдается)
Size: a a a
2020 February 03
PD
Лесом микросервисы! Пустой хайп это. Хорошо модуляризированное монолитное приложение проще поддерживать, развивать, тестировать и развертывать. Да и тупых задержек из-за сериализации всего в JSON нет
Развертывать без останова уже не очень просто...
И переживать сбои железа
И переживать сбои железа
o
Там пробелмы наверное не из-за json, а из-за кап теоремы могут быть..
ПФ
Лесом микросервисы! Пустой хайп это. Хорошо модуляризированное монолитное приложение проще поддерживать, развивать, тестировать и развертывать. Да и тупых задержек из-за сериализации всего в JSON нет
если всегда следовать этому совету — то не будет масштабирования нагруженных частей без масштабирования ненужных
AV
Каждый сервис начнется с копипаста
Есть мнения, что небольшой копипаст лучше небольшого зацепления. :-)
ПП
Есть мнения, что небольшой копипаст лучше небольшого зацепления. :-)
Ключевое слово небольшой, иначе баги правятся в 20 местах
AV
Ключевое слово небольшой, иначе баги правятся в 20 местах
Не понимаю связи. Почему?
ПП
Не понимаю связи. Почему?
Хорошо, изменился формат ошибки для сервисов или нужно добавить в актуатор доп инфу для всех
AO
Ключевое слово небольшой, иначе баги правятся в 20 местах
Один проектный bom в нем в депенденси менеджмент все библиотеки одинакового кода. Готово
T
если всегда следовать этому совету — то не будет масштабирования нагруженных частей без масштабирования ненужных
Часто микросервисы пихают в бизнесы, которым за что лет работы второй узел не потребуется
ПФ
Часто микросервисы пихают в бизнесы, которым за что лет работы второй узел не потребуется
Что не делает тебя более правым
AV
Хорошо, изменился формат ошибки для сервисов или нужно добавить в актуатор доп инфу для всех
В смысле "изменился формат для сервисов"? А как же потребители - они в курсе перемен?
Нужно добавить для всех - добавляем для всех, что тут сложного.
Вот когда мы хотим поменять инфу для 80%, а у нас всё на одной центральной библиотеке завязано - вот где настоящий головняк. И как потом отличать тех, где общая инфа от остальных.
Нужно добавить для всех - добавляем для всех, что тут сложного.
Вот когда мы хотим поменять инфу для 80%, а у нас всё на одной центральной библиотеке завязано - вот где настоящий головняк. И как потом отличать тех, где общая инфа от остальных.
AV
Если все микросервисы всегда вместе деплоятся - то может нафиг их и делать монолит?
T
Что не делает тебя более правым
Думаю, нет советов, которым надо всегда следовать. Разве что совет головой думать
БС
Думаю, нет советов, которым надо всегда следовать. Разве что совет головой думать
Тоже спорный совет, когда опыта мало, советы и good practice могут оказаться больше «думания головой»
ПФ
Думаю, нет советов, которым надо всегда следовать. Разве что совет головой думать
ну можно дать приклоьный многокритериальный ответ на тему "вам стоит думать о микросервисах на этапе дизайна когда…", "вам стоит думать о демонолитизации когда…", "вам стоит думать о ремонолитизации когда…"
T
Можно. Но лень. Я же не доклад делаю
PD
Ну, сократи до 'вам стоит думать, и только потом делать'
o
Вы лучше скажите вот что - правильно делать Сервис ( я имею в виду сущности вида class BlahBlahService) как просто набор несвязанных методов котоыре имеют отношение к BlahBlah (т.е под каждую задачу разработчик идет в такой сервис и добавляет метод если не находит подходящего) или все таки сервис должен иметь строгий интерфейс, который предпоочтительноо не менять, и гибкие возможности по запросам, чтобы не добавлять никаких методов (разработка и поддержка такого сервиса усложнится)?
PD
Зависит от пользователя этого сервиса и требований по совместимости.