상태 기반 웹 서비스는 얼마나 훌륭하고 필요한가요?

Question

실제 프로젝트에서는 어떤 종류의 서버를 보시나요?

1) 웹 서비스는 상태 비저장이어야 합니다.기본적으로 모든 요청마다 사용자 이름/비밀번호를 보내야 하며, 모든 요청은 HTTPS를 사용해야 하며 필요할 때마다 사용자 개체를 인증하고 로드합니다.

2) 웹 서비스 세션:웹 컨테이너와 마찬가지로 적어도 인증된 User 객체를 저장할 수 있고 세션 ID와 유사한 것을 가질 수 있으므로 모든 요청에서 User를 인증, 로드 및 확인할 필요가 없습니다.

3) 고정 서비스(요청 전반에 걸쳐 지속적인 서비스): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

나는 상태 저장 서비스(및 웹 애플리케이션 세션)의 확장성 문제를 이해하지만 때로는 장바구니와 같은 일종의 상태가 있어야 합니다.하지만 이 상태를 데이터베이스에 저장할 수도 있습니다(백엔드를 일종의 세션으로 사용). 아아) 또는 전체 상태를 클라이언트에 전달합니다(클라이언트는 전체 장바구니를 다시 보낼 책임이 있습니다).

사실, 적어도 웹 애플리케이션의 경우 세션은 많은 상황에서 많은 도움이 됩니다.시스템이 "웹 서버가 다운되면 사용자가 하던 일을 다시 시작해야 한다"는 점을 인정하는 경우 확장성 문제를 무시할 수 있으며, 이것이 허용되지 않는 경우 세션 클러스터를 시도할 수 있습니다.

웹 서비스는 어떤가요?나는 웹 서비스가 웹 애플리케이션과 매우 다르다고 결론을 내리고 옵션 1)(항상 상태 비저장)을 받아들이고 싶지만 실제 프로젝트 경험을 바탕으로 다른 의견을 듣는 것이 좋을 것입니다.

Answer 1

이상적으로 웹 서비스(및 웹 사이트)는 상태 비저장이어야 합니다.

불행하게도 이를 위해서는 매우 잘 고려된 문제 영역과 명확한 관심사 분리가 필요합니다.

나는 그것을 실제로 발견했다. 최대 현실 세계 웹 사이트 확장성이 제한되더라도 상태에 의존합니다.

나도 그걸 발견했어 많은 현실 세계 웹 서비스 또한 상태에 의존합니다.

궁극적으로 '올바른' 결정은 특정 문제에 대해 작동하는 결정이므로 상태에 의존하는 웹 서비스를 작성하고 확장성이 문제가 되면 나중에 리팩터링하는 것이 괜찮을 것입니다.

Answer 2

작은 차이일 뿐이지만 여전히 언급해야 할 사항은 다음과 같습니다.

그렇지 않다 웹 서비스의 상태 확장성을 죽이는 것이 아니라 앱 서버의 상태 그것은 확장성을 죽이는 웹 서비스를 호스팅하고 있습니다.이 사용자가 이 서버에 액세스해야 한다고 말하는 순간(고정 세션에서 수행된 것처럼) 확장성 옵션이 효과적으로 제한됩니다.당신이 도달하고 싶은 요점은 '무료 로드 밸런싱 앱 서버 중 하나'가 이 웹 서비스 요청을 처리할 수 있다는 것입니다. 앱 서버를 1개 더 추가하면 % 더 많은 사용자를 처리할 수 있어야 합니다..

인증 토큰을 전달하기 위해 상태를 유지하고 각 요청마다 서비스가 데이터 저장소(예: 중복되고 분할된 저장소)에서 '상태'를 검색하도록 하려면 완전히 괜찮습니다(개인적으로 권장함).분산+복제된 키/값 데이터 저장소).이것이 바로 Amazon이 SimpleDb를 사용하고 Google이 BigTable을 사용하는 방식입니다.

Ebay는 약간 다른 접근 방식을 취하고 대부분의 클라이언트 상태를 쿠키에 저장하므로 모든 요청과 함께 전달됩니다.훨씬 더 많은 트래픽을 생성하지만 서버 중 하나가 여전히 요청을 처리할 수 있으므로 여전히 확장 가능합니다.

확장 가능한 데이터 저장소를 원한다면 다음을 살펴보는 것이 좋습니다. 레디스 키/값 데이터 저장소에서 이길 수 없는 속도와 기능을 갖추고 있습니다.

당신은 또한 확인해야합니다 highscalability.com 빠르고 확장 가능한 서비스를 구축하는 방법에 대한 좋은 자료에 액세스하려는 경우.

Answer 3

서비스가 단일 트랜잭션 지향인지(예: 주식 시세 가져오기) 또는 서비스의 출력이 여러 트랜잭션을 통해 특정 클라이언트에서 제공되는 데이터에 의존하는지(이 경우 상태가 유지되어야 함)에 따라 크게 달라집니다.

확장성 문제에 관한 한, 데이터베이스에 상태를 저장하는 것은 실제로 나쁜 방법은 아닙니다(사실 서버 팜 전체에서 서비스의 로드 밸런싱을 수행하는 경우 이것이 유일한 방법일 것입니다).

Answer 4

Flex 클라이언트를 사용하면 상태가 서비스 외부에서 클라이언트 계층으로 이동한다고 생각합니다.서비스를 상태 비저장 상태로 유지하고 클라이언트가 필요한 상태를 유지하도록 합니다.서비스는 단순하게 유지되며 클라이언트는 원하는 대로 서비스를 자유롭게 결합할 수 있습니다.

Answer 5

상태와 인증을 동일시하는 것 같습니다.세션 상태에 사용자 이름과 비밀번호를 저장하는 데 익숙하신가요?

이전 ASMX 웹 서비스의 경우에도 이는 필요하지 않습니다."로그인" 작업에 필요한 정보를 전달하기만 하면 됩니다.이 작업은 "인증 티켓" 헤더를 반환하도록 정의됩니다.

인증이 필요한 다른 모든 작업에는 이 "인증 티켓" 헤더가 필요합니다.그들은 각각 헤더를 확인하여 그것이 유효하고 인증된 사용자를 나타내는지 확인합니다.그렇다면 그들은 그들의 임무를 수행할 것입니다.그렇지 않은 경우 인증이 필요함을 나타내는 SOAP 오류를 반환합니다.

상태는 필요하지 않습니다.서비스가 실행되는 모든 서버(예: 웹 팜)에서 인증 티켓의 유효성을 검사할 수 있는지 확인하기만 하면 문제가 없습니다.