Солидные микросервисы

Солидный микросервис
Микросервисы набирают популярность и становятся мейнстримом в разработке ПО. Вынесение вычислений в облако способствует этому процессу, подтверждением чему служит запуск нано-серверов от, казалось бы, нерасторопного Microsoft. Что же такое эти микросервисы, какие задачи они позволяют решить и с какими проблемами сталкиваются разработчики при работе с ними? На эти вопросы мы попытаемся найти ответы далее.

Определение

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

  1. Разбиение на компоненты через сервисы
  2. Сервисы определяются бизнес-задачами
  3. Логика реализована в методах сервиса, а для передачи сообщений используются простейщие каналы передачи

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

На мой взгляд, микросервисы — это своеобразный SOLID-принцип на уровне приложений. Вполне логично, что каждый микросервис решает задачи, связанные с единственным или несколькими неразделимыми объектами домена (The Single Responsibility Principle). Также любой сервис, по своей природе, открыт для раширения, но его трудно модифицировать, особенно не имея доступа к исходному коду (The Open Closed Principle). В силу того, что сервисы взаимодействуют между собой по контракту, то имеется возможность заменять одну реализацию сервиса, на другую (The Liskov Substitution Principle), конечно, если он соотвествует контракту. При проектировании микросервисов, также как и в обьектно-ориентированном программировании, имеет смысл по возможности разделять сервисы на более мелкие, тем самым реализуя принцип разделения интерфейсов (Interface segregation principle). Ну и безусловно наши микросервисы не должны зависеть от реализации ни самого микросервиса, ни других используемых компонент (The Dependency Inversion Principle)

Преимущества

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

  1. Масштабируемость. Действительно микросервисную архитектуру очень легко масштабировать: проще простого запустить несколько процессов микросервиса и поставить перед ними балансировщик для обработки возросшего потока данных.
  2. Отказоустойчивость. Надёжность достигается за счёт того же запуска дополнительных процессов. В отличие от того же монолита или stateful-сервисов микросервис требует значительно меньшего количества ресурсов для запуски нового экземпляра.
  3. Обновляемость. Малая связанность сервисов и их относительная простота делает процесс тестирования и обновления технологий очень приятным занятием. Для того, чтобы опробовать новую платформу для разработки не нужно переписывать всё приложение целиком. Точнее «всё приложение»-микросервис стало значительно меньших размеров и переписать его стало возможно в обозримые сроки. Таким образом, приложение с миросервисной архитектурой довольно легко обновлять.

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

Трудности

Основная трудность при использовании архитектуры микросервисов — разбиение бизнес-логики на независимые сервисы и организация взаимодействия между ними. При проектировании солидной сервисной архитектуры, неважно какого размера, имеет смысл руководствоваться правилами, изложенными CEO Amazon Джеффом Бизосом: основная идея заключается в том, чтобы сервисы взаимодействовали исключительно через предоставляемый ими API и не использовать никаких других способов будь то общая база данных или другое общее хранилище. В противном случае сервис запутается в тентаклях логики надстроенной над общими данными. Собственно, подобная ситуация противоречит использованию простейших каналов данных, поскольку БД таковым не является. Чтобы исключить подобный плачевный сценарий развития событий нужно, в первую очередь, хорошо представлять себе потоки данных: какие структуры необходимы для обеспечения работы и какими способами их можно получить, — для чего в свою очередь нужно хорошо знать предметную область приложения.

Заключение

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

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

Поделиться
This entry was posted in Programming and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>