Как лучше всего отделить веб-службу от ее общедоступных доменных имен?
Я пытаюсь разработать систему, которая позволяет использовать несколько общедоступных конечных точек, которые переходят в одну веб-службу. Веб-служба должна иметь возможность определять, какая конечная точка была предполагаемым адресатом запроса. Вот небольшой пример конфигурации, которая может соответствовать всем требованиям:
В этой системе «обратные прокси» (за неимением лучшего термина) добавляют заголовок HTTP к входящим запросам, прежде чем они попадут в веб-службу. В противном случае прокси полностью прозрачны для запроса и ответа.
Мы - магазин Windows, использующий IIS7 / WCF.
Цель состоит в том, 1) поддерживать только одну веб-службу, а не одну для каждого домена, и 2) отделить управление доменом / веб-сайтом от бизнес-логики веб-службы. То есть, если мы знаем, что контекст всегда будет указываться с ключом в заголовке HTTP, тогда нам не нужно беспокоиться об изменении доменов или конкретном содержимом Request.Headers["HOST"].
Мои вопросы: разумный ли это подход? Если да, то есть ли приложение, которое будет выполнять работу «обратных прокси»? (Squid? Сам IIS?)
Спасибо вам за помощь!
Мне кажется, что вы пытаетесь создать одно приложение, которое выполняет две совершенно разные вещи. В определенный момент база кода и функциональность будут частично совпадать, но я недостаточно хорошо знаю ваше приложение, чтобы помочь вам в этом. У меня есть 2 возможных решения для вас:
Я бы попытался отделить код, связанный с представлением, от ваших контроллеров и моделей, если вы идете в направлении MVC. Это даст вам более четкое разделение бизнес-логики. Один из возможных способов сделать это - поместить ваши представления в 2 отдельных каталога, но затем включить код из общего 3-го каталога. Это дает вам одну общую библиотеку, которая обрабатывает внутреннюю логику, четко разделяя логику представления.
Я бы не стал бояться заголовка HTTP Host. Это требуется для HTTP / 1.1, и все современные браузеры его используют. Черт возьми, виртуальный хостинг полностью зависит от него, и вам будет сложно найти администратора IIS или Apache, который сказал бы вам не использовать виртуальные хосты в производстве. Большой недостаток, конечно, заключается в том, что если вы выполняете проверку заголовка на стороне приложения, вы можете столкнуться с некоторыми довольно уродливыми операторами if / case. Единственное, что делает установка обратного прокси, - это ищет хост и добавляет еще один заголовок в дополнение к хосту. Таким образом, вы действительно просто добавляете больше заголовков и усложняете свою архитектуру с помощью обратного проксирования.
Во-первых, ваше поле HTTP-хоста должно сохраняться вашим обратным прокси-сервером, когда он передает запрос. Если это не так, значит, ваш прокси настроен неправильно (и странно!).
Во-вторых, передача дополнительных заголовков и идентификация трафика с их помощью является стандартным и приемлемым способом идентификации трафика, обрабатываемого балансировщиком нагрузки. Например, именно так обычно настраиваются балансировщики нагрузки, чтобы информировать веб-серверы о том, что трафик поступает через SSL (поскольку SSL не может быть проксирован на этом уровне).
Наконец, я думаю, что вы слишком усложняете свою проблему. Насколько часто доменные имена меняются по сравнению с содержимым, стоящим за ними ?! На самом деле Интернет не так устроен ... Нет ничего плохого в том, что ваше приложение обслуживает контент на основе имени домена в заголовке HTTP Host, это очень распространенная практика.
Один из способов сделать это - иметь небольшой набор облачных балансировщиков нагрузки, каждый из которых нацелен на ваш веб-сервис. Rackspace предоставляет LBaas, и, возможно, другие тоже.
http://www.rackspace.com/cloud/cloud_hosting_products/loadbalancers/
Полное раскрытие информации: я работаю в Rackspace, но не в продажах.