Как строить и деплоить Go-приложения?

Question

[Urvin]

Привет!
Встал на путь изучения Go, придумал амбициозный проект для этого и столкнулся с тем. что меня мучают несколько вопросов, без знания которых не очень-то и начинается:

1. В проекте должны быть как веб-сервер, так и задачи, запускаемые по расписанию. При этом, конечно, используется общий код, например ORM-объекты. Это нормально будет сделать для консольных тасков отдельное приложение с рутингом (или даже 100500 приложений для каждой задачи)?

2. Зная, что весь проект будет собран на Go, остается ли смысл в менеджерах очередей и не проще ли запускать соответствующие задачи в горутинах?

3. Как правильно деплоить приложение с веб-сервером, чтобы пользователь не заметил переключения версий?
Мне пока видится правильным запускать каждую новую версию на своем порту и переключать поток пользователей nginx-ом на соответствующий порт. Это нормально, так делают? Сам сервер запускать в screen?

Благодарю за ответы!

Answer 1

[Tyranron]

1. Нормально будет как внутри единого процесса крутить (с помощью какого-то robfig/cron, к примеру), так и отдельными процессами (cron-задачами, или даже демонами). Здесь всё зависит от конкретной ситуации и того что Вам нужно. У каждого подхода свои очевидные трейд-офф'ы. Просто выбираете то, что Вам больше подходит. На кодовую базу это мало влияет, ибо всегда можно переиспользовать пакеты, да и вообще можно держать всё в едином бинарнике, просто прокинув разные CLI-интерфейсы.

2. Горутины не могут быть пошарены между несколькими серверами. Если Ваши амбиции влезут в один сервер, то на внешние очереди можно не грузиться.

3. Если речь идёт строго об одном процессе, который нельзя размножить, то смотрите в сторону graceful updates/restarts. Если же Вы можете множить приложение (в конце-концов живём в век победившых Docker/Kubernetes), то есть более общие техники, подходящие абсолютно для любого приложения: blue/green deployment либо rolling update (в том же Kubernetes из-коробки).

Comments

[Urvin]

Спасибо, принял!
Изучаю и думаю.

[Николай Прогрессов]

2. Горутины могут быть прошарены между несколькими серверами, просто нужно добавить функционал, что-нибудь типа глобального флага, который анализируется в начале каждой итерации. Флагом может быть файл, флагом может быть отдельная горутина, которая по сети получает признак и меняет индикатор для всех горутин. Таким образом можно поменять не только качественные характерстики горутин, но и поведенческие, если горутины реализуют интерфейсы.

[Tyranron]

Николай Прогрессов, а ещё на горутинах можно построить акторов, а потом поверх дерево супервизиров на манер эрланга, а потом шаринг/миграцию акторов по сети между нодами, и много чего ещё... Но суть то вопроса стояла не в самих горутинах а в local in-memory state vs external shared state. И что в случае с шарингом акторов, что в случае "по сети получает признак", эта внешняя шина должна быть. Будь то хоть внешняя очередь сообщения, хоть БД, хоть p2p связи.

Answer 2

[Андрей]

Я бы не стал использовать внутренние очереди.
Внешние очереди не потеряют данные при краше приложения.

Answer 3

[Дмитрий Афонченко]

По поводу строительства не знаю, но вот по поводу деплоя немного подскажу, вдруг полезно будет. Вот статья на Хабре: https://m.habr.com/ru/post/421087/
В своё время замучился искать, как это правильно делается.

Comments

[Urvin]

Спасибо!
Про сервисы успел нагуглить. Смущало то, что что systemctl restart сначала ждет, пока все отрубится, а затем заново запускает сервис. И в это время юзеры ловят веселые 500-е ошибки. graceful из ответа, вроде как, решает эту проблему.
И не могу согласиться с автором статьи - я бы все же использовал NGINX перед сервисом. Каждый должен заниматься своим делом. Сервер - эффективно работать с сетью, приложение - с бизнес-логикой.

[Дмитрий Афонченко]

Urvin, я тоже не могу согласиться, хоть я и автор) но там идея была показать развёртку самого сервиса. Вот) это я просто пример скрипта для гитлаба отметил, который можно уже по своему усмотрению допиливать)