응용 프로그램이 클라이언트 서버 모델입니다.클라이언트 서버 아키텍처 디자인
클라이언트 응용 프로그램에는 고객이 일상적으로 사용하는 로컬 데이터베이스가 있습니다.
서버는 클라이언트의 통합 정보가있는 다른 데이터베이스와 다른 주요 사항을 보유하고 있습니다. 등 (클라이언트 측에서 사용할 수없는) 서버로부터 데이터
클라이언트 또는 서버 둘 갖는 정적 IP 주소를 액세스, 데이터 마이그레이션 :
주기적으로, 클라이언트와 서버에 대한 통신 할 필요가있다.
클라이언트가 서버에 원활하게 연결할 수 있도록하려면 어떻게해야합니까?
모든 것을 단일 위치 (예 : 클라우드 또는 데이터 센터)에 배치하는 것은 비즈니스 요구 사항으로 인해 옵션이 아닙니다.
단일 서버가있는 경우 정적 IP를 사용할 수없는 이유는 무엇입니까?
항상 외부에서 볼 수있는 IP가 있습니까? 그러면 동적 DNS가 당신을위한 것입니다. 서버가 IP 주소 변경시 DNS 서버에 알립니다.
어느 누구도 공개 할 수없는 주소가 없다면 중재자 (프록시)가 필요합니다. 이제이 중재자는 데이터를 알게되거나 데이터가 암호화됩니다.
이러한 중재자는 서버에 server @ mydomain과 같은 특정 JID가 할당되는 XMPP 서버 일 수 있으며 클라이언트는 자신의 ID (예 : customername @ mydomain)에 할당되거나 일부 PubSub 솔루션 또는 클라이언트와 서버 모두 주기적으로 사서함을 읽는 전자 메일 기반 솔루션 (예, 더러운 경우) 일 수도 있습니다.
대부분의 ESB 솔루션에서도 마찬가지입니다.
인터넷에서 클라이언트 - 서버 아키텍처를 생성하려면 서버 (또는 자체 응용 프로그램 별 프로토콜로 서버에 연결하는 중재자)에게 공개적으로 접근 할 수 있어야합니다.
나는 DynDNS 방식으로 이것을하려고 생각했다. 차이점은 프록시 서버가 두 피어 사이에 있고 두 피어가 프록시를 IP에 대해 알리는 클라이언트를 실행하게된다는 것입니다. 두 명의 동료가 의사 소통하기를 원할 때 그들은 다른 동료의 IP 주소가 무엇인지에 대해 프록시에게 물어볼 것이며 프록시는 가장 많은 uptodate IP를 줄 것입니다. – daehaai
그들 사이에 안정적인 무언가가 있다면, VPN과 같은 무언가에 양방향 채널을 구축 할 수도 있습니다.하지만 통신이이 무언가를 통해 진행될 필요가 없다는 것은 사실입니다. 단지 이름 일뿐입니다. 기재. – Aadaam
요구 사항은 클라이언트 서버 대신 P2P 응용 프로그램처럼 들립니다. "비즈니스 요구 사항 때문에 한 위치 (예 : 클라우드 또는 데이터 센터)에서 클라이언트 및 서버 데이터베이스와 서비스를 배치 할 수 없습니다." – Rudy
이 요구 사항은 데이터를 필요로하는 고객으로부터 온 것입니다 그들의 전제 : | (그래 물어 보지 !!!) – daehaai