Size: a a a

Архитектура ИТ-решений

2021 July 12

PD

Phil Delgyado in Архитектура ИТ-решений
При этом есть несколько сценариев, в которых нужны микросервисы:
- решение оргпроблем (совместная разработка большой командой)
- необходимость и возможность горизонтального масштабированияя
- специфические требования к надежности
- специфические требования к кастомизации
источник

PD

Phil Delgyado in Архитектура ИТ-решений
И я бы сказал, что нужно минимум два пункта для перехода к микросервисам. Только один часто (но не всегда) проще решить в монолите.
источник

SV

Sergey V in Архитектура ИТ-решений
Горизонтальное масштабирование приложения и в монолите обычно неплохо работает. Узкое место обычно база данных, не app server
источник

SV

Sergey V in Архитектура ИТ-решений
Совместную разработку можно решить… двумя монолитами 😂
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Угу, поэтому и говорю, что одного пункта обычно мало, нужно несколько.
И да, все задачи можно решить и в рамках монолита (ну, почти все).
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Это уже два "микро"-сервиса )
Но да, каждая команда пилит свой монолит - вполне часто встречающийся паттерн.
источник

p

pragus in Архитектура ИТ-решений
Обрати внимания, что большая часть твоих аргументов - это "мало кому надо" и "это можно сделать".  Например, заранее докинуть памяти или заранее навтыкать проверок в коде. Фактически, оно про "Знал бы, где упасть, соломки бы подостлал". Это всё хорошо, но они ничем не помогают если ты оказался в неприятной ситуации.  

А в случае с бюджетированием сервисов сработают лимиты и балансер отправит запрос на живой инстанс.
источник

p

pragus in Архитектура ИТ-решений
Так я ж и спрашивал: что делать когда кончилась бд?
источник

П

Пух in Архитектура ИТ-решений
Ну вот микросервисы это получается везде соломку стелем и дальше думать?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, если у тебя проблемы с алгоритмом, то никакого "живого инстанса" не будет, все умерли по OOM, так что не аргумент )
И да, лимиты и бюджет нужны для очень небольшого числа проектов и только ради этого тащить микросервисы - очень дорого и вряд ли обоснованно.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, типа у нас вебсайтик на 1mln DAU, нафига там микросервисы (а многие делают, а потом страдают...)
источник

p

pragus in Архитектура ИТ-решений
В каком-то смысле да. "Выжить до конца дня" итд. Главное, чтобы это было незаметно для клиента.
источник

p

pragus in Архитектура ИТ-решений
Больной сервис можно запустить хоть в сотне экземпляров с политикой "рестарт после 5 запросов". А что с монолитом?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, если стоимость возможного простоя окупает переход на микросервисы.
источник

p

pragus in Архитектура ИТ-решений
Вот чуваки играют на бирже. Вложились, а ты прилёг.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Это нужно иметь очень большой запас по мощностям. Реально - только облако, а это отдельные цены.
Но, вообще говоря, в монолите раз в час переключаться на standby - тоже норм, делов-то.
источник

p

pragus in Архитектура ИТ-решений
Я не про "раз в час", а "каждые 5 запросов - респавн"
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Еще раз, если у тебя настолько высокие требования к SLA, то их нужно решать специфическими способами.
Или специально сделанный монолит или специально сделанные микросервисы.
В любом случае - это очень специальные решения, не общие.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
И это никак не связано с выбором "микросервисы vs монолит" для любого проекта.
источник

p

pragus in Архитектура ИТ-решений
Не обязательно. Помимо всего прочего ты чётко понимаешь сколько тебе ресурсов надо, а единица масштабирования - сервис, а не вообще вся система целиком.
источник