Roman

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

интересно увидеть полную картину, для чего это.

лучше такие вещи поднимать как сервис,
с путями пол-беды, проблем добавится с открытыми дескрипторами.

почему именно map? больше бы контекста, это для себя или часть другой задачи?

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

без мапинга

https://github.com/gorilla/websocket

но если у Вас возникает подобный вопрос, возможно не стоит эту часть писать на Go?

по сути, это возможно, реализовав go-ws (сервер) + javascript-ws (клиент) + go (сервер приложения), задача сама по себе трудоемка, и требует соотв.навыков, больше бы подробностей.

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

соединение с бд, как выше писали, всетаки лучше делать при старте сервиса, а не при новом запросе,

db.SetMaxOpenConns - решит задачу, но кажется мне, опять таки при множестве запросов, db.Close() не всегда будет успевать закрывать и опять будут проблемы..

вижу как-то так:

func someMethod(db *sql.DB, e map[string]string)  {

}

func main(){

 db, err := sql.Open("mysql", "user:pass@tcp(10.10.10.10:3036)/dbname")
  if err != nil {
    log.Print(err.Error())
  }
defer db.Close()

....
switch e["Event"] {
  case "SomeEvent":
    go someMethod(db,e)			
}
...

}

думаю нужно больше информации, чтобы понять, для чего, в данном случае, используется рнр и зачем там go

недавно делал что-то похожее: на сервак приходит tar.bz2 архив, в нем текстовые файлы с данными, таких архивов в течении часа собирается достаточно много, данные текстовые нужно прочитать и положить в 2 таблицы: подробная и обобщенная, и для полученных данных выполнить некоторые генерации .json-файлов и .md5 рнр-скриптом, который лет 5 используется в многих местах

времени было мало, сделал по тупому :)

1. go-рутина крутиться и читает каждые 5-10 сек (точно не помню) спец.папку куда ложим архивы, если архив есть - создается файл archive-name.log и начинается процесс расспаковки и т.п.

2. сам процесс работы нужно отображать в браузере, сокеты использовать времени не было, получилось просто: ажакс отправляет запрос с id-архивом, и читает лог-файл с нулевого места или с места последнего чтения, так как если более 30сек скрипт выполняется - апач вываливал gateway timeout.

3. когда go-приложение заканчивало свою работу - создавался файл archive-id.done и вызывается рнр-скрипт с помощью exec.cmd

4. когда клиент читал лог по ИД ресурса и есть файл *.done - считалось, что клиент получил всю инфу, и создавался еще один файл .finished

5. горутина из пункта 1) кроме поиска архива, ищет .finish и .done, если такое есть - удаляет использованнЫе данные.

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

работает в результате все очень быстро.

1. на сервер нужно доставить исходники проекта на Go, если без CI/CD - то с помощью git, или, ладно, FTP

2. делаем тот же go build - получаем бинарник, который можно запустить

в своих проектах (ос виндовс, на серверах линукс) делаю примерно так:

есть build.sh - компилирует проект
go build -o my-app ./

есть service.sh - запускает полученный бинарник

ACTION=$1
SERVICE="./my-app"
SERVICE_PID=$(ps -aux | awk '$11=="'$SERVICE'" {print $2}')

if [ -z $ACTION ]
then
	echo "Command not found"
	exit;
fi

if ! [ -x $SERVICE ]
then
	echo "Service execute permission not granted"
	exit;
fi

if [ $ACTION = 'start' ]
then
	if ! [ -z $SERVICE_PID ]
	then
		echo "Service PID:{$SERVICE_PID}"
	else
		nohup $SERVICE > log/$(date +%F-%H-%M-%S).log 2>&1 </dev/null &
	fi
elif [ $ACTION = 'restart' ]
then
	if  ! [ -z $SERVICE_PID ]
	then
		kill -s KILL $SERVICE_PID
	fi
	nohup $SERVICE > log/$(date +%F-%H-%M-%S).log 2>&1 </dev/null &
elif [ $ACTION == 'stop' ]
then
	if  ! [ -z $SERVICE_PID ]
        then
                kill -s KILL $SERVICE_PID
	else
		echo "Service PID not found"
        fi

fi

build.sh, service.sh, my-app - должны иметь право выполняться: chmod +x *

service.sh запускает фоном, то что выводит в stdout пишу в ./log/ - потому папка ./log должна быть создана с соотв.правами на запись

порядок действий:

./build.sh
./service.sh restart # start - чистый запуск, stop - убивает процесс

как-то так

кстати можно и nginx использовать, но там конфиг.прописывать на соотв.порт или unix-socket .. много разных способов.