Микросервисная архитектура

Существует несколько разных подходов к созданию приложений. Например, некоторые продукты строятся из микросервисов (модулей), которые никак не зависят друг от друга, что не мешает им выполнять свои локальные функции. Такой способ называется микросервисной архитектурой (Microservices Architecture, MSA) и сейчас активно набирает обороты. Благодаря ему приложение собирается подобно конструктору, блоки которого можно заменить на другие или по-разному компоновать. Для сравнения — в рамках традиционного подхода программный продукт воспринимается как монолит и создается совсем по другому принципу, значительно уступающему в гибкости. Разберемся, почему компании постепенно отходят от монолитной архитектуры в пользу микросервисов, какими преимуществами обладают последние. 

Принципы микросервисной архитектуры

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

В противовес монолитной архитектуре микросервисная подразумевает разбиение приложения на независимые функциональные элементы различного назначения. Между ними «проложены» четкие границы, что позволяет отдельно видоизменять и дополнять каждый компонент, добиваясь отказоустойчивости и большей надежности продукта. Такая особенность «играет на руку», если необходимо создать мощное многофункциональное приложение, которое призвано безотказно и корректно работать даже в процессе масштабирования. 

Особенности микросервисной архитектуры

Остановимся на каждом аспекте:


• Микросервисы. Как уже упоминалось, приложение строится из распределенных модулей, каждый из которых выполняет свою узкую функцию. Развитие микросервисов происходит в несколько итераций, а управляются они с помощью автоматизированных решений. 
  
• Сообщение модулей. Микросервисы взаимодействуют друг с другом по схеме Smart Endpoints And Dumb Pipes, в рамках которой исходящие и входящие послания обрабатываются модулями-отправителями и модулями-получателями, а задача каналов связи состоит только в передаче информации. Чаще всего такое «общение» модулей реализуется с помощью простых API.
  
• Команда разработки. В идеале она должна состоять из создателей каждого модуля, DevOps-инженера и других узких специалистов, знакомых с особенностями микросервисной архитектуры. Но на практике часто выходит, что один и тот же человек может разрабатывать несколько микросервисов. Это допустимо, если у специалиста есть необходимая квалификация.
  
• Языки программирования. Вполне возможно создавать модули на разных языках, поскольку они не связаны между собой. Использование нескольких технологий никак не влияет на интеграцию микросервисов и не сказывается на функционале готовых приложений. Чаще всего модули для вычислений создаются на базе Python, веб-модули — с помощью JavaScript, а для высоконагруженных элементов применяется Go. 
  
• Среды развертывания и инструментарий. Можно эксплуатировать любые фреймворки и библиотеки, которые необходимы для решения отдельных задач. Однако есть и специфические инструменты для микросервисных продуктов, с помощью которых можно управлять всей системой и осуществлять настройки. Примеры таких решений: сервисы для отслеживания и фиксирования логов в работе приложений, Docker для упаковки данных в контейнеры и Kubernetes для совершения операций с этими контейнерами, системы для CI/CD, то есть интеграции модулей и их развертывания. 
  

Для создания микросервисов и их интеграции можно использовать гибридную платформу Hybrid Integration Platform Bercut. Она располагает готовыми инструментами для выполнения задач бизнеса, обладает гибким интерфейсом, рассчитана для работы пользователей с разными уровнями навыков.

Преимущества и недостатки микросервисной архитектуры

У модульных приложений достаточно много достоинств, среди которых:


• Удобство обновлений. Не нужно полностью переписывать приложение, а затем заново его развертывать — достаточно внести изменения в отдельные микросервисы. Если какие-то из них негативно влияют на работу продукта, можно удалить их или заменить на другие. 
  
• Высокая отказоустойчивость. Вспомним, что по факту модули не связаны друг с другом, поэтому если откажет один или даже несколько, остальные продолжат исправно работать. 
  
• Гибкость масштабирования. Можно наращивать производительность конкретных модулей или запускать новые процессы. С монолитными приложениями такие манипуляции не проходят, поскольку нельзя увеличить ресурсы для одного компонента — только для всей системы сразу.
  
• Возможность маневрирования технологиями. Не нужно привязываться к одному языку программирования или определенному набору инструментов. 
  
• Продуманный контроль качества. В работе с микросервисами у каждого члена команды свои задачи, поэтому проще отследить какие-то неисправности и ошибки. 
  
• Независимость данных микросервисов. Можно изменять информацию, относящуюся к отдельным модулям без опасений затронуть остальные. 
  

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

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

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

Четвертый минус — снижение производительности из-за большого количества микросервисов. Это связано с тем, что информация переходит от одного модуля к другому, в результате система работает в разы медленнее. Глобально проблема решается благодаря усилиям разработчиков и специальным инструментам, но в отдельных случаях все равно встречается. 

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

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

То есть такая архитектура подойдет для сложных проектов, например:

• Супераппов.
  
• Мнофункциональных продуктов, которые необходимо точечно масштабировать.
  
• Программ с объемным исходным кодом.
  
• Приложений, нагрузка на компоненты которых «плавает» в связи с внешними факторами.
  
• Программных продуктов, создаваемых под конкретные тренды.
  
• Сферы облачных вычислений, которая подвергается большим нагрузкам и «не терпит» перебоев в работе. 
  

Но успех внедрения «модульного» подхода зависит не только от специфики проекта, а от грамотной реализации и целесообразности. Создание приложений из модулей стоит как минимум отложить, если в команде нет специалистов с необходимой квалификацией. Также это не лучший вариант для стартапов, поскольку в этом случае чаще всего стоит задача как можно скорее выпустить программное решение, что проще сделать благодаря монолитному подходу. И третий аргумент против микросервисов — наличие корректно работающего приложения, в котором объективно ничего не нужно менять.

Где применяется «модульная» архитектура

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

Иногда на микросервисы переходят с монолитного подхода, поскольку в таком случае будет проще горизонтально масштабироваться при росте охватов. Подобным образом часто поступают крупные компании, которые уже располагали готовыми приложениями. Например, так сделали ЯндексGo, Amazon и другие гиганты рынка в своей сфере. 

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

Заключение 

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