Павел Мизонов
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.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.