Поделиться через

Архитектура микрослужб

Подсказка

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

Скачать в формате PDF

Архитектура микросервисов .NET для приложений .NET в контейнерах, миниатюра обложки электронной книги.

Как подразумевает имя, архитектура микрослужб — это подход к созданию серверного приложения в виде набора небольших служб. Это означает, что архитектура микрослужб в основном ориентирована на серверную часть, хотя подход также используется для внешнего интерфейса. Каждая служба выполняется в собственном процессе и взаимодействует с другими процессами с помощью таких протоколов, как HTTP/HTTPS, WebSockets или AMQP. Каждая микрослужба реализует конкретный комплексный домен или бизнес-возможности в пределах определенной границы контекста, и каждая из них должна быть разработана автономно и развертываться независимо. Наконец, каждая микрослужба должна владеть соответствующей моделью данных домена и логикой домена (суверенитет и децентрализованное управление данными) и может основываться на различных технологиях хранения данных (SQL, NoSQL) и различных языках программирования.

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

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

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

Схема различий между двумя методами развертывания.

Рис. 4-6. Монолитное развертывание и подход микрослужб

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

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

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

  • Мониторинг и проверка работоспособности служб и инфраструктуры.

  • Масштабируемая инфраструктура для служб (то есть облачные и оркестраторы).

  • Проектирование безопасности и реализация на нескольких уровнях: проверка подлинности, авторизация, управление секретами, безопасное взаимодействие и т. д.

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

  • Методы и инфраструктура DevOps и CI/CD.

Из них в этом руководстве рассматриваются только первые три. Последние два пункта, связанные с жизненным циклом приложений, рассматриваются в дополнительной электронной книге "Контейнеризованный жизненный цикл приложений Docker на платформе и с инструментами Microsoft".

Дополнительные ресурсы

НазадДалее