Микроросервисы - это небольшие независимые приложения, каждое из которых выполняет свою роль и имеет четкую зону ответственности. Каждый микросервис может иметь свой собственный технологический стэк, жизненный цикл разработки и релизов (в идеальном мире).
Основные характеристики микросервисов:
- Разделение на компоненты (сервисы)
- Группировка по бизнес-задачам
- Сервисы имеют бизнес-смысл
- Умные сервисы и простые коммуникации
- Децентрализованное управление
- Децентрализованное управление данными
- Автоматизация развертывания и мониторинга
- Design for failure (Chaos Monkey)
На последнем пункте следует остановиться отдельно. Поскольку теперь у нас не один большой сервис, а множество мелких, да еще и нагрузка сильно выросла, мы должны быть готовы к тому, что любой из наших микросервисов может умереть в любой момент и этого никто не должен заметить. Каждый запущенный микросервис требует наличия мониторингов, сбора логов и всего спектра инфраструктурной работы. Проделывать все это вручную очень ресурсозатратно и неэффективно. Как результат - новый виток и появление облачных систем управления микросервисами наподобие Kubernetes.
Kubernetes - облачная платформа, которая позволяет упростить процесс работы с микросервисами. В свою очередь, приложения, разрабатываемые для подобной облачной платформы должны удовлетворять ряду инфраструктурных требований. Эти требования хорошо сформулированы в манифесте 12-factors-apps.
Однако, помимо инфраструктурных требований, в микросервисной архитектуре возникают требования и к разделению бизнес-логики, обработке данных и способе взаимодействия с другими микросервисами.
И пока мы не углубились слишком далеко в микросервисную архитектуру, хотелось бы еще раз вернуться к монолиту, сравнить его с микросервисной архитектурой и привести некоторые аргументы в сторону обеих технологий.
Монолит лучше выбирать в следующих случаях:
- Если у вас новый домен и/или нет знаний в этом домене
- Если вы делаете прототип или быстрое решение
- Если команда не очень квалифицированная (все начинающие, например)
- Если вам требуется просто написать код и забыть о нем
- Если мало денег на проект — микросервисы обойдутся дорого
Микросервисы лучше выбрать, если:
- Точно понадобится линейное масштабирование
- Вы понимаете бизнес-домен, сможете выделить ограниченный контекст и сможете обеспечить согласованность на бизнес-уровне
- Команда высококвалифицированная, есть опыт и пара загубленных проектов с микросервисами в прошлом (все равно с первого раза сделать микросервисы не выходит)
- Предстоит долгосрочное сотрудничество с заказчиком
- Достаточно средств для инвестирования в инфраструктуру
- если необходимо, чтобы две микрослужбы активно взаимодействовали друг с другом, то, скорее всего, они должны быть одной микрослужбой
- если микрослужба должна полагаться на другую службу для обслуживания прямого запроса, то она не является полностью автономной
- некоторые говорят, что слабая модель предметной области является антишаблоном
В действительности это зависит от того, что вы реализуете. Если вы создаете довольно простую микрослужбу (например, службу CRUD), то слабая модель предметной области не является антишаблоном. Однако если вам предстоит иметь дело со сложной предметной областью микрослужбы, имеющей множество постоянно меняющихся бизнес-правил, слабая модель предметной области может быть антишаблоном для этой микрослужбы или ограниченного контекста. В этом случае проектирование в соответствии с расширенной моделью предметной области с сущностями, содержащими данные и поведение, а также с реализацией дополнительных шаблонов DDD (агрегатов, объектов значений и т. п.) может обеспечить огромные преимущества для долгосрочного успешного существования такой микрослужбы.
Преимущества подхода:
- возможна технологическая разнородность
- легко достигается изящная деградация
- отдельные части системы независимо масштабируются
- независимое развертывание сервисов
- простое разделение отвественности между командами
Проблемы, которые порождают микросервисы:
- развертывание
- мониторинг
- отладка
- консистентность
- аналитика
- интеграционное тестирование
- безопасность и авторизация сервисов
Микросервисная архитектура базируется на нескольких принципах:
- моделирование вокруг бизнес-концепций;
- культура автоматизации;
- скрытые подробности внутренней реализации;
- всесторонняя децентрализация;
- независимое развёртывание;
- изолированные сбои;
- всесторонен наблюдение.
Микросервисная архитектура (как и любая другая) должна обладать слабой связностью сервисов и сильным зацеплением внутри каждого сервиса.