Eugene-Usachev
@Eugene-Usachev

Как писать микросервисную архитектуру?

Я решил добавить себе в портфолио (я только закончил школу и забочусь о портфолио, чтобы найти первую работу) проект с микросервисами. Схемы красивые начертил, всё распланировал и внезапно понял, что не знаю, как писать. У меня 3 вопроса (если сможете ответить хотя бы на один, я буду благодарен).

Первый вопрос

Как это приложение добавлять на GitHub? Я имею в виду, стоит ли мне создать отдельный аккаунт для этого приложения и выделить каждому сервису свой репозиторий или создать один репозиторий и бить его по папкам (но тогда к чему микросервисы?)?


Второй вопрос

Как выглядит эталонная структура сервиса. Я имею в виду, что в обычном приложении у меня есть папка internal, в которой лежат папки repository, services, handlers (специально именно эти три написал). При этом структура может выглядеть как-то так:
internal
--handlers
----handlers.go
----user.handler.go
----post.handler.go
--services
----services.go
----user.service.go
----post.service.go
--repository
----repository.go
----user.repository.go
----post.repository.go


А в микросервисной архитектуре структура такой быть не может. В ней, получается, нет пакета services. И тут вопрос, значит ли это, что я могу обращаться к репозиторию прямо из handlers? Кажется, что так нельзя, но тогда как назвать пакет с бизнес логикой?

И сразу ещё один вопрос. В этой структуре у меня, получается, пакет handlers состоит только из 2 файлов (интерфейса и реализации) и repository тоже только из 2. Это странно. Не могли бы вы начертить структуру в ответе?


Третий вопрос

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

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

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

Можете ответь, какой из способов правильный и почему?
  • Вопрос задан
  • 379 просмотров
Пригласить эксперта
Ответы на вопрос 2
Вы не сможете себе в портфолио добавить микросервисную архитектуру просто написав ее в пет-проекте. Настоящие микросервисы можно пощупать только на масштабах больших компаний и их инфраструктуре, так что устраивайтесь джуном/стажером в какой-нибудь Авито или Озон.

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

Сделайте лучше хороший проект-монолит, отработайте навыки языка, БД, развертывания, гита, итд... на одном проекте. Будет гораздо полезнее.
Ответ написан
@Everything_is_bad
Забей на микросервисы, джуны не способны их нормально сделать, тут тупо нужен опыт, так что для начала пиши монолит. Красивое раскидывание кода по папкам, вообще не имеет отношение к микросервисам.

Условно мы отправляем сообщение в чат, в котором состоит пользователь. Нам нужно получить и заблокировать список пользователей, добавить сообщение, и разблокировать.
зачем вообще тут блокировать пользователей?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы