Как организовать архитектуру Go микросервиса?

Question

[ReallyNoob]

Всем привет! Пару недель изучаю Го и пытаюсь продумать архитектуру микросервиса.

У моего сервиса достаточно стандартные вводные: есть несколько сущностей (посты, категории блога), которые можно создавать/редактировать, обновлять удалять.

Есть потребности общаться с другими сервисами. Для межсервисного общения использую gRPC.

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

1. Было удобно работать с CRUD операциями над сущностми
   
2. Было удобно писать/поддерживать запросы в другие микросервисы
   
3. Было удобно делать выборки из БД в рамках своего микросервиса
   
4. Было удобно разложить какие-то функции-хелперы
   
5. Было удобно структурировать саму бизнес логику запросов моего микросервиса
   

Как-то так. Прошу прошения за сумбурное описание, но как получилось.

Answer 1

[uvelichitel]

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

Comments

[ReallyNoob]

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

[Даша Циклаури]

ReallyNoob, у тебя будет возможно +1-2 слоя еще:
- слой бизнес логики с методами которые дергаются из прото-хэндлеров
- слой работы с БД (это опционально), возможно, если не нужно каких-то хитрых синхронизаций и достаточно драйвера, то можно прямо из слоя БЛ получать данные

Функции хэлперы, вероятно, уходят в другой пакет, потом переиспользуются другими микросервисами

[ReallyNoob]

Т.е вся логика пишется просто в методах прото хендлерах?

[f0rk]

Т.е вся логика пишется просто в методах прото хендлерах?

ReallyNoob, да, это хорошая отправная точка. Не стоит городить абстракции там, где в них нет необходимости.

Answer 2

[basrach]

Было удобно

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

Определено точно можно сказать, что в go не нужно строить дизайн сервиса так же как в RR, Java или .Net. Лучше всего понять как должно быть устроено go приложение - это поизучать известные проекты, например: https://github.com/gomods/athens , https://github.com/google/exposure-notifications-server