7 паттернов микросервисной архитектуры на примере музыкального сервис
The example is a music-listening service called Пай.Музыку with more than 100,000 monthly users and a team of over 10 engineers. It recently added podcasts and a musician's personal account. The new areas are meant to be updated often and scaled separately because of different loads, while core logic should be released less frequently.
Представим, что мы разрабатываем сервис для прослушивания музыки — Пай.Музыку. В него уже заходит больше 100 тысяч пользователей в месяц, в команде работает 10+ инженеров, а недавно к музыке добавились подкасты и личный кабинет музыканта. Новые направления хочется часто обновлять и отдельно масштабировать (из-за разной нагрузки), основную логику — релизить пореже. Но пока всё живёт в одном монолите: общий релизный цикл тормозит команды, а изменения в одних и тех же файлах приводят к мерж-конфликтам. Команда приняла решение распилить монолит на несколько микросервисов. Но вот незадача: почти никто не имел такого опыта, а о паттернах читали лишь в книжках. Давайте поможем команде внедрить нужные паттерны, заодно обсудив, какую проблему они решают и чем приходится платить за это. На примере этой системы разберём семь паттернов микросервисной архитектуры, их ограничения и короткие примеры на Python. В этой статье слова “сервис” и “микросервис” используются взаимозаменяемо. Читать далее