2012-02-04 2 views
1

응용 프로그램 서버의 수가 APP1, APP2, APP3 ... APPN 인 것으로 가정합니다.웹 응용 프로그램을 n 개의 응용 프로그램 서버와 dao를 사용하여 웹 응용 프로그램을 확장하는 경우

이제 모든 앱 서버는 동일한 DB에 액세스해야합니다.

그래서 내가 별도의 컴퓨터 시스템에 DB와 함께 DAO를 넣고 내 웹 기반 응용 프로그램을 확장 내게 도움이 될 것입니다 웹 서비스

으로 DAO를 노출하지만?

나는 아키텍처

  load banncer 
appS1 appS2 .....  appSn 

     dao as webservice 
     DB 

좋은 생각인가 다음 사용할 계획? 어떻게 그러한 아키텍처에서 세션 관리를 처리 할 수 ​​있습니까?

+0

나쁘지 않아, 당신은 또한 웹 서비스에서 결과의 일부를 캐시 할 수 있습니다 메모리 안에서 웹 서비스로부터 캐시를 넣을 수도 있습니다. 앱 내에 메모리 캐시를 가질 수 있습니다. 그게 더 좋아질거야. – DarthVader

+0

가장 좋은 방법입니까? DAO 레벨 권리 (위의 3 번 수준) 또는 응용 프로그램 수준에서 현금화하는 것을 의미합니까? 나는 DAO 수준 인 – user93796

+0

에서 최대 절전 모드를 사용하려고 계획 중입니다. 캐싱해야합니다. 최대 절전 모드 캐싱에 대해서는 확신 할 수 없지만 예를 들어 앱 서버와 DAO 간에는 memcached를 사용할 수 있습니다. 응용 프로그램 및 웹 서비스에서 메모리 캐싱을 사용하여 가장 자주 사용되는 데이터 또는 쿼리 결과를 저장합니다. 데이터를 콜렉션 및 조회 콜렉션으로 저장할 수도 있습니다. – DarthVader

답변

1

당신이 가진 것은 괜찮습니다. 그러나 웹 서비스 인 DAO는 증가하는로드에 대처할 수 없으며 웹 서비스 요청은 네트워크 오버 헤드를 추가 할 수 있습니다. 내가 제안하는 것은 당신의 앱을 그대로 유지하고 캐싱 (코드 변경이 필요할 수 있음)을 추가하고 앱 서버와 데이터베이스를 확장하는 것입니다.

일반적인 방식으로 수평 확장하려면 DBMS에 더 많은 응용 프로그램 서버와 더 많은 슬레이브를 추가해야합니다. 일반적으로 값 개체 및 일반적으로 시간이 지남에 따라 많이 수정되지 않는 자주 필요한 개체를 캐시하는 데 사용되는 MemcacheD와 같은 캐싱 서버를 추가합니다. 캐싱은 결과가 캐시되므로 쿼리보다 빠르게 응답합니다.

위의 접근 방식은 약 8 년간 사용되었습니다. 데이터가 저장되는 방식과 인프라 가용성에 대한 최근 변화로 인해 대담한 모드 () 기존 앱을 수정하기 위해 목에 통증이있을 수 있습니다.) 단계는 앱을 (부분적으로 또는 완전히) 수정하여 no-SQL 데이터 저장소를 사용하는 것입니다. 이러한 데이터 저장소는 무거운 읽기 - 쓰기 용으로 특별히 제작되었습니다 . 이이 방법으로 가면 많은 옵션이 있습니다 - 카산드라, MongoDB를, 디나모, 그리고 many more

관련 문제