Оценка и готовность микрослужб

  • Статья

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

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

Общие сведения о приоритетах бизнеса

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

Ниже приведены некоторые приоритеты, которые следует учитывать:

  • Инновации
  • Надежность
  • Эффективность

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

Запись архитектурных решений

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

Учитывайте следующие факторы:

  • Существует ли совместное управление?
  • Вы отслеживаете решения и их компромиссы в журнале архитектуры?
  • Может ли ваша команда легко получить доступ к журналу архитектуры?
  • Есть ли у вас процесс оценки средств, технологий и платформ?

Оценка состава команды

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

Учитывайте следующие факторы:

  • Разделены ли команды на основе поддоменов, следуя принципам проектирования на основе домена ?
  • Являются ли ваши команды кроссфункциональными, с достаточной емкостью для создания и работы связанных микрослужб независимо?
  • Сколько времени тратится на нерегламентированные действия и задачи, которые не связаны с проектами?
  • Сколько времени тратится на совместную работу между командами?
  • У вас есть процесс выявления и минимизации технического долга?
  • Как вы узнали уроки и опыт взаимодействия между командами?

Использование методологии двенадцатифакторов

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

Общие сведения о подходе декомпозиции

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

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

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

Оценка готовности DevOps

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

При оценке возможностей DevOps для архитектуры микрослужб следует учитывать следующие моменты:

  • Знакомы ли люди в вашей организации с основными принципами и принципами DevOps?
  • Понимают ли команды средства управления версиями и их интеграцию с конвейерами CI/CD?
  • Правильно ли вы реализуете методики DevOps?
    • Вы следуйте гибким методикам?
    • Реализована ли непрерывная интеграция?
    • Реализована ли непрерывная доставка?
    • Реализуется ли непрерывное развертывание?
    • Реализован ли непрерывный мониторинг?
    • Существует ли инфраструктура как код (IaC) ?
  • Вы используете правильные средства для поддержки CI/CD?
  • Как настроить промежуточные и рабочие среды, управляемые для приложения?
  • Имеет ли цепочка инструментов поддержку сообщества и модель поддержки и предоставляет ли соответствующие каналы и документацию?

Определение бизнес-областей, которые часто изменяются

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

Учитывайте следующие факторы:

  • Можно ли развертывать службу независимо?
  • Соответствует ли служба принципам DDD?
  • Соответствует ли служба принципам SOLID?
  • Является ли база данных частной для службы?
  • Вы построили службу с помощью поддерживаемого шаблона корпуса микрослужб?

Оценка готовности инфраструктуры

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

Учитывайте эти факторы при оценке готовности инфраструктуры:

  • Обеспечивает ли инфраструктура масштабируемость развернутых служб?
  • Поддерживает ли инфраструктура подготовку с помощью сценариев, которые можно автоматизировать с помощью CI/CD?
  • Предоставляет ли инфраструктура развертывания соглашение об уровне обслуживания для доступности?
  • У вас есть план аварийного восстановления и запланированные расписания детализации?
  • Данные реплика в разные регионы для аварийного восстановления?
  • У вас есть план резервного копирования данных?
  • Описаны ли варианты развертывания?
  • Отслеживается ли инфраструктура развертывания?
  • Поддерживает ли инфраструктура развертывания самовосстановление служб?

Оценка циклов выпуска

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

  • Как часто вы создаете и освобождаете приложения?
  • Как часто выпуски завершаются сбоем после развертывания?
  • Сколько времени занимает восстановление или исправление проблем после сбоя?
  • Используется ли семантическое управление версиями для приложений?
  • Поддерживаете ли вы разные среды и распространяете один и тот же выпуск в последовательности (например, сначала на промежуточное, а затем в рабочую среду)?
  • Используете ли вы управление версиями для API?
  • Следуйте правильным рекомендациям по управлению версиями для API?
  • Когда вы изменяете версию API?
  • Какой подход подходит для обработки управления версиями API?
    • Управление версиями пути URI
    • Управление версиями параметров запроса
    • Управление версиями типов контента
    • Пользовательское управление версиями заголовков
  • У вас есть практика для управления версиями событий?

Оценка взаимодействия между службами

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

Учитывайте следующие факторы:

  • Вы следуете при первом подходе к API, где API рассматриваются как граждане первого класса?
  • Есть ли у вас длительные операции цепочки, в которых несколько служб взаимодействуют по последовательности по синхронному протоколу связи?
  • Вы рассмотрели асинхронное взаимодействие в любой точке системы?
  • Вы оценили технологию брокера сообщений и ее возможности?
  • Вы понимаете пропускную способность сообщений, которые службы получают и обрабатывают?
  • Вы используете прямой обмен данными между клиентами?
  • Нужно ли сохранять сообщения на уровне брокера сообщений?
  • Используется ли шаблон "Материализованное представление" для решения поведения микрослужб?
  • Реализованы ли вы повторные попытки, разбиение цепи, экспоненциальная обратная связь и Jitter для надежного взаимодействия? Распространенный способ обработки этого — использовать шаблон послов.
  • Определены ли события домена для упрощения взаимодействия между микрослужбами?

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

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

Учитывайте следующие факторы:

  • Используются ли службы непосредственно клиентами?
  • Существует ли шлюз API, который выступает в качестве фасада для всех служб?
  • Можно ли шлюзу API настроить такие политики, как ограничения квоты, макетирование ответов и фильтрация IP-адресов?
  • Вы используете несколько шлюзов API для решения потребностей различных типов клиентов, таких как мобильные приложения, веб-приложения и партнеры?
  • Предоставляет ли шлюз API портал, на котором клиенты могут обнаруживать и подписываться на службы, например портал разработчика в Azure Управление API?
  • Предоставляет ли решение возможности балансировки нагрузки L7 или Брандмауэр веб-приложений (WAF) вместе со шлюзом API?

Оценка обработки транзакций

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

Учитывайте следующие аспекты.

  • Сколько распределенных транзакций есть в системе?
  • Какой подход к обработке распределенных транзакций? Оцените использование шаблона Сага с оркестрацией или хореографией.
  • Сколько транзакций охватывает несколько служб?
  • Вы используете модель транзакций ACID или BASE для обеспечения согласованности и целостности данных?
  • Используются ли операции длинной цепочки для транзакций, охватывающих несколько служб?

Оценка модели разработки служб

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

Учитывайте следующие факторы:

  • Используется ли шаблон службы для запуска разработки новых служб?
  • Следует ли использовать методологию приложения "Двенадцать факторов" и использовать одну базу кода для микрослужб, изоляции зависимостей и внешней конфигурации?
  • Храните ли вы конфиденциальную конфигурацию в хранилищах ключей?
  • Контейнеризировать службы?
  • Знаете ли вы требования к согласованности данных?

Оценка подхода к развертыванию

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

При оценке плана развертывания учитывайте следующие факторы:

  • У вас есть стратегия развертывания служб?
  • Вы используете современные инструменты и технологии для развертывания служб?
  • Какой тип совместной работы требуется для групп при развертывании служб?
  • Подготавливаете инфраструктуру с помощью инфраструктуры в качестве кода (IaC)?
  • Вы используете возможности DevOps для автоматизации развертываний?
  • Распространяете ли вы одни и те же сборки в нескольких средах, как предлагается методологией приложения "Двенадцать факторов"?

Оценка платформы размещения

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

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

Учитывайте следующие факторы:

  • Какая платформа размещения используется для развертывания служб (виртуальных машин, контейнеров, бессерверных)?
  • Можно ли масштабировать платформу размещения? Поддерживает ли она автомасштабирование?
  • Сколько времени занимает масштабирование платформы размещения?
  • Вы понимаете соглашения об уровне обслуживания, предоставляемые различными платформами размещения?
  • Поддерживает ли ваша платформа размещения аварийное восстановление?

Оценка мониторинга служб

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

Учитывайте следующие факторы:

  • Отслеживайте развернутые службы?
  • У вас есть механизм ведения журнала? Какие инструменты вы используете?
  • Есть ли у вас инфраструктура распределенной трассировки?
  • Записываете ли вы исключения?
  • Вы поддерживаете коды бизнес-ошибок для быстрого выявления проблем?
  • Вы используете пробы работоспособности для служб?
  • Используется ли семантическое ведение журнала? Реализованы ли ключевые метрики, пороговые значения и индикаторы?
  • Маскировка конфиденциальных данных во время ведения журнала?

Оценка назначения маркера корреляции

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

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

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

Учитывайте следующие факторы:

  • На каком этапе вы назначаете маркер корреляции?
  • Какой компонент назначает маркер корреляции?
  • Сохранить маркеры корреляции в базе данных службы?
  • Какой формат маркеров корреляции?
  • Регистрируются ли маркеры корреляции и другие сведения о запросе?

Оценка необходимости платформы корпусов микрослужб

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

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

Учитывайте следующие факторы:

  • Вы используете платформу корпусов микрослужб?
  • Вы используете Dapr для взаимодействия с перекрестными проблемами?
  • Не зависит ли язык платформы шасси?
  • Является ли ваша платформа шасси универсальной, поэтому она поддерживает все виды приложений? Платформа шасси не должна содержать логику для конкретного приложения.
  • Предоставляет ли платформа шасси механизм использования выбранных компонентов или служб по мере необходимости?

Оценка подхода к тестированию приложений

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

Например, при создании приложения необходимо начать с разработки архитектуры. При использовании метода shift-left вы проверяете разработку уязвимостей с помощью таких средств, как Microsoft Threat Modeling. При запуске разработки можно проверить исходный код, выполнив такие средства, как статическое тестирование безопасности приложений (SAST) и используя другие анализаторы для выявления проблем. После развертывания приложения можно использовать такие средства, как динамическое тестирование безопасности приложений (DAST), чтобы протестировать его во время размещения. Функциональное тестирование, тестирование хаоса, тестирование на проникновение и другие виды тестирования выполняются позже.

Учитывайте следующие факторы:

  • Вы пишете тестовые планы, охватывающие весь жизненный цикл разработки?
  • Включены ли тестировщики в собраниях требований и в течение всего жизненного цикла разработки приложений?
  • Вы используете проект на основе тестов или на основе поведения?
  • Вы тестируете истории пользователей? Вы включаете критерии принятия в истории пользователей?
  • Протестируйте проект с помощью таких средств, как Microsoft Threat Modeling?
  • Вы пишете модульные тесты?
  • Используются ли статические анализаторы кода или другие средства для измерения качества кода?
  • Вы используете автоматизированные средства для тестирования приложений?
  • Вы реализуете методики Secure DevOps ?
  • Вы выполняете тестирование интеграции, комплексное тестирование приложений, тестирование нагрузки и производительности, тестирование на проникновение и тестирование хаоса?

Оценка безопасности микрослужб

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

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

Учитывайте следующие факторы:

  • Требуется ли проверка подлинности и авторизация для службы?
  • Используется ли шлюз API для проверки маркеров и входящих запросов?
  • Используется ли ssl или mTLS для обеспечения безопасности для обмена данными служб?
  • Есть ли политики безопасности сети, позволяющие обеспечить необходимую связь между службами?
  • Вы используете брандмауэры (L4, L7), где применимо для обеспечения безопасности внутренних и внешних коммуникаций?
  • Вы используете политики безопасности в шлюзе API для управления трафиком?

Соавторы

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

Основные авторы:

  • Ovais Mehboob Ахмед Хан | Старший архитектор облачных решений — проектирование
  • Nabil Siddiqui | Архитектор облачных решений — digital & Application Innovation

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги