Создание собственных приложений для облачной среды в Spring — часть 4

Первое, что вы заметите, это то, что этот интерфейс использует аннотацию под названием @FeignClient . Эта аннотация говорит Feign, что мы будем разговаривать с сервисом под названием «участники» . Feign будет использовать Eureka, чтобы выяснить правильный URL-адрес для службы участников. Остальная часть интерфейса должна выглядеть довольно знакомой, если вы знакомы с Spring MVC. @RequestMapping аннотацию на getParticipants метод говорит симулировать сделать GET запрос на обслуживание участников по пути / рас / raceId .

На этом этапе у вас будут ошибки компиляции в вашем интерфейсе, потому что в сервисе гонок нет класса с именем Участник . Если вы опытный Java-разработчик, ваш первый инстинкт, вероятно, будет сделать некоторый рефакторинг. Вы можете перейти к услуге для участников, чтобы извлечь Участникакласс в свой проект. Затем вы измените сервис участников и гонок, чтобы они зависели от этого нового проекта. Это укоренилось в наших умах из-за принципа СУХОЙ (не повторяйся), который говорит, что мы не должны копировать и вставлять код повсюду из-за того, что он станет не поддерживаемым. Это, безусловно, серьезная проблема, однако мы должны сбалансировать принцип DRY с другими принципами микросервисов. Проблема такого подхода к рефакторингу нашего приложения состоит в том, что теперь у нас есть общий класс, используемый двумя (или более) службами. Что происходит, когда один сервис должен внести изменения в этот класс? Если изменение достаточно радикальное, вы можете сломать другой сервис. Это означает, что сервисы не могут развиваться независимо друг от друга,что является одним из преимуществ, которые мы пытаемся достичь с помощью микросервисов.

В конце дня вы должны принять решение, которое подходит именно вам, вашей команде и вашему проекту. Хотите ли вы делиться кодом между вашими микросервисами или хотите получить возможность развивать свои сервисы независимо друг от друга? В этом случае мы НЕ будем следовать принципу СУХОЙ и создадим нового участника класс в нашем сервисе гонок. Почему? Подумайте о том, как бы вы работали, если бы создавали настоящее приложение для микросервисов промышленного уровня. Вы будете разработчиком в команде, которая отвечает за один сервис. Теоретически вы ничего не будете знать о реализации других сервисов, от которых вы зависите, единственное, на что вы можете положиться — это их публичный API. Они могут даже не быть реализованы на том же языке, который вы используете. Исходя из этой логики, для вас имеет смысл создать класс участников в вашем сервисе, соответствующий тому, что будет возвращать их общедоступный API. На мой взгляд, когда дело доходит до микросервисов, разделение кода между сервисами, как правило, не имеет смысла.

В OcrRacesApplication.java  создайте новый класс участников :

class Participant {
    private String firstName;
    private String lastName;
    private String homeState;
    private String shirtSize;
    private List<String> races;
    public Participant(String firstName, String lastName, String homeState,
            String shirtSize, List<String> races) {
        super();
        this.firstName = firstName;
        this.lastName = lastName;
        this.homeState = homeState;
        this.shirtSize = shirtSize;
        this.races = races;
    }

    public Participant(){}
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
    public String getHomeState() {
        return homeState;
    }
    public void setHomeState(String homeState) {
        this.homeState = homeState;
    }
    public String getShirtSize() {
        return shirtSize;
    }
    public void setShirtSize(String shirtSize) {
        this.shirtSize = shirtSize;
    }
    public List<String> getRaces() {
        return races;
    }
    public void setRaces(List<String> races) {
        this.races = races;
    }
}

class RaceWithParticipants extends Race {
    private List<Participant> participants;

    public RaceWithParticipants(Race r, List<Participant> participants) {
        super(r.getName(), r.getId(), r.getState(), r.getCity());
        this.participants = participants;
    }

    public List<Participant> getParticipants() {
        return participants;
    }

    public void setParticipants(List<Participant> participants) {
        this.participants = participants;
    }
}

@Autowired
private ParticipantsClient participantsClient;

@RequestMapping("/participants")
    public List<RaceWithParticipants> getRacesWithParticipants() {
        List<RaceWithParticipants> returnRaces = new ArrayList<RaceWithParticipants>();
        for(Race r : races) {
            returnRaces.add(new RaceWithParticipants(r, participantsClient.getParticipants(r.getId())));
        }
        return returnRaces;
    }

[
   {
      "name":"Spartan Beast",
      "id":"123",
      "state":"MA",
      "city":"Boston",
      "participants":[
         {
            "firstName":"Ryan",
            "lastName":"Baxter",
            "homeState":"MA",
            "shirtSize":"S",
            "races":[
               "123",
               "456"
            ]
         }
      ]
   },
   {
      "name":"Tough Mudder RI",
      "id":"456",
      "state":"RI",
      "city":"Providence",
      "participants":[
         {
            "firstName":"Ryan",
            "lastName":"Baxter",
            "homeState":"MA",
            "shirtSize":"S",
            "races":[
               "123",
               "456"
            ]
         },
         {
            "firstName":"Stephanie",
            "lastName":"Baxter",
            "homeState":"MA",
            "shirtSize":"S",
            "races":[
               "456"
            ]
         }
      ]
   }
]