2011-05-11 3 views
0

현재 Im은 Java 웹 응용 프로그램을 개발 중이고 단일 웹 서버를 최대한 활용하기 위해 여러 가지 기술 유형을 결합하는 방법을 연구하고 있습니다. 지금까지자바 애플리케이션을위한 일반적인 웹 아키텍처는 무엇입니까?

내 계획은 다음과 같은 아키텍처 설정

Internet -> 
Varnish (reverse proxy) -> 
Apache2 (mod_pagespeed, mod_jk) -> 
Ehcache-web (caching html page fragments,spring-cache) -> 
Tomcat (java appsrv) -> 
Ehcache (cache layer) -> 
MySQL (persistance layer) 

이 디자인에 문제가 있습니까을하는 것입니다? 그렇다면 스케일링 및 클러스터링은 어떻게됩니까? 다른 (더 나은) 솔루션이 있습니까?

감사합니다.

+0

달려있다 - 나는 당신이 짓고있는 응용 프로그램이 정말로 열심히 타격을 가하지 않는 한 Varnish 날 1을 사용하는 것을 고려하지 않을 것이다. Tomcat과 MySQL (캐싱 레이어) 사이에서 memcached를 사용하는 것도 고려해야합니다. – lobster1234

+0

아아, 바람둥이와 MySQL 사이에 ehcache가 있습니다. – netbrain

답변

1

전통적인 방식으로 웹 응용 프로그램을 구상하지는 않지만 서비스 제공 업체와 소비자 측면에서는 그렇습니다. 직장에서는 Shindig 인터페이스를 구현하여 빌드 된 Tomcat에서 실행되는 RESTful API 레이어를 사용했습니다. 계층은 MongoDB뿐만 아니라 MySQL과 상호 작용합니다. 우리는 Memcached를 사용하여 near/far 캐싱을 수행했습니다. Memcached는 많은 목록을 사용하고 기반 작업을 설정한다는 점에서 Redis로 이동할 계획입니다. 이 레이어는 특정 API (예 : 상태 업데이트 푸시)와 관련하여 Twitter 및 Facebook과도 연결됩니다. 모든 엔드 포인트는 OpenSocial 호환 REST/XML 호출로 액세스 할 수 있습니다. 우리는 NewRelic을 사용하여 서비스 성능과 SLA를 모니터링합니다. 현재 우리는 10ms의 응답 시간으로 30K RPM을 조금 넘습니다. 우리는 4 개의 Tomcat, 3 개의 memcached, 3 개의 MySQL (1M 2S) 및 3 개의 MongoDB (replicaset) 클러스터를 가지고 있습니다. 모든 스택은 XenServer에서 호스팅하고 Centos를 실행하는 가상 컴퓨터에서 실행됩니다. 우리는 알림을 보내거나 제 3 자 (트위터/페이스 북)와 대화하는 것과 같은 메시징/비동기 작업을 위해 RabbitMQ를 사용하여 VM 스레드를 차단하지 않습니다. 플랫폼이 대중화되면서 가까운 시일 내에 HornetQ + Scala Actors로 이동할 계획입니다. 검색은 Solr에서 실행되지만 ElasticSearch로 적극적으로 마이그레이션하고 있습니다.

우리는 하나 이상의 클라이언트 플랫폼을 제공 할 수 있도록이 API/서비스 기반 모델에서 시스템을 설계했습니다. 따라서 모바일 앱이 출시되면 모바일 용으로 별도의 스택 세트를 사용하는 대신 API를 다시 사용할 수 있습니다. 이 아키텍처는 프런트 엔드와의 연결없이 백 엔드 오퍼링을 추상화합니다. 우리가 가지고있는 프런트 엔드는 PHP/Zend에 내장되어 있으며 JQuery를 광범위하게 사용합니다. Google은 HTML5, Phonegap 및 Sencha 터치를 사용하여 모바일 프런트 엔드를 구축하고 있습니다.

보안을 위해 개방형 GET이 있지만 쓰기는 2-legged oauth를 통해 보안됩니다. 외부 소비자 및 앱 개발자에게 API를 개방하면 3-ogeh oauth를 제공해야합니다.

이 요약본이 도움이되기를 바랍니다. 추가 정보가 필요하거나 질문이 있으시면 언제든지 주저하지 말고 의견을 말하십시오.

+0

참으로 흥미 롭습니다. 플랫폼 및 기술 선택 및 기타 유틸리티에 대한 의견을 보내 주셔서 감사합니다. – netbrain

1

우리는 mod_jk를 통해 apache와 통신하는 4 개의 서버에 6 개의 서버에 3 개의 Apache (2)로드 밸런서를, 3 개의 바니시 프록시를 사용합니다. RDBMS로서 우리는 Oracles를 보유하고 있습니다. 나는 DB 선택이 중요하다고 생각한다. 우리의 콘텐츠는 우리 존재입니다. 그 이유 때문에 DB 제품이 필요합니다. 응답 성, 견고 함, 확장 성, 신뢰성, 가용성 등입니다. 최악의 경우 지원이 필요할 수 있습니다. 이러한 이유로 우리의 선택은 오라클이었습니다.

Tomcat/Application Server 선택은 응용 프로그램 아키텍처에 따라 다릅니다. 우리의 경우 우리는 Coremedia CMS (콘텐츠 서버, 마스터 라이브 서버, 피더 (feeder) 등 CORBA를 통해 통신하는 분산 서비스를 포함하는 Spring 기반 CMS)와 클러스터 된 Tomcat만으로 충분합니다.

나는 목록/설정과이 조합이 대부분의 경우에 매우 훌륭하고 충분하다고 생각합니다.