Здравствуйте, artelk, Вы писали:
G>>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет. Б>>Профит микросервисов в их независимости друг от друга: A>Полная независимость возможна только если сервисы друг друга не вызывают.
"Независимость" подразумевает, что у сервиса есть API. А вот как он реализуется — клиентов не интересует.
N>Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
В том и дело, что у Скайденса из Новой Зеландии станет 0 денег, а у остальных будет как было. У Васи в Нью-Васюках снимут коммунальные услуги два раза. У Пети из Питтсбурга припишут в кассе.
Так понятнее стало? Да, где-то что-то всегда сломано. Но только где-то и что-то, а не сразу и у всех. "Большие данные" (С)
N>Вопрос в ответственном отношении к работе.
Бизнес — это про деньги, а не про ответственное отношение.
N>Хотя, для детских проектов с тремя пользователями сойдет.
Не угадал.
Наоборот.
Как раз где три пользователя — там все будет сразу видно и заметно. Такой подход (перманентные частичные отказы) работает только на миллионах и миллиардах. Тогда всегда можно перевести стрелки "у вас интернет плохой". А если три пользователя, и у одного не работает, — это сразу треть (!) всех пользователей, серьезный отказ.
Здравствуйте, SkyDance, Вы писали:
N>>Вопрос в ответственном отношении к работе. SD>Бизнес — это про деньги, а не про ответственное отношение.
Кек, у меня многие вопросы исчезли. Вот оно что оказывается. Тяп-ляп-лишь-бы-работало оказывается это ожидаемый бизнесом результат. А люди то не виноваты, они просто делают то что им приказывают владельцы бизнеса.
Здравствуйте, SkyDance, Вы писали:
SD>В "обычной программе" придется разбираться, у кого что падает. А тут сразу видно.
Всегда сочувствую тем, кому запрещают логи писать и метрики расставлять.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, artelk, Вы писали:
Б>>>Профит микросервисов в их независимости друг от друга: A>>Полная независимость возможна только если сервисы друг друга не вызывают. C>"Независимость" подразумевает, что у сервиса есть API. А вот как он реализуется — клиентов не интересует.
У классов есть API, а как он реализуется — клиентов не интересует.
У библиотек функций есть API, а как он реализуется — клиентов не интересует.
В чем преимущество у микросервисов в данном контексте?
Может в том, что параметры функций\методов передаются по значению, т.е. неявно глубоко клонируются при передаче?
Этого же можно добится и без выноса кода в отдельный процесс — либо через сериализацию+десериализацию (то, что сейчас используется в при вызове удаленного сервиса, но без собственно отправки сообщения по сети), либо путем написания генератора декораторов интерфейсов, которые клонируют параметры и возвращаемые значения каждого метода интерфейса. И в Java и в .Net такой генератор пишется на раз и переиспользуется везде где надо, если надо.
Здравствуйте, Буравчик, Вы писали:
Б>Это пока у тебе запросы скромные — 128 Гб и 32 ядра. А если больше, то становится выгоднее взять несколько серверов вместо супермощного.
Нуууу... У нас запросы 3Тб и не-считал-сколько-ядров. Тем не менее разрабы идут по пути минимизации сетевого трафиика, переключаясь на внутрихостовые протоколы взаимодействия. Потому что МЕДЛЕННО.
Мантры "микосервисы"/"мастубирование" на них как-то не действуют
Здравствуйте, artelk, Вы писали:
A>В чем преимущество у микросервисов в данном контексте?
На самом деле выше уже был дан единственный верный ответ. Микросервисы нужны чтобы максимально разграничить ответственность команд.
Правда в подавляющем большинстве случаев это не нужно.
Здравствуйте, artelk, Вы писали:
C>>"Независимость" подразумевает, что у сервиса есть API. А вот как он реализуется — клиентов не интересует. A>У классов есть API, а как он реализуется — клиентов не интересует. A>У библиотек функций есть API, а как он реализуется — клиентов не интересует. A>В чем преимущество у микросервисов в данном контексте?
Библиотека классов будет на том же самом языке, что и пользователи этих классов. Для сервисов это совсем необязательно.
Далее, в большинстве приложений системы сборки позволяют иметь только одну версию библиотек. Так что если какая-то команда хочет использовать более новую версию зависимости (скажем, взять новую версию OpenSSL), то это будет влиять на все остальные команды. В результате, по мере роста проекта такие обновления становятся всё более болезненными. В случае с API всё просто.
Ну и напоследок, в случае с API обычно легко контролировать кто и как его использует, в отличие от библиотеки классов в монолитном приложении.
Здравствуйте, Cyberax, Вы писали:
C>Далее, в большинстве приложений системы сборки позволяют иметь только одну версию библиотек. Так что если какая-то команда хочет использовать более новую версию зависимости (скажем, взять новую версию OpenSSL), то это будет влиять на все остальные команды. В результате, по мере роста проекта такие обновления становятся всё более болезненными. В случае с API всё просто.
Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
A>>В чем преимущество у микросервисов в данном контексте?
G>На самом деле выше уже был дан единственный верный ответ. Микросервисы нужны чтобы максимально разграничить ответственность команд.
Это аргумент в пользу того, что сервисы не должны быть слишком большие, т.е. больше, чем одна команда сможет поддерживать и развивать.
Но у микросервисов декларируемая гранулярность же намного выше.
G>Правда в подавляющем большинстве случаев это не нужно. G>В остальном только недостатки.
Здравствуйте, Sheridan, Вы писали:
G>>Установка сложного приложения без докера выглядит так: ... G>>Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик. S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
только какая то старая версия может пропасть с серверов, тогда надо делать ее копии у себя и тд
Здравствуйте, mogadanez, Вы писали:
M>только какая то старая версия может пропасть с серверов, тогда надо делать ее копии у себя и тд
Не распарсил... Старая версия чего? Куда пропасть? Зачем сохранить?
Здравствуйте, Sheridan, Вы писали:
S>Не распарсил... Старая версия чего? Куда пропасть? Зачем сохранить?
1) Устновить nodejs\веб-сервер\еще какую-нибудь-фигню версии 15.43.442, именно такой, потому что на другом не тестировалось и корректность работы не гарантируется.
2) Поднять базу на mongodb 12.697 и кэш на редис на 3.974, именно на таких, потому что на других не тестировалось и работоспособность не гарантируется.
S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
M>1) Устновить nodejs\веб-сервер\еще какую-нибудь-фигню версии 15.43.442, именно такой, потому что на другом не тестировалось и корректность работы не гарантируется.
M>2) Поднять базу на mongodb 12.697 и кэш на редис на 3.974, именно на таких, потому что на других не тестировалось и работоспособность не гарантируется.
В чём именно проблема?
M>
S>>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
А, тебе слова не понравились. А почему ты решил что "выкачать всё нужное" означает "выкачать самые последние версии всего подряд"?
ansible это описание деплоя, код. Как напишешь — так и будет.
Здравствуйте, Sheridan, Вы писали:
C>>Далее, в большинстве приложений системы сборки позволяют иметь только одну версию библиотек. Так что если какая-то команда хочет использовать более новую версию зависимости (скажем, взять новую версию OpenSSL), то это будет влиять на все остальные команды. В результате, по мере роста проекта такие обновления становятся всё более болезненными. В случае с API всё просто. S>Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите?
Нет, микросервисы не проще и не быстрее монолита. Они позволяют масштабироваться для очень больших проектов, над которыми работает сотни человек.
Здравствуйте, Mamut, Вы писали:
C>>Ну и напоследок, в случае с API обычно легко контролировать кто и как его использует M>Мммм. Ну, это не совсем так.
Зависит от реализации. В Амазоне для использования API обычно требовалось, чтобы команда добавила разрешения для конкретных клиентов.
