Резюме: Что-то не так с загрузкой контента напрямую в производство? Это не изменение кода или функциональности. Только редактирование/добавление контента. В настоящее время мы используем 4 сервера для этого, это немного свинство. Подробности читайте ниже.
Я только что унаследовал сеть малого и среднего бизнеса, которая имеет все виды идиосинкразий. Одна из таких идиосинкразий сбивает с толку своей сложностью. Я почти уверен, что это машина Руба-Голдберга, но я хочу быть уверен.
У нас есть клиент-серверное приложение, которое использует сервер приложений на базе IIS. Этот сервер приложений является посредником между веб-интерфейсом и подключением к базе данных, которая в нашем случае размещена на другом сервере (MSSQL2005). Есть файлы .tif, которые загружаются через это приложение и хранятся в базе данных как blob. Есть также данные, которые создают маску поверх изображения (чтобы оно могло создавать заполненные формы). Мы также размещаем публичный сервер, который действует как репозиторий для этих изображений/масок, чтобы другим не приходилось вручную создавать их.
Ладно, как у меня дела? По сути, файл .tif и данные идут на одном конце, а на другом конце общественность может скачать это изображение/данные.
Вот странная часть. Вместо того, чтобы позволить нашим пользователям загружать эти завершенные (и проверенные) изображения непосредственно в производство, они попадают на внутренний сервер. Затем процесс извлекает blob и воссоздает файл .tif. Этот процесс также извлекает только необходимые данные для форм. Затем он поступает на промежуточный сервер. Этот промежуточный сервер является дубликатом производственного сервера, но мы фактически никогда не используем эту его часть — за исключением этого процесса. После промежуточного сервера запускается другая задача, чтобы окончательно реплицировать изображение и данные на производственный сервер. Однако промежуточный сервер используется для веб-разработки. Если что-то случится, он может разорвать эту цепочку событий и остановить репликации.
Также стоит отметить, что этот производственный сервер регулярно резервируется, поэтому промежуточный сервер не предназначен для аварийного восстановления. Промежуточный сервер также никоим образом не является публичным, поэтому он не используется для резервирования. Он просто есть.
Чтобы добавить соли на рану, эти задачи, похоже, выполняются с помощью скриптов VBS, файлов BAT и запланированных задач Windows, а не с помощью каких-либо задач/триггеров SQL Server.
Мой вопрос: «А это все необходимо?» Почему нельзя настроить триггер на исходном сервере SQL для обновления производственного сервера всякий раз, когда флаг QA устанавливается в значение true? Зачем все это копирование? Есть ли причина, которую я упускаю?
Я просто хочу убедиться, что поступаю правильно, чтобы наладить работу нашей сети.
Спасибо за прочтение.
решение1
Я чувствую зловонный след лени. Полагаю, где-то в процессе разработки этого конкретного приложения что-то не сработало. Или, скорее, сработало в Staging, но не в Production. И чтобы все заработалопрямо сейчасони подключили промежуточный сервер к рабочему в том виде, как вы упомянули. Что он и сделал. И поскольку он работал, кто-то не потрудился выяснить, почему он не работал изначально, и просто оставил его.
Входите вы.
Почему это так? Потому что это работает.
Как это стало так? Неизвестно, но я думаю, что что-то сломалось и стало ключевой частью того, почему это стало так.
Не стесняйтесь разобраться с этимверноспособ.