Распределённые стили: микросервисная архитектура
В этом уроке вы познакомитесь с микросервисной архитектурой, узнаете, чем она отличается от сервис-ориентированной, а также узнаете, когда следует её использовать.
Микросервисная архитектура
Основным элементом микросервисной архитектуры, как и SOA, является сервис — это независимо развёртываемый элемент ПО, который реализует некоторую функцию. При этом, сервисы микросервисной архитектуры отличаются от сервисов SOA:
- Типами.
- Размером.
- Наличием собственного хранилища данных.
Типы сервисов
В отличие от SOA, в микросервисной архитектуре выделяют всего два типа сервисов:
- Функциональный сервис (Functional service) — это сервис, который реализует определённые значимые для пользователей функции.
- Инфраструктурный сервис микросервисной архитектуры аналогичен инфраструктурному сервису в SOA.
Функциональные сервисы отражают ключевую концепцию микросервисной архитектуры — делиться как можно меньшим (Share-as-little-as-possible). Эта концепция прямо противоположна концепции SOA — делиться как можно большим.
К функциональным сервисам может непосредственно обратиться клиент (веб-браузер, настольное приложение или другая программа). Для выполнения запроса клиента один функциональный сервис может обратиться к другому функциональному сервису напрямую.
Инфраструктурные сервисы доступны только функциональным сервисам одного приложения.
Рассмотрим типы сервисов на примере приложения для доставки цветов. После добавления функций, таких как доставка шаров, доставка подарков, исполнение поздравительной песни, производительность приложения снизилась.
Для увеличения производительности приложение для доставки цветов может быть разработано с помощью микросервисной архитектуры.
Функциональными сервисами могут стать, например:
- Заказы — оформление заказа, изменение данных заказа и его статуса, отмена заказа.
- Клиенты — регистрация, авторизация, изменение данных клиента.
- Склад — изменения данных о товарах на складе.
Размер сервиса
Приставка «микро» предполагает, что сервисы микросервисной архитектуры значительно меньше сервисов SOA.
Микросервисы — это маленькие, узкоспециализированные сервисы. Размеры сервисов SOA варьируются от небольших сервисов приложения до очень больших сервисов предприятия.
Одним из самых больших вызовов, которые изначально стояли перед архитекторами ПО при проектировании приложений с использованием SOA, являлось определение размера сервиса. Архитекторы ПО часто проектировали слишком маленькие сервисы, что приводило к реализации приложений с низкой производительностью.
Однако для выполнения одного запроса со стороны клиента (веб-браузера, настольного приложения или другой программы) в SOA, как правило, требуется участие множества сервисов. В микросервисной архитектуре, как правило, наоборот — один сервис выполняет один запрос.
И в SOA, и в микросервисной архитектуре, выбор оптимального размера сервиса — это непростая и важная архитектурная задача. Дело в том, что размеры сервисов приложения влияют на производительность.
В IT-индустрии существуют множество способов определения оптимального размера сервисов. Количество строчек программного кода для этого не подходит, потому что разные языки программирования требуют разного количества строчек для реализации одной и той же функции.
Например, программный код на языке Java будет более объёмным, чем на языке Kotlin.
Рассмотрим три основных способа:
- По времени выполнения запроса.
- По времени разработки сервиса.
- По простоте понимания внутреннего устройства.
По времени выполнения запроса
Если сервисы слишком маленькие, то для выполнения запроса множеству сервисов потребуется взаимодействовать между собой, что отразится на времени выполнения запроса.
Представьте, что для выполнения запроса нужны три сервиса. «Потребитель» может быть сервисом, приложением, или другим элементом ПО. Время, необходимое для обращения потребителя к сервису и сервисов к друг другу, составляет, например, 100 миллисекунд (мс). Время, затраченное только на передачу данных, составит 600 миллисекунд. При этом, каждому сервису нужно также потратить время на обработку этих данных.
Объединение трёх сервисов в один сократит время передачи данных в три раза — до 200 миллисекунд.
Время передачи данных для выполнения запроса клиента — это отличный способ определения оптимального размера сервиса в микросервисной архитектуре.
Поиск оптимального размера сервиса — это непрерывный процесс. Как правило, архитектор ПО проектирует сначала более крупные сервисы, затем изучает то, как фактически используются сервисы, измеряет время передачи данных и только после этого разбивает крупные сервисы на более мелкие.
По времени разработки
Дэйв Фарли (Dave Farley) — разработчик с 40-летним стажем и автор книги «Непрерывное развёртывание ПО» (англ. «Continuous Delivery») предлагает следующий взгляд на определение размера микросервиса:
Представьте, что вам нужно «выбросить» микросервис и создать его заново. Если это займет несколько дней или пару недель, то масштаб определен верно. Если идея «выбросить» микросервис пугает вас, вероятно, он слишком большой.
Команде разработки может понадобиться разработать микросервис заново, например, если применение новой технологии окажется неудачным.
По простоте понимания внутреннего устройства
Архитектор ПО и технический директор Джеймс Льюис (James Lewis) сказал:
Микросервис должен быть таким же большим, как моя голова.
На первый взгляд это определение размера не кажется полезными, но на самом деле оно значит, что один разработчик должен быть способным легко понять весь программный код микросервиса целиком. При этом стоит учитывать опыт разработчика, его знания о системе и о предметной области.
При этом, архитектору ПО следует учитывать, что чем меньше микросервисы, тем больше их количество в системе. С ростом количества микросервисов возрастает сложность системы, а командам разработки потребуется изучать и внедрять новые технологии, чтобы с ней справиться.
Хранилище данных
SOA не предъявляет никаких требований к хранилищам данных, их формату и взаимодействию сервисов с ними. Микросервисный стиль также не предъявляет требований к формату хранилищ данных, но, в соответствии с концепцией «делиться как можно меньшим», предполагает наличие отдельного хранилища данных для каждого сервиса.
Такой подход называется изоляцией данных (Data Isolation).
Например, в хранилище сервиса «Заказы» будет располагаться таблица «Заказы», а в хранилище сервиса «Клиенты» — таблица «Клиенты».
Изоляция данных помогает команде разработки не координировать свою работу с другими командами, а значит, сокращает время выполнения проекта.
Она также помогает избежать непредвиденных ошибок при разработке. Например, если одна команда удалит поле таблицы, которое используется сервисом другой команды.
Слой API
Микросервисная архитектура отличается от SOA наличием слоя интерфейса программирования приложения (Application Programming Interface — API Layer). В отличие от промежуточного ПО для обмена сообщения в SOA, слой API не является неотъемлемым элементом микросервисного стиля, но встречается очень часто.
В спринте «Проектирование пользовательских интерфейсов» вы узнали, что интерфейс — это место соприкосновения и взаимодействия двух независимых объектов: пользователей, программного или аппаратного обеспечений.
Если пользовательский интерфейс является местом соприкосновения пользователей с программным или аппаратным обеспечением, то границей между программами является интерфейс программирования приложения.
API — это граница между программами, которая позволяет им использовать возможности языков программирования для взаимодействия.
Слой API — это программа, которая представляет собой единую точку входа в приложение извне. Его основная роль в архитектуре ПО — перенаправление запросов клиентов нужному сервису приложения.
В отличие от промежуточного ПО для обмена сообщениями, слой API не замыкает на себе всё взаимодействие между сервисами — он берёт на себя только взаимодействие между клиентами и сервисами.
Если слой API отсутствует, то клиенты будут обращаться к сервисам напрямую. Это значит, что клиенты должны будут знать актуальное расположение сервиса и, в случае его изменения, их потребуется дорабатывать.
Кроме того, если для выполнения запроса клиента требуется участие нескольких сервисов, ему также потребуется самостоятельно обращаться к ним.
Рейтинг архитектурных характеристик
Рассмотрим рейтинг архитектурных характеристик микросервисного стиля.
Производительность (высокий)
Если размер сервиса оптимален, то выполнение запроса не занимает много времени. Это значит, что приложение работает быстро, то есть оно обладает высокой производительностью.
Микросервисная архитектура улучшает производительность приложения и сокращает затраты на аппаратное обеспечение. Некоторым микросервисам может требоваться мощный процессор, а другим — большие объемы памяти. Разные микросервисы одного приложения можно развёртывать на серверах с различными техническими характеристиками.
Возможность модификации (высокий)
Как правило, функциональные сервисы приложения не взаимодействуют друг с другом. Это значит, что командам разработки легко внести изменения.
В IT-индустрии существует множество различных технологий: языков программирования, фреймворков, СУБД, операционных систем, инструментов разработки и других.
Например, согласно онлайн-энциклопедии истории только языков программирования (Online Historical Encyclopaedia of Programming Languages), человечество разработало почти 9 тысяч языков программирования. В настоящее время из них используются, по разным источникам, от 250 до 2,500.
Многообразие технологий вызвано тем, что для решения разных задач подходят разные технологии. Для реализации приложения с микросервисной архитектурой возможно использовать разные технологии. Архитектор ПО совместно с разработчиками могут выбрать те из них, что лучше подходят для решения задач каждого микросервиса.
Команде разработки может потребоваться переписать микросервис, если выбранная технология не принесла ожидаемых результатов. Благодаря тому, что микросервисы маленькие, они могут быть сравнительно быстро переписаны.
Масштабируемость (высокий)
Поскольку приложение c микросервисной архитектурой разбито на независимо разворачиваемые сервисы, каждый компонент может масштабироваться отдельно, позволяя настраивать масштабирование в зависимости от потребностей продукта.
Больше про масштабирование вы узнаете в следующем уроке.
Простота разработки (низкая)
Для реализации микросервиса, как правило, требуется написать меньше программного кода (в сравнении с монолитом), разработчикам проще разобраться в нём и удобнее с ним работать. Но несмотря на кажущуюся простоту, микросервисная архитектура сложна в разработке, начиная от проектирования и заканчивая резвёртыванием. Она требует высокого профессионализма от:
- Архитектора ПО в части определения оптимального размера сервисов. Если сервисы слишком маленькие, то для выполнения запроса множеству сервисов потребуется взаимодействовать между собой, что отразится на времени выполнения запроса. Поэтому архитектор ПО должен ответственно подходить к определению оптимального размера сервисов.
- Команды разработки в части управления изолированными данными. Если запрос требует изменения сервисами данных в своих хранилищах, то командам разработки требуется приложить дополнительные усилия для сохранения целостности данных приложения.
- Команды обслуживания инфраструктуры. Без особого инфраструктурного ПО практически невозможно разработать и сопровождать микросервисы. Для работы с этим ПО, организации часто нанимают отдельных специалистов по Docker, Kubernetes, Red Hat или OpenShift.
Кроме того, в больших системах микросервисов могут быть сотни, поэтому требуется много ресурсов команды. Например, компания Netflix сопровождает более 500 микросервисов.
При этом, благодаря микросервисной архитектуре, каждая команда разработки может работать над одним или несколькими микросервисами независимо от других. Она развёртывает и масштабирует микросервисы без координирования своих действий с другими командами.
Иногда необходимые изменения всё-таки затрагивают больше, чем один сервис. В этом случае с увеличением количества затрагиваемых сервисов увеличивается сложность координации работ над изменениями.
Простота развёртывания (высокий)
Независимые разработка, тестирование и развертывание микросервисов, а также независимость команд разработки делает возможным внедрение непрерывной доставки и развёртывания приложения. Это значит, что:
- Команда разработки будет быстро реагировать на обратную связь от пользователей и чаще выпускать новые функции. Например, компания Amazon развёртывает изменения каждые 11,6 секунд, что стало возможным в том числе благодаря использованию микросервисной архитектуры.
- Увеличится доступность приложения, так как в случае обнаружения критических ошибок можно быстро развернуть предыдущую версию микросервиса.
- Повысится уровень удовлетворенности команды разработки от работы, потому что она будет тратить меньше времени на оптимизацию и исправление ошибок, и больше на разработку новых функций.
Простота тестирования (высокий)
Поскольку функции приложения изолированы в микросверисах, тестирование становится более “точечным”. Провести тестирование для одного микросервиса гораздо проще, для целого монолитного приложения.
Также, поскольку сервисы изолированы друг от друга, доработка ошибок в одном сервисе гораздо меньше затронет работу других сервисов, чем в монолите, где ошибка в одном сервисе может привести к краху всего приложения.
Когда использовать этот стиль
Микросервисная архитектура отлично подходит для:
- Приложения, требующего высокой производительности
В случаях, когда компания выпускает новое ПО, которое будет иметь большое количество пользователей. Важным фактом является наличие у компании компетенций в разработке и развертывании микросервисов. - Приложения с большим количеством функций
В приложении планируется реализовать большое количество функций, то лучшим решением будет разделить эти функции в зависимости от контекстов, чтобы воспользоваться всеми достоинствами микросервисной архитектуры.
Подведём итоги
Основным архитектурным элементом микросервисной архитектуры является сервис — независимо развёртываемый элемент ПО, который реализует некоторую функцию.
В микросервисной архитектуре выделяют всего два типа сервисов:
- Функциональный сервис (Functional service) — это сервис, который реализует значимые для пользователей функции.
- Инфраструктурный сервис микросервисной архитектуры аналогичен инфраструктурному сервису в SOA.
Микросервисы — это маленькие, узкоспециализированные сервисы. Размер микросервиса определяется не количеством строчек кода, а временем выполнения запроса, временем необходимым на разработку и простотой понимания внутреннего устройства.
В системах с микросервисной архитектурой реализуется правило «делиться как можно меньшим», поэтому сервисы не переиспользуются другими сервисами, а также каждый сервис имеет собственное хранилище данных.
Микросервисная архитектура отличается от SOA наличием слоя интерфейса программирования приложения (API Layer). Его основная роль в архитектуре ПО — перенаправление запросов клиентов нужному сервису приложения.
Микросервисная архитектура позволяет добиться высоких показателей производительности по сравнению с другими стилями архитектуры. При этом реализация приложений с микросервисной архитектурой требует высокого профессионализма архитектора, команды разработки и команды обслуживания инфраструктуры.