Как разработчики Spring Cloud разрешают конфликты служб и скремблирование экземпляров?

Spring Cloud
Как разработчики Spring Cloud разрешают конфликты служб и скремблирование экземпляров?

1. Предпосылки

Когда мы разрабатываем систему микросервисной архитектуры, хотя и говорится, что каждый микросервис изолирован и может разрабатываться отдельно, на самом деле это не так. также должны быть запущены его контекстные службы, зависимые базовые службы и т. д., но если у вас большое количество системных служб и зависимостей, это более сложная проблема! Есть ли способ повысить эффективность разработки?

file

Как показано на рисунке выше, можем ли мы использоватьСервер развертывает все службывверх, а затем развиватьЗапускайте локально только те сервисы, за разработку которых вы отвечаете., так как он должен полагаться на другие службы, локально запускаемые службы также должны быть зарегистрированы в общедоступном реестре;

пример业务服务BВ реестре зарегистрировано 3 экземпляра Это: сервер, разработка A и разработка B, начатые сами по себе.

Но это создает новую проблему:Сервисы будут конфликтовать,это значит开发Aотлаживать свои собственные业务服务BПри обслуживании запрос может переходить на чужие инстансы (сервер, разработка Б)

 

Во-вторых, решения

Более элегантный способ решить эту проблему скремблирования служб состоит в том, чтобы自定义负载均衡规则, в основном для достижения следующих целей:

  1. обычный пользовательПри доступе к странице на сервере все запрошенные маршруты просто вызывают服务器上的实例
  2. разработка АПри доступе сначала вызываются все запрошенные маршруты开发A本机启动的实例, если нет то звоните服务器上的实例
  3. развитие БПри доступе к тому же, что и выше, сначала вызываются все запрошенные маршруты.开发B本机启动的实例, если нет то звоните服务器上的实例

 

В-третьих, конкретная реализация

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

  1. различать不同用户的服务实例
  2. выполнить自定义负载均衡规则

3.1 ДифференциацияЭкземпляры службы для разных пользователей

Вы можете напрямую использовать метаданные реестра, чтобы различать

Основные реестры поставляются с управлением метаданными кNacosНапример, просто добавьте в файл конфигурации

spring:
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
        metadata:
          version: zlt

под метаданнымиversionэто метаданные, которые я добавилkeyэто версия,valueдля злотых

После запуска службы метаданные будут зарегистрированы, как показано ниже.

file

После выделения метаданных текущая ситуация выглядит следующим образом

  • экземпляр сервераversionПусто
  • Экземпляры, запускаемые локально самими разработчикамиversionкак уникальный идентификатор (собственное имя)
    file

 

3.2 Пользовательские правила балансировки нагрузки

первый вSpring CloudБалансировка нагрузки экземпляров в среде микросервиса выполняетсяRibbonБыть ответственным за.CustomIsolationRuleПодробную информацию о классе можно посмотреть по адресу:CustomIsolationRule.java

public class CustomIsolationRule extends RoundRobinRule {
    /**
     * 优先根据版本号取实例
     */
    @Override
    public Server choose(ILoadBalancer lb, Object key) {
        if (lb == null) {
            return null;
        }
        String version = LbIsolationContextHolder.getVersion();
        List<Server> targetList = null;
        List<Server> upList = lb.getReachableServers();
        if (StrUtil.isNotEmpty(version)) {
            //取指定版本号的实例
            targetList = upList.stream().filter(
                    server -> version.equals(
                            ((NacosServer) server).getMetadata().get(CommonConstant.METADATA_VERSION)
                    )
            ).collect(Collectors.toList());
        }

        if (CollUtil.isEmpty(targetList)) {
            //只取无版本号的实例
            targetList = upList.stream().filter(
                    server -> {
                        String metadataVersion = ((NacosServer) server).getMetadata().get(CommonConstant.METADATA_VERSION);
                        return StrUtil.isEmpty(metadataVersion);
                    }
            ).collect(Collectors.toList());
        }

        if (CollUtil.isNotEmpty(targetList)) {
            return getServer(targetList);
        }
        return super.choose(lb, key);
    }

    /**
     * 随机取一个实例
     */
    private Server getServer(List<Server> upList) {
        int nextInt = RandomUtil.randomInt(upList.size());
        return upList.get(nextInt);
    }
}

Наследовать правила опросаRoundRobinRuleДля достижения основной логики является

  1. На основе номера версии, введенного выше по течениюversion, если есть значение, взять服务元信息серединаversionэкземпляр с тем же значением
  2. номер исходной версииversionЕсли значение отсутствует или номер версии не соответствует какой-либо службе,服务元信息серединаversionэкземпляр с пустым значением

  И через переключатель конфигурации, чтобы контролировать, открывать ли пользовательское правило загрузки

@Configuration
@ConditionalOnProperty(value = "zlt.ribbon.isolation.enabled", havingValue = "true")
@RibbonClients(defaultConfiguration = {RuleConfigure.class})
public class LbIsolationConfig {

}

 

4. Резюме

упомянутый вышеЭкземпляр DiffServа такжеПользовательские правила загрузкиВ основе всего решения лежит изоляция экземпляров службы, а остальное нужно сделатьвверх по течениюversionКак это передать?, ниже предлагаю две идеи

  • Разработчик сам запускает front-end проект и передает его в front-end проект единообразно через параметры конфигурации.version
  • пройти черезpostmanПри вызове интерфейса добавьте его в параметр заголовка
    file

 

Ссылаться на

GitHub.com/NEP West Oh You/DIS…

 

Рекомендуемое чтение

 

file

Категории