Производительность при передаче данных между микросервисами и микросервисами - PullRequest
Новая
       10

Производительность при передаче данных между микросервисами и микросервисами

1 голос
/ 05 марта 2020

У меня есть такой контроллер: 

@RestController
@RequestMapping("/stats")
public class StatisticsController {

    @Autowired
    private LeadFeignClient lfc;

    private List<Lead> list;


    @GetMapping("/leads")
    private int getCount(@RequestParam(value = "count", defaultValue = "1") int countType) {

        list = lfc.getLeads(AccessToken.getToken());

        if (countType == 1) {
            return MainEngine.getCount(list);
        } else if (countType == 2) {
            return MainEngine.getCountRejected(list);
        } else if (countType == 3) {
            return MainEngine.getCountPortfolio(list);
        } else if (countType == 4) {
            return MainEngine.getCountInProgress(list);
        } else if (countType == 5) {
            return MainEngine.getCountForgotten(list);
        } else if (countType == 6) {
            return MainEngine.getCountAddedInThisMonth(list);
        } else if (countType == 7) {
            return MainEngine.getCountAddedInThisYear(list);
        } else {
            throw new RuntimeException("Wrong mapping param");
        }

    }


    @GetMapping("/trends")
    private boolean getTrend() {
        return MainEngine.tendencyRising(list);
    }

По сути, это микросервис, который будет обрабатывать статистику на основе списка «бизнес-интересов». FeignClient - ПОЛУЧЕНИЕ списка усеченных до требуемых информационных отведений. Все работает правильно.

Меня беспокоит только производительность - вся эта статистика (countTypes) будет представлена ​​на целевой странице веб-приложения. Если я буду звонить им один за другим, будет ли каждый звонок снова и снова получать список потенциальных клиентов? Или список будет как-то храниться во временной памяти? Я могу представить, что если список станет длиннее, его загрузка может занять некоторое время.

Я пытался вызвать их вне этого метода, @PostConstruct, чтобы заполнить список в начале обслуживания, но у этого решения есть две основные проблемы: аутентификация не может быть обработана маркером oauth, извлеченный список будет нечувствителен к добавлению / удалению отведений, потому что он загружается только в начале.

Ответы [ 2 ]

0 голосов
/ 09 марта 2020

Вам необходимо внедрить слой кэширования для повышения производительности. Вы можете предварительно загрузить кэш сразу после запуска приложения. Таким образом, вы получите готовый ответ в кеше. Я бы предложил go с кешем Redis. Но любой кеш сделает эту работу. Кроме того, было бы лучше, если бы вы могли переместить логи c функции getCount () в некоторый класс обслуживания.

0 голосов
/ 05 марта 2020

list = lfc.getLeads(AccessToken.getToken()); будет вызываться с каждым GET запросом. Либо взгляните на кэширование ответов, которые могут быть полезны, когда вам нужно часто получать большой объем данных.

Я бы начал здесь: Baeldung's: учебник Spring cache , который дает вам идея о кешировании. Затем вы можете взглянуть на реализацию EhCache или внедрить собственный перехватчик, помещающий / получающий данные из / во внешнее хранилище, такое как Redis.

Кэширование - единственный способ решить эту проблему: Поскольку Feign клиент вызывается с другим запросом (на основе токена) данные не устарели c и должны быть кэшированы .

...