Реализация

Опыт разработки последних лет свидетельствует

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

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

Проблемы монолитов:

 - Медленная разработка
 - Длинный и тяжелый путь сохранения изменений и развертывания
 - Трудности с масштабированием
 - Проблема надежности
 - Зависимость от постепенно устаревающего стека технологий

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

Микросервисы

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

В микросервисной архитектуре:

- единицей модульности является сервис.
- Сервисы обладают API.
- у каждого сервиса есть своя база данных.

Ключевой особенностью микросервисной архитектуры является то, что сервисы слабо связаны между собой и взаимодействуют только через API. Слабой связанности можно достичь за счет выделения каждому сервису отдельной базы данных.

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

Преимущества выбранного подхода:

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

Трудности микросервисов, которые нужно учитывать:

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

Выводы

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

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

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

Микросервисная архитектура не панацея. У нее есть существенные недостатки, такие как повышенная сложность.

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