Согласно Statista, больше 80% организаций со штатом от 5,000 сотрудников используют микросервисную архитектуру, или микросервисы. Разработка микросервисов помогает бизнесу масштабироваться, делают приложения надежнее и упрощают кодовую базу. Но подходят они не всем.

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

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

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

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

Микросервисы и монолит — чем они отличаются

Рассмотрим в чём разница между микросервисной и монолитной архитектурой на таблице:

В чем преимущества микросервисов

Рассмотрим основные преимущества микросервисной архитектуры:  

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

• Масштабируемость. Можно масштабировать сервисы независимо. Например, если поиск по приложению нагружен слабо — ему хватит одного сервера. Если нагрузка вырастет, его архитектуру можно будет масштабировать как горизонтально так и вертикально. Существуют сервисы, которые автоматически выделяют ресурсы по потребности, например, Amazon EC2 Auto Scaling, Kubernetes, и Google Cloud Run. 

• Упрощение кодовой базы. Для поддержки микросервиса программистам не нужно знать весь код всего продукта. Специалист может работать над одним локальным микросервисом, не влияя на остальные. В монолитах всё наоборот — программисты тратят много времени на чтение кода, который им фактически не нужен.

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

• Гибкость. При создании микросервисов для проекта вы можете использовать столько языков программирования, фреймворков и инструментов, сколько захотите. Например, можно выбрать Go как основной язык бизнес логики, а в ML модулях использовать более подходящий для таких задач Python. В монолитах это невозможно, поэтому программисты тратят своё время на «борьбу с кодом», а не на поиск лучших решений для бизнеса.

Кому подойдёт разработка микросервисов

Может быть вы слышали, что в Amazon используют «правило двух пицц»: в команде должно быть столько людей, сколько можно накормить двумя большими пиццами. Иначе команда, не сможет работать без мискоммуникаций. 

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

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

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

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

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

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

Go и Java для разработки микросервисов — почемы мы используем эти языки программирования

Микросервис можно написать на любом языке, но есть технологии, которые лучше заточены под эту архитектуру. В Surf мы часто используем Go, также известный как Golang, и Java. Вот основные преимущества этих языков:

• Golang и Java поддерживают многопоточность. Golang — это очень быстрый язык благодаря «горутинам» — технологии, которая обеспечивает еще более высокую скорость, чем традиционные потоки. 

• Безопасность: оба этих языка обладают сильной типизацией и автоматическим управлением памятью. Это помогает предотвращать ошибки и упрощает отладку кода.

• Golang и Java хорошо работают с технологиями контейнеризации, такими как Docker и Kubernetes. Эти технологии используются для развертывания и управления распределенными архитектурами. Например, Golang позволяет легко упаковать приложения в контейнеры и управлять ими на уровне микросервисов.

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

Разработка микросервисного бэкенда для ERP системы — кейс KFC

KFC обратились к нам для разработки кастомной Enterprise Resource Management (ERP) системы — клиенту нужно было перевести документооборот внутри ресторанов KFC из бумажного в цифровой формат и частично автоматизировать операционное управление. Для этого требовался сложный бекенд.

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

В качестве платформы использовали Spring Boot — фреймворк, который упрощает создание и управление автономными веб-приложениями. Для распределения ресурсов остановились на Kubernetes. Всего мы написали 7 микросервисов, которые разбиты по тематике. 

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

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

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

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

Подводя итог

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

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

• Микросервисы успешно используются как стартапами, так и крупными компаниями. Банк Monzo построил более 1600 микросервисов, включая те, которые работают на Go, а Netflix использует более 1000 микросервисов. Обе компании довольны своим выбором: они достигли желаемых результатов.

В Surf мы разрабатываем бэкенд решения на основе микросервисов и монолитов уже 12 лет. Наши клиенты — это крупные банки, foodtech и ecommerce проекты и быстро растущие стартапы. Для нас нет стандартных решений — мы подбираем техстек под бизнес требования каждого клиента.