Микросервисная архитектура — очень популярная концепция в настоящее время, она не создается из воздуха, а является неизбежным результатом развития технологий. Хотя общепризнанных технических стандартов и предварительных спецификаций для микросервисной архитектуры не существует, в отрасли уже существует несколько влиятельных платформ микросервисной архитектуры с открытым исходным кодом.Архитекторы могут выбрать подходящий микросервис в соответствии с технической мощью компании и характеристиками проекта. безопасно реализовать преобразование микросервиса или процесс разработки проекта.
В этой статье перечислены четыре часто используемых решения для микросервисной архитектуры, а именно: ZeroC IceGrid, Spring Cloud, на основе очереди сообщений и Docker Swarm.
Микросервисная архитектура ZeroC IceGrid
Как микросервисная архитектура, ZeroC IceGrid разработан на основе RPC-фреймворка и обладает хорошей производительностью и распределенными возможностями.Ниже приведена его общая схематическая диаграмма.
IceGrid обладает следующими отличительными характеристиками архитектуры микросервисов.
Во-первых, архитектура микросервисов требует централизованного реестра сервисов, а также какого-то механизма обнаружения сервисов. Регистрация сервиса IceGrid определяется XML-файлами, а его реестром сервисов является Ice Registry, который является независимым процессом и обеспечивает механизм высокой доступности для HA; соответствующий механизм обнаружения сервисов — это именованный сервис запросов, то есть API, предоставляемый LocatorService Имя службы используется для запроса доступного адреса соответствующего экземпляра службы.
Во-вторых, каждый микросервис в микросервисной архитектуре обычно развертывается как независимый процесс, а когда используются сервисы без сохранения состояния, сервисы обычно предоставляются несколькими независимыми процессами. Соответственно, в IceGrid IceBox — это отдельный процесс, когда IceBox инкапсулирует только один Servant — это типичный микросервисный процесс.
Затем в микросервисную архитектуру обычно необходимо встроить какой-либо механизм балансировки нагрузки. В IceGrid это реализовано через встроенный в клиентский API алгоритм балансировки нагрузки.По сравнению со способом переадресации трафика через middleware Proxy, подход IceGrid более эффективен, но увеличивает нагрузку и сложность разработки платформы, т.к. Все клиенты должны реализовать логику алгоритма балансировки нагрузки.
Наконец, хорошая платформа с микросервисной архитектурой должна упрощать и облегчать развертывание приложений. Мы видим, что IceGrid предоставляет grid.xml для описания и определения Приложения на основе микросервисной архитектуры, инструмент командной строки для развертывания этого Приложения одним щелчком мыши и вспомогательный инструмент для публикации бинарных программ — icepatch2. На следующем рисунке показан рабочий механизм icepatch2. icepatch2server подобен FTP-серверу и используется для хранения двоичного кода и файлов конфигурации, которые будут опубликованы на каждом узле, в то время как icepatch2client, расположенный на каждом узле, извлекает файлы из icepatch2server.Во время этого процесса расширенные функции, такие как поскольку сжатая передача и дифференциальная передача используются для уменьшения ненужной передачи файлов. Чтобы объективно оценить, до технологии Docker icepatch2 все еще был очень продвинутым и полным, а также значительно снижал рабочую нагрузку по эксплуатации и обслуживанию микросервисных систем в распределенных кластерах.
Если система разрабатывается на основе IceGrid, обычно есть три типовых технических решения, и на следующем рисунке показаны эти три технических решения.
Первая схема представляет собой схему постепенного преобразования, которая больше соответствует традиционным веб-проектам Java.В Spring Boot есть только компоненты контроллера, но нет слоя доступа к данным и объектов службы.Эти компоненты контроллера вызывают удаленные микросервисы Ice, развернутые в IceGrid через Ice RPC. ., упакованный как служба REST для внешнего интерфейса. Общая идея этой программы ясна и разделение труда понятно. Лидер дает базовую основу этого подхода в проекте с открытым исходным кодом для справки:GitHub.com/my cat APA tide. ….
Вариант 2 и вариант 3 больше подходят для команд с сильными возможностями JavaScript переднего плана.Например, команды, которые очень хорошо разбираются в Node.js, могут рассмотреть вариант 2, который заключается в использовании JavaScript вместо Spring Boot для реализации служб REST. Для систем, которые в основном используются для интернет-приложений, можно рассмотреть третий вариант: JavaScript на стороне браузера напрямую взаимодействует с Ice Glacier2 с помощью технологии HTML5 WebSocket, которая в целом эффективна и гибка.
IceGrid также добавил контейнерный режим работы после версии 3.6, то есть Ice Node и Ice Registry можно запускать через Docker-контейнеры, что упрощает развертывание IceGrid на Linux. Для системы микросервисной архитектуры Ice, написанной на Java, мы также можем использовать механизм загрузки удаленного класса Java, чтобы позволить каждому узлу автоматически загружать указанный пакет Jar с удаленного HTTP-сервера и загружать соответствующий класс Servant, чтобы получить аналогичный Docker Hub. .механизм. На следующем рисунке показана конкретная схема реализации, данная при упоминании ранее проекта с открытым исходным кодом mycat-ice.
Микросервисная архитектура Spring Cloud
Spring Cloud — это набор фреймворков для реализации микросервисов на основе Spring Boot, поэтому он может использовать только язык Java, что является наиболее очевидным отличием его от нескольких других фреймворков для микросервисов. Spring Cloud — это комплексное решение, включающее в себя множество подпроектов, среди которых Spring Cloud Netflix, разработанный Netflix и позже включенный в Spring Cloud, является основным проектом микросервисной архитектуры Spring Cloud, то есть его можно просто считать что микросервисная архитектура Spring Cloud — это Spring Cloud Netflix, когда мы будем использовать Spring Cloud позже, если мы не заявим это специально, это означает Spring Облачный Нетфликс.
Прежде всего, реестр служб в Spring Cloud — это модуль Eureka, который предоставляет реестр служб, клиент обнаружения служб и простой интерфейс управления.Все службы используют клиент обнаружения служб Eureka для регистрации в Eureka, показана соответствующая схема ниже, и вы заметите, что она очень похожа на одну из предыдущих диаграмм в главе 4.
Так как же Spring Cloud решает проблему балансировки нагрузки на сервисы? Поскольку интерфейс микросервиса Spring Cloud в основном реализован на основе протокола REST, он использует традиционный механизм HTTP-прокси. Как показано на рисунке ниже, Zuul похож на сервисный шлюз Nginx, и все клиентские запросы проходят через этот шлюз для доступа к фоновым службам.
Zuul получает служебную информацию от Eureka и автоматически завершает сопоставление правил маршрутизации без ручной настройки.Например, путь URL-адреса /customer/* на приведенном выше рисунке сопоставляется с микрослужбой Customer. Когда Zuul перенаправляет запрос в указанную микрослужбу, он использует механизм балансировки клиентской нагрузки, аналогичный ZeroC IceGrid, который называется компонентом Ribbon.На следующем рисунке показана взаимосвязь между Zuul и Eureka, а также схематическая диаграмма балансировки нагрузки службы.
Ниже представлена панорама платформы микросервисной архитектуры Spring Cloud. Мы видим, что он явно наследует непротиворечивую идею Spring Framework-интеграции!
Как видно из рисунка, платформа микросервисной архитектуры Spring Cloud объединяет следующие технологии и функциональные модули, которые обычно используются при разработке реальных проектов.
Основанный на модуле OAuth Spring Security, он решает проблемы безопасности службы.
Возможность предоставления комплексных услуг.
Автоматический выключатель Hystrix, который реализует функцию защиты предохранителей для некоторых ключевых сервисных интерфейсов.Если служба не отвечает (например, тайм-аут или сбой сетевого подключения), Hystrix может перенаправить запрос на резервный метод в потребителе службы. Если служба постоянно дает сбой, Hystrix быстро выйдет из строя (например, путем прямого вызова внутреннего резервного метода без повторного вызова службы), пока служба не вернется в нормальное состояние.
Панель мониторинга может упростить рабочую нагрузку разработки, связанную с эксплуатацией и обслуживанием.
В целом Spring Cloud является хорошей альтернативой Dubbo, хотя Spring Cloud представляет собой микросервисную архитектуру, основанную на интерфейсе связи REST, а Dubbo основан на связи RPC. Для интернет-бизнес-платформы Java, не требующей очень высокой производительности, использование Spring Cloud является относительно низкопороговым решением.
Микросервисная архитектура на основе очереди сообщений
В дополнение к стандартной микросервисной архитектуре, основанной на RPC-коммуникациях (и RPC-подобных RPC-коммуникациях, таких как Http Rest, SOAP и т. д.), существует также микросервисная архитектура, основанная на коммуникации с очередью сообщений. ) реализовать взаимодействие между собой. На следующем рисунке представлена схема взаимодействия между различными компонентами в рамках этой микросервисной архитектуры.Мы видим, что промежуточное программное обеспечение сообщений является ключевым.Он отвечает за соединение различных микросервисов и компонентов пользовательского интерфейса и играет важную роль взаимосвязи всей системы.
Архитектура микросервиса на основе очереди сообщений представляет собой конструкцию полностью асинхронного режима связи. Между компонентами нет прямой взаимосвязи, и нет таких вещей, как интерфейс службы и вызов службы. Службы взаимодействуют друг с другом и с бизнесом посредством сообщений. С этой точки зрения микросервисная архитектура на основе очереди сообщений очень близка к модели акторов. На самом деле, модель распределенного актора также можно считать микросервисной архитектурой, и она существовала задолго до концепции микросервисов. Ниже приведена схема микросервисного дизайна торгового веб-сайта.Мы видим, что он использует микросервисную архитектуру на основе очереди сообщений.
Сотовая платформа NetEase использует идею архитектуры микросервисов, основанную на очереди сообщений.Как показано на рисунке ниже, микросервисы передают сообщения через RabbitMQ для реализации связи.
По сравнению с вышеперечисленными микросервисными архитектурами, микросервисных архитектур, основанных на очередях сообщений, не так много, и случаев относительно мало. дизайнерские идеи и эталонные архитектуры, а известная платформа с открытым исходным кодом не сформирована. Поэтому, если эта микросервисная архитектура должна быть реализована, проектная группа в основном должна спроектировать и внедрить базовую платформу микросервисной архитектуры с нуля. Стоимость высока и высок риск. Поэтому архитектор должен быть «заземлен», прежде чем делать решение Комплексное мышление и объективная оценка.
Микросервисная архитектура Docker Swarm
Docker Swarm на самом деле является продуктом платформы микросервисной архитектуры Kubernetes с открытым исходным кодом Docker, «имитирующей» Google, но она не могла идти в ногу со своими противниками и всегда не имела влияния в отрасли. Когда в 2016 году был выпущен Docker 1.12, Docker Swarm был принудительно интегрирован в Docker Engine и больше не выпускался как отдельный инструмент, как это сделала Microsoft для продвижения Internet Explorer. Но даже при этом сложно скрыть тот факт, что Docker Swarm пал до того, как прославился.
Первоначальная цель Docker Swarm — превратить некоторые отдельные хосты Docker в кластер, как показано на рисунке ниже. Мы можем создать кластер Swarm с помощью простого инструмента командной строки Docker.
Позже, по мере того, как платформа микросервисной архитектуры Kubernetes становилась все более популярной, Docker начал усердно работать над тем, чтобы Swarm приблизился к направлению Kubernetes, то есть стал микросервисной платформой, основанной на технологии контейнеров. Структурная схема кластера Swarm приведена ниже.
Из диаграммы мы видим, что в кластере Swarm есть две роли узлов.
Swarm Manager: отвечает за управление кластером, поддержание состояния кластера и планирование задач (Task) для рабочих узлов (Swarm Node) и т. д.
Узел Swarm: размещает экземпляры контейнера, работающие в кластере Swarm, и каждый узел активно сообщает о запущенных на нем задачах и поддерживает состояние синхронизации.
Docker Compose на приведенном выше рисунке — это официальный проект Orchestration, который предоставляет файл формата YAML для описания контейнеризованного распределенного приложения и предоставляет соответствующие инструменты для реализации функции развертывания одним щелчком мыши. На следующем рисунке показано соответствующее определение файла YAML для двухузлового кластера Couchbase, который затем развертывается на двух узлах Node в кластере Swarm.
Обратите внимание на определение службы в файле YAML в левой части рисунка выше.Узел диспетчера Swarm присваивает каждой службе уникальное DNS-имя, поэтому обнаружение службы и балансировка нагрузки могут быть достигнуты с помощью самого старого и простейшего механизма опроса DNS. который явно заимствован из Kubernetes. Поскольку Docker Swarm во многом имитирует дизайн своего предшественника Kubernetes и не имеет большого влияния на архитектуру микросервисов, мы не будем подробно описывать его здесь.