Java 독립형 애플리케이션의 확장 성 및 고 가용성

Question

현재 Linux 상자에서 Java 통합 응용 프로그램을 실행하고 있습니다. 먼저 응용 프로그램의 개요.

Java 응용 프로그램은 독립형 응용 프로그램입니다 (Oracleas, Weblogic, Jboss 등과 같은 Java EE 애플리케이션 서버에 배포되지 않음). 스탠드만으로는 데스크탑 응용 프로그램이 아니라는 것을 의미합니다. 그러나 메인 클래스의 명령 줄에서 실행됩니다. 사용자는이 응용 프로그램과 직접 상호 작용하지 않습니다. 메시지는 API를 사용하여 대기열에 덤프 된 다음 내 응용 프로그램에서 계속 읽어 보며 지속적으로 연중 무휴 24 시간 실행됩니다. 사용자는 직접적인 상호 작용이 없기 때문에 데스크탑 앱으로 자격이 없습니다.

Spring을 사용하고 WebSphere MQ 및 Oracle 데이터베이스에 연결합니다. WebSphere MQ의 대기열을 듣는 스프링 리스너 (Spring Message Driven Pojos)를 사용합니다. 큐에 메시지가 있으면 응용 프로그램은 MQ에서 메시지를 읽고 데이터베이스에 덤프 (삽입/업데이트)를 읽습니다.

이제 문제는 다음과 같습니다.

1. 이 응용 프로그램을 어떻게 수평으로 확장 할 수 있습니까? 더 많은 상자를 넣고 동일한 응용 프로그램의 여러 인스턴스를 실행하는 것입니다. 실행 가능한 접근 방식입니까?
2. 스프링 MDP에서 EJB MDB로 이동하는 것을 고려해야합니까? 따라서 응용 프로그램 서버에 배포합니다. 그렇게함으로써 추가 혜택이 있습니까?
3. 응용 프로그램을 높이 이용할 수 있도록 요청이 있습니까 (HA)? 독립형 응용 프로그램을 만들기 위해 제안 된 방법론이나 전략은 무엇입니까?

Answer 1

"독립형"== "데스크탑"입니까?

사용자는 메시지 구동 Bean을 소유 한 컨트롤러와 어떻게 상호 작용합니까?

귀하의 질문에 대한 나의 의견 :

1. 각각의 스레드에서 실행되므로 리스너 풀에 더 많은 메시지 리스너를 추가하여 확장 할 수 있습니다. 데이터베이스 연결 풀의 크기와 메시지 리스너와 일치해야하므로 증가해야합니다. 더 많은 서버를 추가하기 전에 그렇게하십시오. 충분한 램이 있는지 확인하십시오.
2. EJB MDB가 Spring MDB를 통해 무엇을 구매하는지 모르겠습니다. "앱 서버"를 계속 참조합니다. 특히 Weblogic, Websphere, Jboss, Glassfish와 같은 Java EE 앱 서버를 의미합니까? Tomcat에 Spring을 배포하는 경우 Tomcat을이 대화에서 "앱 서버"로 간주합니다.
3. HA는로드 밸런싱 및 장애 조치를 의미합니다. 동기화되거나 핫 재배치 가능한 데이터베이스가 있어야합니다. 대기열과 동일합니다. F5는로드 밸런싱을위한 훌륭한 하드웨어 솔루션입니다. 당신이 있다면 인프라 사람들과 이야기 할 것입니다.

Answer 2

또 다른 옵션입니다 테라코타, 당신이 원하는 것을 정확하게하는 프레임 워크; 여러 기계에서 앱을 동시에 실행하고 그 중에서 부하의 균형을 맞추십시오.

Answer 3

모든 애플리케이션에 대한 수평 스케일링은 데이터 수요가 증가함에 따라 결국 한계가 발생합니다. 이러한 제한은로드 및 서버/데이터베이스 성능에 의해 결정됩니다. 어느 시점에서 스케일링으로 수요와 부하가 증가하면 서버/데이터베이스 수도 증가해야합니다. 저장중인 데이터에 따라 서버/데이터베이스는 복제 및 동기화되어야하거나 여러 서버에서 데이터를 분할하려면 일종의 해싱 알고리즘을 사용해야합니다. 동기화 된 데이터 소스 수를 늘리면 해당 서버를 복제/동기화하는 비용도 증가합니다. 그렇기 때문에 해시 접근 방식이 비용을 최소화하기 위해 더 매력적 일 수 있습니다.

진정한 고 가용성 솔루션은 구현 비용이 매우 비쌉니다. 나는 다양한 수준의 HA를 보았지만 정의상 그것은 최소의 가동 시간 또는 데이터 소스에 대한 액세스 손실을 의미합니다. 이를 달성하려면 데이터 소스 중 하나가 실패 할 때 데이터를 얻을 수있는 기능을 잃지 않고 중복 하드웨어를 활용할 수있는 중복 하드웨어, 네트워킹 및 소프트웨어가 많이 필요합니다. 하드웨어 고장은 불가피하며, 정전 및 기타 임의의 자연 행위뿐만 아니라 일어날 것입니다. 이 데이터가 얼마나 중요한지에 따라 HA 솔루션은 여러 독립 전력망에 여러 개의 데이터 센터가 필요합니다. 분명히 될 것입니다 매우 비싸기 때문에이 데이터가 최종 사용자에게 얼마나 중요한지에 달려 있습니다.

따라서 HA는 값 비싼 아키텍처가 필요한 극단적 인 시나리오입니다. 대부분의 경우 사람들이 다운 타임을 최소화하는 데 관심이 있으며 데이터 소스의 크기에 따라 데이터 소스의 핫 스피어를 추가하면 상당히 저렴하게 달성 될 수 있습니다.

Answer 4

1. 수평 스케일링 메시지 구동 앱이 쉽습니다 ... 대부분의 경우. 동일한 대기열에서 작동하는 다른 메시지 리스너를 확실히 추가 할 수 있습니다. 그러나 메시지 순서에 미묘한 의존성이있을 수 있기 때문에 조심하십시오. 프로세서 하나만 있으면 지금은 문제가되지 않을 수도 있지만 하나 이상의 경우 메시지가 어느 시점에서 "순서대로"처리 될 것이라고 보장받습니다.
2. EJB MDP는 스프링 MDBS를 넘어서는 아무것도 제공하지 않습니다. 작동하는 것을 고수하십시오.
3. 수평 적으로 프로세서를 확장하는 것이 시작이지만 이것은 조금 더 많은 토론이 필요합니다.

HA의 경우 요구 사항을 명확히해야합니다. "고 가용성"은 대기열 기반 앱의 흥미로운 질문입니다. 앱이 몇 분 동안 다운되면 메시지가 큐에 쌓여 있습니다. 앱을 백업 및 실행할 수있는 한 해당 메시지는 여전히 약간의 대기 시간만으로도 처리됩니다. 아마도 "메시지의 최대 허용 대기 시간은 무엇입니까?"

하드웨어 고장, 데이터 센터 손실 등에 대한 우려의 구성 요소가있을 수 있습니다. 동일한 위치에서 수평 스케일링으로 해결되지 않습니다. 큐 자체, 프로세서, 백엔드 데이터베이스 및 연결하는 모든 네트워크 하드웨어 등 모든 계층에서 모든 구성 요소를 복제해야합니다.

비싼 제안이므로 "HA 시나리오와 비 HA 시나리오 사이의 다운 타임의 연간 손실 기대치의 델타는 무엇입니까?" ALE는 직접 손실과 규제 또는 법적 비용을 모두 통합하므로 다운 타임 비용을 포착하는 좋은 방법입니다.

Answer 5

.1. 대기열에서 더 많은 청취자를 만들면 소비자 수가 확장 될 수 있습니다. 소비자가 사망함에 따라 나머지 소비자는 계속 운영 할 수 있습니다. 참고 : MQ와 데이터베이스에는 고 가용성 솔루션도 있어야합니다.

.2. 응용 프로그램 서버가 귀하의 경우에 어떤 차이를 만들지 확실하지 않습니다. 아마도 어떤 기능을 사용하려고하는지 설명 할 수 있습니까?

.삼. 1에 대한 내 대답을 참조하십시오.

Answer 6

여러 상자를 만들려고 했습니까? MQ의 문서를 볼 수 있다고 생각합니까? 여러 상자를 실행하면 MQ에서 약간의 구성이 필요할 수 있지만 ISA를 실행합니다.