이 디자인으로 더 발전하기 전에 현재의 접근 방식이 성능 문제로 이어질 지 여부와이 작업을 수행하는 더 좋은 방법이 있는지를 파악하려고합니다 . 내가 먼저 디자인에 대한 몇 가지 상황에 맞는 제공하는 경우이 가장 적합한 생각 :백엔드를 공개하지 않고 프론트 엔드와 백엔드 사이트간에 효율적으로 통신하기
현재 디자인 나는 현재 내 환경은 두 개의 별도의 서버로 설계 한
을의 그들이 프론트 엔드와 백엔드 호출 할 수 있습니다.
프런트 엔드
이 서버는 세계에 열려 있습니다. 고객은이 사이트를 방문하여 제품을 보거나 구매 한 후 곧 계정 관련 정보를 볼 수 있습니다.
백엔드
모든 정보가 데이터베이스에서 개최되는 경우이 서버입니다. 사용자가 자신의 라이센스 및 다운로드 우리의 제품의 인증을받은 경우에
통신
프론트 엔드는 현재 백엔드에 대한 액세스를 필요로하는 유일한 방법이다. 이를 위해 프론트 엔드는 curl_exec를 통해 JSON 요청을 백엔드 서버로 보내는 PHP 스크립트를 호출합니다. 백엔드의 응답은 프론트 엔드에게 해당 다운로드 요청을 처리하는 방법을 알려줍니다 (예 : 라이센스 무효).
추론
이 디자인에 대한 이유는 사용자에게 백엔드 정보 노출되지 않도록하는 것입니다. 클라이언트 측에서 모든 사용자는 프론트 엔드 서버로 요청을 보게됩니다. 프론트 엔드 서버가 손상된 경우 백엔드 API에 보낼 매개 변수를 정확히 알지 못하면 프론트 엔드의 빌드 방법을 읽는 사용자는 백엔드 DB에 액세스 할 수 없습니다. 그럼에도 불구하고 API가 공개하는 내용에 따라 정보의 매우 낮은 하위 집합에만 액세스 할 수 있습니다.
문제점
이 서버 간 통신이 지금 일어나는 사용자가 라이센스 세부 사항을 사용하여 우리의 제품을 다운로드하려고 할 때입니다 유일한 시간. 비교적 말하면 두 서버간에이 API를 통한 트래픽은 비교적 적습니다.
내 관심사는 사용자 "제어판"을 만들고 싶다는 것입니다. 여기에서 라이센스/계정으로 로그인 할 수 있고, 활성 라이센스를 볼 수 있으며, 이전 주문에 대한 세부 정보에 액세스 할 수 있습니다. 이는 이미 이러한 모든 정보가 백엔드에서만 사용 가능하다는 것을 의미합니다. API를 통해 노출 시키십시오. 여기서 문제는 사용자가 제어판을 통해 (페이지를 새로 고치는 것만으로도) 모든 요청이 두 서버간에 많은 트래픽을 축적한다는 것입니다.
질문 여기 개발자의 경험에서
이 커뮤니케이션 디자인은 확장 성?프론트 엔드가 백엔드로 터널링 된 많은 요청을 기다리는 결과를 낳기 때문에 병목 현상이 생기고 사용자 인터페이스가 느려지 게 될까봐 걱정됩니다.
귀하의 의견은 무엇입니까? 비슷한 도전에 직면 한 사람이 있습니까? 그 도전을 어떻게 극복 했습니까? 이러한 종류의 요구 사항을 달성하기위한 가장 좋은 방법은 무엇입니까? 이 질문이 너무 모호하지 않기를 바랍니다.
먼저 의견을 보내 주셔서 감사합니다. 병목 현상에 대한 우려가 DB 쿼리 일 필요는 없습니다. 두 서버의 PHP 스크립트 사이의 POST 요청에 비해 응용 프로그램과 데이터베이스 서버 간의 통신이 더 많습니다. 내 목표는 응용 프로그램 서버에 DB 세부 정보를 노출하지 않고 응용 프로그램 서버가 "작업"을 보내는 DB 서버의 스크립트에 위임하는 것이 었습니다. – Tiago
앱 서버의 IP가 DB 서버에 대량의 요청을 보내고 있다는 것을 의미하기 때문에 앱 서버 스크립트에서 DB 서버 스크립트로 전송되는 이러한 POST 요청이 DB 서버의 웹 서버에 의해 보류 또는 스로틀되기 시작합니다. 말이 돼? – Tiago
그것은 나에게 아직 의미가 없습니다. 방대한 양의 POST 요청이나 다른 유형의 요청에도 관심이 있습니까? 캐싱은 POST 요청에 도움이되지 않지만 컨트롤 패널 기능으로 대량의 GET 요청을 추가하는 것처럼 나에게 들린다. 캐싱은 많은 도움이된다. –