Вводное руководство по Spring Cloud, написанное для Xiaobai

Spring Cloud

В настоящее время компания использует Spring Cloud, и я чувствую, что мое понимание Spring Cloud недостаточно систематично, поэтому я планирую систематически разбираться в своем понимании Spring Cloud. Пока учился и практиковался, сам сделал кейс Spring Cloud.Учитывая, что доступ к GitHub относительно медленный, я выложил код в облако. адресgit ee.com/depositcard6013/SPR…Я сделал более подробные комментарии в нем, так что вы можете попробовать сделать это самостоятельно после прочтения.

Введение в микросервисную архитектуру

Когда программное обеспечение постепенно усложняется, затраты на разработку, эксплуатацию и обслуживание также растут, что также является одной из причин изменения или обновления архитектуры в процессе разработки и разработки программного обеспечения, снижения сложности программного обеспечения и снижение сложности софта одна из причин.Распространенный способ-разобрать,разбить софт на несколько модулей,чтобы сложность была равномерно распределена,да и на лезвии можно использовать хорошую сталь,что это значит? Возьмем, к примеру, сервер, объем запросов всех модулей неодинаков, трафик некоторых модулей неизбежно будет очень высоким.В качестве примера электронной коммерции трафик платежных сервисов или модулей относительно стабилен в обычное время, но на Double Eleven трафик будет быстро увеличиваться.В это время компании часто расширяют платежный сервис и предоставляют какие-то ресурсы для платежного сервиса.Если эти сервисы не демонтированы и сервисы упакованы в единое целое, то ресурсы I give не может использоваться только платежным сервисом.

Причина, по которой микросервисная архитектура стала новой нормой, заключается в том, что она снижает сложность программного обеспечения, полностью использует ресурсы и повышает скорость разработки. Демонтаж службы достаточно понятен. Когда трафик службы увеличивается, я могу только расширить возможности этой службы. Это для полного использования ресурсов. Кроме того, он также может добиться быстрой интеграции. Я повторно интегрирую это Когда служба используется, это не повлияет на другие службы, то есть развязку. Но это не значит, что микросервисы идеальны, управляйте и эксплуатируйте микросервисы По сравнению с прошлым он стал немного сложнее, поэтому популярны Docker и K8.

Подводя итог, обсуждаемые здесь микросервисы относятся к микросервисной архитектуре, Грубо говоря, мы можем понять микросервисную архитектуру таким образом, Программные модули разделены в соответствии с бизнесом, каждый модуль работает независимо, и каждый модуль сам по себе является мономером.

Распределено и снова сгруппировано

«Распределенная система — это совокупность нескольких независимых компьютеров, которые представляются пользователям как единая связанная система». Принципы и парадигмы распределенных систем Распределенная система — это система, образованная группой компьютеров, которые взаимодействуют друг с другом через сеть и координируют свое поведение. Компоненты взаимодействуют друг с другом для достижения общей цели. "Википедия"

существует«Давайте поговорим об архитектуре программного обеспечения»В этой статье я обсудил распределение и кластеризацию, но этого недостаточно, потому что технологии постоянно развиваются, а использование ресурсов постоянно улучшается. Вышеупомянутый дистрибутив делает упор на группу компьютеров. Да, нельзя класть все яйца в одну корзину. Раньше я думал, что если бы у меня был компьютер с обильными ресурсами и я использовал Docker для завершения развертывания, считалось бы это дистрибутивом? Это не может быть засчитано, потому что, что, если этот компьютер по какой-то причине не может предоставлять услуги? Если представить себе процесс как яйцо, то компьютер — это корзина с яйцами, а потом корзина разобьется. Я думаю, распределенные должны подчеркивать, что группа компьютеров должна подчеркивать эту возможность аварийного восстановления и стремиться минимизировать потери.

Так как же наша система может нормально предоставлять услуги после того, как сервер больше не может предоставлять услуги в случае распределенной системы? Как будто компьютер не сломался? То есть кластер, то есть одна и та же программа находит несколько серверов и разворачивает их несколько раз. Один сломан, другой у меня. Если вы все сломаны? Не должен быть таким отсталым.

в заключении:

  • Если несколько программ развернуты на нескольких разных компьютерах и взаимодействуют друг с другом через сеть для окончательного выполнения услуги, то систему, состоящую из этих программ, можно назвать распределенной системой.
  • Если одна и та же программа развертывается несколько раз на локальном компьютере, это очень легко сделать с помощью Docker, который называется централизованным кластером.
  • Если он развернут несколько раз на разных компьютерах, мы можем назвать его распределенным кластером.

Все они представляют собой кластеры, которые увеличивают объем доступа к программам.По сравнению с централизованными кластерами, распределенные кластеры имеют еще одну возможность обеспечения устойчивости к сбоям, но они также создают новые проблемы. Это теорема CAP, которую мы обсудим ниже.

Что нужно знать о теореме CAP

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

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

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

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

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

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

Из приведенного выше обсуждения мы можем сделать вывод, что CAP не может иметь оба, мы можем выбрать только два, мы можем выбрать CP и AP. Но учтите, что если вам нужен AP, а не C, мы можем ослабить требования к согласованности.

В приведенном выше обсуждении C — это строгая согласованность, то есть данные каждого узла являются последней версией, мы можем ослабить требования к согласованности, то есть перейти на более раннюю версию, и существуют разные уровни согласованности:

  • Слабая согласованность: данные каждого узла могут быть не последней версии.
  • Окончательная непротиворечивость: ослабьте временные требования.По истечении определенного периода времени все данные каждого узла будут обновлены.

Пример: операция записи не ожидает завершения записи всеми узлами перед возвратом ответа, а ждет некоторое время для завершения синхронизации каждого узла.

Требования к доступности. Чтобы система удовлетворяла требованиям доступности, каждый исправный узел должен отвечать на каждый запрос. Когда мы обычно измеряем доступность системы, она рассчитывается по времени простоя:

Ссылки на записи блога:

Spring Cloud и Spring Boot

Выше мы упоминали микросервисную архитектуру, разделяя программные модули в соответствии с бизнесом, мы используем Spring boot для создания сервисов и используем Spring Cloud для управления сервисами. Что означает это управление? Давайте подумаем о проблемах, возникающих после того, как программное обеспечение разделено на модули, и каждый модуль работает независимо:

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

Разработка Spring Boot Трилогия Spring Cloud

Позиционирование Spring Boot

Прежде чем я добавил несколько групп, потому что я искал информацию, я видел, как некоторые люди спрашивали, как сейчас изучать технологию среды Spring.Некоторые люди просто говорили: не изучайте Spring, Spring MVC и начинайте учиться непосредственно из Spring Boot. , Говоря, что Spring Spring MVC отстал. Здесь мы позаботимся о взаимосвязи между загрузкой Spring и Spring MVC Spring.

Т.к. у нас много настроек при разработке Spring и SpringMVC, и те, кто делал интеграцию с SSM понимают (SSM относится к Spring, SpringMVC, MyBatis), то в какой-то степени можно думать, что эти конфигурации фиксированные, т.е. кто класс, то общая идея Spring Boot заключается в том, что я могу помочь вам настроить все эти конфигурации, чтобы ускорить вашу разработку. Кроме того, не сложнее ли иметь дело с версией между некоторыми ключевыми зависимостями? Spring Boot сочетает в себе некоторые фиксированные зависимости, то есть стартер, что еще больше ускоряет разработку.

Но нижним слоем Spring Boot по-прежнему является Spring, SpringMVC. Нет вопроса о том, кто более продвинут, чем другой, но с Spring Boot быстрее разрабатывать. Spring Boot - это немного большая тема. Из-за нехватки места я не буду здесь слишком много рассказывать. и проверьте информацию.

Связь между Spring Boot и Spring Cloud

Компоненты серии Spring Cloud созданы с помощью загрузки Spring, поэтому их разработка также выполняется быстро. Но как только вы совершите ошибку, если у вас нет глубокого понимания Spring MVC, вы будете сбиты с толку.

Spring Boot также является огромным проектом, который содержит множество стартеров (если вы не понимаете эти стартеры, вы можете сделать свою домашнюю работу, и вы все еще можете понять, если не понимаете следующее) Spring Cloud — это огромный проект с различными компонентами, включенными ниже. Поэтому мы обычно управляем версиями Spring Boot и Spring Cloud единым образом в родительском проекте.

Общие операции для разработки Spring Boot

  • Чтобы ввести зависимости, мы обычно используем maven для этого.
  • написать файл конфигурации
  • Аннотировать класс запуска

Компоненты Spring Cloud, представленные в этой статье

Вот семейная серия Spring Cloud Netflix:

  • Eureka Registry Director Service Discovery and Mutual Calling
  • Притвориться удаленным абонентом
  • Балансировщик нагрузки ленты
  • Зуул шлюз
  • конфиг центр конфигурации
  • Предохранители Hystrix

Реестр Эврика

Если теперь у меня есть три службы A, B и C, то я хочу в это время вызвать службу B. Должен ли я вызывать B напрямую через явный URL-адрес? Конечно, нет, мы действительно можем найти соответствующие идеи дизайна в сетевой связи, представьте себе телефон в прошлом, предполагая, что А хочет позвонить Б, это не телефонная линия от дома А к дому Б, предполагая, что А имеет больше друзей, телефонная линия дома А не может быть установлена.Это только связь между двумя компаниями.Предполагая, что мы продолжаем вводить новых пользователей, эта идея прямого подключения телефонной линии между пользователями, которым необходимо общаться с друг друга скоро сделают наши. Проводка становится неуправляемой, вот так:

В один прекрасный день D переехал, и эта линия должна была следовать за D в любое время. Стоимость миграции была слишком высока.По сути, когда мы соединили телефонную линию и сетевой кабель, нам пришлось ввести сетевой кабель из собственного дома и подключите его к сети оператора телекоммуникаций.Их будет несколько.На среднем уровне связь реализуется через эти средние уровни, и вызов службы также является соответствующей идеей дизайна.Сервис А напрямую вызывает сервис Б через явный URL (IP+ порт + имя интерфейса: 192.168.3.1:8080/купить/), который день B Измените адрес службы, и ваша служба A также последует.Это одно из применений регистрационного центра:

Это использование центра регистрации Eureka. Имя службы хранится в центре регистрации. Зарегистрированная служба может получить имя службы других служб через Eureka и выполнить удаленный вызов через имя службы, чтобы служба не нужно изменить его IP. Имейте в виду, просто оставьте свое имя прежним. Эврика делится на сервер и клиент.Реестр является сервером, а клиент должен предоставлять услуги реестру. Создание микросервисов с помощью Spring Cloud и Spring Boot очень просто и обычно состоит из трех шагов:

  <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>
    </dependencies>
  • написать файл конфигурации
server:
  port: 9991
eureka:
  client:
    service-url:
      defaultZone: http://localhost:${server.port}/eureka/
    register-with-eureka: false 
    fetch-registry: false

defaultZone — адрес центра регистрации, позволяет ли register-with-eureka Eureka зарегистрироваться. fetch-registry Получает ли Eureka адреса других сервисов самостоятельно.

  • Отметьте соответствующую аннотацию в классе запуска.
EnableEurekaServer // 该注解标识该服务是服务注册中心。
SpringBootApplication
public class MicroEureka {
    public static void main(String[] args) {
        SpringApplication.run(MicroEureka.class,args);
    }
}

Когда мы рассматриваем реестр как оператора связи, мы получаем другие варианты использования реестра:

  • Регистрация службы: Это эквивалентно открытию учетной записи.Поставщиком службы является служба, вызываемая другими службами.Когда она запускается, она регистрируется в реестре, отправляя запрос на отдых, и несет некоторую собственную информацию метаданных ( например, имя службы, порт).

  • Обновление услуг: это эквивалентно оплату законопроекта. Телефонный счет практически исчерпан. Оператор Telecom призванит вас оплатить счет. Если вы не оплатите счет, ваш телефон будет выключен. То есть после того, как служба зарегистрирована, поставщик услуг будет поддерживать сердцебиение для продолжения скоростного реестра, и я все еще жив.

  • Сервис не в сети: Номер продажи, когда сервис нормально закрывается, он отправляет REST запрос в реестр на Eureka Server, сообщите в сервисный центр, я не использую этот номер.

  • Получить услугу и вызов службы: это эквивалентно совершению телефонного звонка.Потребители услуг могут получить список зарегистрированных услуг через реестр, а затем использовать имена экземпляров услуг в этих списках для совершения удаленных вызовов через Feign и Ribbon.

  • Fail-to-fail: то есть отключение, если вы не платите в течение определенного периода времени, оператор связи отключит вас, если вы продолжите работать по умолчанию. По умолчанию каждый период времени (по умолчанию 60 секунд) будет удалять службы, которые не обновились после тайм-аута (по умолчанию 90 секунд) из текущего списка.

  • Механизм самозащиты: Реестр настолько важен, я точно не могу развернуть только один, а вдруг он рухнет, поэтому приходится разрабатывать распределенный кластер. Но мы знаем, что раз речь идет о распределении, мы должны выбирать.Эврика выбирает ТД, а отказоустойчивость раздела должна существовать, потому что никогда нельзя гарантировать, что сеть абсолютно надежна, а А — это доступность, а это значит, что Эврика не может быть строго согласованной. Чтобы гарантировать A, Eureka вводит механизм самозащиты. Режим самозащиты — это мера защиты от аномальных колебаний сети. Использование режима самозащиты может сделать кластер Eureka более надежным и стабильным.

  • Механизм самозащиты означает, что если более 85% узлов не имеют нормального пульса в течение 15 минут, то Эврика считает, что произошел сбой сети между узлами и центром регистрации. -механизм защиты, и может произойти следующее: Несколько ситуаций:

    • Eureka Server больше не удаляет службы, срок действия которых истекает из-за отсутствия пульса в течение длительного времени, из списка регистрации, ожидая возвращения сети в стабильное состояние.
    • Eureka Server по-прежнему может принимать запросы на регистрацию и запросы для новых служб, но не будет синхронизироваться с другими узлами, чтобы гарантировать, что текущий узел по-прежнему доступен.
    • Когда сеть вернется в стабильное состояние, новая регистрационная информация будет синхронизирована с другими узлами.

Так же, как телекоммуникационная сеть, вы не можете просто подключиться к телекоммуникационной сети, вам также нужен инструмент связи, телефон или компьютер, чтобы общаться с другими, тогда звонки между сервисами Feign и Ribbon.

Материалы, на которые ссылается реестр Eureka:

Удаленный вызов Feign и Ribbon

feign завершает взаимные вызовы между службами

Согласно нормальной работе Spring Boot мы сначала вводим зависимости:

	<dependency>
             <groupId>org.springframework.cloud</groupId>
             <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
         </dependency>
         <dependency>
             <groupId>org.springframework.cloud</groupId>
             <artifactId>spring-cloud-starter-openfeign</artifactId>
         </dependency>
            <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
        </dependency>

Затем напишите соответствующую конфигурацию, как указано выше:

Spring:
  application:
    name: cityclient
server:
  port: 8081
eureka:
  client:
    service-url:
      defaultZone: http://localhost:9991/eureka/

Отметьте соответствующую аннотацию в классе запуска:

SpringBootApplication
// 该服务是Eureka的客户端，仅限于Eureka
@EnableEurekaClient
// 注册中心有许多替代品，该注解无缝适应其他注册中心
@EnableDiscoveryClient
// 表明此服务要进行远程调用
@EnableFeignClients
public class MicroEurekaClient {
    public static void main(String[] args) {
        SpringApplication.run(MicroEurekaClient.class,args);
    }
}

Как мне звонить другим службам, в этом примере я буду звонить в городскую службу:

@FeignClient(value = "city") // 服务名
public interface CityClient {
	// 对应的url
    @GetMapping("cityTest")
     String select();
}

Затем введите его в соответствующий слой управления.

Лента завершает взаимные звонки между сервисами

Лента завершает взаимный вызов сервисов через RestTemplate.Сначала мы должны загрузить RestTemplate в IOC-контейнер. Затем вызовите его в соответствующем контроллере:

   @Autowired
    private RestTemplate restTemplate;
    @GetMapping("testRibbon")
    public void  testRibbon(){
        String result = restTemplate.getForObject("http://city/cityTest", String.class);
        System.out.println(result);
    }

Лента балансировки нагрузки

Запросы, обрабатываемые одной службой, действительны. Чтобы справиться с дополнительными запросами, мы можем задействовать кластер, то есть я запущу другой сервис для того же сервиса. В настоящее время есть два из тот же сервис.Когда приходит запрос, он должен быть Какой сервис должен обрабатывать запрос?Это алгоритм балансировки нагрузки и балансировщик нагрузки. Существует два типа балансировки нагрузки:

  • Лента балансировки нагрузки клиента Список услуг находится в Eureka, а клиент получает список от Eureka.При инициации вызова Ribbon решает, какую службу вызывать в соответствии с алгоритмом балансировки нагрузки.
  • Балансировка нагрузки сервера (Nginx) Есть два экземпляра одного и того же сервиса, и Nginx решает, какой сервис выполнить этот запрос.

Знакомство с несколькими часто используемыми алгоритмами балансировки нагрузки:

  • Метод Round Robin назначается по очереди в порядке запросов, проще говоря, это можно понимать как очередность.
  • Случайный метод Для ответа на запрос случайным образом выбирается удачливый сервис.
  • Взвешенный опрос Назначьте веса каждой службе и настройте высокий приоритет для ответа на запросы.

Лента по умолчанию использует алгоритм опроса, который можно очень просто настроить и реализовать: унаследовать класс AbstractLoadBalancerRule и переписать метод выбора.

Автоматический выключатель Hystrix

После того, как мы решим вызов службы и балансировку нагрузки, вскоре появятся новые проблемы При взаимном вызове между службами, что мне делать, если служба по какой-то причине недоступна или время отклика слишком велико?

Например, во время Double Eleven продолжают ли пользователи ждать результатов скупки или возвращают аннулирование, если им не удается схватиться в течение определенного периода времени? Люди устали ждать. Я думаю, у вас уже есть ответ, который должен вернуть результат с ошибкой. Это может улучшить пользовательский опыт. Вот что делает предохранитель Hystrix,

Как совместить с Feign?Мы обычно используем Feign для выполнения сервисных вызовов,

// value 指定调用哪个服务
// fallback 指定由哪个类返回快速失败结果    
@FeignClient(value = "city", fallback = CityClientImpl.class) //
public interface CityClient {
	  // 客户端的地址
    @GetMapping("cityTest")
     String select();
}

@Component
public class CityClientImpl implements CityClient {
    @Override
    public String select() {
        return "调用失败";
    }
}

Панель управления Hystrix

Приборная панель Hystrix, как и приборная панель автомобиля, отображает рабочее состояние Hystrix в режиме реального времени.Через приборную панель Hystrix мы можем видеть различные индикаторы Hystrix, чтобы быстро находить проблемы в системе.

Страница при запуске:

Страницы после: )

шлюз маршрутизации zuul

Теперь структура нашей системы в основном обрела форму со следующей структурой:Но наша система по-прежнему имеет следующие проблемы:

  • URL-адреса, предоставляемые сервером извне, являются реальными, и посторонние используют эти URL-адреса для запуска атак. Чтобы защитить безопасность услуги, мы можем быть похожими на Диди, номер телефона клиента, полученный водителем после получения заказа, является виртуальным для защиты безопасности клиента, и URL-адрес, который мы раскрываем снаружи, также может быть виртуальным. .
  • Проверка безопасности и избыточность проверки входа: для обеспечения безопасности системы каждый модуль микрослужбы будет выполнять определенные проверки, но микрослужба независима, и мы должны выполнить набор проверок в каждом модуле микрослужбы. Очевидно, что это лишнее.
  • Серьезная связь между экземплярами службы и балансировкой нагрузки: внешний балансировщик нагрузки Nginx должен поддерживать список всех служб, то есть ip + порт + имя службы. В один прекрасный день мой IP и сервисное подразделение меняются, мне нужно пойти в Nginx, чтобы изменить его.

Это приводит к API Gateway:, который решает вышеуказанные проблемы. Шлюз обеспечивает:

  • Маскировка URL-адресов, виртуальный URL-адрес отображается снаружи, и шлюз сопоставляет виртуальный URL-адрес с реальным.
  • Унифицированная проверка для уменьшения избыточности проверки
  • Связь между экземплярами службы и балансировкой нагрузки эквивалентна добавлению промежуточного слоя к экземплярам службы и Nginx, а Nginx не имеет прямого доступа к экземплярам.

Одним словом, Zuul также умеет балансировать нагрузку, так что вы хотите Nginx? Шлюз также должен быть кластеризован и сбалансирован по нагрузке, поэтому Nginx можно использовать с zuul.

С этим слоем наша архитектура становится такой:

Конфигурация центра конфигурации Spring Cloud

До сих пор наша архитектура стремилась к совершенству, но все же есть небольшое несовершенство.Архитектура микросервисов разбивает наше программное обеспечение на сервисы один за другим.Каждый сервис имеет соответствующий файл конфигурации.Когда сервисов больше, файл конфигурации будет Он становится трудно управлять, потому что он разбросан по различным сервисам, и эти файлы конфигурации имеют общие черты, поэтому у нас, естественно, будет такой спрос, можем ли мы управлять файлами конфигурации микросервисов унифицированным образом? Это цель центра конфигурации, Spring Cloud предоставляет нам компонент конфигурации, который является центром конфигурации.

Идея центра конфигурации компонента config заключается в следующем: файлы конфигурации централизованы в репозитории сайтов, размещающих код, таких как github и gitee, и центр конфигурации напрямую подключен к этому репозиторию.Каждый сервис задает конфигурацию center и имя файла конфигурации в файле конфигурации.То есть запрашивайте ресурсы из файла конфигурации, а затем центр конфигурации отправляет соответствующий файл в соответствующую службу.

Суммировать

Пока конкуренция между компонентами Spring Cloud очень ожесточенная.В реестре есть Eureka и nacos, а также есть шлюз от Spring Cloud. Но идея не изменилась, просто разделите модули и усвойте идею.

Использованная литература:

Категории