Микросервисы: Микросервисы развивались на основе идеи «разделяй и властвуй». В прошлом традиционная крупномасштабная и всеобъемлющая система с трудом удовлетворяла рыночный спрос на технологии с развитием Интернета, поэтому мы перешли от отдельной архитектуры к распределенной архитектуре, а затем от распределенной архитектуры к Архитектура SOA.После разделения и декомпозиции степень детализации становится все меньше и меньше, пока не родилась микросервисная архитектура.
Микросервисная архитектура — это архитектурный шаблон, который выступает за разделение одного приложения на набор небольших служб, которые координируют и взаимодействуют друг с другом, чтобы обеспечить максимальную ценность для пользователей.
Каждая служба работает в своем собственном процессе, и службы взаимодействуют друг с другом с помощью упрощенного механизма связи (обычно это RESTful API на основе HTTP). Каждая услуга строится вокруг определенного бизнеса и может быть независимо развернута в производственной среде, среде, подобной производственной, и т. д. Кроме того, следует по возможности избегать унифицированного и централизованного механизма управления услугами.Для конкретного сервиса следует выбирать соответствующие языки и инструменты для его построения в соответствии с бизнес-контекстом.
На сегодняшний день на рынке распространены следующие платформы микросервисов: Spring Cloud и Dubbo.
Обнаружение регистрации службы
Обнаружение регистрации службы: Регистрация службы предназначена для ведения реестра, а регистрация службы — для ведения реестра, который управляет всеми адресами службы в системе. Когда новая служба запускается, она передает информацию о своем адресе в реестр. Доверяющая сторона службы может напрямую запросить у реестра адрес поставщика услуг. В настоящее время существует множество инструментов для регистрации сервисов, таких как ZooKeeper, Consul, Etcd и eureka от Netflix. Существует две формы регистрации службы: регистрация клиента и регистрация третьей стороны.
Регистрация службы (зоозащитник)
Регистрация службы — это работа, за регистрацию и отмену которой отвечает сама служба. Когда служба запускается, она регистрируется в реестре, а когда служба отключается, она отменяет регистрацию. В этот период также необходимо поддерживать пульсацию с реестром. Сердцебиение не обязательно должно выполняться клиентом, но также может выполняться реестром (этот процесс называется зондированием). Недостаток этого метода в том, что работа по регистрации связана с обслуживанием, и разные языки должны реализовывать набор логики регистрации.
обнаружение службы
Когда вызывающая служба вызывает службу, она может перейти в центр регистрации и обнаружения служб, чтобы получить доступные службы через имя службы.Центр обнаружения служб получает все доступные службы из списка служб в памяти, а затем балансировщик нагрузки выбирает сервис по установленным правилам.Возвращает ip-порт HTTP-сервиса вызывающему абоненту.Если это сервис grpc, получает подключение сервиса из пула подключений и возвращает его вызывающему абоненту.
Шлюз API
Шлюз API: API Gateway — это сервер и единственный вход в систему. С точки зрения объектно-ориентированного проектирования он похож на шаблон Facade. Шлюз API инкапсулирует внутреннюю архитектуру системы и предоставляет настраиваемый API для каждого клиента. У него также могут быть другие обязанности, такие как аутентификация, мониторинг, балансировка нагрузки, кэширование, фрагментация запросов и управление ими, а также обработка статических ответов.
Шлюз API отвечает за пересылку запросов, композицию и преобразование протоколов.. Все запросы от клиентов проходят через шлюз API, который направляет эти запросы в соответствующие микросервисы. Шлюз API часто обрабатывает запрос и объединяет результаты нескольких служб, вызывая несколько микрослужб. Он может конвертировать между веб-протоколами и внутренними протоколами, не дружественными к Интернету, такими как протокол HTTP, протокол WebSocket.
Суть подхода шлюза API заключается в том, что все клиенты и потребители получают доступ к микросервисам через единый шлюз и обрабатывают все некоммерческие функции на уровне шлюза. Обычно шлюз также предоставляет API доступа REST/HTTP. Сервер регистрирует службы и управляет ими через API-GW.
запрос на переадресацию
Переадресация услуг в основномЗапросы к клиенту устанавливают нагрузку микросервисаперенаправлены в другую службу.
Консолидировать соответственно
ПучокБизнесу необходимо вызывать несколько сервисных интерфейсовРабота, которую можно только выполнить, объединяется в единый вызов для предоставления унифицированных услуг внешнему миру.
Преобразование протокола
Суть в том, чтобы поддерживатьSOAP,JMSНапримерRestпреобразование протокола между.
конверсия данных
Суть в том, чтобы поддерживатьXMLиJsonВозможности преобразования формата сообщения между (необязательно).
сертификат безопасности
• Управление клиентским доступом и политика безопасности на основе токенов • Для шифрования передаваемых данных и сообщений и расшифровки на сервер требуется независимый прокси-пакет SDK на стороне клиента • Шифрование передачи на основе HTTPS, поддержка цифровых сертификатов клиента и сервера • Аутентификация безопасности службы на основе OAuth2.0 (код авторизации, клиент, режим пароля и т. д.).
Центр конфигурации
Центр конфигурации: Конфигурационный центр обычно используется для настройки параметров системы и должен отвечать следующим требованиям: эффективный сбор данных, восприятие в реальном времени и распределенный доступ.
Центр конфигурации зоофилара
Схема реализованной архитектуры показана ниже.Данные загружаются в память для решения задачи эффективного сбора, а восприятие в реальном времени реализуется с помощью механизма мониторинга узла zookeeper.
Настройка центральной классификации данных
Планирование событий (кафка)
Унифицированное планирование служб сообщений и событий, часто используемые kafka, activemq и т. д.
Сервисное отслеживание (стартер-сыщик)
Поскольку количество микросервисов продолжает расти, необходимо отслеживать процесс распространения запроса от одного микросервиса к другому, и Spring Cloud Sleuth решает эту проблему.Он представляет уникальный идентификатор в журнале, чтобы обеспечить согласованность между вызовами микрослужб, чтобы вы могли отслеживать, как запрос передается от одной микрослужбы к другой.
• Чтобы обеспечить отслеживание запросов, когда запрос отправляется в конечную точку входа в распределенную систему, необходимо, чтобы платформа отслеживания услуг создала для запроса уникальный идентификатор отслеживания. распределенная система, фреймворк всегда передает уникальный идентификатор. , пока не будет возвращен запрашивающей стороне,Этот уникальный идентификатор является идентификатором трассировки, упомянутым выше.. Через запись Trace ID мы можем связать все журналы обработки запросов;
• Для подсчета времени задержки каждого блока обработки, когда запрос достигает каждого компонента службы или когда логика обработки достигает определенного состояния, его начало, конкретный процесс и конец также помечаются уникальным идентификатором.Для каждого пролета он должен иметь два узла: начало и конец.Записав временные метки начального и конечного промежутка, можно подсчитать временную задержку пролета., помимо записей временных меток, может содержать и некоторые другие метаданные, такие как: название события, информация о запросе и т. д.;
• В приложениях Spring Boot путем введения в проект зависимости spring-cloudstarter-sleuth автоматически создается механизм отслеживания для каждого канала связи для текущего приложения, например:
• Запросы проходят через промежуточное ПО для обмена сообщениями, такое как RabbitMQ, Kafka (или любую другую реализацию связывателя Spring Cloud Stream). • Запросы проходят через прокси-сервер Zuul. • Запросы, инициированные через RestTemplate.
Сервисный автоматический выключатель (Hystrix)
Сервисный предохранитель: в микросервисной архитектуре обычно имеется несколько вызовов сервисного уровня. Сбой основных сервисов может привести к каскадным сбоям, что приведет к недоступности всей системы. Это явление называется эффектом сервисной лавины. Эффект лавины услуг — это процесс, при котором недоступность «поставщиков услуг» приводит к недоступности «потребителей услуг» и постепенно увеличивает недоступность.
Принцип предохранителя очень прост, как протектор питания. Он может потерпеть неудачу быстро, если он обнаружит много похожих ошибок в течение определенного периода времени,Несколько вызовов быстро удаляются, больше не доступа к удаленному серверу, предотвратите приложение, которое приложение будет продолжать выполнять операции, которые могут потерпеть неудачу., позволяя приложению продолжать выполнение, не дожидаясь исправления ошибок или тратя время процессора на ожидание длительного тайм-аута. Автоматические выключатели также могут позволить приложению диагностировать, была ли ошибка исправлена, и если это так, приложение попытается снова вызвать операцию.
Механизм автоматического выключателя Hystrix
Автоматические выключатели хорошо понимаются, когдаHystrix CommandКогда количество неудачных запросов к серверной службе превышает определенный процент (по умолчанию 50%), прерыватель цепи переключается в открытое состояние (Open).В это время все запросы не будут выполняться напрямую и не будут отправлены на серверную службу.После того, как автоматический выключатель остается в разомкнутом состоянии в течение определенного периода времени (по умолчанию 5 секунд), он автоматически переключается в полуоткрытое состояние. государство (HALF-OPEN). В это время будет определять запрос на возврат, если запрос успешно, закрытое состояние переключателя автоматического выключателя обратно (CLOSED), Или переключитесь в открытое состояние (OPEN). Автоматический выключатель Hystrix подобен предохранителю в нашей домашней цепи. Как только серверная служба становится недоступной, автоматический выключатель напрямую отключает цепочку запросов, чтобы избежать отправки большого количества недействительных запросов, влияющих на пропускную способность системы и автоматический выключатель имеет возможность обнаруживать и восстанавливать себя.
Управление API
Инструмент управления SwaggerAPI
Инструмент управления SwaggerAPI: Адрес официального сайта:swagger.ioSwagger — это программное обеспечение для автоматического создания онлайн-документов интерфейса RESTFUL + программное обеспечение для функционального тестирования.Это стандартизированная и полная структура, стандартная, независимая от языка, для создания, описания, вызова и визуализации веб-сервисов RESTful. Общая цель состоит в том, чтобы клиент и файловая система обновлялись с той же скоростью, что и сервер. Файловые методы, параметры и модели тесно интегрированы в серверный код, что позволяет постоянно синхронизировать API. Swagger упрощает развертывание управления и использование мощных API.
Последняя версия — V3, SwaggerUI Restful API — это простые инструменты для тестирования и документирования. Простой, красивый, удобный в использовании. JSON API, читая сам проект конфигурации дисплея, зависит только от некоторых статических файлов html, css.js.Вы можете использовать практически любой веб-контейнер.
Немного, ключ и три ссылки все здесь!