Микросервисы

Павел Мизонов
April 5, 2016

Введение

С ростом объёма кода и функциональности программного продукта, возникает необходимость управления сложностью приложения. Хорошо продуманная архитектура и правильное разбиение приложения на модули помогают справляться с поставленной задачей. Вариантом реализации архитектуры может быть монолитное приложение, когда вся или большая часть бизнес-задач имеет одну кодовую базу. Альтернативой является построенное на микросервисах приложение, в котором общая бизнес-задача разбита на отдельные части, каждая из которых имеет отдельное приложение (микросервис) со своей кодовой базой. К микросервисам в своих приложениях прибегают такие компании, как Amazon, Netflix, The Guardian. О преимуществах и недостатках подобной архитектуры по сравнению с монолитным приложением, будет рассказано ниже.

Что такое микросервисы?

Это небольшие модули, разделённые по принципу выполнения одной бизнес-задачи или одного класса задач. Основная цель такого разделения - возможность изменения отдельно взятого микросервиса, не меняя при этом связанных с ним компонентов. Бизнес-логика приложения разбивается на отдельные части, каждая из которых представляет собой небольшое приложение, выполняющее одну бизнес-задачу (single responsibility). Число таких приложений ничем не ограничено и между собой они общаются, используя API, построенное, например, на основе HTTP.

Какие преимущества дает использование микросервисов?

1. Избавляемся от высокого зацепления кода, разделяя приложение на микросервисы.

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

2. Легко масштабируем.

Это можно осуществить за счёт размещения микросервисов на разных серверах. Если в приложении есть несколько не очень требовательных к вычислительным ресурсам микросервисов, их можно размещать на одном хосте. Для более требовательных микросервисов - выделить хост мощнее. Микросервисы выполняющие неблокирующие задачи можно ставить в параллель.

3. Разные сервисы могут разрабатывать разные группы разработчиков.

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

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

Например, в web-приложениях для одних микросервисов можно использовать Ruby (Sinatra), а для других - node.js, потому что микросервисы изолированы друг от друга и технология их реализации никак не скажется на поведении приложения в целом.

Сложности использования микросервисов

1. Сложнее реализовать общее поведение для всех микросервисов (авторизация запросов, агрегация данных из разных микросервисов).

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

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

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

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

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

Список источников информации:

Martin Fowler: Microservices.
Sam Newman. Building Microservices. Designing Fine-Grained Systems. O'Reilly Media, 2015.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.