전통적인 방식으로 웹 응용 프로그램을 구상하지는 않지만 서비스 제공 업체와 소비자 측면에서는 그렇습니다. 직장에서는 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를 제공해야합니다.
이 요약본이 도움이되기를 바랍니다. 추가 정보가 필요하거나 질문이 있으시면 언제든지 주저하지 말고 의견을 말하십시오.
달려있다 - 나는 당신이 짓고있는 응용 프로그램이 정말로 열심히 타격을 가하지 않는 한 Varnish 날 1을 사용하는 것을 고려하지 않을 것이다. Tomcat과 MySQL (캐싱 레이어) 사이에서 memcached를 사용하는 것도 고려해야합니다. – lobster1234
아아, 바람둥이와 MySQL 사이에 ehcache가 있습니다. – netbrain