Galina Iaroshenko

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

Данная статья является переводом. Автор: Vikash Kumar, ревьюер: Dan Ackerson. Ссылка на оригинал.

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

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

• Более легкой и быстрой разработки
• Ремонтопригодности
• Масштабируемости

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

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

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

1. Примите принцип единственной ответственности

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

Соберите вместе то, что меняется по одной и той же причине, и разделите то, что меняется по разным причинам О’Райли

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

Давайте разберем этот принцип на примере.

Портал электронной коммерции может иметь такую ​​архитектуру микросервисов:

Данное изображение и все последующие взяты отсюда.

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

2. Создавайте команды с четкими обязанностями

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

Давайте разберем это на примере:

В организации могут быть определенные группы, такие как разработчики UI/UX, разработчики интерфейсов, разработчики серверной части, администраторы баз данных, QA, разработчики промежуточного программного обеспечения и т. д., которые работают изолированно, но ежедневно взаимодействуют посредством встреч – лично или с помощью различных средств связи, таких как JIRA, Slack и т. д.

Иногда в системе могут возникать небольшие ошибки, а иногда даже большие ошибки. Таким образом, SCRUM может быть одним из вариантов решения. Это помогает каждому члену команды разумно использовать время. Но поскольку команды организованы на основе ролей, интеграция одного обновления в рамках одного спринта может стать сложной задачей. Например, если разработчики UI/UX не получают никакой информации от серверных разработчиков об изменениях в API, новый API вообще не будет полезен.

Итак, каково решение?

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

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

3. Используйте правильные инструменты и фреймворки

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

Использование правильных инструментов, фреймворков и библиотек поможет реализовать микросервисную архитектуру. Если вы планируете делать это на Java, рассмотрите Spring Boot Project. Выбор правильных инструментов и фреймворков требует много времени и усилий, поэтому вот список проверенных инструментов и технологий для работы:

1. Jenkins и Bamboo для автоматизации развертывания
2. Docker для контейнеризации
3. Postman для тестирования API
4. Kubernetes для взаимодействия контейнеров и развертывания
5. Logstash для мониторинга
6. DevSecOps для управления всем процессом жизненного цикла разработки программного обеспечения
7. GitHub для управления исходным кодом и контроля версий
8. Простой сервис очередей Amazon для обмена сообщениями
9. SonarQube для проверки качества и безопасности кода
10. Ansible для управления вашей конфигурацией
11. Jira для отслеживания проблем и управления проектами

4. Сохраняйте асинхронную связь между микросервисами

Между микрослужбами существует два типа связи: синхронная и асинхронная. Давайте разберем это на примере:

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

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

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

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

Вы можете увидеть пример этого ниже:

5. Внедрите модель DevSecOps и защитите микросервисы

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

1. Код приложения (основная логика).
2. Сервисный код приложения (сетевые подключения, установление сеанса и т. д.).
3. Инфраструктура (ресурсы для хранения данных, сети, платформы и т. д.)
4. Мониторинг (непрерывное наблюдение за приложением).

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

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

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека devops’а» Интересно, перейти к каналу

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

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

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

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

7. Развертывание каждого микросервиса отдельно

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

Некоторые из наиболее распространенных и популярных шаблонов для развертывания микросервисов:

1. Несколько экземпляров службы на хост.
2. Экземпляр службы на контейнер.
3. Один экземпляр службы на хост.
4. Экземпляр службы на ВМ.

8. Управление микросервисами

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

Вот некоторые из проверенных платформ для оркестровки:

• K8s (Kubernetes)
• AKS (Azure Kubernetes Services)
• ECS (Amazon Elastic Container Services)
• Azure Container Apps

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

9. Используйте эффективную систему мониторинга

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

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

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

Давайте рассмотрим несколько примеров инструментов мониторинга микросервисов.

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

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

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

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

Prometheus: бесплатный программный инструмент с открытым исходным кодом, который предлагает решения для мониторинга и модификации.

Заключение

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

***

Материалы по теме

• 💎🍇🎈 Что выбрать для проекта: монолиты vs микросервисы vs бессерверная архитектура
• Что такое микросервисная архитектура и когда ее применять
• 🐳 Микросервисная архитектура на примере Python и gRPC