Моя команда изучает проблему в нашей производственной среде (см. сообщение о переполнении стека). Мы тщательно изучили уровень приложения (например, код, журналы и т. Д.), А также провели анализ пакетов низкого уровня, но безрезультатно. Странно то, что эта проблема возникает только в производственной среде. Еще более странно то, что код неисправности не менялся более года.
Сейчас мы подошли к тому моменту, когда нам нужно начать изучать другие варианты, одним из которых является замена производственной среды на новую. Здесь я надеюсь, что вы все можете мне чем-то помочь.
Я ищу предложения / рекомендации о том, как как можно проще заменить старую производственную среду на новую. Однако в течение некоторого времени мне нужно, чтобы старая и новая среда работали в тандеме, чтобы убедиться, что новая среда решает проблему. Новая среда будет использоваться группой администраторов, в то время как старая среда будет использоваться не администраторами. После того, как мы выполним нашу проверку, старая среда будет полностью отключена.
Я думал поставить какой-то прокси перед сервером, чтобы я мог перенаправлять запросы по мере необходимости, и смотрел на Приложение Load Balancer Apache Tomcat. Я не уверен, что это будет лучший подход, поэтому надеюсь, что кто-то здесь может предложить несколько предложений.
Предположения
Серверные технологии приложений
Глядя на ТАК вопрос Я не знаю, что это проблема системного уровня - описание там похоже на ошибку приложения. В любом случае, всегда стоит подумать об обновлении вашей среды, поэтому я попробую :-)
Общий план действий для серьезного изменения программного обеспечения или миграции обычно выглядит следующим образом (из вашего вопроса SO, везде, где я говорю DB / Database, вы должны думать о своем сервере App2):
В вашем случае, в зависимости от того, где возникает странное поведение, вы можете сократить большую часть этого на шаге 3: если ваши администраторы - единственные, кто видит некорректную часть приложения, тогда ваши администраторы могут победить тестовую копию среды, пока они не воспроизведут ошибку или не убедятся, что она исчезла (и если ошибка появится, вы вернетесь в область приложений).
Если проблема связана с пользователем, единственное реальное решение - разместить новый материал там, где пользователи могут его получить, что в основном означает прохождение всего процесса.
У вас также есть несколько разных проблем, потому что вы хотите запускать свои среды параллельно: если обе среды будут писать в базу данных, вам нужно будет принять меры предосторожности, чтобы убедиться, что обе среды записывают одинаковую информацию в свою копию базы данных (мультиплексирование соединения на вашем балансировщике нагрузки), или что обе среды могут безопасно взаимодействовать с единой базой данных.
Параллельная работа в значительной степени устраняет первый и третий пункты из пункта 5 выше (вы не дублируете серверные части, а «старая» среда продолжает работать - вы просто поддерживаете новую рядом с ней).
В вашем конкретном случае с идентичными приложениями в App1 вы можете использовать App2 в качестве общей базы данных, но это то, о чем вам нужно подумать с точки зрения программного обеспечения (будет ли App2 волноваться, если он увидит, что с ним разговаривают несколько хостов?).
Независимо от того, что вы делаете, определенно держитесь за свою старую среду некоторое время, не касаясь ее (это может быть дольше или короче, в зависимости от вашей конкретной ситуации - например, в моей компании примерно через 8 часов после серьезного изменения схемы БД мы накопил так много данных, что мы не можем откатиться назад: потеря данных будет катастрофической, а восстановление затянется).
Как только вы убедитесь, что новая среда решила вашу проблему (или, по крайней мере, работает так же хорошо, как старая среда без новый проблемы) вы можете превратить старый материал в лабораторию разработки.