Рекомендации по микросервисной архитектуре

Примечание. Источник статьи: колонка Geek Time «Изучение архитектуры с нуля».

Методы

Детализация обслуживания

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

метод разделения

На основе теории «трех мушкетеров» можно рассчитать соответствующее количество услуг после разделения.

1. Разделение на основе бизнес-логики

Определите бизнес-модули в системе в соответствии с кругом обязанностей и разделите каждый отдельный бизнес-модуль на независимую службу.
Трудная проблема заключается в том, что понимание «Сферы ответственности» сильно различается. Например, в системе электронной коммерции первый способ — разделить услугу на 3 услуги «товар», «транзакция» и «пользователь», а второй способ — разделить на «товар», «заказ». , "оплата", "доставка" "Есть 6 сервисов для продавцов" и "покупателей", какой способ разумнее?
Путаница заключается в разделении с точки зрения бизнеса.Нет проблем как с грубыми, так и с мелкими шкалами, потому что в основе разделения лежит бизнес-логика.Чтобы судить о степени детализации разделения, мы не можем вычислить ее с точки зрения бизнес-логики и по принципу "трех мушкетеров".Примерный объем службы
Например, если есть 10 человек, согласно вышеизложенным принципам необходимо разделить около 4 сервисов, то в сферу ответственности «сервиса пользователя» можно включить все «логин, регистрация, управление пользовательской информацией»; если команда размер составляет 100 человек для поддержки службы, количество служб может достигать 40, тогда «вход пользователя» является службой; если размер команды достигает 1000 человек для поддержки бизнеса, то «управление подключением пользователей» может быть независимой службой

2. На основе масштабируемого разделения

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

3. Разделение по надежности

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

выгода

Избегайте сбоев неосновных служб, влияющих на основные службы.

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

Решения по обеспечению высокой доступности основных услуг могут быть проще

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

Возможность снизить затраты на высокую доступность

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

4. Разделение по производительности

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

Вышеупомянутые разделения могут быть свободно расположены и объединены в соответствии с реальной ситуацией.

инфраструктура

«Автоматизация» — важная часть.Если соответствующая инфраструктура не надежна, то микросервис — это смоляная яма, из-за которой исследования и разработки, тестирование, эксплуатация и обслуживание попадают в различные ловушки.
Инфраструктура микросервиса показана на рисунке ниже.

Внедрение микросервисов

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

Стройте инфраструктуру по приоритету

1. Обнаружение сервисов, маршрутизация сервисов, отказоустойчивость сервисов: это самая базовая микросервисная инфраструктура.
1. Структура интерфейса, шлюз API: в основном для повышения эффективности разработки, структура интерфейса предназначена для повышения эффективности разработки внутренних сервисов, шлюз API предназначен для повышения эффективности стыковки с внешними сервисами.
1. Автоматизированное развертывание, автоматизированное тестирование, центр конфигурации: в основном для повышения эффективности тестирования, эксплуатации и обслуживания.
1. Мониторинг услуг, отслеживание услуг, безопасность услуг: в основном для дальнейшего повышения эффективности эксплуатации и обслуживания.
Важность вышеперечисленных двух типов инфраструктур 3 и 4 будет становиться все более и более важной по мере увеличения количества узлов микросервиса, но когда количество узлов микросервиса невелико, его можно поддерживать вручную.Хотя эффективность не высока, это в принципе выдерживает

инфраструктура

автоматизированный тест

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

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

По сравнению с унифицированной системой количество узлов для развертывания микросервисов увеличилось в разы, а то и в десятки раз, а также сильно возрастет частота развертывания микросервисов (например, 70% наших бизнес-систем развернуты на рабочих дней).
Такая крупная операция развертывания требует большого количества рабочей силы и подвержена ошибкам, если ее продолжают выполнять вручную, поэтому для завершения операции развертывания требуется автоматизированная система развертывания.
Автоматизированная система развертывания включает в себя такие функции, как управление версиями, управление ресурсами (например, управление машинами, управление виртуальными машинами), операции развертывания и операции отката.

Центр конфигурации

Количество узлов микросервисов очень велико, а ручная модификация выполняется путем ручного входа в каждую машину, что неэффективно и подвержено ошибкам.
Особенно при развертывании или устранении неполадок необходимо быстро добавлять, удалять, изменять и проверять конфигурацию, а ручное управление явно неприемлемо.
Некоторые конфигурации среды выполнения необходимо динамически изменять, и все узлы вступают в силу немедленно, что невозможно сделать вручную.
Таким образом, микросервисам нужен единый центр конфигурации для управления конфигурацией всех узлов микросервисов.
Центр конфигурации включает в себя управление версиями конфигурации (например, для одного и того же микросервиса 10 узлов обслуживают мобильных пользователей и 20 узлов обслуживают пользователей Unicom, элементы конфигурации одинаковы, а значения конфигурации разные), добавление, удаление, изменение , а также проверка конфигурации, конфигурации узла, синхронизации конфигурации, отправки конфигурации и других функций.

структура интерфейса

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

Если мы просто укажем протокол HTTP/REST без указания спецификаций данных JSON и JSON, возникнет такая путаница: некоторые микросервисы используют XML, некоторые — JSON, а некоторые — пары ключ-значение; даже если одно и то же — JSON, а Формат данных JSON отличается. Таким образом, каждый микросервис должен адаптироваться к нескольким, а то и десяткам интерфейсных протоколов, что равносильно передаче работы, когда-то выполненной ESB, самому микросервису, эффективность которого явно неприемлема, поэтому требуется унифицированный интерфейсный фреймворк. .
Платформа интерфейса не является исполняемой системой и обычно предоставляется для всех вызовов микросервисов в виде библиотек или пакетов. Например, для приведенного выше примера JSON базовая техническая группа может предоставить пакеты для синтаксического анализа на разных языках (пакет Java, пакет Python , библиотека C и т. д.)

Шлюз API

После разделения системы на микросервисы внутренние микросервисы связаны между собой, а доступ друг к другу осуществляется по принципу «точка-точка».
Если внешняя система хочет вызвать определенную функцию системы, а также использует метод «точка-точка», внешняя система будет очень «большой головой».
Потому что с точки зрения внешней системы ей не нужно и она не может понять разделения обязанностей и границ такого количества микросервисов, она обращает внимание только на те возможности, которые ей нужны, а не на то, какие микросервисы должны предоставлять возможности.
Система доступа к внешней системе также включает в себя ограничения, связанные с безопасностью и разрешениями.Если внешняя система напрямую обращается к микросервису, это означает, что каждый микросервис должен реализовывать свои собственные функции безопасности и разрешений, а это не только много работы, но и повторяющаяся работа.
Исходя из приведенного выше анализа, микросервисам нужен единый API-шлюз, отвечающий за работу доступа внешних систем.
Шлюз API — это интерфейс для доступа к внешней системе. Все внешние системы должны получать доступ к системе через шлюз API, в основном включая аутентификацию доступа (разрешен ли доступ), контроль разрешений (к каким функциям можно получить доступ), шифрование передачи, маршрутизацию запросов. , Управление потоком и другие функции

обнаружение службы

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

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

1. Забота о себе

Структура самообслуживания выглядит следующим образом:

Структура самообслуживания означает, что каждый микросервис самостоятельно выполняет обнаружение сервиса. Например, на рисунке ЭКЗЕМПЛЯР СЛУЖБЫ A обращается к РЕГИСТРУ СЛУЖБЫ, чтобы получить информацию о регистрации службы, а затем напрямую обращается к ЭКЗЕМПЛЯРУ СЛУЖБЫ B.
Реализация обнаружения службы самообслуживания относительно проста, поскольку функции этой части обычно предоставляются каждому вызову микрослужбы через унифицированную программную библиотеку или пакет, и каждая микрослужба не будет повторяться сама по себе. давление доступа распределяется на каждый узел микросервиса, и нет очевидного давления и риска в производительности и доступности.

2. Агентство

Структура агентства выглядит следующим образом:

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

сервисная маршрутизация

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

Отказоустойчивость сервиса

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

сервисный мониторинг

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

эффект

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

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

отслеживание услуг

Мониторинг службы может обеспечить мониторинг и сбор информации на уровне узла микрослужбы, но если нам нужно отслеживать полный путь запроса в микрослужбе, мониторинг службы трудно осуществить. Если полная информация о цепочке запросов каждой службы отправляется в систему мониторинга службы в режиме реального времени, объем данных будет слишком большим для обработки.
Разницу между мониторингом услуг и отслеживанием услуг можно просто резюмировать как разницу между макро и микро. Например, служба A запрашивает службу B по протоколу HTTP 10 раз, а B возвращает объект JSON через HTTP.Мониторинг службы будет записывать количество запросов, время ответа, код ошибки ответа, параметры запроса и возвращенные объекты JOSN.
В настоящее время, будь то распределенная трассировка или трассировка служб микросервисов, большинство технологий реализации трассировки запросов основаны на статье Google Dapper «Dapper, крупномасштабная инфраструктура трассировки распределенных систем».

служба безопасности

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

Примечание. Учащиеся, которым интересно узнать о столбце Geek Time, могут проверитьGeek Time Column - доступна услуга кэшбэка