Говоря о трендах, хотелось бы сказать, что в настоящее время развиваются фреймворки, построенные на отказе от использования Reflection API. Dependency injection в Spring, сериализация с помощью Jackson построены на использовании Reflection, что сильно бьет по производительности, но было достаточно удобным решение до недавнего времени. Фреймворк Micronaut полностью построен на отказе от Reflection, и это дает существенный прирост производительности при измерении ряда параметров. Micronaut использует продвинутый компилятор и генерацию байткода, что позволяет создать все бины (управляемые фреймворком объекты) в ходе компиляции.
Пока доля Micronaut очень мала, но он используется в продакшене. Я предполагаю, что в какой-то момент Spring может также внедрить подобный подход.
Продолжает развиваться реактивное программирование, которое является в какой-то степени новой парадигмой в программировании.
Spring развивает свой реактивный фреймворк Spring WebFlux, который поддерживает библиотеку Reactor.
Ряд современных задач не решается традиционными методами, такими как блокирующий Input/Output, HTTP-протокол. Одним из решений данных вопросов является применение подходов реактивного программирования (Reactor, RxJava), использование новых протоколов передачи данных (RSocket). У нас также готовится курс ReactJava как продолжение TopJava на реактивном стеке.
ПО становиться большим и сложным. Очень большое приложение сложно поддерживать одной командой, управлять его жизненным циклом - разработкой, релизами.
Если в большое монолитное приложение добавляется новая функциональность приходиться выполнять повторного тестирование всей большой системы, в результате срок выхода новых фич увеличивается.
Микросервисная архитектура позволяет решить эту проблему - она предполагает разделение большого приложения на отдельные приложения-модули, которые взаимодействуют друг с другом. Над одним модулем-сервисом может работать один человек или небольшая команда. У такого модуля-сервиса будет отдельный Git-репозиторий, он может быть задеплоен (развернут) независимо от остальной системы. При таком подходе, команды могут вести работу над различными сервисами параллельно, параллельно деплоить их на серверах. При внесении изменений в микросервис “А”, вероятность вызывать проблемы в микросервисе “B” снижается. У разных микросервисов могут быть собственные базы данных. Это также повышает надежность и гибкость. Например, если по каким то причинам после обновления банковского микросервиса, ответственного за выдачу кредитов возникли сбои и база данных оказалась недоступна, другие компоненты системы, имеющие отдельные базы данных, продолжат свою работу без сбоев.
Это существенно упрощает доработку, тестирование и деплой таких систем.
Использование микросервисов дает большую гибкость в выборе технологий. Нам не нужно ограничивать себя в использовании технологий для того, чтобы все стандартизировать внутри одной большой системы. Работая с отдельными микросервисами, мы можем выбрать идеально подходящие технологии для отдельных задач. Например, один микросервис может использовать реляционные базы данных, а второй эффективнее решает свою задачу используя NoSQL базу данных или in memory базу данных.
Еще одно важное преимущество, которое дает микросервисная архитектура это возможность легко масштабировать систему горизонтально.
Предположим, что банк испытывает быстрый рост обращений об открытии новых счетов.
Если банк использует монолитную архитектуру, то есть одно большое приложение, ему может потребоваться запускать отдельный экземпляр всего своего приложения и направлять часть обращений от клиентов на этот экземпляр (instance).
Если же банк использует микросервисную архитектуру, он может запустить несколько экземпляров только сервиса, ответственного за открытие новых счетов и распределять нагрузку между этими экземплярами. При этом микросервис, ответственный за выдачу кредитов, который не испытывает повышенной нагрузки, может остаться в одном экземпляре. При этом увеличение числа микросервисов, ответственных за открытие счетов может происходить автоматически с помощью инструментов DevOps и Kubernetes.
Однако использование микросервисов также создает сложности. Разработка систем, построенных на микросервисной архитектуре на порядок сложнее. Обслуживание таких систем также существенно сложнее.
Компания должна обслуживать множество серверов, обеспечивать мониторинг каждого микросервиса и так далее. Также security таких систем существенно сложнее, поскольку мы имеем дело с множеством приложений, коммуницирующих друг с другом и все эти коммуникации должны быть безопасными.
Следующий, готовый стать самым популярным после TopJava курс - Микросервисы.