코드를 모듈화하여이 문제를 해결했습니다.

우리의 주요 웹 사이트는 약 8 년 전에 지어졌으며, 스프링 프레임 워크의 초기 공헌자 중 한 명이 웹 사이트를 구축 할 수있을만큼 운이 좋았 기 때문에 꽤 잘 세워진 기초였습니다. 그러나 불행히도 우리는이 개발자가 진행 방향에 대한 논쟁 후에 스프링을 포크하기로 결정했을 정도로 운이 좋지 않았 으므로이 코드베이스는 이제 스프링 1.1.4 (또는 그 빈티지의 것)의 유지되지 않는 포크에 붙어 있습니다.

우리는 새로운 버전의 Spring으로 이동하기 위해 코드를 다시 작성하려고 시도했지만 매우 어려웠습니다. 따라서 우리의 솔루션은 Spring 3.x, Hibernate 3.6 등과 같은 최신 프레임 워크를 사용하여 사이트의 새로운 기능을 완전히 별도의 애플리케이션에서 모듈로 구축하는 것이 었습니다.

이제 동일한 기본 URL에서 실행되는 두 개의 웹 응용 프로그램이 있으며 Apache의 mod_proxy 모듈을 사용하여 각 경로를 적절한 응용 프로그램에 할당합니다. 예를 들어 “/ members”는 이전 응용 프로그램으로 이동하고 “/ directory”는 새 응용 프로그램으로 이동합니다. 그러나 사이트 방문자는 다른 응용 프로그램을 사용하고 있는지 전혀 모릅니다. 그들은 사용자와 똑같이 보입니다.

예를 들어, 회원이 사이트에 로그인 할 때 (새로운 애플리케이션을 사용하여) 두 애플리케이션은 통신해야합니다. 기존 애플리케이션에 현재 로그인되어 있음을 알려야합니다. localhost. 두 앱간에 필요한 통합 양은 최소로 나타났습니다.

이 작업을 수행하는 데있어 중요한 부분은 공유 자산을 식별하고 함께 패키지하는 것이 었습니다. 따라서 모든 정적 텍스트, 그래픽, 스타일 시트, Javascript 및 템플릿은 원본 응용 프로그램에서 새 응용 프로그램과 기존 응용 프로그램이 모두 사용하는 별도의 세 번째 프로젝트로 옮겨졌습니다. 이를 통해 웹 응용 프로그램은 완전히 분리되어 있어도 동일한 방식으로 보이고 작동합니다.

시간이 지남에 따라 우리는 궁극적으로 완전히 필요하지 않을 때까지 점점 더 많은 원래 응용 프로그램을 교체 할 것이라고 생각합니다. 이 기술의 좋은 점은 일련의 작고 위험이 적은 변경을 통해 천천히 수행 할 수 있다는 것입니다. 새로운 시스템으로 대규모의 위험한 갑작스런 전환이 필요하지 않습니다.

답변