Вообще начать стоит с того, что понятие "с большим количеством бизнес логики" довольно растяжимое. Если говорить о микросервисах, то в них обычно много бизнес-логики и не получается. Потому что если такое начинает происходить, то стоит задуматься, а точно ли в микросервисе нет лишней ответственности? Возможно, стоит этот сервис поделить на более мелкие?
Немного из личного опыта и не совсем по теме вопроса, мало ли пригодится. Я писал микросервисы на go и заметил следующие недостатки (лично для меня):
- В большинстве микросервисов бывают довольно простые запросы к базе данных и удобно было бы использовать что-то вроде Doctrine или SQLalchemy. В go, к сожалению, инструментов такого уровня нет. Gorm лично мне не понравился совершенно.
- Недавно была необходимость запилить сервис, взаимодействующий со Sphinx, но нормальных библиотек для Go для этой задачи внезапно не оказалось. Есть вот такая, но она устарела (еще не позволяет ее нормально юзать в несколько потоков). Неустаревшей и нормальной библиотеки вообще нет. Либо я плохо искал.
- Сложно сделать нормальную структуру проекта, чтобы не было циклических зависимостей. По крайней мере, вскоре начинает не покидать ощущение, что пишешь какой-то код низкого качества. Хотя может это субъективно или проходит с опытом.
- Если не запилить что-то типа контейнера зависимостей, то покрывать тестами проект становится неудобно, т.к. тесты при запуске в параллель начинают юзать одни и те же глобальные переменные. Опять-таки может и это субъективно.
- Во фреймворке gin/gonic сложно запилить нормальную валидацию для json. Если в структуре, на которую маппишь, поле типа int, а ты передал в json число в кавычках (строку вместо числа по сути), то поймать такую ошибку и выдать нормальную ошибку валидации невозможно, т.к. валидация там (в этом фреймворке) запускается после маппинга.
Плюсы:
- Строгая типизация
- Результат компиляции - один бинарь
- Довольно интересный проброс ошибок (многим не нравится, мне понравился)
- Высокая скорость
- Низкое потребление памяти
- Есть потоки
