Вступление
Spring Framework - очень надежный фреймворк, выпущенный в 2002 году. Его основные функции могут применяться к простым Java-приложениям или расширяться до сложных современных веб-приложений.
Поскольку он постоянно обновляется и следует новым парадигмам архитектуры и программирования, он предлагает поддержку многих других фреймворков, которые работают с ним рука об руку.
С таким огромным набором функций вполне нормально, что он знакомит нас с некоторыми новыми аннотациями, которые являются ключевой частью разработки приложений Spring.
Конфигурация Spring полностью настраиваема, что изначально было сделано с помощью файлов конфигурации XML. Однако этот подход устарел, и в настоящее время большинство людей прибегают к настройке аннотаций.
При этом эта серия статей направлена на раскрытие возможностей, которые вы, как разработчик, должны настраивать и использовать фреймворк Spring:
- Аннотации Spring: @RequestMapping и его варианты
- Аннотации Spring: основные аннотации
- Аннотации Spring: Spring Cloud
- Аннотации Spring: аннотации к тестированию
Аннотации Spring Cloud
Spring Cloud - отличное расширение и без того надежной Spring Framework. Это позволяет разработчикам легко и безболезненно создавать общие шаблоны, когда дело доходит до облачной архитектуры, такой как настройка автоматических выключателей, клиентов обнаружения, маршрутизации и т. Д.
Мы уже опубликовали несколько статей, охватывающих некоторые из этих тем, поэтому, если вы хотите увидеть эти аннотации на практических примерах, это отличное начало:
- Spring Cloud: открытие сервисов с Eureka
- Spring Cloud: маршрутизация с Zuul и Gateway
- Весеннее Облако: Гистрикс
- Весеннее Облако: Турбина
- Spring Cloud Stream с RabbitMQ: микросервисы, управляемые сообщениями
@EnableConfigServer
Spring Cloud знакомит нас с несколькими полезными инструментами, каждый из которых требует некоторой настройки.
Если мы используем несколько инструментов, было бы логично хранить все
детали конфигурации в одном месте, как в файле application.properties
Для этого мы аннотируем класс @EnableConfigServer , применяемой на
уровне класса:
@SpringBootApplication
@EnableConfigServer
public class SomeApplication {
public static void main(String[] args) {
SpringApplication.run(SomeApplication.class, args);
}
}
Эта аннотация сообщает Spring, где искать конфигурации, и, создав такую
централизованную конфигурацию сервера, другие приложения могут общаться
с ним через его порт, который по умолчанию равен 8080 .
@EnableEurekaServer
При разработке проекта с микросервисной архитектурой, особенно когда существует множество сервисов, которые должны работать вместе, мы сталкиваемся с проблемой. Как эти службы общаются друг с другом.
Мы могли бы жестко закодировать все имена и порты в файле свойств, но это плохая практика и вообще не масштабируется. Даже если бы мы это сделали, что произойдет, если существует несколько экземпляров службы? Какой ответ на запрос?
Чтобы решить эту проблему, мы можем полагаться на Service Discovery через Eureka.
Очень похоже на @EnableConfigServer , мы создадим сервер Eureka,
аннотируя класс с помощью @EnableEurekaServer , который теперь можно
использовать для поиска других зарегистрированных на нем сервисов и
управления ими:
@SpringBootApplication
@EnableEurekaServer
public class SomeApplication {
public static void main(String[] args) {
SpringApplication.run(SomeApplication.class, args);
}
}
@EnableEurekaClient
Сервер Eureka - ничто без его услуг. Каждый сервис, который мы хотим
привлечь к нашему серверу, должен быть аннотирован аннотацией
@EnableEurekaClient
В качестве альтернативы мы могли бы использовать
@EnableDiscoveryClient , которая происходит от spring-cloud-commons
. Хотя, если вы знаете конкретную реализацию, которую будете
использовать, лучше конкретизировать. Если вы используете более
генетическую @EnableDiscoveryClient , Spring выберет реализацию на
основе .jar присутствующих в пути к классам.
@SpringBootApplication
@EnableEurekaClient
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
@EnableDiscoveryClient
Аннотации клиента обнаружения по умолчанию, которые помечают класс как услугу, которую следует поставить в поле зрения сервера.
@EnableCircuitBreaker
Опять же, при работе с микросервисами мы сталкиваемся с большой проблемой. Обычно службы работают с другими службами для выполнения определенных запросов.
Допустим, служба A вызывает службу B, которая полагается на службу C для выполнения запроса. Теперь предположим, что служба C полностью выходит из строя из-за сетевой ошибки или перегрузки. Далее происходит каскадная ошибка в потоке логики, возвращающемся в службу A.
Что мы можем сделать, чтобы исправить это, - это установить автоматические выключатели. Каждая служба должна иметь точку разрыва цепи, и если что-то не так, они «размыкают свои цепи», чтобы проблема не переносилась на другие службы. В этом случае выбранный нами автоматический выключатель изолирует отказавшую службу, чтобы другие службы не могли вызвать ее и тоже выйти из строя.
@EnableCircuitBreaker применяется на уровне класса для каждой службы в
нашей микросервисной архитектуре:
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceA {
public static void main(String[] args) {
SpringApplication.run(ServiceA.class, args);
}
}
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceB {
public static void main(String[] args) {
SpringApplication.run(ServiceB.class, args);
}
}
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceC {
public static void main(String[] args) {
SpringApplication.run(ServiceC.class, args);
}
}
Шаблон выключателя в Spring реализован через Spring Cloud: Hystrix .
@HystrixCommand
Чтобы схема автоматического выключателя работала полностью, мы не можем
только аннотировать классы. Поскольку почти во всех ситуациях мы можем
«ожидать», что метод может быть рискованным в том смысле, что он может
дать сбой при вызове, мы помечаем их @HystrixCommand . Наряду с
аннотацией мы также можем добавить флаг, указывающий на другой метод,
который будет запускаться в случае сбоя исходного:
@GetMapping(value = "/personalized/{id}")
@HystrixCommand(fallbackMethod = "recommendationFallback")
public Product[] personalized(@PathVariable int id) {
Product[] result = restTemplate.getForObject("http://recommendation-service/recommendations", Product[].class);
return result;
}
public Product[] recommendationFallback(int id) {
System.out.println("=======recommendationFallback=========" + id);
return new Product[0];
}
@RibbonClient
Лента работает как балансировщик нагрузки на стороне клиента и дает вам контроль над клиентами HTTP и TCP.
В большинстве случаев при использовании клиента обнаружения, такого как Eureka, вам не нужно использовать эту аннотацию, поскольку она применяется по умолчанию. В подавляющем большинстве случаев параметры по умолчанию достаточно хороши, чтобы позаботиться о балансировке нагрузки, но если вам нужно их настроить, вы можете сделать это:
@Configuration
@RibbonClient(name = "custom", configuration = CustomConfiguration.class)
public class SomeConfiguration {
}
Класс CustomConfiguration также должен быть @Configuration с
пользовательскими настройками ленты, настроенными как beans.
@LoadBalanced
@LoadBalanced используется для обозначения RestTemplate s, которые
должны работать с RibbonLoadBalancerClient при взаимодействии с вашими
сервисами:
@RestController
@RibbonClient(name = "custom", configuration = CustomConfiguration.class)
public class SomeApplication {
@LoadBalanced
@Bean
RestTemplate restTemplate(){
return new RestTemplate();
}
// ...
}
Эта аннотация в основном позволяет RestTemplate использовать
встроенную поддержку балансировки нагрузки.
Заключение
Фреймворк Spring - это мощный и надежный фреймворк, который действительно изменил правила игры, когда дело доходит до разработки веб-приложений. Среди множества проектов модуль Spring Cloud является отличным расширением исходной структуры.