Введение

Архитектура микросервисов существует уже давно.Архитектура микросервисов — это метод преобразования одного приложения в набор небольших сервисов, каждый из которых работает в своем собственном процессе и использует упрощенный метод взаимодействия (например, HTTP) для связи.

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

Микросервисы и монолитные сервисы

В исходной программной системе это обычно один сервис. Для монолитных сервисов все сервисы находятся в одном процессе. Корпоративные приложения обычно состоят из трех основных частей: пользовательского интерфейса на стороне клиента (состоящего из HTML-страниц и javascript, работающего в браузере на компьютере пользователя), базы данных (состоит из базы данных, которая подключается к общему, обычно реляционному управлению базой данных). ) Многие таблицы составляют систему) и серверные приложения.

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

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

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

Как говорится, яйца в одну корзину не помещаются.

Так что разделение огромных монолитных сервисов на микросервисы — настоящий бум системной архитектуры.

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

Характеристики микросервисов

Каковы характеристики микросервисов? Какой сервис можно назвать микросервисом?

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

Например, определение кружка, которое мы выучили в школе, ясно говорит нам, что такое кружок. Для микросервисов такого определения нет.

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

служба компонентов

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

В современных программах есть много вещей, которые можно назвать компонентами, например пакеты зависимостей jar в java, пакеты зависимостей в python и т. д.

Эти библиотеки могут быть связаны с программами во время выполнения для запуска в памяти как функции.

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

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

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

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

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

подразделение организации

Согласно закону Конвея: то, как организация общается, определяет структуру системы.

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

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

связь между сервисами

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

Каковы общие методы вызова между службами?

Наиболее распространенным является вызов между протоколами HTTP/HTTPS.Преимущество этого метода в том, что протокол прост и универсален, а стоимость совместимости невысока.

Если это кросс-язык, обычно используется протокол удаленного вызова RPC, такой как Thrift.Преимущество этого метода в том, что он быстрее, чем HTTP-вызовы, но его сложнее вызывать. Конкретный клиент должен быть создан.

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

Децентрализованное управление

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

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

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

Децентрализованное управление данными

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

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

Данные проверяются и исправляются с помощью механизма компенсации.

Автоматическое развертывание

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

Ответ на исключение

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

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

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

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

Суммировать

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

Напоследок позвольте задать вам вопрос: в реальных проектах многие хотят разбить существующие монолитные сервисы на микросервисы, но каждый микросервис по-прежнему использует одну и ту же базу данных, а значит, различия между этими микросервисами все же есть, есть пересечение данных. Так является ли такой микросервис настоящим микросервисом?

Эта статья была включена вwoohoo. Флойд press.com/09-micros и…

Самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!

Добро пожаловать, чтобы обратить внимание на мой официальный аккаунт: «Программируйте эти вещи», разбирайтесь в технологиях, лучше поймите себя!