AV
if (question.contains("как лучше")) respond.with("it depends!");Size: a a a
2020 February 03
AV
Ой сорри, палюсь
AG
Микросервисы можно делать и внутри монолита, если продумать интерфейс, чего обычно ен наблюдается)
Я тоже думал что микросервисы это хайп. Но он и вправду хорош когда можно разделять бизнес логики на независимые части, и каждый микросервис бандить к конкретной ядре процессора. Это даст очень хороший прирост производительности
PD
Ээ, микросервисы - это про решение орг.проблем, а не технологических.
AG
Ну в моем случае это самое эффективное применение микросервисов
PD
А кто мешает это сделать внутри приложения?
AG
всмыле внутри одной jvm?
PD
Например.
AG
тогда как я смогу бандить их в отдельные ядра?
AG
каждый микросервис внутри отдельной JVM запускается
AG
Ну у меня HFT приложение
PD
Вот как-то так? Или оно не работает?
GitHub - OpenHFT/Java-Thread-Affinity: Bind a java thread to a given core
https://github.com/OpenHFT/Java-Thread-Affinity
GitHub - OpenHFT/Java-Thread-Affinity: Bind a java thread to a given core
https://github.com/OpenHFT/Java-Thread-Affinity
AG
Оно самое. Работает четко. не надо никаких танцы с бубнами
PD
Я так понял, что оно позволяет отдельные треды мапить, а не всю jvm.
AG
Кстати да. просто я все равно каждый микросервис отдельным процессом запускаю
PD
Ну и зачем тогда отдельным?
AG
Так даже лучше не надо будет перезапустить все приложение
AG
Ну и зачем тогда отдельным?
как я сказал чтобы не перезапустить. Если отдельно то можно несколько консюмеров запустить если надо
2020 February 04
ПП
В смысле "изменился формат для сервисов"? А как же потребители - они в курсе перемен?
Нужно добавить для всех - добавляем для всех, что тут сложного.
Вот когда мы хотим поменять инфу для 80%, а у нас всё на одной центральной библиотеке завязано - вот где настоящий головняк. И как потом отличать тех, где общая инфа от остальных.
Нужно добавить для всех - добавляем для всех, что тут сложного.
Вот когда мы хотим поменять инфу для 80%, а у нас всё на одной центральной библиотеке завязано - вот где настоящий головняк. И как потом отличать тех, где общая инфа от остальных.
А что API прибито гвоздями на всю жизнь?
Отлично, какое количество сервисов приемлемо для копипастного подхода?
Два? Ок. Двадцать? А тридцать?
Надо исходить из ситуации, но я не вижу причин менять общие вещи для сервисов для 80%.
По крайней мере, если они делаются для одной компании, по единому стандарту.
Другое дело, когда аутсорс.. Но всегда же можно группировать и делать общие либы.
Отлично, какое количество сервисов приемлемо для копипастного подхода?
Два? Ок. Двадцать? А тридцать?
Надо исходить из ситуации, но я не вижу причин менять общие вещи для сервисов для 80%.
По крайней мере, если они делаются для одной компании, по единому стандарту.
Другое дело, когда аутсорс.. Но всегда же можно группировать и делать общие либы.
AV
А что API прибито гвоздями на всю жизнь?
Отлично, какое количество сервисов приемлемо для копипастного подхода?
Два? Ок. Двадцать? А тридцать?
Надо исходить из ситуации, но я не вижу причин менять общие вещи для сервисов для 80%.
По крайней мере, если они делаются для одной компании, по единому стандарту.
Другое дело, когда аутсорс.. Но всегда же можно группировать и делать общие либы.
Отлично, какое количество сервисов приемлемо для копипастного подхода?
Два? Ок. Двадцать? А тридцать?
Надо исходить из ситуации, но я не вижу причин менять общие вещи для сервисов для 80%.
По крайней мере, если они делаются для одной компании, по единому стандарту.
Другое дело, когда аутсорс.. Но всегда же можно группировать и делать общие либы.
Изменить одинаково 20 сервисов.
Сложно? Нет.
Скучно? Да.
Написать систему абстракций экономящих при случае строчки кода.
Сложно? Да
Скучно? Нет
-----
Какой из вариантов экономичнее? Вопрос риторический, отвечать не надо.
Я сам - адепт скучного кода.
Сложно? Нет.
Скучно? Да.
Написать систему абстракций экономящих при случае строчки кода.
Сложно? Да
Скучно? Нет
-----
Какой из вариантов экономичнее? Вопрос риторический, отвечать не надо.
Я сам - адепт скучного кода.