J: Тренды в Java разработке: микросервисы, отказ от Reflection, рективное программирование (Topjava) HD

Купить курс Topjava и другие курсы — alexnikiforov.com/javaops

Таймкоды:
01:41 — тренд на отказ от Reflection API, Micronaut
02:37 — тренд на развитие реактивного программирования (Reactor, Spring WebFlux)
03:31 — Микросервисы — преимущества и сложности

Первая часть обзора технологий — youtu.be/fVVep7NJMeg
Вторая часть обзора технологий — youtu.be/fVVep7NJMeg

Запись на консультацию:
— 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 таких систем существенно сложнее,
поскольку мы имеем дело с множеством приложений,
коммуницирующих друг с другом и все эти коммуникации
должны быть безопасными.