Атрибут микросервисной архитектуры
Лидерство в микросервисе, часть 2
- Компоненты услуг
- Услуги Бизнес-подход
- Децентрализованное управление данными
- Отказ услуг
- Простая маршрутизация
Компоненты услуг
Компонент означает единицу работы/задачи, которая может быть независимо обновлена и заменена. Одна из основных причин использования сервисов в качестве компонентов заключается в том, что сервисы можно развертывать независимо. Если служба состоит из нескольких компонентов, сложно развернуть и отслеживать службу компонентов в случае сбоя. Таким образом, если мы считаем, что другая сторона приложения разбивается на несколько сервисов, то мы можем ожидать, что многие изменения отдельных сервисов потребуют повторного развертывания только этого сервиса. И это неправильно, потому что некоторые крошечные изменения изменят интерфейсы сервисов и подействуют в ответ на некоторую координацию.
Бизнес-подход в сфере услуг
Каждая крупная организация ищет масштабируемую систему, поэтому технические детали уходят в сторону в зависимости от бизнес-подхода и будущих обновлений. Таким образом, они стараются разделить большое приложение на части, а руководство сосредотачивается на технологическом уровне, что приводит к группам пользовательского интерфейса, группам логики на стороне сервера и группам баз данных. Но руководству сложно разобраться в централизованных слоях, а вот технарям — хорошо. На изображении ниже мы определяем технологические уровни как хороший бизнес-подход в виде различных команд организации.
Бизнес-подход к микросервисам относится к области пользовательского интерфейса и постоянного хранилища. Соответственно команды являются кросс-функциональными, включая команды разработчиков: пользовательский опыт, базы данных и команды управления проектами.
Децентрализованное управление данными
Микросервисы отдают предпочтение децентрализованному управлению данными и программному обеспечению, построенному на собственной уникальной базе данных. Это распространенная проблема при интеграции в крупное корпоративное приложение. Хороший способ справиться с этим, используя понятие ограниченного контекста в доменно-ориентированном дизайне. DDD делит сложные компоненты на несколько компонентов ограниченного контекста и отображает отношения между ними. Монолитные приложения предпочитают единую логическую базу данных для постоянных данных, предприятия часто предпочитают единую базу данных для ряда приложений, но микросервисы имеют децентрализованные решения по хранению данных. Таким образом, мы можем сказать, что децентрализация ответственности за данные между микросервисами использовалась для облегчения обновления.
Отказ службы
Микросервисы, скорее всего, созданы для защиты от сбоев. Мониторинг в микросервисах прост по сравнению с монолитом, и это может помочь снизить вероятность сбоя. Микросервисы более современны, чем архитектура монолитных систем, из-за этой отказоустойчивости.
Простая маршрутизация
Микросервисы имеют интеллектуальные конечные точки, а шаблоны архитектуры действуют как система UNIX, где они получают запросы, обрабатывают их и генерируют ответы.
Следующая тема — Предварительные требования к микросервисам.
Счастливого обучения.
