Кому нужна микросервисная архитектура

Выбор архитектуры для проекта — это важный шаг для продукта. Ведь от этого выбора зависит весь дальнейший процесс разработки и поддержки проекта. Эта статья посвящена микросервисам, но также мы рассмотрим и другие виды архитектур.

Начнем с монолита. Концепция монолитной архитектуры ПО подразумевает то, что компоненты приложения объединяются в одну программу на одной платформе. Как правило монолитное приложение состоит из БД, пользовательского интерфейса и серверного приложения.

Основной недостаток монолитной архитектуры — громоздкая кодовая база, из-за которой ухудшается качество кода, и он становится трудным для понимания. Также при внедрении новых технологий часто возникают трудности, так как приходится переписывать большое количество кода. А из-за самой концепции, монолит обладает ограниченной гибкостью.

Сервис-ориентированная архитектура или сокращенно SOA – это архитектура, которая предполагает под собой модульное приложение, состоящее из слабосвязанных программных компонентов. Концепция заключается в том, что приложение может быть спроектировано так, чтобы его модули легко интегрировались и могли быть использованы повторно.

Основной недостаток сервис-ориентированной архитектуры — ее сложность и, как следствие, трудности с управлением всеми службами. Также SOA требует больших ресурсов, как человеческих, так и денежных. А сама система обладает низкой производительностью при использовании нескольких сервисов одновременно.

Микросервисная архитектура — тип архитектуры программного обеспечения, который заключается в разбиении системы на отдельные компоненты, представляющие из себя независимые сервисы. Каждый отдельный сервис выполняет свои функции. Благодаря четким границам сервисы легко масштабируются, а для их разработки можно использовать разные языки программирования.

С каждым годом популярность микросервисов среди разработчиков растет. Исследование IBM показало, что 56% организаций планируют перейти на MSA. При этом 78% организаций у которых есть микросервисы планируют и дальше вкладывать средства в их развитие. Ведь они подходят для крупных интернет-продуктов, а если один из сервисов выйдет из строя, то остальные продолжат работать.

Такие крупные компании, как PayPal, eBay и Amazon перешли от монолитной к микросервисной архитектуре. Микросервисы ориентированы на бизнес-приоритеты, в то время как тот же монолит делает акцент на технологических уровнях, пользовательских интерфейсах и базах данных.

Но в чем причина такой бешеной популярности микросервисов и стоит ли менять архитектуру? Попробуем разобраться.

При падении одного из сервисов, остальные остаются в рабочем состоянии. Благодаря этому один неисправный сервис не влияет на работу остальных. Однако на этапе проектирования микросервисов следует уделить внимание тому, как недоступность сервисов влияет на user experience.

Отказоустойчивости можно добиться с помощью отсутствия взаимозависимостей микросервисов. Для этого в качестве инфраструктуры лучше использовать варианты с возможностью самовосстановления, например Kubernetes. Также можно использовать шлюз API со встроенной устойчивостью, запросы кэша в потоковом процессоре, например Kafka.

Масштабируемость — это способность системы увеличивать производительность за счет увеличения количества выделенных ей ресурсов. Микросервисная архитектура позволяет масштабировать каждый сервис отдельно, не затрагивая остальную систему.

Если вертикальное масштабирование может быть ограничено пропускной способностью каждого отдельного сервиса, то горизонтальное масштабирование не ограничено. Кроме того оно может быть полностью автоматизировано и работать с микросервисами динамически.

В рассматриваемой архитектуре под сервисами подразумевается не часть back-end`а, а полноценная реализация бизнес-логики. Каждый сервис проектируется, создается, тестируется и развертывается независимо. Благодаря этому ускоряется разработка и релиз.

Из-за того, что разработчики релизят отдельные сервисы, а не приложение целиком, снижаются риски выпустить программную часть, из-за которой будет нарушаться работа всей системы.

Каждый отдельный сервис физически изолирован от остального приложения. Это достоинство и недостаток архитектуры одновременно, так как теперь нужно грамотно выстраивать коммуникацию между сервисами. А с увеличением количества сервисов будет расти сложность в их сообщении.

Какой выход из ситуации? Построить грамотные контракты между сервисами. Основная идея контрактного программирования — объединение программного кода и спецификаций. В нашем случае сервис обязуется выполнить контракт (условие), заключенное с другим сервисом. Если один сервис не удовлетворяет условиям другого, то контракт не выполняется.

Разделение приложения на микросервисы влечет за собой большое количество артефактов управления. MSA требует планирования и ресурсов. Также возрастает роль автоматизации процессов, их тестирования и развертывания, что, в свою очередь, повышает требования к мониторингу сервисов.

Для внедрения микросервисной архитектуры компаниям придется внедрить культуру DevOps, обеспечить взаимодействие между разработчиками, тестировщиками и т.д. То есть поменять стиль мышления, особенно если речь идет о переходе с монолита.

При переходе к микросервисам растет сетевая задержка. Стоит понимать, что задержка при коммуникации сервисов будет всегда, а минимизировать потери можно с помощью планирования архитектуры продукта.

Регрессионное тестирование нужно, чтобы удостовериться, что исправление одних багов не привело к возникновению новых, но уже в других сервисах. При проведении регрессионного тестирования придется поднимать все микросервисы разом.

В данном случае сложность в том, что тестировать приходится больше: не только отдельные сервисы, но и их взаимодействие друг с другом. Это сильно увеличивает время и ресурсы, которые будут затрачены на тестирование, а бизнес к такому, увы, не готов.

Микросервисная архитектура подходит далеко не всем.

MSA — это ваша тема, если команда планирует разработать среднего размера веб-приложение, которое состоит из набора модулей. При этом модули слабо связаны или изолированы друг от друга.

Также выбор MSA может быть обусловлен требованиями бизнеса постоянно вносить изменения в продукт и ускорить процесс разработки. Такая архитектура подойдет для проектов, которые требуют точечного масштабирования и изменений в различных точках приложения.

Микросервисы применимы и к продуктам, в которых предполагается использовать различные технологии, например несколько языков. А также планируется интеграция с внешними сервисами, например платежными системами и банками.

Так в 2013 году компания Netflix перешла от монолитной архитектуры к микросервисам и продолжает активно развиваться в этом направлении, создавая все больше сервисов. А Amazon и вовсе разработал AWS — самую большую в мире облачную платформу, которая предоставляет доступ к отдельным сервисам по подписке. Реализовано это решение, в том числе с применением микросервисной архитектуры.

Выбор архитектуры для проекта — сложная задача. Микросервисы подойдут не для всех приложений. Да и часто последствия от выбора той или иной архитектуры становятся видны только по прошествии времени.

Однозначно микросервисы — это не ваш вариант, если команда не обладает достаточным количеством знаний и ресурсов для их реализации. Поэтому предлагаем рассмотреть другие виды архитектуры программного обеспечения и обозначить, в каких случаях лучше остановиться именно на них.

Монолит подойдет для стартапов, которым нужно как можно скорее разработать и выпустить продукт. Архитектура монолитного программного обеспечения может быть полезной, если ваша команда находится на начальной стадии разработки, вы создаете непроверенный продукт и не имеете опыта работы с микросервисами.

Большинство компаний так или иначе сейчас используют монолитную архитектуру. Например, тот же Сбер пользуется данной концепцией при создании своих продуктов.

SOA подойдет для сложных корпоративных систем. Так можно будет организовать сложные приложения, которые впоследствии будут изолированы в независимые сервисы.

Один из ярких примеров использования SOA-архитектуры — компания Cisco. В 2010 году Cisco внедрила сервисы для согласования процесса заказа их продуктов. Дочерним компаниям, бизнес-партнерам и подразделениям предоставили сервисы, с помощью которых можно добавить процессы связанные с заказом на свой сайт.

Микросервисы несут в себе определенную сложность. Поэтому если у вас есть приложение, которое и так хорошо работает, то не стоит все рушить ради модных тенденций. Если вы уже решили перейти на микросервисы, то обязательно донесите до бизнеса все возможные последствия.

Рассмотреть MSA для вашего проекта стоит, если у вас есть опытная команда, знание концепции DevOps и сложное приложение, которое можно будет разбить на сервисы. Бездумное внедрение микросервисов из плохого кода создаст плохую инфраструктуру. Помните, что при неоправданном использовании микросервисов все их преимущества сводятся к нулю.