Как отключить CompositeDiscoveryClient и SimpleDiscoveryClient в библиотеке обнаружения служб - PullRequest
Новая
       18

Как отключить CompositeDiscoveryClient и SimpleDiscoveryClient в библиотеке обнаружения служб

0 голосов
/ 22 февраля 2019

Мы написали собственный клиент обнаружения служб (SD) на основе spring-cloud-common SPI , что означает, что он предоставляет реализации для интерфейсов ServiceRegistry и DiscoveryClient и некоторых других Spring-обеспечиваемые абстракции.

Приложения, использующие нашу библиотеку, просто добавляют ее в свой файл pom, и она автоматически связывает DiscoveryClient с собственной реализацией, InHouseDiscoveryClient

<dependency>
   <groupId>blah.blah<groupId>
   <artifactId>inhouse-service-discovery-client<artifactId>
<dependency>

Однако, скореечем ссылаться на InHouseDiscoveryClient в коде, лучше использовать интерфейс DiscoveryClient, как показано ниже 

# Good 
@Autowired
DiscoveryClient client;

# Bad (binds app to a particular SD implementation)
@Autowired
InHouseDiscoveryClient client;

Таким образом, мы должны добавить spring-cloud-commons в проект. 

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-commons</artifactId>
    </dependency>

Здесь начинается проблема .Библиотека commons фактически автоматически связывает две дополнительные реализации DiscoveryClient - SimpleDiscoveryClient и CompositeDiscoveryClient.

Это создает странный пользовательский опыт для наших клиентов.Вместо того, чтобы просто иметь InHouseDiscoveryClient, пользователи оказываются с этими дополнительными компонентами.

Можно ли предотвратить автоматическое подключение реализаций spring-cloud-commons DiscoveryClient?И если да, то можно ли это сделать в нашей библиотеке, а не в приложениях конечного пользователя?

1 Ответ

0 голосов
/ 24 февраля 2019

В итоге я расширил AutoConfigurationImportFilter в своей библиотеке, чтобы удалить автоматически подключаемые bean-компоненты из облачных сообществ.Я также удалил его индикатор состояния, но у нас была особая причина для этого - скорее всего, лучше оставить его. 

my.package

public class StratusDiscoveryExclusionFilter implements AutoConfigurationImportFilter {

private static final Set<String> SHOULD_SKIP = new HashSet<>(
        Arrays.asList(
                // DiscoveryClient Beans
                "org.springframework.cloud.client.discovery.composite.CompositeDiscoveryClientAutoConfiguration",
                "org.springframework.cloud.client.discovery.simple.SimpleDiscoveryClientAutoConfiguration",
                // Health indicators
                "org.springframework.cloud.client.CommonsClientAutoConfiguration")
);

/**
 * For each class name, provide an assocated boolean array indicated whether or not to include
 */
@Override
public boolean[] match(String[] classNames, AutoConfigurationMetadata metadata) {
    boolean[] matches = new boolean[classNames.length];

    for (int i = 0; i < classNames.length; i++) {
        matches[i] = !SHOULD_SKIP.contains(classNames[i]);
    }
    return matches;
 }
}

Я думаю добавить ссылку на это в файл spring.factories моей библиотеки 

org.springframework.boot.autoconfigure.AutoConfigurationImportFilter=my.package.MyExclusionFilter
...