Настроить весеннюю перезагрузку для нескольких вызовов API

Question

У меня есть приложение api для загрузки Spring, которое имеет POST-конечную точку, Позволяет называть его/doSomething как метод. После получения запроса на/doSomething конечная точка Мне нужно сохранить эти данные в нашем приложении и то необходимо сделать запрос GET для другого api [A] с этим запросом, чтобы получить GET из API [B], а затем снова отправить сообщение в API [B]. В этом случае лучший способ справиться с повторением Spring.

Вы можете найти код ниже

@RequestMapping(value = "/subpub", method = RequestMethod.POST, headers = {"content-type=application/x-www-form-urlencoded"}) 
    public String subPub(HttpServletRequest request, HttpServletResponse response, @RequestBody String rawBody) { 
    //persists some data on this database 

    //this method will invoke api[A] and api[B] 
    integrationServiceBean.processCourseMetaData("_id"); 
    return "OK" 
}; 

IntegrationServiceBean класс

package com.pearson.reader.integration; 

@Service 
public class IntegrationServiceBean { 


    /** 
    * This method will process meta data submission for registrar api by invoking authentication service, receive 
    * section details by section id and update meta data 
    * 
    * @param sectionId 
    */ 
    @Retryable(RuntimeException.class) 
    public void processCourseMetaData(final String sectionId) { 

     System.out.println("Invoking processCourseMetaData"); 

     ResponseEntity<String> responseEntity = registrarService.findOneSection(sectionId); 
     String responseBody = responseEntity.getBody(); 

     LinkedHashMap requestObj = (LinkedHashMap) JsonUtils.jsonToObject(responseBody); 
     LinkedHashMap metaDataObj = (LinkedHashMap) requestObj.get(Constant.Response.META_DATA); 
     if (!contextConfig.getMetaDataCopyable().isEmpty()) { 

      metaDataObj.put(Constant.MetaData.COPYABLE, contextConfig.getMetaDataCopyable()); 
     } 
     if (!contextConfig.getMetaDataPending().isEmpty()) { 

      metaDataObj.put(Constant.MetaData.PENDING, contextConfig.getMetaDataPending()); 
     } 
     metaDataObj.put(Constant.MetaData.LAUNCH_URL, getLaunchUrlByEnvironment(requestObj, sectionId)); 

     String updatedSectionPayload = JsonUtils.toJsonString(requestObj); 

     registrarService.updateSection(sectionId, updatedSectionPayload); 
    } 

    @Recover 
    public void recover(RuntimeException e){ 
     System.out.println("Recovering - returning safe value"+e.getMessage()); 

    } 



} 

Моя проблема, если повторная попытка применяется для интеграции услуг боб будет ли это влияние на производительность для основной части бывшего приложения . для сохранения данных на главной конечной точке.

А что было бы лучшей практикой

Answer 1

Предложен метод @Retryable называется в изолированном потоке, блокируя текущий выполняющийся поток.

В перспективе вашего кода перспективного,

Сохранение происходит в потоке (скажем, поток А) и интеграции услуги обрабатываются в другом потоке (скажем, нить B). Таким образом, Thread A блокируется до тех пор, пока B не закончится. Таким образом, следующая строка integrationServiceBean.processCourseMetaData("_id"); блокируется до тех пор, пока она не будет завершена успешным или исчерпанием лимита повторной попытки.

Приходит по вашему вопросу.

Сохранение данных не затрагивается. Поэтому я не думаю, что есть какой-то удар производительности.

Говоря о наилучшей практике

с помощью Retry, когда есть сеть раздела между сервисами, является хорошей практикой. Это делает приложение надежным.