Cris
Member
Будет большая стена текста с всей необходимой информацией, нужна подсказка.
Задание:
Делаю курсовую. Задача - сделать система для туристической компании.
Задачи системы: составление/продажа туров, отчеты, некоторая функциональность для управления компании.
Будет интеграция сторонних систем для бухгалтерии, управление персоналом и еще некоторые.
Система так же будет автоматически резервировать места в гостинице, делать страховку, покупать билеты для путешествия.
Главная задача системы - возможность масштабируемости, в будущем компания разрастается на весь мир.
С системой будут работать, в основном, только персонал компании в офисах, но будет предоставлять некоторые функции и для конечного клиента + иметь доступ к система в любой точке мира.
Технология: С#.NET
Курсовая делается не в одиночку.
Что решили:
Остановились на решении сделать веб-приложение, но учитывая наши "глубокие" познания C# и вообще технологий для масштабируемости веб приложений появились проблемы.
Что хотим сделать:
Будет IIS сервер на котором будет "frontend" часть приложения.
При возрастании нагрузки будем добавлять IIS сервера и балансировать его же возможностями(Application Request Routing)
Система должна поддерживать добавление новых подсистем.
Допусти: есть подсистема которая работает с гостиницами и имеет метод getHotel(id).
Теперь, как вызвать метод getHotel из фронт энда в подсистеме которая может находится на другом сервера?
Решили делать так: фронтенд подключается к серверу очереди и делает задачу для подсистемы которая работает с гостиницами на получение информации, и продолжает пока обрабатывать другие данные.
Фронтенд и подсистема подключены к очереди какой-то магией(скорей всего это будет сокет и с передачей данных в json, но хотелось бы что-то более родного для .net, думали над web services но не до конца разобрались с ним) - это одна из проблем.
Очередь запросов сообщает всем гостиничным подсистемам что появилась задача. - необязательно, возможно подсистемы просто будут опрашивать очередь.
Подсистема (их может быть несколько для балансировки нагрузки)
обращается к очереди и берет себе задачу, делает, возвращает результат назад в очередь.
Проблема: как правильно очереди сообщить фронтенду что пришел результат и его можно вернуть клиенту(фронтенд в это время, если уже все сделал, ждет информации о гостинице)?
Вариант решения, который мне не очень нравится: внутри asp.net веб приложения будет работать бэкграунд(я еще не знаю как его сделать) и слушать соединение с очередью, когда он получает данные от очереди, что информация готова, и собственно получает ее, он должен сделать магию и передать эти данные в нужный экземпляр веб приложения которое ждет их.
Как это сделать: фронтэнд, когда хочет отправить запрос на получении информации, вызывает метод из бэкграунд потока, передает ему что он хочет сделать и указатель на объект куда нужно записать ответ, в ответ получает mutex который нужно заблокировать, этот мьютекс первоначально заблокирует сам бекграунд и разблокирует только когда придут данные, бекграунд создаст пару мьютекс-идентификатор: и идентификатор уже отправит в очередь.
Фронтенд в это время уже продолжит работать и когда ему понадобится результат запроса он просто заблокирует мьютекс и продолжит когда он освободится бекграундом что означает что есть результат.
Мне это решение не совсем нравится, хочется чего-то другого.
Проблема: как правильно сделать приложение для очереди? я думаю делать приложение + key-value бд которая все будет хранит.
самый простой варинт - хранить все запросы в памяти, но это может быть печально если упадет сервер и как все восстановить.
Что делать если упадет очередь или подсистема?
Если упадет фронтенд - оборвутся коннекты с клиентом, но что делать с подсистемой и очередью которые выполняют запросы?
Если упадет подсистема: очереди нужно хранить еще приблизительное время выполнения запроса и опрашивать подсистему на счет результат/продление времени, если очередной запрос неудачный - то или сообщить фронтенду,что есть проблемы или снова поставить задачу на конвейер для другой подсистемы.
Что делать если упадет очередь? по смыслу "если упадет подсистема" все может выполнять бекграунд на фронтенде.
масштабируемость: фронт енд, очередь, подсистемы могут быть в нескольких экземплярах на нескольких серверах.
п.с. что-то какая-то стена текста получилась
п.с.2 учусь в Чехии, Прага, частный университет. факультет информатики.
Задание:
Делаю курсовую. Задача - сделать система для туристической компании.
Задачи системы: составление/продажа туров, отчеты, некоторая функциональность для управления компании.
Будет интеграция сторонних систем для бухгалтерии, управление персоналом и еще некоторые.
Система так же будет автоматически резервировать места в гостинице, делать страховку, покупать билеты для путешествия.
Главная задача системы - возможность масштабируемости, в будущем компания разрастается на весь мир.
С системой будут работать, в основном, только персонал компании в офисах, но будет предоставлять некоторые функции и для конечного клиента + иметь доступ к система в любой точке мира.
Технология: С#.NET
Курсовая делается не в одиночку.
Что решили:
Остановились на решении сделать веб-приложение, но учитывая наши "глубокие" познания C# и вообще технологий для масштабируемости веб приложений появились проблемы.
Что хотим сделать:
Будет IIS сервер на котором будет "frontend" часть приложения.
При возрастании нагрузки будем добавлять IIS сервера и балансировать его же возможностями(Application Request Routing)
Система должна поддерживать добавление новых подсистем.
Допусти: есть подсистема которая работает с гостиницами и имеет метод getHotel(id).
Теперь, как вызвать метод getHotel из фронт энда в подсистеме которая может находится на другом сервера?
Решили делать так: фронтенд подключается к серверу очереди и делает задачу для подсистемы которая работает с гостиницами на получение информации, и продолжает пока обрабатывать другие данные.
Фронтенд и подсистема подключены к очереди какой-то магией(скорей всего это будет сокет и с передачей данных в json, но хотелось бы что-то более родного для .net, думали над web services но не до конца разобрались с ним) - это одна из проблем.
Очередь запросов сообщает всем гостиничным подсистемам что появилась задача. - необязательно, возможно подсистемы просто будут опрашивать очередь.
Подсистема (их может быть несколько для балансировки нагрузки)
обращается к очереди и берет себе задачу, делает, возвращает результат назад в очередь.
Проблема: как правильно очереди сообщить фронтенду что пришел результат и его можно вернуть клиенту(фронтенд в это время, если уже все сделал, ждет информации о гостинице)?
Вариант решения, который мне не очень нравится: внутри asp.net веб приложения будет работать бэкграунд(я еще не знаю как его сделать) и слушать соединение с очередью, когда он получает данные от очереди, что информация готова, и собственно получает ее, он должен сделать магию и передать эти данные в нужный экземпляр веб приложения которое ждет их.
Как это сделать: фронтэнд, когда хочет отправить запрос на получении информации, вызывает метод из бэкграунд потока, передает ему что он хочет сделать и указатель на объект куда нужно записать ответ, в ответ получает mutex который нужно заблокировать, этот мьютекс первоначально заблокирует сам бекграунд и разблокирует только когда придут данные, бекграунд создаст пару мьютекс-идентификатор: и идентификатор уже отправит в очередь.
Фронтенд в это время уже продолжит работать и когда ему понадобится результат запроса он просто заблокирует мьютекс и продолжит когда он освободится бекграундом что означает что есть результат.
Мне это решение не совсем нравится, хочется чего-то другого.
Проблема: как правильно сделать приложение для очереди? я думаю делать приложение + key-value бд которая все будет хранит.
самый простой варинт - хранить все запросы в памяти, но это может быть печально если упадет сервер и как все восстановить.
Что делать если упадет очередь или подсистема?
Если упадет фронтенд - оборвутся коннекты с клиентом, но что делать с подсистемой и очередью которые выполняют запросы?
Если упадет подсистема: очереди нужно хранить еще приблизительное время выполнения запроса и опрашивать подсистему на счет результат/продление времени, если очередной запрос неудачный - то или сообщить фронтенду,что есть проблемы или снова поставить задачу на конвейер для другой подсистемы.
Что делать если упадет очередь? по смыслу "если упадет подсистема" все может выполнять бекграунд на фронтенде.
масштабируемость: фронт енд, очередь, подсистемы могут быть в нескольких экземплярах на нескольких серверах.
п.с. что-то какая-то стена текста получилась
п.с.2 учусь в Чехии, Прага, частный университет. факультет информатики.