В настоящее время у меня есть приложение C #, работающее как служба Windows. Приложение запускает TCPListener, затем через некоторое время цикл захватывает клиентов и немедленно передает их в ThreadPool.UnsafeQueueUserWorkItem для выполнения всей фактической работы. Клиент закрывается в конце вызова UnsageQueueUserWorkItem. Базовый код приведен ниже:
var server = new TcpListener(ip, port);
server.Start();
while (true)
{
try
{
TcpClient client = await server.AcceptTcpClientAsync();
var cw = new TcpClientService(logger, client, parser, dataRepo, propertyRecordDefinitions,
vimAlertsSent, reservations, emailClient);
ThreadPool.UnsafeQueueUserWorkItem(x => ((TcpClientService)x).Run(), cw);
}
catch(Exception iex)
{
//DO SOME LOGGING
}
finally
{
}
}
Все это работает как служба Windows на виртуальной машине в AWS. Мне интересно, подходит ли это для Google Cloud Run (или любой другой функции без сервера / состояния). Я получаю сотни запросов (клиентов) в минуту и надеюсь масштабироваться до тысяч. Насколько я понимаю, Cloud Run потенциально может быть запущен входящим запросом, тогда я мог бы просто запустить свой код TcpClientService, который в настоящее время вызывается Threadpool.UnsafeQueueUserWorkItem. Это хорошая реализация? Это то, для чего оптимизирован Google Cloud Run? Мне интересно, увижу ли я некоторую деградацию в том, что соединения с БД не могут быть объединены в пул, а некоторые другие структуры, которые я разделяю по потокам (все мои входные данные для вызова TcpClientService), должны будут обновляться при каждом вызове функции. Мысли?
