Подробное объяснение микросервисной архитектуры

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

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

первоначальный спрос

Несколько лет назад Сяо Мин и Сяопи вместе открыли онлайн-супермаркет. Сяомин отвечает за разработку программы, а Сяопи отвечает за другие вопросы. В то время Интернет еще не был развит, а онлайн-супермаркеты были еще голубым океаном. Пока функция реализована, зарабатывать можно по желанию. Таким образом, их потребности очень просты.Им нужен только веб-сайт в общедоступной сети, и пользователи могут просматривать и покупать продукты на этом веб-сайте.Кроме того, им нужен управленческий фон, который может управлять продуктами, пользователями и данными о заказах.

Давайте составим список характеристик:

• Веб-сайт
  • Функции регистрации и входа в систему
  • Витрина товаров
  • разместить заказ
• опыт управления
  • Управление пользователями
  • товарный менеджмент
  • Управление заказами

Из-за простых требований Сяо Мин сделал медленное движение левой и правой рукой, и сайт был готов. Из соображений безопасности фон управления веб-сайтом не используется. Сяо Мин воспроизводит замедленное движение правой и левой рукой и управляет веб-сайтом. Общая схема архитектуры выглядит следующим образом:

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

По мере роста бизнеса...

Хорошие времена длились недолго: в течение нескольких дней последовали различные онлайн-супермаркеты, что оказало сильное влияние на Сяомин Сяопи.

Под давлением конкуренции Сяомин Сяопи решил применить несколько маркетинговых методов:

• Запускайте акции. Например, новогодние скидки, купи два и получи один бесплатно во время Весеннего фестиваля, купоны на корм для собак ко Дню святого Валентина и так далее.
• Расширяйте каналы и добавляйте мобильный маркетинг. В дополнение к веб-сайту также необходимо разработать мобильное приложение, апплет WeChat и т. д.
• Прецизионный маркетинг. Используйте исторические данные для анализа пользователей и предоставления персонализированных услуг.
• ...

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

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

На этом этапе есть много необоснованных мест:

• Веб-сайты и мобильные приложения содержат много повторяющегося кода для одной и той же бизнес-логики.
• Иногда данные передаются через базы данных, а иногда передаются через интерфейсные вызовы. Отношения вызова интерфейса беспорядочны.
• Чтобы предоставить интерфейс другим приложениям, отдельное приложение постепенно становится все больше и больше и содержит много логики, которая ему изначально не принадлежала. Границы приложений размыты, а атрибуция функций сбивает с толку.
• Серверная часть управления изначально была разработана с низким уровнем гарантии. Узкие места в производительности возникли после добавления функций, связанных с анализом данных и управлением продвижением, что повлияло на другие приложения.
• Структура таблицы базы данных зависит от множества приложений и не может быть реорганизована и оптимизирована.
• Все приложения работают с одной базой данных, и эта база данных имеет узкое место в производительности. Особенно когда выполняется анализ данных, производительность базы данных резко падает.
• Разработка, тестирование, развертывание и обслуживание становятся все более сложными. Даже изменение небольшой функции требует одновременного выпуска всего приложения. Иногда в релиз случайно добавляется какой-то непроверенный код, или после изменения функции что-то идет не так в другом неожиданном месте. Чтобы смягчить влияние проблем, которые могут возникнуть в результате релиза, и влияние приостановки онлайн-бизнеса, все приложения должны быть выпущены в три или четыре часа утра. После релиза, чтобы проверить нормальную работу приложения, мы должны следить за пиковым периодом пользователей следующего дня...
• В команде происходят изменения. Часто долго спорят о том, на каком приложении должны быть надстроены какие-то общие функции, и в итоге либо просто сделать это отдельно, либо поставить в рандомное место, но не поддерживать.

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

Пришло время внести изменения

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

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

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

• Служба пользователя
• товарный сервис
• Рекламные услуги
• Заказать услугу
• Служба анализа данных

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

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

1. База данных становится узким местом в производительности и рискует создать единую точку отказа.
2. Управление данными имеет тенденцию быть хаотичным. Даже при хорошем модульном дизайне в начале со временем всегда будет явление, когда один сервис извлекает данные из другого сервиса прямо из базы данных.
3. Структура таблицы базы данных может зависеть от нескольких служб, что влияет на все тело и его трудно настроить.

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

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

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

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

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

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

После того, как преобразование было завершено, Сяо Мин и Сяохун четко определили свои горшки. Эти двое очень довольны, все так красиво и идеально, как уравнения Максвелла.

Однако……

нет серебряной пули

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

В прошлом для монолитных приложений устранение неполадок обычно выполнялось путем просмотра журналов, изучения сообщений об ошибках и стеков вызовов. а такжеМикросервисная архитектура. Все приложение разделено на несколько сервисов, и очень сложно найти точку отказа.. Сяо Мин проверяет журналы один за другим и вызывает их вручную по одной службе за раз. После более чем десятиминутных поисков Сяо Мин наконец обнаружил точку отказа: служба продвижения перестала отвечать из-за слишком большого количества полученных запросов. Все остальные сервисы прямо или косвенно вызывают сервис продвижения, поэтому они тоже падают.В архитектуре микросервисов сбой одного сервиса может иметь лавинный эффект, вызывая сбой всей системы.. Фактически, перед фестивалем Сяо Мин и Сяохун провели оценку объема запросов. Как и ожидалось, ресурсов сервера достаточно для поддержки объема запросов фестиваля, значит, что-то не так. Однако ситуация срочная, каждая минута и каждая секунда — пустая трата денег, поэтому у Сяо Мина нет времени на устранение проблемы, поэтому он решил построить несколько новых виртуальных машин в облаке, а затем развернуть новые сервисы продвижения одной. по одному узлу. После нескольких минут работы система, наконец, восстановилась до нормального состояния. Подсчитано, что за время сбоя были потеряны сотни тысяч продаж, и сердца этих троих обливается кровью...

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

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

• В микросервисной архитектуре все приложение разделено на несколько сервисов, и очень сложно найти точку сбоя.
• Стабильность снизилась. Увеличение количества служб увеличивает вероятность отказа одной из служб, а отказ одной службы может привести к отказу всей системы. На самом деле, в сценариях крупносерийного производства всегда будут возникать сбои.
• Количество служб очень велико, а рабочая нагрузка по развертыванию и управлению очень велика.
• Развитие: как сделать так, чтобы каждый сервис сохранял синергию в условиях непрерывного развития.
• Тестирование: после разделения службы почти все функции будут включать несколько служб. Первоначальный тест одной программы стал тестом вызовов между сервисами. Тестирование становится более сложным.

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

Мониторинг - поиск признаков отказа

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

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

Большинство компонентов не нужно разрабатывать самостоятельно, и в Интернете есть компоненты с открытым исходным кодом. Сяомин загрузил RedisExporter и MySQLExporter, Эти два компонента предоставляют индикаторные интерфейсы кэша Redis и базы данных MySQL соответственно. Микросервисы реализуют интерфейсы пользовательских индикаторов на основе бизнес-логики каждого сервиса. Затем Xiaoming использует Prometheus в качестве сборщика индикаторов, а Grafana настраивает интерфейс мониторинга и оповещения по электронной почте. Строится такая система мониторинга микросервисов:

Обнаружение проблем — отслеживание ссылок

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

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

Изображение изДокументация по Истио

Как видно из рисунка, это запрос пользователя на посещение страницы продукта. В процессе запроса сервис productpage последовательно вызывает интерфейсы сервиса деталей и отзывов. Служба отзывов вызывает интерфейс рейтингов в процессе ответа. Запись всей трассировки ссылок представляет собой дерево:

Чтобы реализовать отслеживание ссылок, каждый вызов службы будет записывать как минимум четыре элемента данных в HTTP-заголовки:

• traceId: traceId идентифицирует ссылку вызова, запрошенную пользователем. Вызовы с одинаковым идентификатором трассировки относятся к одной и той же ссылке.
• spanId: идентификатор, идентифицирующий вызов службы, то есть идентификатор узла отслеживания ссылок.
• parentId: spanId родительского узла.
• requestTime & responseTime: время запроса и время ответа.

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

Выше приведено лишь минимальное описание. Теоретические основы отслеживания ссылок можно найти в GoogleDapper

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

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

Анализ проблем — анализ журнала

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

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

Сяо Мин исследовал и использовал известный компонент анализа журнала ELK. ELK — это аббревиатура трех компонентов Elasticsearch, Logstash и Kibana.

• Elasticsearch: поисковая система, которая также является хранилищем логов.
• Logstash: сборщик журналов, который получает входные данные журнала, выполняет некоторую предварительную обработку журнала и выводит его в Elasticsearch.
• Kibana: компонент пользовательского интерфейса, который находит данные через API Elasticsearch и отображает их пользователям.

Последний маленький вопрос: как отправлять журналы в Logstash. Одним из решений является прямой вызов интерфейса Logstash для отправки журнала в выходной файл журнала. Таким образом (эй, зачем использовать «снова») для изменения кода... Поэтому Сяо Мин выбрал другое решение: журнал по-прежнему выводится в файл, а в каждом сервисе развернут агент для сканирования файла журнала и вывода. это к Логсташу.

Шлюз — контроль разрешений, управление услугами

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

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

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

Так как количество услуг во всем интернет-супермаркете не особенно велико, Сяо Мин применяет самое грубое решение:

Регистрация службы с обнаружением — динамическое масштабирование

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

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

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

В общем случае операция добавления экземпляра выглядит следующим образом:

1. Развернуть новый экземпляр
2. Зарегистрируйте новый экземпляр с помощью балансировщика нагрузки или DNS.

Операция состоит всего из двух шагов, но если операция регистрации в балансировщике нагрузки или DNS выполняется вручную, то все не так просто. Подумайте об ощущении от ручного ввода 40 IP-адресов после добавления 40 экземпляров...

Решение этой проблемы — автоматическая регистрация и обнаружение сервисов. Во-первых, необходимо развернуть службу обнаружения служб, которая предоставляет информацию об адресах для всех зарегистрированных служб. DNS также является службой обнаружения служб. Затем каждая служба приложения автоматически регистрируется в службе обнаружения служб при запуске. А после запуска службы приложений список адресов каждой службы приложений будет синхронизироваться из службы обнаружения служб в локальную в режиме реального времени (периодически). Служба обнаружения служб также периодически проверяет состояние работоспособности служб приложений и удаляет неработоспособные адреса экземпляров. Таким образом, вам нужно только развернуть новый экземпляр при добавлении экземпляра и просто закрыть службу, когда экземпляр переходит в автономный режим.Обнаружение службы автоматически проверит увеличение или уменьшение количества экземпляров службы.

Обнаружение служб также работает с балансировкой нагрузки на стороне клиента. Поскольку служба приложения синхронизировала список адресов службы локально, при доступе к микрослужбе она может сама определять политику загрузки. Вы даже можете добавить некоторые метаданные (версия службы и другая информация), когда служба зарегистрирована, и клиентская загрузка выполняет управление трафиком на основе этих метаданных для реализации таких функций, как A/B-тестирование и публикация сине-зеленых.

Существует множество компонентов для обнаружения сервисов, таких как Zookeeper, Eureka, Consul, Etcd и т. д. Однако Сяо Мин чувствовал, что его уровень хорош, и хотел продемонстрировать свои навыки, поэтому он написал один на основе Redis...

автоматический выключатель, снижение качества обслуживания, ограничение тока

предохранитель

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

Картинка из "Дизайн микросервисов》

понижение уровня обслуживания

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

Ограничение

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

контрольная работа

В микросервисной архитектуре тестирование делится на три уровня:

1. Сквозное тестирование: Охватывает всю систему, обычно тестируя модели пользовательского интерфейса.
2. Тест службы: проверка интерфейса службы.
3. Юнит-тестирование: Тесты на соответствие модулям кода.

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

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

Сложность тестирования службы заключается в том, что служба часто будет зависеть от какой-либо другой службы. Эту проблему можно решить с помощью Mock Server:

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

Микросервисная структура

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

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

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

Другой способ — Service Mesh

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

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

Изображение из:Pattern: Service Mesh

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

Изображение из:Pattern: Service Mesh

Преимущество Sevice Mesh по сравнению с микросервисным фреймворком в том, что он не вторгается в код, а также его удобнее обновлять и поддерживать. Его часто критикуют за проблемы с производительностью. Несмотря на то, что петлевая сеть не генерирует фактические сетевые запросы, по-прежнему существуют дополнительные затраты на копии памяти. Кроме того, существует некоторая централизованная обработка трафика, что также влияет на производительность.

конец, начало

Микросервисы — это не конец архитектурной эволюции. Идя дальше, есть еще такие направления, как Serverless и FaaS. С другой стороны, есть и люди, которые подолгу поют вместе, делят и делят, заново открывают единую структуру...

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

Отсканируйте код, чтобы следовать

Эта статья опубликована в блогеOpenWriteвыпуск!