2000+ 클라이언트 시스템을위한 애플리케이션 서버로서의 REST 서비스. 좋은 생각입니까?


11

우리는 2000 개 이상의 머신에 배포 될 javaFx의 UI를 가진 시스템을 구축 할 것입니다 (최소는 2000이지만 더 많을 것입니다-5000 대의 머신에 도달 할 수 있습니다).

다른 이유 / 제한 사항은 머신에 설치해야하므로 웹 브라우저 인터페이스로는 사용할 수 없습니다.

2000+ 머신은 다른 지리적 위치 그룹에 속합니다. 일반적으로 연결 상태는 좋지만 더 많은 원격 위치에서는 연결 상태가 좋지 않을 수 있습니다.

데이터베이스에 직접 액세스하는 대신 Spring + Spring Boot + Spring Data (java)를 사용하여 REST 서비스 클러스터를 구축하려고합니다.

REST 서비스는 Json을 수락하고 리턴합니다.

다음과 같은 이유로 좋은 생각이라고 생각합니다.

  • 이 서비스는 데이터베이스 연결 풀의 역할을합니다 (데이터베이스의 2000+ 연결은 문제를 일으킬 것이라고 생각합니다).
  • 일부 쿼리를 제공하기 위해 로그 읽기가 포함 된 데이터베이스를 다른 읽기 전용 데이터베이스로 만들 수 있습니다.
  • REST 서비스를 실행하기 위해 더 많은 머신을 추가 할 수 있으므로 확장 성이 향상됩니다.
  • 보안 및 대역폭 절약을 위해 압축과 함께 HTTPS를 사용할 수 있습니다.
  • 2000+ 머신을 재배치하지 않고 비즈니스 엔티티를 중앙에서 변경하는 것이 가능합니다.
  • 다른 시스템과 더 잘 통합됩니다 (REST 서비스를 가리킴).

정말 좋은 생각입니까?

긍정적이거나 부정적인 경험을 공유 할 수 있습니까?

감사합니다.


1
REST가 캐싱을 염두에두고 설계 되었기 때문에 합리적인 아이디어라고 생각합니다. 당신은 할 수 있습니다 비 영구적 인 클라이언트 연결의 부하를 줄이기 위해 WebSocket을 사용을 고려, 그러나 이것은 당신의 API의 사용 패턴에 따라 달라집니다. WebSocket은 많은 수의 작은 요청 / 응답 트랜잭션을 지속적인 연결로 다중화 할 수있을 때 강점을 보여주기 시작합니다. 즉, 규모를 축소하는 것이 더 간단 할 수도 있습니다.
blz

8
데이터베이스는 공용 인터넷에서 액세스 할 수 없으며 항상 방화벽 뒤에 있어야합니다. 따라서 REST API 또는 이와 유사한 것을 통해 데이터베이스를 보호하는 것이 표준 절차입니다. 또한 다른 보안 기능을 더 쉽게 추가 할 수 있습니다. 예를 들어 사용자가 보거나 편집 할 권한이없는 데이터 항목을 편집하지 못하게합니다.
amon

답변:


3

이것은 당신이하려는 일에 따라 가능한 많은 답변이있는 열린 질문입니다. 그럼에도 불구하고 의견이 충분히 크지 않기 때문에 답변으로 몇 가지를 추가 할 것입니다.

이 서비스는 데이터베이스 연결 풀의 역할을합니다 (데이터베이스의 2000+ 연결은 문제를 일으킬 것이라고 생각합니다).

예, 좋은 생각입니다. 더 적은 수의 연결을 열어두고 요청이 서비스에 도착할 때 재사용합니다. 그러나 요청이 얼마나 빨리 제공되고 각 요청이 데이터베이스를 얼마나 많이 사용하는지 알아야합니다. 그렇지 않으면 작은 풀이 쉽게 고갈되고 데이터베이스 연결이 해제 될 때까지 다른 요청이 차단됩니다.

캐싱은 이미 가져온 데이터를 반환하는 데 도움이 될 수 있습니다 (내가 말했듯이 수행하려는 작업에 따라 다릅니다-쿼리가 고유하면 많이 캐시 할 수 없음).

또한 풀 크기에는 사용중인 서비스 수가 곱해집니다. 일부 서비스는 큰 데이터베이스 풀 크기를 사용할 수 있습니다. 더 많은 서비스를 제공하고 풀 크기를 줄여야 데이터베이스 전체에 동일한 수의 연결을 열 수 있습니다.

일부 쿼리를 제공하기 위해 로그 읽기가 포함 된 데이터베이스를 다른 읽기 전용 데이터베이스로 만들 수 있습니다.

데이터베이스가 쉽게 병목 현상이 될 수 있습니다. 연결이 너무 많거나 쿼리가 너무 많으면 연결이 끊어 질 수 있습니다. 이때 서비스를 수평으로 확장 할 수있는 것은 중요하지 않습니다. 모든 요청은 결국 동일한 데이터베이스에 도달합니다.

이를 보호하는 다양한 방법이 있습니다. 이미 언급 한 캐싱 (사용 사례에 따라 다름), 다른 서버에서 일부 정보를 복제하여 언급 한대로 일부 쿼리를 제공함 , CQRS (사용 사례에 따라 다름), 관계형 vs 비 관계형 사용 (사용 사례에 따라 다름) 등

이와 같은 데이터를 배포하면 CAP 정리 가 적용되기 시작합니다. 일관성과 가용성 사이에서 타협해야 할 수도 있으므로주의하십시오.

REST 서비스를 실행하기 위해 더 많은 머신을 추가 할 수 있으므로 확장 성이 향상됩니다.

예, REST 서비스는 확장되지만 위에서 언급 한 것처럼 데이터베이스를 보호하지 않으면 병목 현상이 발생하기 쉽습니다.

보안 및 대역폭 절약을 위해 압축과 함께 HTTPS를 사용할 수 있습니다.

예, 다른 것뿐만 아니라 나중에 인증 / 인증을 원할 수도 있습니다.

2000+ 머신을 재배치하지 않고 비즈니스 엔티티를 중앙에서 변경하는 것이 가능합니다.

예, 그러나 어느 정도까지는 모든 종류의 변화가 아닙니다. 주요 변경 사항이 있으면 클라이언트도 업데이트해야합니다. 따라서 클라이언트를 최신 버전으로 업데이트하거나 이전 클라이언트가 계속 작업하고 응용 프로그램을 사용할 수 있도록하는 전략을 생각해보십시오.

다른 시스템과 더 잘 통합됩니다 (REST 서비스를 가리킴).

예, 그러나 그것은 당신이 통제 할 수없는 서비스를위한 클라이언트를 의미합니다.

주요 변경 사항을 적용하고 2000+ JavaFX 클라이언트를 업데이트하는 좋은 전략이 있다면 아무런 문제가 없습니다. 그러나 다른 클라이언트가 존재하고이를 제어 할 수없는 경우 REST 서비스에서 버전 관리를 구현하고 모든 사람이 최신 버전으로 업데이트 할 수있을 때까지 둘 이상의 버전을 지원해야합니다.

내가 말했듯이, 그것은 당신이하려는 일에 달려 있습니다. 전반적으로, 당신은 좋은 생각입니다. 그러나 데이터베이스 앞에 REST 서비스를 사용하기 때문에 물건이 무료로 제공되지는 않습니다.

그냥 내 2 센트!


좋은 답변입니다. 나는 가능한 한 빨리 RESTful API에서 버전 관리를 고려할 가치가 있다고 Thiago에게 강조하고 싶었습니다. 처음에해야 할 필요는 없지만 알고 있어야하고 준비해야합니다.
Daniel Hollinrake
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.