Исправление Aber, (текущая версия) :
Я линейный кодер в энетерпрайз - spring-boot + spring-cloud, все вериться в кубрентетс.
Ничего не поменялось. Очень толстые микросервисы, уж точно не микро, просто отдельные монолитики над которыми работают отдельные команды. Раньше эти микросервисы называли инфраструктурными проектами, типа сервер авторизации и т.д.
Получается, что мне нужно запускать десять JVM-ов? Не очень хорошо с точки зрения потребления ресурсов. Тем более, что Java не отдаёт память.
Есть подвижки, ряд GC научился отдавать память системе, только надо еще поискать как этот GC включить и в какой версии JVM нужный GC есть.
Будет десять тред-пулов?
Да.
удобней пользоваться великим и ужасным java.util.logging-ом.
slf4j + logback стал стандартом.
В каждом приложении свои настройки логов будут.
Так и есть, по крайне мере там где я работал.
Получается нужен ещё какой-то сервис, куда сваливать все логи
Для сбора логов используют стек ELK
А то вроде томкат старый, но чем его заменять - не понимаю.
Нет. Он из коробки используется как встроенный сервлет-контейнер в spring-boot, для WebMVC выбор только между tomcat и jetty. Для spring webflux выбор будет больше, т.к. он не привязан к servlet api.
И причём не понятно, зачем всё это. Собственно тред про это - посоветуйте, как это всё нынче делают и зачем это всё делают?
Делают по новому из-за микросервисного подхода. Он позволяет разбить разработку на множество команд, где у каждой команды свой релизный цикл, даже свой стек и другой язык. Другого ничего не дает, если не проектировать high availability сервис самого начала то получается микросервисная архитектура со множеством критических точек, ничем от модульных монолитов не отличающиеся кроме ввода механизмов обмена сообщениями.
Судя по описанию у тебя все очень хорошо, ищи узкие места и смотри что может из современных подходов помочь. В моем мире очень много каргокульта, ощущение что берут что-то и слепо пытаются приспособить даже не задаваясь вопросом, а какую проблему это должно таргетировать.
Исправление Aber, :
Я линейный кодер в энетерпрайз - spring-boot + spring-cloud, все вериться в кубрентетс.
Ничего не поменялось. Очень толстые микросервисы, уж точно не микро, просто отдельные монолитики над которыми работают отдельные команды. Раньше эти микросервисы называли инфраструктурными проектами, типа сервер авторизации и т.д.
Получается, что мне нужно запускать десять JVM-ов? Не очень хорошо с точки зрения потребления ресурсов. Тем более, что Java не отдаёт память.
Есть подвижки, ряд GC научился отдавать память системе, только надо еще поискать как этот GC включить и в какой версии JVM нужный GC есть.
Будет десять тред-пулов?
Да.
удобней пользоваться великим и ужасным java.util.logging-ом.
slf4j + logback стал стандартом.
В каждом приложении свои настройки логов будут.
Так и есть, по крайне мере там где я работал.
Получается нужен ещё какой-то сервис, куда сваливать все логи
Для сбора логов используют стек ELK
А то вроде томкат старый, но чем его заменять - не понимаю.
Нет. Он из коробки используется как встроенный сервлет-контейнер в spring-boot, для WebMVC выбор только между tomcat и jetty. Для spring webflux выбор будет больше, т.к. он не привязан к servlet api.
И причём не понятно, зачем всё это. Собственно тред про это - посоветуйте, как это всё нынче делают и зачем это всё делают?
Делают по новому из-за микросистемного подхода. Он позволяет разбить разработку на множество команд, где у каждой команды свой релизный цикл, даже свой стек и другой язык. Другого ничего не дает, если не проектировать high availability сервис самого начала то получается микросервисная архитектура со множеством критических точек, ничем от модульных монолитов не отличающиеся кроме ввода механизмов обмена сообщениями.
Судя по описанию у тебя все очень хорошо, ищи узкие места и смотри что может из современных подходов помочь. В моем мире очень много каргокульта, ощущение что берут что-то и слепо пытаются приспособить даже не задаваясь вопросом, а какую проблему это должно таргетировать.
Исходная версия Aber, :
Я линейный кодер в энетерпрайз - spring-boot + spring-cloud, все вериться в кубрентетс.
Ничего не поменялось. Очень толстые микросервисы, уж точно не микро, просто отдельные монолитики над которыми работают отдельные команды. Раньше эти микросервисы называли инфраструктурными проектами, типа сервер авторизации и т.д.
Получается, что мне нужно запускать десять JVM-ов? Не очень хорошо с точки зрения потребления ресурсов. Тем более, что Java не отдаёт память.
Есть подвижки, ряд GC научился отдавать память системе, только надо еще поискать как этот GC включить и в какой версии JVM нужный GC есть.
Будет десять тред-пулов?
Да.
удобней пользоваться великим и ужасным java.util.logging-ом.
slf4j + logback стал стандартом.
В каждом приложении свои настройки логов будут.
Так и есть, по крайне мере там где я работал.
Получается нужен ещё какой-то сервис, куда сваливать все логи
Для сбора логов используют стек ELK
А то вроде томкат старый, но чем его заменять - не понимаю.
Нет. Он из коробки используется как встроенный сервлет-контейнер в spring-boot, для WebMVC выбор только между tomcat и jetty. Для spring webflux выбор будет больше, т.к. он не привязан к servlet api.
И причём не понятно, зачем всё это. Собственно тред про это - посоветуйте, как это всё нынче делают и зачем это всё делают?
Делаю по новому из-за микросистемного подхода. Он позволяет разбить разработку на множество команд, где у каждой команды свой релизный цикл, даже свой стек и другой язык. Другого ничего не дает, если не проектировать high availability сервис самого начала то получается микросервисная архитектура со множеством критических точек, ничем от модульных монолитов не отличающиеся кроме ввода механизмов обмена сообещниями.
Судя по описанию у тебя все очень хорошо, ищи узкие места и смотри что может из современных подходов помочь. В моем мире очень много каргокульта, ощущение что берут что-то и слепо пытаются приспособить даже не задаваясь вопросом, а какую проблему это должно таргетировать.