Тренды в Java разработке: микросервисы, отказ от Reflection, рективное программирование (Topjava)
Vložit
- čas přidán 21. 08. 2024
- Купить курс Topjava и другие курсы - alexnikiforov....
Таймкоды:
01:41 - тренд на отказ от Reflection API, Micronaut
02:37 - тренд на развитие реактивного программирования (Reactor, Spring WebFlux)
03:31 - Микросервисы - преимущества и сложности
Первая часть обзора технологий - • Курс "Topjava" от java...
Вторая часть обзора технологий - • Курс "Topjava" от java...
Запись на консультацию:
- telegram - @alexnikiforovcom
- mail - nikiforov.san.sanich@gmail.com
Могу помочь Вам с составлением плана обучения, ответить на вопросы в части Java, сделать code-review, помочь с пэт проектом или решение учебных задач.
Тренд на отказ от reflection
В настоящее время развиваются фреймворки, построенные на на отказе
от использования Reflection API.
Dependency injection в Spring, сериализация с помощью
Jackson построены на использовании Reflection, что
сильно бьет по производительности, но было достаточно
удобным решение до недавнего времени.
Фреймворк Micronaut послностью построен на отказе от
reflection и это дает существенный прирост
производительности при измерении ряда параметров.
Я предполагаю, что в какой то момент
Spring может также внедрить подобный подход.
Тренд на развитие реактивного программирования
Продолжает развиваться реактивное программирование,
которое является в какой то степени новой парадигмой
в программировании.
Spring развивает свой реактивный фреймворк Spring WebFlux,
который поддерживает библиотеку Reactor.
Ряд современных задач не решается традиционными
методами, такими как блокирующей Input/Output,
HTTP протокол. Одним из решений данных вопросов
является применение подходов реактивного
программирования (Reactor, RxJava), использование
новых протоколов передачи данных (RSocket).
Тренд на использование микросервисов
Если в большое монолитное приложение добавляется новая
функциональность приходиться выполнять повторного тестирование
всей большой системы, в результате срок выхода новых фич увеличивается.
Микросервисная архитектура позволяет решить эту проблему - она
предполагает разделение большого приложения на отдельные
приложения-модули, которые взаимодействуют друг с другом.
Над одним модулем-сервисом может работать один человек или
небольшая команда. У такого модуля-сервиса будет отдельный
Git-репозиторий, он может быть задеплоен (развернут) независимо
от остальной системы. При таком подходе, команды могут вести работу
над различными сервисами параллельно, параллельно деплоить
их на серверах. При внесении изменений в микросервис “А”,
вероятность вызывать проблемы в микросервисе “B” снижается.
У разных микросервисов могут быть собственные базы данных.
Это также повышает надежность и гибкость. Например, если по каким то причинам после обновления банковского микросервиса, ответственного за выдачу кредитов возникли сбои и база данных оказалась недоступна, другие компоненты системы, имеющие отдельные базы данных, продолжат свою работу без сбоев.
Это существенно упрощает доработку, тестирование и деплой таких систем.
Использование микросервисов дает большую гибкость в выборе
технологий. Нам не нужно ограничивать себя в использовании
технологий для того, чтобы все стандартизировать внутри
одной большой системы. Работая с отдельными микросервисами,
мы можем выбрать идеально подходящие технологии для отдельных задач.
Например, один микросервис может использовать реляционные
базы данных, а второй эффективнее решает свою задачу
используя NoSQL базу данных или in memory базу данных.
Еще одно важное преимущество, которое дает микросервисная
архитектура это возможность легко масштабировать систему горизонтально.
Предположим, что банк испытывает быстрый рост обращений
об открытии новых счетов.
Если банк использует монолитную архитектуру,
то есть одно большое приложение, ему может потребоваться
запускать отдельный экземпляр всего своего приложения
и направлять часть обращений от клиентов на этот экземпляр (instance).
Если же банк использует микросервисную архитектуру,
он может запустить несколько экземпляров только сервиса,
ответственного за открытие новых счетов и распределять
нагрузку между этими экземплярами.
При этом микросервис, ответственный за выдачу кредитов,
который не испытывает повышенной нагрузки, может остаться
в одном экземпляре. При этом увеличение числа микросервисов,
ответственных за открытие счетов может происходить автоматически
с помощью инструментов DevOps и Kubernetes.
Однако использование микросервисов также создает сложности.
Разработка систем, построенных на микросервисной архитектуре
на порядок сложнее. Обслуживание таких систем также
существенно сложнее.
Компания должна обслуживать множество серверов,
обеспечивать мониторинг каждого микросервиса и так далее.
Также security таких систем существенно сложнее,
поскольку мы имеем дело с множеством приложений,
коммуницирующих друг с другом и все эти коммуникации
должны быть безопасными.
Александр, ведь вы недавно перешли в IT, подскажите, как так быстро освоили такое огромное количество знаний?
До трудоустройства потребовалось 800-900 часов обучения. Ну и продолжаю осваивать. Это процесс непрерывный.
@@NikiforovJava Круто)) у меня 1100 часов, также залез в кубернетес, микросервисы
👍🏻
Первый! :-)
Объем материала дейстительно большой, если углубляться в каждую затронутую тему
Все сравнивают микросервисы с монолитом и почему то все забывают про существования Java ee
Что Вы имеете ввиду? Я точно не знаю делают ли на java ee микросервисы, предполагаю, что это вполне возможно. Монолит точно делают/делали. Так что к java ee насколько я понимаю это тема фреймворков, архитектура это отдельная история
Почему перестали выходить видео ... надоело ?
Скорее всего просто работы много плюс семья
Больше микросервисов богу микросервисов. На самом деле, лучше бы нормально код писали и не нужны были бы ваши микросервисы. А потом это оргию из микросервисов сопровождать. Вот где главный гемерой начинается.
Не переживай- chatGPT сопроводит , а мы отдыхать пойдём
Ну то есть Amazon, Netflix, Uber, другие IT гиганты, а также множество крупных банков, которые перешили или переходят на микросервисы , занимаются этим зря? Правильно я понимаю? :)
@@NikiforovJava Когда у тебя много денег, то можно чем угодно баловаться)
У них не просто много денег. Они побеждают конкурентов. Значит наверное делают все правильно
@@NikiforovJava Это немного не так работает. Они привлекают деньги инвесторов, у которых их ОЧЕНЬ много (то что они их вливают в стартапы, это просто некое развлечение, когда их девать некуда, ну и потенциальное получение прибыли).
Много денег -> найм хороших специалистов -> получение хорошего конечно продукта. А микросервисная архитектура это уже вторичное. Когда у вас в штате 10к+ сотрудников можно из говна и палок ракету построить.
Они не побеждают конкурентов. Отсутствие конкуренции на рынке != победить конкурентов. Опять же отсутствие за счет поглощения компаний на рынке, чтобы не дать вырасти в самостоятельную конкурирующую компанию. И примеров таких очень много.