[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Микросервисная архитектура
Страницы: 1, 2
twin
Цитата (AllesKlar @ 29.11.2017 - 15:55)
Еще 5 мажорных версий?
Ну пусть минорные. Просто кто то трудится, улучшает чего то, а кто то ждет понедельника. smile.gif


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Цитата (Santehnick @ 29.11.2017 - 19:28)
Пока в этом нет необходимости. Но мы закладываем в приложение возможность горизонтального масштабирования.
Понятно. Любопытно было бы посмотреть на решения, потому что мне как то смутно представляется масштабируемость с помощью микросервисов.

На первый взгляд все красиво - разносим разные задачи по разным железякам и радуемся. Однако не все так просто, это работало бы тогда, когда:
а) Микросервисы загружались бы распределенно сами. Другими словами потребность в каждом из них была бы равна. Но это обычно не так. Тут конечно можно подбирать железо под сервис, но уж больно это все не уютно мне кажется, жить в ожидании оверхеда.
б) Они были бы настолько самодостаточны, что в идеале не нуждались бы друг в друге. Но это тоже не так. В противном случае выигрыш в производительности будет не столь уж велик.

Как то я иначе представляю себе горизонтальную масштабируемость

AllesKlar преследует цель распределения разработки, масштабируемость его не сильно интересует. А зря. Интересно, как при этом он решит вопрос распределения нагрузки. Сейчас, как я понял, все решается балансировкой. А с микросервисами как?

Кстати, про разработку. Ужасы, которые описал AllesKlar, на самом деле не особо куда денутся. Просто трансформируются в несколько другие.

Все равно придется рано вставать и гулять с собакой. smile.gif Потому что деплоить даже один микросервис придется в том же составе:
Цитата (AllesKlar @ 29.11.2017 - 14:40)
(я, разработчик фичи, серверный адми, админ базы данных)
причем на много чаще, чем сейчас. Потому что микросервисов много, релизятся они чаще. А если деплоить их кучей, по понедельникам марта, то по сути разница не велика на самом деле. А на самотек с минорными версиями это не пустишь, потому что ты сам описал ответственности.

И всё. То же самое, только сервера меняем на микросервисы:

- выводим из работы первый хост (15 минут ожидания, пока DNS от IP сервера отвалятся)
- ввод в работу первого микросервиса.
- продакшн-тест
- второй микросервис...
- третий микросервис...

отвалилось все нахрен!
Цитата (AllesKlar @ 29.11.2017 - 14:40)
Срочно роллбэк по всем серверам!!! Пока я разогреваю анальный-термо-крипто-анализатор, разработчик фичи нервно пытается воспроизвести баг и его пофиксисить, причем, если баг был даже не в его фичи, меня это мало интересует, я просто блокирую релиз с багом (счет идет на минуты, т.к. в 7 утра - точка не возврата, либо мы принимаем решение деплоить дальше БЕЗ возможности отката, либо мы сомневаемся и откатываем ВСЕ назад), т.к. в 8:00 система должна быть стабильной и клиенты должны работать.


Цитата (AllesKlar @ 29.11.2017 - 14:40)
Микросервисы нужны тогда, когда монолит перестал справляться, и в том же монолите уже четко определяются границы кандидатов на отдельные сервисы.
Мне кажется, что плавно поменять одну архитектуру на другую довольно сложно. Слишком велик риск непредвиденных ситуаций. Систему на микросервисах нужно проектировать изначально, либо полностью всё переписать, опять же спроектировав по новой. Хотя выделить некоторых кандидатов конечно можно, что собственно часто и делается. Допустим работа с графикой на одном сервере, файловый менеджер на другом и т.д. Но это не MSA по сути.

Я вот, как обычно, почитал не только про плюсы микросервисов, но и про их минусы. Пока что не впечатлило. Но! Наверняка есть что то интересное. Так что может действительно вынести все это в отдельную тему?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.