Микросервисная архитектура - основные принципы. Часть 1

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

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

Принцип микросервисов № 1: Высокая связность и низкая связанность

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

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

Связывание измеряет, сколько знаний один модуль имеет о другом (т. е. насколько тесно связаны разные части программы). Высокий уровень связанности указывает на то, что многие модули знают друг о друге; между модулями не так много инкапсуляции. Низкий уровень связанности указывает на то, что многие модули изолированы друг от друга. Когда компоненты в приложении слабо связаны, вы также можете легко протестировать приложение.

Принцип микросервисов № 2: дискретные границы

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

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

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

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

Принцип микросервисов № 3: принцип единой ответственности

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

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

Принцип микросервисов № 4: проектирование на случай сбоя

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

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

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