Перевод статьи: https://amplication.com/blog/the-complete-microservices-guide
Автор: Мули Готтлиб
21 сентября 2023 г.
Введение в микросервисы
Почему микросервисы?
Микросервисы стали популярным архитектурным подходом к проектированию и созданию программных систем благодаря нескольким веским основаниям и преимуществам. Это подход к проектированию, который предполагает разделение приложений на несколько отдельных и независимых сервисов, называемых «микросервисами», который дает ряд преимуществ, в том числе автономность каждого сервиса, что упрощает обслуживание и тестирование в изолированной среде по сравнению с монолитной архитектурой.
На рис. 1 показана простая архитектура на основе микросервисов, на примере которой наглядно представлен независимый, изолированный характер сервисов. Каждый конкретный сущностный объект, принадлежащий приложению, изолирован в своем сервисе. Например, UserService, OrderService и NotificationService ориентированы на различные части бизнеса.
Вся система разделена на сервисы. Эти сервисы не только управляются независимыми командами, которые используют свой собственный набор технологий, но даже масштабируются отдельно друг от друга.
Короче говоря, каждый сервис обслуживает конкретную предметную область бизнеса. Поэтому возникает вопрос — «Как разбить приложение на микросервисы?» Что ж, это тот случай, когда микросервисы сталкиваются с доменно-ориентированным проектированием (DDD).
Лайкосы / Подписки / Курсы
Что такое доменно-ориентированное проектирование?
Доменно-ориентированное проектирование (DDD) — это подход к разработке программного обеспечения, при котором особое внимание уделяется моделированию программного обеспечения на основе предметной области, которую оно обслуживает.
Сюда входит понимание и моделирование предметной области или пространства прикладной области приложения, что влечет за собой тесное сотрудничество между экспертами в предметной области и разработчиками программного обеспечения. Такое сотрудничество создает общее понимание предметной области и гарантирует, что разработанное программное обеспечение будет точно соответствовать ее особенностям.
Это означает, что микросервисы — это не только выбор набора технологий для вашего приложения. Прежде чем создавать свое приложение, вам необходимо понять, с какой предметной областью вы работаете. Это даст вам представление об уникальных бизнес-процессах, выполняемых в вашей организации, что позволит легко разделить приложение на очень маленькие микросервисы.
При этом создается распределенная архитектура, в которой ваши сервисы больше не нужно развертывать все вместе для одной цели. Вместо этого они развертываются отдельно, а также могут быть развернуты для групповых целей.
Что такое распределенные сервисы?
Распределенные сервисы относятся к архитектуре программного обеспечения и подходу к проектированию, при котором различные компоненты, модули или функции приложения распределяются по нескольким машинам или узлам в сети.
В современных компьютерных системах такой подход обычно используется для улучшения масштабируемости, доступности и отказоустойчивости. Как показано на рис. 1, микросервисы по своей природе представляют собой распределенные сервисы, поскольку каждый сервис изолирован от других и выполняется в своем собственном экземпляре.
Мгновенная генерация серверное приложение, готовое к работе в производственной среде
Больше не тратится время на повторяющееся кодирование.
В микросервисной архитектуре значительное внимание уделяется инфраструктуре, поскольку способ развертывания и управления микросервисами напрямую влияет на эффективность и масштабируемость системы.
Существует несколько способов решения проблем инфраструктуры в микросервисной архитектуре.
-
Контейнеризация. Микросервисы часто упаковываются в контейнеры, такие как Docker, которые инкапсулируют приложение и его зависимости, обеспечивая согласованность между средой разработки, тестовой средой и производственной средой. Контейнеризация упрощает развертывание и управление ресурсами инфраструктуры.
-
Оркестрация. Микросервисы, как правило, развертываются и управляются с помощью платформ оркестрации контейнеров, таких как Kubernetes. Kubernetes автоматизирует развертывание, масштабирование и управление контейнеризованными приложениями. Это гарантирует эффективное распределение микросервисов по узлам инфраструктуры и возможность восстановления после сбоев.
-
Обнаружение сервиса. Микросервисы должны обнаруживать друг друга и взаимодействовать друг с другом в динамическом режиме. Инструменты обнаружения сервисов, такие как встроенные механизмы обнаружения сервисов etcd, Consul или Kubernetes, помогают находить микросервисы, работающие на разных узлах инфраструктуры, и подключаться к ним.
-
Масштабируемость. В микросервисной архитектуре особое внимание уделяется горизонтальному масштабированию, при котором при необходимости можно добавлять дополнительные экземпляры микросервисов, чтобы справляться с возросшими рабочими нагрузками. Инфраструктура должна поддерживать динамическое распределение и масштабирование ресурсов по мере необходимости.
Как создать микросервис?
Первым шагом в создании микросервиса является разбивка приложения на набор сервисов. Разбивка монолитного приложения на микросервисы включает в себя процесс декомпозиции, при котором вы идентифицируете отдельные функциональные возможности в монолите и реорганизуете их в отдельные, независимые микросервисы.
Этот процесс требует тщательного планирования и учета различных факторов, как описано ниже.
-
Анализ монолита. Тщательно изучите существующее монолитное приложение, включая его архитектуру, зависимости и функциональные возможности.
-
Идентификация бизнес-возможностей. Определите отличительные бизнес-возможности или функциональные возможности монолита. Это могут быть функции, модули или сервисы, которые можно логически разделить.
-
Определение границ сервиса. Установите четкие границы для каждого микросервиса. Определите, за что будет отвечать каждый микросервис, и убедитесь, что эти обязанности согласованы и четко определены.
-
Разделение данных. Изучите зависимости данных и решите, как данные будут распределяться между микросервисами. Возможно, вам придется ввести репликацию данных, синхронизацию данных и отдельные базы данных для каждого микросервиса.
-
Коммуникационные протоколы. Определите коммуникационные протоколы и API-интерфейсы между микросервисами. Для взаимодействия между сервисами обычно используются интерфейсы RESTful API, gRPC или очереди сообщений.
-
Отдельные базы исходного кода. Создайте разные базы исходного кода для каждого микросервиса. Для этого может потребоваться извлечение соответствующего кода и функциональности из монолита в отдельные репозитории для хранения исходного кода или в виде пакетов при использовании стратегии монорепозитория.
-
Декомпозиция базы данных. Если монолитное приложение использует одну базу данных, возможно потребуется разделить базу данных на более мелкие базы данных или схему внутри базы данных для каждого микросервиса.
-
Реализация логики сервиса. Разработайте бизнес-логику для каждого микросервиса. Убедитесь, что каждый микросервис может работать автономно и выполнять свои конкретные функции.
-
Интеграция и тестирование. Проведите всестороннее комплексное тестирование, чтобы убедиться, что микросервисы могут взаимодействовать и работать вместе должным образом. Для поддержания качества кода используйте непрерывную интеграцию (CI) и автоматическое тестирование.
-
Документация. Ведите полную документацию для каждого микросервиса, включая документацию по API и руководство по использованию для разработчиков, которые будут взаимодействовать с сервисами.
После разбивки сервисов важно установить правильные стандарты обмена данными между вашими микросервисами.
Как микросервисы обмениваются данными друг с другом?
Обмен данными между сервисами — важный аспект, который следует учитывать при создании микросервисов. Поэтому, какой бы подход вы ни выбрали, важно обеспечить, чтобы такая передача данных была эффективной и надежной.
Существует две основные категории обмена данными на основе микросервисов
-
Обмен данными между сервисами
-
Обмен данными внутри сервиса
Обмен данными между сервисами
Обмен данными между сервисами в микросервисах касается взаимодействия отдельных микросервисов друг с другом и внутри микросервисной архитектуры.
Микросервисы могут использовать два фундаментальных подхода к обмену сообщениями для взаимодействия с другими микросервисами в обмене данными между сервисами.
Синхронная передача данных
Одним из подходов к внедрению обмена данными между сервисами является синхронная передача данных. Синхронная передача данных — это подход, при котором сервис вызывает другой сервис через такие протоколы, как HTTP или gRPC, и ждет, пока сервис не ответит.
Асинхронная передача сообщений
Второй подход — асинхронная передача сообщений. В этом случае сервис отправляет сообщение, не дожидаясь немедленного ответа.
Затем асинхронно один или несколько сервисов обрабатывают сообщение в своем собственном темпе.
Обмен данными внутри сервиса
Обмен данными внутри сервиса в микросервисах — это взаимодействие и обмен данными внутри одного микросервиса, с охватом различных компонентов, модулей и уровней, входящих в этот микросервис.
Проще говоря, в отличие от обмена данными между сервисами, которое предполагает взаимодействие между различными микросервисами, обмен данными внутри сервиса сосредотачивается на внутренней работе одного микросервиса.
Но, какой бы подход вы не выбрали, необходимо убедиться, что вы создаете идеальный баланс обмена данными, чтобы гарантировать, что в ваших микросервисах не происходит чрезмерного обмена данными. Потому что в таком случае это может привести к появлению «избыточных» («болтливых») микросервисов.
Что такое избыточность в обмене данных микросервисов?
«Избыточность» относится к ситуации, когда между микросервисами происходит чрезмерный или частый обмен данными.
Это означает, что микросервисы отправляют друг другу множество сетевых запросов или вызовов API, что может иметь ряд последствий и проблем, таких как снижение производительности, повышенная сложность, проблемы масштабируемости и сетевой трафик.
Рисунок: Избыточный микросервис
Как показано выше, UserService имеет чрезмерный обмен данными с OrderService и самим собой, что может привести к проблемам с производительностью и масштабированием из-за чрезмерного количества сетевых вызовов.
Как используется промежуточный слой в микросервисах?
Промежуточный слой играет решающую роль в микросервисной архитектуре, предоставляя услуги, инструменты и компоненты, которые облегчают обмен данными, интеграцию и управление микросервисами. Давайте обсудим некоторые варианты использования.
-
Связь между сервисами. Промежуточный слой предоставляет коммуникационные каналы и протоколы, которые позволяют микросервисам обмениваться данными друг с другом. Сюда могут входить брокеры сообщений, такие как RabbitMQ, Apache Kafka, платформы RPC, например, gRPC или RESTful API.
-
Обнаружение сервиса. Промежуточный слой для обнаружения сервисов помогает микросервисам находить другие микросервисы и подключаться к ним в динамическом режиме, особенно в динамических или контейнеризированных средах. В этом процессе помогают такие инструменты, как Consul, etcd или функции обнаружения сервисов Kubernetes.
-
API-шлюз. API-шлюз — это компонент промежуточного слоя, который служит точкой входа для внешних клиентов для доступа к микросервисам. Он может осуществлять аутентификацию, авторизацию, маршрутизацию запросов и агрегирование ответов от нескольких микросервисах.
-
Безопасность и аутентификация. Компоненты промежуточного слоя часто предоставляют функции безопасности, такие как аутентификация, авторизация и шифрование, для обеспечения безопасного обмена данными между микросервисами. Для повышения безопасности используются такие инструменты, как шлюзы безопасности OAuth2, JWT и API.
-
Мониторинг и ведение журналов. Промежуточный слой часто включает в себя компоненты мониторинга и ведения журналов, такие как ELK Stack, Prometheus и Grafana, для отслеживания работоспособности, производительности и поведения микросервисов. Это помогает при поиске и устранении неисправностей и оптимизации производительности.
Создание микросервисов с помощью Node.js
Создание микросервисов с помощью Node.js стало популярным выбором благодаря неблокируемой, событийно-ориентированной архитектуре Node.js и обширной экосистеме библиотек и платформ.
Если вы хотите создать микросервисы с помощью Node.js, есть способ значительно ускорить этот процесс за счет использования инструмента Amplication.
Amplication — это бесплатный инструмент с открытым исходным кодом, предназначенный для разработки серверных компонентов приложения интернета. Он ускоряет разработку приложений Node.js за счет автоматического создания полнофункциональных приложений со стереотипным кодом — вам останется просто добавить свою собственную бизнес-логику. Это упрощает процесс разработки и повышает производительность, позволяя вам сосредоточиться на своей основной цели: создании отличных приложений. Узнайте больше здесь.
Понимание основ REST API.
REST (передача состояния представления) — это архитектурный стиль разработки сетевых приложений. REST APIs (интерфейсы прикладного программирования) — это способ предоставить функциональные возможности системы или сервиса другим приложениям через HTTP-запросы.
Как создать конечную точку REST API?
Существует множество способов разработки REST API. Здесь мы используем инструмент Amplication. Это можно сделать всего за несколько кликов.
Процесс создания REST API можно посмотреть на скриншотах, приведенных ниже.
1. Нажмите на кнопку “Добавить новый проект”.
Это позволяет клиентской части приложения взаимодействовать с сервисом серверной части и получать данные от него.
Шаблон BFF (Backend For Frontend) — это шаблон архитектурного проектирования, используемый для разработки приложений на основе микросервисов, особенно с разнообразными клиентскими интерфейсами, такими как веб-сайты, мобильные устройства и другие устройства. Шаблон BFF предполагает создание отдельного серверного сервиса для каждого внешнего приложения или типа клиента.
Рассмотрим внешнее пользовательское приложение, состоящее из двух компонентов: приложения на стороне клиента, находящегося за пределами вашей системы, и серверного компонента, известного как BFF (Backend For Frontend), в границах вашей системы. BFF — это вариант шаблона API-шлюза, но он добавляет дополнительный уровень между микросервисами и каждым типом клиента. Вместо единой точки входа в систему вводится несколько шлюзов.
Такой подход позволяет создавать собственные API-интерфейсы, адаптированные к конкретным требованиям каждого типа клиента, например мобильного устройства, веб-сайта, настольного компьютера, голосового помощника и т. д. Это устраняет необходимость объединять все в одном месте. Более того, исключается влияние на ваши серверные сервисы конкретных проблем API-интерфейса, зависящих от типа клиента: ваши серверные сервисы могут обслуживать «чистые» проблемно-ориентированные API-интерфейсы, а все переносы, специфичные для клиента, находятся в BFF. Эта концепция показана на схеме ниже.
Источник: https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0
Микросервисы + Безопасность
Безопасность — важнейший аспект при создании микросервисов. Только авторизованные пользователи должны иметь доступ к вашим API-интерфейсам. Итак, как вы можете защитить свои микросервисы?
Выберите механизм аутентификации
Защитите свои микросервисы, используя аутентификацию на основе маркеров (JWT или OAuth 2.0), API-ключи или аутентификацию на основе сеанса, в зависимости от требований вашего приложения.
Централизованный сервис аутентификации
При наличии нескольких микросервисов рассмотрите возможность использования централизованного сервиса аутентификации. Это позволяет пользователям пройти аутентификацию один раз и получить маркеры для последующих запросов. Если вы используете API-шлюз, аутентификация и авторизация обычно объединены там.
Защищенная связь
Чтобы предотвратить подслушивание и перехват данных, убедитесь, что связь между микросервисами и клиентами зашифрована с помощью протоколов TLS (обычно HTTPS) или других защищенных протоколов.
Внедрение промежуточного слоя аутентификации
Каждый микросервис должен иметь промежуточный слой аутентификации для проверки входящих запросов. Проверьте маркеры или учетные данные и получите идентификационные данные пользователя.
Проверка маркеров
Для аутентификации на основе маркеров для проверки маркеров JWT или маркеров OAuth 2.0 используйте библиотеки или платформы, поддерживающие проверку маркеров. Выполните проверки срока действия маркера.
Управление пользователями и ролями
Внедрите управление пользователями и ролями в каждом микросервисе или используйте внешнего поставщика идентификационных данных для управления идентификационными данными и полномочиями пользователей.
Ролевое управление доступом (RBAC)
Внедрите RBAC для определения ролей и полномочий. Назначайте роли пользователям и используйте их для управления доступом к определенным конечным точкам или ресурсам микросервиса.
Промежуточный слой авторизации
Включите промежуточный слой авторизации в каждый микросервис для реализации управления доступом на основе ролей и полномочий пользователей. Такой промежуточный слой должен проверять, имеет ли аутентифицированный пользователь необходимые полномочия для выполнения запрошенного действия.
Точное управление доступом
Рассмотрите возможность реализации точного управления доступом для управления доступом к отдельным ресурсам или наборам данных в микросервисе на основе атрибутов пользователя, ролей или владения.
В целом важно учитывать 10 основных рисков, связанных с нарушением безопасности API OWASP, и реализовывать превентивные стратегии, которые помогут преодолеть эти риски нарушения безопасности API-интерфейса.
💡Совет от профессионала. Когда вы создаете микросервисы с использованием инструмента Amplication, многие из вышеперечисленных проблем уже решаются автоматически — каждый созданный сервис включает в себя встроенный промежуточный слой аутентификации и авторизации. Вы можете легко управлять ролями и полномочиями для своих API-интерфейсов из интерфейса Amplication, а сгенерированный код уже будет включать соответствующие декораторы промежуточного слоя (охранные условия) для обеспечения авторизации на основе того, что вы задали в Amplication.
Тестирование микросервисов
Модульное тестирование
Модульное тестирование микросервисов включает тестирование отдельных компонентов или модулей микросервиса в изолированной среде, чтобы проверить правильность их функционирования.
Такое тестирование предназначено для проверки поведения тестируемых частей самого низшего порядка вашего микросервиса, таких как функции, методы или классы, без внешних зависимостей.
Например, в нашем микросервисе, который мы создали ранее, мы можем выполнить модульное тестирование OrderService, моделируя его базу данных и внешние вызовы API и проверяя, что OrderService сама по себе не содержит ошибок.
Тестирование взаимодействия компонентов системы
Тестирование взаимодействия компонентов системы включает проверку правильности совместной работы различных микросервисов при взаимодействии в рамках более крупной системы.
Такое тестирование проверяет эффективность взаимодействия и обмена данными между интегрированными микросервисами.
Развертывание микросервисов в производственной среде
Развертывание микросервисов в производственной среде требует тщательного планирования и выполнения, чтобы обеспечить стабильность, надежность и масштабируемость вашего приложения. Давайте рассмотрим некоторые основные шаги и их особенности.
-
Контейнеризация и оркестрация. Сначала нам нужно контейнеризировать микросервисы, используя такие технологии, как Docker. Контейнеры обеспечивают согласованность в среде разработки, тестовой среде и производственной среде. Для управления контейнерами и их развертывания с поддержкой масштабирования используйте платформы оркестрации контейнеров, такие как Kubernetes.
-
💡 Вы знали? Amplication предоставляет Dockerfile для контейнеризации ваших сервисов в готовом виде и имеет плагин для создания Helm Chart для ваших сервисов, чтобы упростить оркестрацию контейнеров.
-
Инфраструктура, представленная как код (IaC). Определите свою инфраструктуру с помощью кода (IaC) для автоматизации предоставления ресурсов, таких как виртуальные машины, балансировщики нагрузки и базы данных. В этом могут помочь такие инструменты, как Terraform, Pulumi и AWS CloudFormation.
-
Непрерывная интеграция и непрерывное развертывание (CI/CD). Внедрите конвейер сборки для автоматизации сборки, тестирования и развертывания микросервисов. Этот конвейер должен включать модульное тестирование, комплексное тестирование и этапы автоматизированного развертывания.
-
💡 Вы знали? У инструмента Amplication есть плагин для GitHub Actions, который создает начальный конвейер CI для вашего сервиса!
-
Настройка среды. Поддерживайте отдельные настройки среды, такие как разработка, конвейеризация и производство, чтобы обеспечить согласованность и свести к минимуму человеческие ошибки во время развертываний.
-
Управление учетными цифровыми идентификационными данными. Надежное хранение важных параметров конфигурации и учетных цифровых идентификационных данных обеспечивается с помощью таких инструментов, как AWS Secrets Manager или HashiCorp Vault. Избегайте жесткого кодирования учетных цифровых идентификационных данных в коде или файлах конфигурации.
-
Мониторинг и регистрация. Внедряйте решения для мониторинга и ведения журналов, чтобы отслеживать работоспособность и производительность ваших микросервисов в режиме реального времени. Могут помочь такие инструменты, как Prometheus, Grafana и ELK Stack (Elasticsearch, Logstash, Kibana).
-
💡 Правильно! Вы угадали! У инструмента Amplication есть плагин для OpenTelemetry, который отслеживает созданные вами сервисы и отправляет их в Jaeger
Масштабирование микросервисов
Масштабирование микросервисов включает в себя настройку мощности вашего приложения на основе микросервисов для обработки возросших нагрузок, трафика или объема данных при сохранении производительности, надежности и оперативности. Масштабирование может осуществляться вертикально (увеличение масштаба) и горизонтально (уменьшение масштаба). Ключевым преимуществом микросервисной архитектуры по сравнению с монолитной архитектурой является возможность индивидуального масштабирования каждого микросервиса, что обеспечивает экономичную работу (как правило, высокая нагрузка влияет только на отдельные микросервисы, а не на все приложение).
Вертикальное масштабирование
Вертикальное масштабирование означает обновление ресурсов отдельного экземпляра микросервиса, таких как ЦП и память, для эффективного управления более высокими рабочими нагрузками.
Главный плюс такого подхода — нет необходимости беспокоиться о том, чтобы архитектура имела нескольких экземпляров одного и того же микросервиса, и о том, как их координировать и синхронизировать. Это простой подход, не требующий изменения архитектуры или кода. Недостатками этого подхода являются: а) вертикальное масштабирование в конечном итоге оказывается ограниченным (в одном экземпляре можно выделить лишь ограниченное количество ОЗУ и ЦП) и очень быстро становится дорогостоящим; б) это может потребовать некоторого простоя, поскольку во многих случаях вертикальное масштабирование экземпляра включает в себя предоставление нового, более крупного экземпляра, а затем перенос микросервиса для работы на новом экземпляре.
Горизонтальное масштабирование
Горизонтальное масштабирование предполагает добавление дополнительных экземпляров микросервиса для распределения рабочей нагрузки и обработки возросшего трафика. Обычно во многих случаях рекомендуется этот подход к масштабированию, поскольку он дешевле (в большинстве случаев) и обеспечивает «бесконечное масштабирование». Кроме того, при использовании этого метода очень легко выполнить обратное масштабирование — достаточно удалить некоторые экземпляры. Однако требуется некоторое архитектурное планирование, чтобы обеспечить идеальную совместную работу нескольких экземпляров одного и того же микросервиса с точки зрения согласованности, координации и синхронизации данных, проблем с привязыванием сеансов и отсутствия блокировки взаимных ресурсов.
Распространенные проблемы и лучшие методы
Микросервисная архитектура предлагает множество преимуществ, но имеет и свои проблемы.
Масштабируемость
-
Проблема. Масштабирование отдельных микросервисов при сохранении общей производительности системы может оказаться сложной задачей.
-
Лучшие методы. Внедрите автоматическое масштабирование на основе метрических показателей в режиме реального времени. Для эффективного масштабирования используйте платформы оркестрации контейнеров, такие как Kubernetes. Проведите тестирование производительности для выявления узких мест.
Защита
-
Проблема. Обеспечение безопасности нескольких микросервисов и управление аутентификацией и авторизацией может быть сложной задачей.
-
Лучшие методы. Внедрите модель безопасности на основе нулевого доверия с надлежащей аутентификацией, например OAuth 2.0, и авторизацией, например RBAC. Используйте API-шлюзы для обеспечения безопасности. Регулярно обновляйте и исправляйте зависимости для устранения уязвимостей безопасности.
Развертывание и DevOps
-
Проблема. Координация развертываний и управление конвейером сборки для большого количества микросервисов может оказаться сложной задачей.
-
Лучшие методы. Внедрите надежный конвейер сборки с автоматизированными процессами тестирования и развертывания. Используйте контейнеризацию, например Docker, и оркестрацию контейнеров, например Kubernetes, для обеспечения согласованности и масштабируемости. Убедитесь, что каждый микросервис полностью автономен с точки зрения развертывания.
Управление версиями и API
-
Проблема. Управление версиями API и обеспечение обратной совместимости имеют решающее значение, когда от API зависят несколько сервисов.
-
Лучшие методы. Используйте версионированный API-интерфейс и по возможности вносите обратно совместимые изменения. Для управления версиями и преобразования внедрите шлюзы API.
Мониторинг и отладка
-
Проблема. Отладка и мониторинг микросервисов в распределенной системе затруднены. Гораздо проще отслеживать поток запроса в монолите, чем отслеживать запрос, обрабатываемый распределенно.
Обработка транзакций базы данных
Обработка транзакций базы данных в микросервисной архитектуре может быть сложной из-за распределенного характера системы.
Микросервисы часто имеют собственные базы данных, и обеспечение согласованности данных и поддержание целостности транзакций между сервисами требует тщательного планирования и использования соответствующих стратегий.
Как показано выше, наличие одной базы данных для каждого микросервиса помогает удовлетворить более строгие требования к моделированию данных и даже позволяет выполнять автономное масштабирование базы данных. Таким образом, у вас будет больше гибкости в устранении узких мест на уровне БД.
Следовательно, при создании микросервисов часто рекомендуется иметь отдельную базу данных для каждого сервиса. Но есть определенные моменты, которые следует учитывать при этом.
1. Микросервисы и изоляция данных. Каждый микросервис должен иметь свою базу данных. Такая изоляция позволяет сервисам управлять данными независимо, не мешая другим сервисам.
2. Распределенные транзакции. По возможности избегайте распределенных транзакций. Они могут быть сложны в реализации и могут оказывать негативное влияние на производительность системы. Используйте их в крайнем случае, когда другой вариант невозможен.
3. Окончательная согласованность. Используйте модель окончательной согласованности. В микросервисной архитектуре часто допускается временная несогласованность данных между сервисами, но в конечном итоге они должны прийти к согласованному состоянию.
4. Использование шаблона Saga. Внедрите шаблон Saga для управления длительными и многоэтапными транзакциями в нескольких микросервисах. Шаблоны Saga состоят из локальных транзакций и компенсирующих действий для поддержания согласованности.
DevOps с микросервисами
Методологии DevOps необходимы при работе с микросервисами, чтобы обеспечить слаженное сотрудничество между командами разработки и операционными группами, автоматизировать процессы и поддерживать гибкость и надежность, необходимые в микросервисной архитектуре.
Вот некоторые важные замечания по DevOps с микросервисами.
Автоматизация
Непрерывная интеграция (CI)
Внедряйте конвейеры CI, которые автоматически создают, тестируют и упаковывают микросервисы каждый раз, когда изменения кода передаются в репозитории системы управления версиями.
Технология непрерывного развертывания ПО (CD)
Автоматизируйте процесс развертывания новых версий микросервисов в различных средах, таких как предварительный просмотр, промежуточная и производственная среда.
Инфраструктура, представленная как код (IaC)
Используйте инструменты IaC, такие как Terraform, Pulumi или AWS CloudFormation, для автоматизации предоставления и настройки ресурсов инфраструктуры, включая контейнеры, виртуальные машины, сетевые ресурсы, ресурсы хранения информации и т. д.
Контейнеризация
Используйте технологии контейнеризации, такие как Docker, для согласованной упаковки микросервисов и их зависимостей. Это обеспечивает согласованную работу микросервисов в различных средах. Внедряйте платформы оркестрации контейнеров, такие как Kubernetes или Docker Swarm, для автоматизации развертывания, масштабирования и управления контейнеризированными микросервисами.
Мониторинг микросервисов
Внедряйте инструменты мониторинга и наблюдения, чтобы отслеживать работоспособность и производительность микросервисов в режиме реального времени. Собирайте метрические показатели, журналы и трассировки для быстрой диагностики проблем. Для комплексного мониторинга используйте такие инструменты, как Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), а также трассировку распределенных систем, например, Zipkin или Jaeger.
Стратегии развертывания
Внедряйте стратегии развертывания, такие как технологии развертывания обновлений и исправлений приложения без малейшего перерыва в обслуживании клиентов и пробные релизы, чтобы свести к минимуму время простоя и риски при развертывании новых версий микросервисов. Автоматизируйте возвраты к предыдущему состоянию при обнаружении проблем после развертывания, обеспечивая быстрый процесс восстановления.
Заключение
В этом подробном руководстве мы углубились в мир микросервисов, рассмотрели концепции, архитектуру, преимущества и проблемы этого революционного подхода к разработке программного обеспечения. Микросервисы предлагают гибкость, масштабируемость и оптимизированную пригодность для обслуживания, но они также требуют тщательного планирования, проектирования и управления для полной реализации своего потенциала. Разбивая монолитные приложения на более мелкие, независимо развертываемые сервисы, организации могут быстрее и гибче реагировать на меняющиеся потребности бизнеса.
Мы рассмотрели такие темы, как создание микросервисов с помощью Node.js, обеспечение безопасности в микросервисах, тестирование микросервисов и важность четко определенных API-интерфейсов. Методологии DevOps имеют решающее значение для успешного внедрения микросервисов, облегчения автоматизации, непрерывной интеграции и непрерывного развертывания ПО. Инструменты мониторинга и наблюдения помогают поддерживать работоспособность системы, а для защиты конфиденциальных данных используются методики обеспечения безопасности.
Приступая к разработке микросервисов, помните, что не существует универсального решения, подходящего всем. Микросервисы должны быть адаптированы к конкретным потребностям и ограничениям вашей организации. Принимая эту архитектуру, учитывайте такие факторы, как командная культура, набор профессиональных навыков и существующая инфраструктура.
Удачи вам в создании идеальной микросервисной архитектуры, и я очень надеюсь, что этот пост в блоге окажется для вас полезным.