Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны Low Coupling и High Cohesion.
Подробности — в видео и текстовой расшифровке ниже.
В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.
https://tproger.ru/events/digital-ottepel-v/?utm_source=in_text
Когда большая система разбивается, часто происходит так, что образовываются команды на базе технологий. При такой ситуации команды размещают логику на тех слоях системы, к которым имеют доступ. Закон Конвея в действии:
Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.
Источник статьи: https://tproger.ru/articles/chto-ta...rhitektury-primery-ispolzovanija-instrumenty/
Подробности — в видео и текстовой расшифровке ниже.
Монолит vs микросервисы
При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.
Что такое контракт
Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.Микросервисная команда
Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.https://tproger.ru/events/digital-ottepel-v/?utm_source=in_text
Когда большая система разбивается, часто происходит так, что образовываются команды на базе технологий. При такой ситуации команды размещают логику на тех слоях системы, к которым имеют доступ. Закон Конвея в действии:
Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.
Насколько большим должен быть микросервис
Логика работы сервиса должна полностью уместиться в голове одного разработчика, независимо от количества кода и людей. Проектируя систему, мы имеем выбор, как разработать каждый микросервис. Например:- Node.js — для простых страничек с отчетами.
- С++ — для real-time приложений.
- Python —для анализа данных.
- Golang — для высоконагруженного сервиса.
- Java — для интеграции с энтерпрайзом.
Инструментарий для реализации микросервисов
В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.- Для CI/CD сейчас активно используются GitLab CI, TeamCity, Jenkins, Github Action, Circle CI.
- В качестве системы оркестрации можно попробовать Nomad или Apache Mesos, а если вы используете Docker, то Kubernetes и Docker Swarm.
- Для Service Discovering можно взять Consul, Eureka или Zookeeper.
- Для мониторинга и сбора логов можно выбрать стек ELK или TICK, а также построить свою систему мониторинга из отдельных продуктов, включая Prometheus, Grafana и Graphite.
Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.
Источник статьи: https://tproger.ru/articles/chto-ta...rhitektury-primery-ispolzovanija-instrumenty/