Разработка
Что такое микросервисы и как их использовать
Архитектура микросервисов или просто микросервисы — это SDLC-подход, на основе которого большие приложения создаются как набор небольших функциональных модулей
Микросервисы стали предпочтительной платформой для разработки облачных приложений. Nginx провел опрос и обнаружил, что около 70% организаций либо используют, либо думают об использовании микросервисов, причем почти треть компаний в настоящее время использует их в производственной среде. Gartner, глобальная исследовательская и консалтинговая компания, определяет микросервис как:
Сервисно-ориентированный компонент приложения, который имеет узкую область видимости, сильную инкапсуляцию, слабую связь, независимое развертывание и независимое масштабирование.
Эта статья посвящена микросервисам. Давайте начнем.
Так такое микросервисы?
Архитектура микросервисов или просто микросервисы — это SDLC-подход, на основе которого большие приложения создаются как набор небольших функциональных модулей. Эти функциональные модули независимо развертываются, масштабируются, нацелены на конкретные бизнес-цели и обмениваются данными друг с другом по стандартным протоколам, таким как HTTP, с помощью API-интерфейсов и облегченного асинхронного обмена сообщениями.
Основным преимуществом архитектуры микросервисов является то, что модули могут быть реализованы с использованием разных языков программирования, иметь свои собственные базы данных и развертываться в различных программных средах, таких как локальная или облачная.
Преимущества микросервисов
У микросервисов есть много преимуществ, которые действительно дают разработчикам преимущество перед монолитными приложениями.
- Несколько сервисов могут быть развернуты независимо в разных средах, таких как локальные или облачные.
- Несколько сервисов могут быть разработаны независимо на основе функциональности.
- Если какая-либо из служб выйдет из строя, другие службы будут продолжать работать, поскольку это изолирует неисправность отказавшей службы.
- В микросервисах проще масштабировать отдельные компоненты, поскольку масштабирование других компонентов не требуется, в отличие от монолитной архитектуры.
- Для разработки разных компонентов в одном приложении можно использовать несколько разных технологий.
Недостатки микросервисов
Микросервисы могут быть модным трендом, но у архитектуры есть недостатки. Вообще, главный минус микросервисов — сложность любой распределенной системы. Вот список некоторых потенциальных проблемных областей и других недостатков, связанных с дизайном микросервисов:
- Связь между сервисами сложна: поскольку теперь все является независимым, вы должны тщательно обрабатывать запросы, перемещающиеся между вашими модулями.
- Больше сервисов — больше ресурсов: несколько баз данных и управление транзакциями может быть сложным.
- Глобальное тестирование усложняется: тестирование приложения на основе микросервисов может быть обременительным. Каждая зависимая служба должна быть подтверждена до начала тестирования.
- Проблемы с отладкой: у каждой службы есть собственный набор логов, которые необходимо просмотреть.
- Проблемы с развертыванием: продукту может потребоваться координация между несколькими службами.
- Крупные и мелкие продуктовые компании: микросервисы отлично подходят для крупных компаний, но могут быть медленнее в реализации и слишком сложны для небольших компаний, которым нужно быстро создавать и выполнять итерацию, и не хотят увязать в сложной оркестровке.
Монолит против Сервис-ориентированного подхода против Микросервисного
- Монолитная архитектура похожа на большой контейнер, в котором все программные компоненты приложения собраны вместе и плотно упакованы.
- Сервис-ориентированная архитектура — это набор сервисов, которые взаимодействуют друг с другом. Взаимодействие может включать либо простую передачу данных, либо два или более сервиса, координирующих некоторую деятельность.
- Микросервисная архитектура — это архитектурный стиль, который структурирует приложение как набор небольших автономных сервисов, смоделированных вокруг бизнес-домена.
Когда стоит использовать микросервисы?
Когда вы работаете с монолитным приложением, и оно разрастается до такой степени, что возникают проблемы с масштабированием или, возможно, когда вы не можете повторно использовать компоненты в разных проектах или платформах, а внедрение новых функций становится болезненно сложным и подверженным ошибкам, можно использовать микросервисы.
При запуске новых приложений вы определенно захотите, чтобы они были легко масштабируемыми, поддерживаемыми, развертываемыми и тестируемыми. С помощью микросервисов их можно реализовать более эффективно и использовать на различных платформах.
Netflix: сотни микросервисов, один гигантский продукт
Давайте на одном простом примере попытаемся понять, как с технологической стороны выглядят микросервисы. Допустим, ваше приложение с картами постоянно отслеживает ваше местоположение и сохраняет комплексную информацию о ваших перемещениях в файле locations.txt. Вы создали приложение под названием LocoList, которое ищет этот файл locations.txt на вашем телефоне и показывает все эти места в простом списке. Оно работает идеально.
Но потом разработчики приложения с картами решили, что лучше будет хранить информацию о вашем местоположении в другом месте, и обновили приложение, которое теперь не хранит этот файл на вашем телефоне. Теперь LocoList не может найти файл locations.txt, и вы не можете получить эту информацию из карт. LocoList перестает работать.
Вся ваша работа над LocoList проведена впустую, потому что изменение в Картах сломало ваше приложение. Это может показаться не таким важным моментом, но в огромном сервисе вроде Netflix изменение в одной части не только разрушит впечатления пользователей, но и приведет к тому, что другие части придется переписывать, чтобы приспособить их к этому изменению. Это называется монолитной архитектурой.
Около десяти лет назад Netflix произвел революцию, создав архитектуру микросервисов, в которой любые приложение, код и ресурсы не зависят друг от друга. Если двум приложениям нужно связаться, они используют API, конкретный набор правил, который действует для обеих программ. Разработчики могут вносить изменения в каждое приложение, если это соответствует API. И так как программы знакомы с API друг друга, обмен информацией не прекратится из-за внесенных изменений.
По оценке Netflix, сервис использует около 700 микросервисов, чтобы контролировать каждую часть продукта: один микросервис хранит информацию о просмотренных сериалах, другой списывает ежемесячную плату с карты, ещё один предоставляет вашему устройству необходимые видеофайлы, ещё один изучает вашу историю, чтобы предложить список фильмов, которые вам могут понравиться, и ещё один предоставляет названия и изображения этих фильмов для главного меню. Это только вершина айсберга. Разработчики Netflix могут вносить изменения в любую часть приложения, будучи уверенными, что сервис будет работать исправно.
Почему архитектура микросервисов так важна для Netflix? Вот чего им удалось достичь с её помощью:
Где они запускают все микросервисы?
Чтобы запустить все эти сервисы, вам нужна мощная сеть серверов. У Netflix ранее было собственное оборудование, но они поняли, что при такой скорости роста им будет сложно создавать масштабируемые системы, которые будут поддерживать их сервис. Компания приняла смелое решение избавиться от собственных серверов и переместить всё, что у них есть, в облако, то есть запустить всё на серверах другой компании, которая будет заботиться об оборудовании, пока разработчики Netflix будут писать программы и разворачивать их на серверах. Для своей инфраструктуры они выбрали Amazon Web Services.
Amazon? Компания, которая управляет Prime Video? Как Netflix может доверять всё своему конкуренту?
Что же, многие компании следуют некоторым соглашениям, по которым они работают друг для друга, конкурируя в одних и тех же категориях. Samsung, например, конкурирует с Apple в производстве телефонов, но в то же время некоторые части iPhone производятся корейской компанией. Netflix был клиентом AWS до появления Prime Video, но это не значит, что они должны враждовать друг с другом.
Оказывается, что сотрудничество Netflix и Amazon является win-win ситуацией для обеих компаний. Netflix является одним из крупнейших клиентов AWS и постоянно запрашивает максимум их возможностей, вводя инновационные способы использования серверов AWS для своих целей: запуска микросервисов, хранения фильмов и управления трафиком. AWS, в свою очередь, совершенствует системы, чтобы позволить Netflix справляться с огромной нагрузкой, и использует приобретенные знания, чтобы обслуживать тысячи других корпоративных клиентов. AWS гордится, что Netflix является их главным клиентом, а Netflix может быстро совершенствовать свои сервисы и сохранять стабильность благодаря AWS. Даже если Netflix влияет на популярность Prime Video или наоборот.
Советы по реализации микросервисов
Шаг 1. Подумайте, действительно ли это нужно вашему приложению и бизнесу.
Шаг 2: Если да, проанализируйте существующую инфраструктуру.
Шаг 3: Подготовьте свою команду к внедрению этой техники.
Шаг 4. Если вы переходите от монолита к микросервисам, уточните у администратора данных, хорошо ли он информирован и понимает задачу.
Шаг 5: Выберите язык программирования и платформу.
Шаг 6. Настройте базовую архитектуру с помощью служб, контейнеров и шаблонов виртуальных машин.
Шаг 7: Если у вас монолитная архитектура, разделите базу данных на множество меньших баз данных.
Шаг 8: Реализуйте шлюзы API.
Шаг 9: Отслеживайте и отображайте происходящее.
Шаг 10: Выполняйте автоматическое тестирование.
Что еще почитать про микросервисы
- Контейнеры и микросервисы: как работает единая система контроля работы транспорта
- Микросервисы SwiftUI
- Когда использовать микросервисы (а когда нет!)
- Почему наша команда отменила переход на микросервисы