클라이언트-서버 아키텍처

1.1 애플리케이션 아키텍처

이 과정은 오랫동안 진지한 애플리케이션의 아키텍처를 설계하지 않을 것이기 때문에 초보자를 위해 설계되었습니다. 그러나 걱정하지 마십시오. 좋은 아키텍처는 규칙이 아니라 예외입니다. 애플리케이션을 구축하기 전에 올바른 애플리케이션 아키텍처를 선택하는 것은 매우 어렵습니다 .

대형 서버 애플리케이션에 널리 사용되는 아키텍처의 예:

• 계층화 된 아키텍처 (Layered Architecture).
• 계층화된 아키텍처.
• 서비스 지향 아키텍처(SOA).
• 마이크로서비스 아키텍처(Microservice Architecture).

그들 각각은 장단점이 있습니다. 그러나 그것들을 공부하면 아무 것도 얻을 수 없습니다. 아키텍처는 "시스템 내에서 수천 개의 개체 상호 작용을 구성하는 방법"이라는 질문에 대한 대답입니다 . 그리고 문제의 전체 복잡성을 경험하기 전에는 솔루션의 전체 다양성을 이해할 수 없습니다.

모든 애플리케이션은 일종의 아키텍처를 사용하거나 최소한 그렇게 하는 척합니다. 따라서 응용 프로그램 설계에 대한 대중적인 접근 방식에 대한 지식을 통해 응용 프로그램 작동 방식을 빠르고 더 잘 이해할 수 있습니다. 이는 필요한 부분을 정확하게 변경하는 것을 의미합니다.

"필요한 경우 변경"은 무엇을 의미합니까? 변경할 필요가 없는 부분이 있습니까? 정확히.

구체적으로 중간 크기의 백엔드 프로젝트를 진행 중이라고 가정해 보겠습니다 . 20명으로 구성된 팀이 5년 동안 작성했습니다. 이 프로젝트는 100인년이 걸렸고 약 10만 줄의 코드가 포함되어 있습니다. 총 2,000개의 클래스로 구성되어 있으며 크기가 다른 10개의 모듈로 나뉩니다.

그리고 가혹한 현실을 추가하십시오. 일부 작업의 논리는 여러 모듈에 분산되어 있습니다. 또한 비즈니스 로직은 프런트엔드(JavaScript로 작성)에 있거나 데이터베이스에 직접 저장 프로시저로 작성될 수 있습니다. 변경 사항을 정확히 적용할 위치를 즉시 결정할 수 있다고 확신하십니까 ?

이것은 내가 당신을 놀라게 하기 위해 꾸민 악몽이 아닙니다. 이것은 전형적인 프로젝트입니다. 더 나빠집니다. 왜 이런 일이 발생합니까? 여러 가지 이유가 있을 수 있지만 거의 항상 다음과 같은 이유가 있습니다.

• 많은 사람들이 프로젝트에 참여하고 있습니다. 그들 각자는 프로젝트를 조금씩 다르게 봅니다.
• 5년 동안 프로젝트에서 10명이 바뀌었고 새로 온 사람들은 그것을 많이 이해하지 못했습니다.
• 소프트웨어를 만드는 것은 모든 것을 끊임없이 바꾸는 끊임없는 변화입니다.
• 5년 전 우리가 건축을 결정했을 때 프로젝트의 아이디어는 다소 달랐다.

그러나 가장 중요한 것은 프로젝트의 아키텍처에 관계없이 작업하는 모든 프로그래머가 이 프로젝트의 작동 방식에 대해 동일한 이해를 고수한다는 것입니다. 가장 간단한 개념인 클라이언트-서버 아키텍처부터 시작하겠습니다.

1.2 클라이언트-서버 상호 작용의 개념

이제 클라이언트-서버 아키텍처 의 기본이 되는 개념을 이해 하고 인터넷에서 수백만 프로그램의 상호 작용이 어떻게 구성되는지 더 잘 이해할 수 있습니다.

이름에서 알 수 있듯이 이 개념에는 클라이언트 와 서버 라는 두 당사자가 포함됩니다 . 여기에서는 모든 것이 삶과 같습니다. 클라이언트는 특정 서비스의 고객이고 서버는 서비스 제공자입니다. 클라이언트와 서버는 물리적으로 프로그램 입니다 . 예를 들어 일반적인 클라이언트는 브라우저입니다 .

다음 예제는 서버로 제공될 수 있습니다.

• Tomcat과 같은 웹 서버.
• MySQL과 같은 데이터베이스 서버.
• Stripe과 같은 결제 게이트웨이.

클라이언트와 서버는 일반적으로 인터넷을 통해 통신합니다(동일한 로컬 영역 네트워크 및 일반적으로 다른 유형의 네트워크에서 작동할 수 있음). 통신은 HTTP, FTP와 같은 표준 프로토콜 또는 TCP나 UDP와 같은 하위 수준 프로토콜을 통해 이루어집니다.

프로토콜은 일반적으로 서버가 제공하는 서비스 유형에 따라 선택됩니다. 예를 들어 화상 통화인 경우 UDP가 일반적으로 사용됩니다.

Tomcat과 서블릿이 어떻게 작동하는지 기억하십니까? 서버는 HTTP 메시지를 수신하고 압축을 풀고 거기에서 필요한 모든 정보를 추출하여 처리를 위해 서블릿에 전달합니다. 그런 다음 처리 결과는 다시 HTTP 응답으로 패키징되어 클라이언트로 전송됩니다.

이것은 일반적인 클라이언트-서버 상호 작용입니다. 브라우저는 웹 클라이언트이고 Tomcat은 웹 서버입니다. Tomcat은 웹 서버라고도 합니다.

하지만 생각해 보면 중요한 것은 이름이 아니라 본질, 즉 프로그램 간의 역할 분배입니다. HTML 페이지에서 실행되는 JS 스크립트는 클라이언트 라고 할 수 있고 서블릿은 서버 라고 할 수 있습니다 . 결국, 그들은 클라이언트-서버 개념의 프레임워크 내에서 쌍으로 작동합니다 .

1.3 중요한 뉘앙스

클라이언트-서버 상호 작용은 이러한 상호 작용이 클라이언트에 의해 시작된다는 원칙에 기반한다는 점도 주목할 가치가 있습니다 . .

클라이언트가 물리적으로 어디에 있고 서버가 어디에 있는지는 중요하지 않습니다. 클라이언트 소프트웨어와 서버 소프트웨어는 일반적으로 서로 다른 시스템에 설치되지만 동일한 컴퓨터에서 실행될 수도 있습니다.

이 개념은 복잡한 시스템을 단순화하기 위한 첫 번째 단계로 개발되었습니다. 그녀는 다음과 같은 강점을 가지고 있습니다.

• 논리 단순화 : 서버는 클라이언트에 대해 아무것도 모르고 향후 데이터를 어떻게 사용할지 모릅니다.
• 약한 클라이언트가 있을 수 있습니다 . 리소스를 많이 사용하는 모든 작업을 서버로 전송할 수 있습니다.
• 클라이언트 코드 및 서버 코드의 독립적인 개발.
• 예를 들어 Tomcat 및 다양한 브라우저와 같은 다양한 클라이언트.

클라이언트와 서버 간의 상호 작용의 가장 기본적인 버전이 그림에 나와 있습니다.

여기서 두 가지 세부 사항을 기록하는 것이 중요합니다. 첫째, 그림은 하나의 서버에 여러 클라이언트가 액세스할 수 있음을 보여줍니다. 둘째, 동시에 액세스할 수 있습니다. 이것은 또한 서버의 중요한 부분입니다.

하나의 클라이언트는 일반적으로 하나의 사용자와 상호 작용하므로 승인조차 필요하지 않은 경우가 많습니다. 그러나 서버는 수천 개의 클라이언트로부터 요청을 처리하며 이를 위한 코드를 개발할 때 권한 부여와 인증을 구분할 수 있어야 합니다.

서버가 수천 개의 요청을 병렬로 처리하는 것도 중요합니다. 이는 백엔드 코드를 개발할 때 리소스에 대한 동시 액세스 작업에 대해 지속적으로 생각해야 함을 의미합니다. 또한 서버 코드는 경쟁 조건(스레드 경쟁), 교착 상태(스레드의 상호 차단) 가능성이 매우 높습니다.

중요한 개체의 수명 주기를 모니터링해야 합니다.

NET을 통해 서버에서 새 스레드를 시작할 수는 없습니다 new Thread().start(). 대신 모든 서비스 스레드 간에 공유할 ThreadPool이 있어야 합니다.

또한 별도의 스레드에서도 실행되기 때문에 비동기 작업을 시작할 수 없습니다. 이러한 작업을 생성할 때 작업을 실행 중인 스레드 풀과 이러한 풀이 오버플로될 경우 어떤 일이 발생하는지 항상 알아야 합니다.

파일 및 디렉토리에 대한 모든 작업은 try-with-resources를 통해 수행되어야 합니다. 일반 응용 프로그램에서 스트림이나 파일을 닫는 것을 잊은 경우 문제가 됩니까? 프로그램을 종료하면 자동으로 닫힙니다. 그러나 코드 어딘가에서 서버의 파일을 닫는 것을 잊고 서버가 몇 달 동안 실행 중이라면 ... 곧 닫히지 않은 수천 개의 파일이 누적되고 OS는 읽기 위해 새 파일 열기를 중지합니다 (파일 작업 OS에 의해 제어됨). 팀리더가 머리를 쓰다듬지 않는다...

1.4 클라이언트-서버 아키텍처

또 다른 중요한 점. 클라이언트-서버 아키텍처는 컴퓨터 간의 상호 작용에 대한 일반적인 원칙만 정의하며 상호 작용의 세부 사항은 다양한 프로토콜에 의해 결정됩니다.

이 개념(클라이언트-서버)은 네트워크의 시스템을 항상 무언가를 필요로 하는 클라이언트 시스템과 필요한 것을 제공하는 서버 시스템으로 나눌 필요가 있음을 알려줍니다. 이 경우 클라이언트는 항상 상호 작용을 시작하고 상호 작용이 발생하는 규칙은 프로토콜에 의해 설명됩니다.

클라이언트-서버 상호 작용 아키텍처에는 두 가지 유형이 있습니다. 첫 번째는 2계층 클라이언트-서버 아키텍처 라고 하고, 두 번째는 다중 계층 클라이언트-서버 아키텍처(때때로 3계층 아키텍처 또는 3계층 아키텍처라고도 함)입니다. 그러나 이것은 특별한 경우입니다).

클라이언트-서버 상호 작용의 2계층 아키텍처 작동 원리는 요청 처리가 이 처리 과정에서 다른 서버를 참조하지 않고 한 서버에서 발생한다는 것입니다.

2계층 클라이언트-서버 상호 작용 모델은 간단한 다이어그램으로 그릴 수 있습니다.

여기에서 첫 번째 수준은 클라이언트와 관련된 모든 것이고 두 번째 수준은 서버와 관련된 모든 것임을 알 수 있습니다.