В прошлом тексте мы подробно разобрали API и REST API. Сегодня раскроем понятие микросервисной архитектуры и поговорим о микросервисах, которые часто работают в связке с API.
Что такое микросервисы
Микросервисы - это сервисы для выполнения одной логической задачи. Они могут общаться между собой через API (о чем поговорим дальше), но они не знают о внутреннем устройстве друг друга. Такое взаимодействие между микросервисами называют микросервисной архитектурой, на основе которой создаются приложения с независимыми сервисами, которые развертываются отдельно друг от друга.
Особенности микросервисной архитектуры становятся очевидными в сравнении с двумя другими популярными типами архитектуры - монолитной и сервис-ориентированной. Поэтому начнем мы с разбора преимуществ и недостатков этих подходов, а затем вернемся к микросервисам.
Монолитная архитектура
В разработке монолитная архитектура считается классическим методом. Приложение на базе монолита представляет из себя единый модуль, который состоит из объединенных компонентов. В структуре такого приложения, как правило, можно выделить три основных модуля: клиентский пользовательский интерфейс, бизнес-логику и базу данных. Все функции управляются в одном месте.
Монолитная архитектура поощряет тесную взаимосвязь компонентов. Конечно, это бывает полезно, но с масштабированием приложения неминуемо повышается и его сложность. Любые изменения негативно сказываются на скорости обработки задач, поэтому для масштабирования приходится задействовать новые серверы, в результате чего начинается неравномерное распределение ресурсов.
В монолитной архитектуре, как правило, используют большую реляционную базу данных, единую для всего приложения. Это делает всю архитектуру громоздкой и менее эффективной.
| МОНОЛИТНАЯ АРХИТЕКТУРА | |||
|---|---|---|---|
| ПЛЮСЫ | МИНУСЫ | ||
| Простая разработка и развертывание. С одной кодовой базой и каталогом (или исполняемым файлом) приложение легче разрабатывать, а развертывание сильно упрощается. К тому же существует множество инструментов для интеграции и облегчения работы. | Увеличение кодовой базы. Со временем размывается структура продуктов, кодовую базу становится сложнее понимать. | ||
| Простая работа с межкомпонентными задачами. Благодаря единой кодовой базе проблемы, которые возникают между компонентами программы, практически отсутствуют. | Сложности в масштабировании. Чтобы добавить функционал, может потребоваться переписать все приложение. Конечно же, на это уйдет много времени и денег. | ||
| Высокая производительность. Еще один плюс единого кода - быстрая межкомпонентная связь. | Отсутствие гибкости. Нужно исправить баг, внедрить новые фичи или обновления? Придется снова развертывать приложение. | ||
Хоть минусы монолитной архитектуры и существенны, в некоторых случаях уместно использовать именно ее. Например, монолит часто используют небольшие команды, которым важно быстрее запустить новый продукт. Но с масштабированием ограничения монолита начинают сказываться сильнее, чем его преимущества. Эта проблема дала толчок для развития сервис-ориентированного подхода.
Сервис-ориентированная архитектура (SOA)
SOA подразумевает создание модульного приложения, которое состоит из слабосвязанных программных компонентов. Концепция этого типа архитектуры заключается в легкой интеграции и повторном использовании модулей приложения.
Важная особенность такого подхода - наличие сервисной шины (enterprise service bus). Это связующее ПО для управления операциями. При необходимости шина также осуществляет преобразование данных.
Деление на модули позволяет небольшим командам сосредотачиваться только на одном сервисе, что сильно сокращает циклы разработки. Сервис - это компонент ПО, предоставляющий определенную функциональность. Он может быть использован другими компонентами или взаимодействовать с внешними системами. В качестве примера можно привести сервис по отправке писем (почтовый сервис) или сервис, который выстраивает получаемые сообщения в очередь.
В отличие от монолита, в SOA база данных не является центральным компонентом архитектуры. Она используется для хранения данных, которые необходимы для работы сервисов. Сервисы могут взаимодействовать с базой данных через специальные интерфейсы, которые обеспечивают доступ к необходимым данным.
| СЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА | |||
|---|---|---|---|
| ПЛЮСЫ | МИНУСЫ | ||
| Многократное использование сервисов. Слабая связь функциональных компонентов позволяет использовать их в разных реализациях. Например, для тестирования и основной бизнес-логики. | Сложное управление службами. Некоторые службы часто отправляют и получают сообщения. Количество таких запросов может достигать миллиона в день. | ||
| Простая поддержка. Так как сервисы независимы, они могут быть легко заменяемы и масштабируемы, что сильно упрощает разработку и сопровождение приложений. | Необходимость больших инвестиций. Для разработки приложения на базе сервис-ориентированной архитектуры нужны серьезные инвестиции. | ||
| Параллельная разработка. Деление на прослойки позволяет одновременно разрабатывать несколько сервисов и завершать их одновременно. | Дополнительная нагрузка. Проверка входных данных должна происходить до взаимодействия сервисов. Это снижает общую производительность, если вы используете несколько сервисов. | ||
По сравнению с монолитом, принципы SOA позволили сократить срок выхода на рынок бизнес-приложений, облегчить их дальнейшее обслуживание и улучшить адаптивность. Со временем SOA эволюционировала, прежние решения становились неэффективными, а технологии менялись. В результате у сервис-ориентированной архитектуры появился отдельный подтип, который стал развиваться параллельно - микросервисная архитектура.
Микросервисная архитектура
Микросервисная архитектура предполагает разделение разработки ПО на набор небольших (еще меньше, чем в SOA) слабосвязанных (или вовсе автономных) модульных сервисов. Каждый такой микросервис представляет отдельную часть ПО, реализует одну функциональность и имеет свою базу данных. Кроме этого, разрабатывать и масштабировать микросервисы можно отдельно друг от друга.
В определении моделей предметной области и правил взаимодействия между сервисами помогает методология разработки ПО DDD (Domain Driver Design). Этот подход предназначен для создания более качественных и гибких систем и фокусируется на понимании предметной области и построении архитектуры системы исходя и бизнес-правил и потребностей этой предметной области.
В сочетании с микросервисной архитектурой метод DDD используется для создания модульных и слабосвязанных микросервисов. В этом случае каждый микросервис представляет собой домен, который имеет свою бизнес-логику и соответствует определенной предметной области. Таким образом получаются гибкие и масштабируемые системы, которые могут адаптироваться к изменяющимся требованиям и нагрузкам.
Для более наглядной работы микросервисов приведем простой пример.
-
Пользователь направляет запрос через UI
-
Пользовательский интерфейс делает запрос в отдельный сервис аутентификации (Auth service)
-
Чтобы проверить, есть ли у пользователя возможность зайти на запрашиваемую страницу, Auth service отправляет запрос в Active directory service
-
Список доступов для пользователей через запрос в базу данных проверяет наличие доступа у пользователя и возвращает данные в сервис аутентификации
-
Auth service понимает, что доступ у пользователя есть, и пускает его в логику программы, которая выдает пользователю ответ на запрос
Этот пример мы визуализировали ниже на изображении. Важно отметить, что все описанное взаимодействие происходит между отдельными сервисами, которые помещены в докер контейнер.
Кажется, что микросервисная архитектура лишь добавляет сложности, ведь появляется множество маленьких сервисов. Но, вместе с тем, появляется и ряд существенных преимуществ. Дополнительные сервисы в такой системе можно встраивать без повреждения общей логики. Каждый сервис автономен, поэтому изменения в одном сервисе не отражаются на других.
При создании распределенных приложений используются также технологии Service Broker и Service Discovery. Service Broker системы позволяют разработчикам легко создавать и управлять приложениями, состоящими из множества микросервисов. Они помогают разделять приложение на несколько независимых сервисов, каждый из которых может быть развернут на отдельном сервере или контейнере.
Благодаря механизму Service discovery сервисы могут находить друг друга и обмениваться информацией о доступности и настройках. В микросервисной архитектуре используют Service discovery для автоматической конфигурации сервисов, обнаружения и разрешения зависимостей между ними. Благодаря SD сервисы могут автоматически адаптироваться к изменениям в конфигурации или при добавлении новых сервисов.
Для работы с базами данных в микросервисах используются различные технологии и инструменты, такие как ORM (Object-Relational Mapping), NoSQL базы данных, API и т.д. Каждый сервис может использовать свою собственную базу данных или же обращаться к общей базе данных через API.
| МИКРОСЕРВИСНАЯ АРХИТЕКТУРА | |||
|---|---|---|---|
| ПЛЮСЫ | МИНУСЫ | ||
| Легкий и быстрый деплой. Это достигается благодаря независимому созданию, тестированию и развертыванию микросервисов. | Сложный мониторинг. Отследить работу каждого микросервиса, когда их сотни или тысячи, физически невозможно. Поэтому нужно работать с системами управления и мониторинга. | ||
| Повышенная гибкость. Можно работать над отдельными частями приложения, а компоненты обновлять без его отключения. При необходимости откатить изменения можно также просто, как и внедрить их. | Проблемы безопасности. Данные между микросервисами передаются по сети. Это повышает риск утечки, а следовательно необходимо принимать дополнительные меры защиты. | ||
| Возможность масштабирования. Можно масштабировать только необходимые части системы, а для других использовать более слабое железо. | Разные языки программирования. Если вы для каждого микросервиса будете использовать свой язык программирования, это, конечно, усложнит развертывание. Важно придерживаться разумного подхода в вопросе использования технологий. | ||
Теперь, разобравшись с понятием микросервисной архитектуры, мы можем перейти к взаимодействию микросервисов друг с другом с помощью API.
Как микросервисы работают в связке с API
Итак, как мы уже с вами поняли, микросервисы работают на основе принципа разделения обязанностей и функций. Вместе множество маленьких сервисов (их могут быть тысячи) образуют один макросервис.
Каждый микросервис программного приложения имеет только одну задачу, но вот объем таких задач зависит уже от разработчиков и концепции самого приложения.
Для упрощения децентрализации серверов в микросервисной архитектуре используются контейнерные технологии. Контейнеры инкапсулируют код с зависимостями в отдельную изолированную среду, которую можно затем перенести в облако.
Конечно, в наборе изолированных модулей нет большой пользы для приложения. Поэтому микросервисы связываются друг с другом с помощью API.
Их взаимодействие похоже на использование общедоступного API одним приложением для интеграции с другим. Только в случае взаимодействия микросервисов используется частный API, который есть у каждого микросервиса. Он определяет запросы, которые сервис может получать, а также способ ответа на них.
Такие API обычно следуют принципам REST, о которых мы говорили в предыдущей статье, или GRPC. Вот как схематично можно описать работу микросервисов, связанных по API.
В данном примере только один микросервис взаимодействует со сторонними разработчиками и выполняет функцию интеграции с другими приложениями. Именно его API общедоступный, а все остальные - частные.
Важно понимать, что API в микросервисной архитектуре может использоваться по-разному, и изображение выше это лишь иллюстрация общей концепции взаимодействия микросервисов и API. В каких-то случаях один микросервис может использовать несколько API, в других один API используется для доступа к нескольким микросервисам и т.д.
Коротко о микросервисной архитектуре
Микросервисная архитектура - подтип сервис-ориентированной архитектуры, который основан на взаимодействии слабосвязанных или автономных сервисов, выполняющих небольшие ограниченные функции. Они взаимодействуют друг с другом с помощью API и могут независимо масштабироваться. Для развертывания микросервисных приложений используют Kubernetes и Docker.
Микросервисная архитектура дает множество преимуществ для гибкой разработки, но чтобы их использовать, важно внимательно подойти к управлению и взаимодействию микросервисов. Создать надежную систему можно только за счет правильного планирования, тестирования, мониторинга и обеспечения безопасности.
Несмотря на то, что микросервисная архитектура считается современным и самым актуальным подходом к разработке продукта, ее использование уместно далеко не всегда. В определенных случаях использование микросервисов может привнести лишнюю сложность в эксплуатацию системы, поэтому будет гораздо уместнее использовать монолитный подход. К тому же, далеко не любой продукт можно просто разделить на маленькие независимые части.
Чтобы обеспечить высокую доступность, микросервисы разворачивают на разных серверах или даже в разных дата-центрах. Для этих целей вы можете воспользоваться услугами 1cloud.
