Принципы проектирования микросервисов. Часть 2

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

Принцип микросервисов № 5: бизнес-возможности

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

Этот принцип важен по нескольким причинам:

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

Принцип микросервисов № 6: Децентрализация

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

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

Принцип микросервисов № 7: Автоматизация процессов

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

Следовательно, вы должны иметь возможность автоматизировать процесс развертывания вашего приложения на основе микрослужб. Вы можете сделать это, приняв культуру DevOps в своей организации и используя правильные инструменты, такие как Azure DevOps или Jenkins.

Принцип микросервисов № 8: Взаимодействие между сервисами

Когда вы разбиваете существующее монолитное приложение на микрослужбы, вы также должны определить способ взаимодействия этих служб. Поскольку архитектура микросервисов позволяет использовать разнородные технологии, как тогда эти сервисы могут взаимодействовать? Именно здесь могут помочь интерфейсы прикладного программирования (API).

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

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

Принцип микросервисов № 9: Мониторинг

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

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

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

Принцип микросервисов № 10: Разделение ответственности за запросы команд (CQRS)

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

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

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

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

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

Подведем итог

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