пакетная обработка или групповая

теперь понял

короч пофигу, суть в том что сингелтоны новичкам лучше сразу запретить

когда они начнут работать с какими-нибудь COM портами - тогда можно подумать

вместо групповой отправки, может лучше в очередь ложить запросы?

и по одному их обрабатывать

а какая разница?

в порядке очереди

ну то есть суть от этого не меняется

тогда точно будем знать, что один запрос

ну да

суть не меняется

у тебя будет 1 процесс которому нужно сделать 10 бизнес транзакций

и есть такая штука что коннекшены имеют свойство закрываться

что будет проверять какой-то класс Connection

а если у нас есть такой класс - лучше его инъектировать в целевой класс

а, еще вспомнил, небольшую тему для обсуждения

ты как то говорил на своем докладе, что лучше не строить микросервисы, если до этого не было нормального опыта в написание монолита

почему?

ты как то говорил на своем докладе, что лучше не строить микросервисы, если до этого не было нормального опыта в написание монолита

как ты думаешь, чем хороший монолит отличается от хорошей микросервисной архитектуры?

сильная зависимость от компонентов

нет

вообще нет

и что будет если ты проиграешь с разделением на контексты (модули, микросервисы) в том и другом случае? какие будут последствия?

в микросервисах не чего страшного не будет, так как я начал писать микросервисы

а вот с монолитом, будут проблемы

в микросервисах не чего страшного не будет, так как я начал писать микросервисы

звучит забавно)

ну да

не знаем что такое батчи, но пишем микросервисы

?

Привет всем

я не пишу микросервисы

У вас чо нет выходных?

это я так, для контекта написал, чтоб понятней было

ну да

у тебя есть два микросервиса. Все шло хорошо. И вот у тебя неверно на ранних этапах были разделены ответственности. И вот теперь тебе на 1 http запрос надо дернуть 4 микросервиса причем один из них надо дернуть несколько раз

в случае с монолитом ты сможешь быстро закастылять. В случае с микросервисами у тебя будут жесткие проблемы

но ведь подобных проблем, можно избежать

надеюсь ты понимаешь что теперь код должен сам рулить своими зависимостями?

Не понимаю, объясни плз

номарльно спроектировав систему

но ведь подобных проблем, можно избежать

проектировать up-front?

что это означает: - у разработчика должен быть неплохой опыт в проектировании систем. - разработчик должен оооочень хорошо понимать предметную область

в случае с микросервисами дополнительно надо вводить devops-сов, каких-то челиков которые будут автоматизировать деплоймент и минимизировать оверхэд от этого

в цемло усложняется поддержка инфраструктуры

с этим согласен

а с точки зрения архитектуры - хороший монолит можно будет легко разделить на микросервисы в будущем

и избежать на ранних этапах огромных оверхэдов на время разработки

номарльно спроектировав систему

если разработчик не может нормально спроектировать монолит, с микросервисами у него нет шансов

ну и давай по другому

какой профит тебе дают микросервисы?

мне - практика в их написании

у тебя команда разработчиков в 50 человек?

не

мне - практика в их написании

бизнесу

2-3

ты вообще никакого значения не имеешь и твои интересы

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

хорошая архитектура позволяет снизить издержки в будущем

и давать более прогнозируемые сроки

в будущем планируется расширение

поэтому подумал о микросервисной архитектуре

в будущем планируется расширение

чем тебя будет ограничивать монолит?

горизонтальное масштабирование

горизонтальное масштабирование норм работает и в случае с монолитами

горизонтальное масштабирование

о, оч простой вопрос. У тебя у каждого микросервиса своя собственная база данных или нет?

да

своя собственная

у тебя данных больше терабайта?

ERROR: S client not available

нет

или планируется ближайшие пару лет?

сложно сказать

Базу ж можно в отдельный сервис вынести

возможно

Базу ж можно в отдельный сервис вынести

это уже не микросервисы.

могу сказать что 90% не знают ООП

lol?

lol?

и ты тоже)

Базу ж можно в отдельный сервис вынести

для справки. Микросервисы это оверпопулярный мегахайповый подход к разработке. По сути это вид SOA архитектуры, или просто архитектура распределенных приложений. Ее основной параметр - отказоустойчивости. Если у тебя у всех элементов есть один общий - база данных, то у тебя есть единая точка отказа. Если упадет база для куска системы упадет вся система

многие называют микросервисами штуки в духе "у меня есть апиха и воркеры для очередей - значит у меня микросервисы". это бред. Это старый добрый монолит

ну да

в котором нет ничего плохого.

просто микросервисы это обычно дороже

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

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

для моей команды скорость разработки не важна

O_O

для моей команды скорость разработки не важна

твоя команда и интересы оной не важны для бизнеса

Есть сервис который авторизирует пользователей и другим сервисам дает данные о них. Другие сервисы без этих данных не смогут показать фоточки ну или тд. Это монолит?

а вот для бизнеса скорость разработки и общая стоимость разработки ой как важна

Есть сервис который авторизирует пользователей и другим сервисам дает данные о них. Другие сервисы без этих данных не смогут показать фоточки ну или тд. Это монолит?

это единая точка отказа. Что бы от нее избавиться часто прибегают к штукам вроде JWT

по сути при таком раскладе у тебя в каждом http запросе будет зашито что умеет чувак и кто он

для справки. Микросервисы это оверпопулярный мегахайповый подход к разработке. По сути это вид SOA архитектуры, или просто архитектура распределенных приложений. Ее основной параметр - отказоустойчивости. Если у тебя у всех элементов есть один общий - база данных, то у тебя есть единая точка отказа. Если упадет база для куска системы упадет вся система

ППКС

но для обычных сайтов он не применим

и не надо будет делать дополнительных запросов в дополнительные сервисы и т.д.

ППКС

?

?

"подписываюсь под каждым словом"

подпишусь под каждым словом

хе

короч, твоя проблема в том, что тебе и твоей команде плевать на деньги

пока что да

я бы сказал это проблема большинства разработчиков