2부. 소프트웨어 아키텍처에 대해 조금 이야기해 보겠습니다.

이 자료는 " 엔터프라이즈 개발 소개 " 시리즈 의 일부입니다 . 네트워크에 대한 첫 번째 부분은 여기에 있습니다 . 소프트웨어 아키텍처는 애플리케이션이 생성되고 전체 프로그램의 모듈과 구성 요소가 상호 작용하는 기반 구조입니다. 프로그래머들은 오랫동안 좋은 아키텍처를 만들기 위해 노력해왔기 때문에 이제 우리가 많은 아키텍처 패턴을 알고 있다는 것은 놀라운 일이 아닙니다. 이를 이해해야 합니다. 웹 애플리케이션을 작성할 때 일반 애플리케이션보다 구성 요소와 모듈이 더 많기 때문에 아키텍처 문제가 심각해집니다. 아키텍처 패턴은 일부 소프트웨어 설계 문제를 해결하기 위해 이미 고안된 방법입니다. 아마도 Factory Method, Abstract Factory, Builder, Prototype, Singleton 등과 같은 디자인 패턴을 이미 접했을 것입니다. 이는 단순히 코드를 작성하고, 클래스를 만들고, 상호 작용 방법을 계획하는 데 사용됩니다. 아키텍처 패턴은 애플리케이션 사용자와 프로젝트의 서버, 데이터 및 기타 구성 요소의 상호 작용을 계획할 때 더 높은 수준의 추상화에서 사용됩니다. 일부 템플릿과 사용 방법을 간략하게 살펴보겠습니다.

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

이름에서 이 주제와 관련된 모든 것이 단순하고 명확하다는 인상을 받습니다. 하지만 조건부 Spring을 공부하기 시작할 때 우리가 말하는 내용을 정확히 이해할 수 있도록 몇 가지 사항을 명확히 하겠습니다. 당신이 채팅을 작성했고 당신과 당신의 친구가 그것을 사용하기 시작했다고 가정해 보겠습니다. 여기에서는 간단한 옵션이 가능합니다. 알고 있는 IP 주소를 사용하여 인터넷을 통해 서로에게 직접 메시지를 보냅니다. 처음에는 다른 친구가 다음과 같은 질문을 하기 전까지는 모든 것이 잘 작동하는 것처럼 보일 수 있습니다. 채팅에 저를 추가하지 않으셨나요?” 그리고 채팅에 공통 친구를 추가하기로 결정하면 구조적 문제에 직면하게 됩니다. 각 채팅 사용자는 사용자 수에 대한 정보를 업데이트하고 새 사용자의 IP 주소를 추가해야 합니다. 그리고 메시지를 보낼 때는 모든 참가자에게 전달되어야 합니다. 이는 앞으로 발생할 가장 명백한 문제입니다. 코드 자체에는 훨씬 더 많은 문제가 숨겨져 있습니다. 이를 방지하려면 사용자에 대한 모든 정보를 저장하고 사용자의 주소를 아는 서버를 사용해야 합니다 . 메시지는 서버로만 전송되어야 합니다. 그리고 그는 차례로 모든 수신자에게 메시지를 보낼 것입니다. 채팅에 서버 측을 추가하기로 결정하면 클라이언트-서버 아키텍처 구축이 시작됩니다.

클라이언트-서버 아키텍처의 구성 요소

그녀가 무엇인지 알아 봅시다. 클라이언트-서버 아키텍처는 웹 애플리케이션 생성의 기초인 디자인 패턴입니다. 이 아키텍처는 세 가지 구성 요소로 구성됩니다.

1. 클라이언트 - 이름에서 일부 정보를 얻기 위해 서버에 접속하는 서비스(웹 애플리케이션) 사용자라는 것이 분명해집니다.

2. 서버는 웹 애플리케이션 또는 해당 서버 부분이 있는 장소입니다. 그는 이용자에 대해 필요한 정보를 소유하거나 요청할 수 있습니다. 또한 클라이언트가 접속하면 서버는 요청한 정보를 반환합니다.

3. 네트워크는 간단합니다. 클라이언트와 서버 간의 정보 교환을 보장합니다.

서버는 다양한 사용자의 엄청난 수의 요청을 처리할 수 있습니다. 즉, 다수의 클라이언트가 있을 수 있으며, 서로 정보를 교환해야 할 경우에는 서버를 통해 이루어져야 합니다. 따라서 서버는 트래픽 제어라는 추가 기능을 하나 더 수신합니다. 우리가 만든 다중 사용자 채팅에 관해 이야기한다면 전체 프로그램 코드는 두 개의 모듈로 구성됩니다.

• 클라이언트 - 인증, 메시지 보내기/받기를 위한 그래픽 인터페이스가 포함되어 있습니다.

• 서버측 - 서버에서 호스팅되고 사용자로부터 메시지를 받아 처리한 다음 수신자에게 보내는 웹 애플리케이션입니다.

우리는 인터넷에서 유용한(또는 그다지 유용하지 않은) 정보를 보고 싶을 때 브라우저를 열고 검색창에 쿼리를 입력하며 이에 대한 응답으로 검색 엔진으로부터 정보를 받습니다. 이 체인에서 브라우저는 클라이언트입니다. 우리가 찾고 있는 것에 대한 정보가 포함된 요청을 서버로 보냅니다. 서버는 요청을 처리하고 가장 관련성이 높은 결과를 찾아 브라우저(클라이언트)가 이해할 수 있는 형식으로 패키징하여 다시 보냅니다. 검색 엔진과 같은 복잡한 서비스에는 많은 서버가 있을 수 있습니다. 예를 들어 인증 서버, 정보 검색 서버, 응답 생성 서버 등이 있습니다. 그러나 클라이언트는 이것에 대해 아무것도 모릅니다. 그에게 서버는 통합된 것입니다. 클라이언트는 진입점, 즉 요청을 보내야 하는 서버의 주소만 알고 있습니다. 모든 국가의 평균 기온을 실시간으로 모니터링하기 위해 이전 부분 에서 살펴본 애플리케이션을 기억해 봅시다 . 아키텍처는 다음과 같습니다. 우리 애플리케이션은 서버에 있습니다. 5초마다 지역 수문 기상 센터의 서버에 요청을 보내고 해당 서버로부터 특정 국가의 온도에 대한 정보를 받아 이 정보를 저장한다고 가정해 보겠습니다. 고객이 "세계의 현재 기온 보기"를 요청하여 당사에 연락하면 당사는 저장된 최신 정보를 국가별로 정렬하여 반환합니다. 따라서 우리 애플리케이션은 서버(사용자 요청을 처리할 때)이자 클라이언트(다른 서버로부터 정보를 받을 때)입니다. 간단한 클라이언트-서버 아키텍처는 매우 드물게 사용되며 매우 간단한 애플리케이션에만 사용됩니다. 매우 크고 복잡한 프로젝트의 경우 다양한 유형의 아키텍처가 사용되며, 이는 앞으로 더 익숙해질 것입니다. 지금은 클라이언트-서버 모델과 매우 유사한 모델을 살펴보겠습니다.

3계층 아키텍처

이는 세 번째 플레이어인 데이터 웨어하우스를 도입하는 아키텍처 패턴입니다 . 이 패턴을 사용할 때 세 가지 수준을 일반적으로 레이어라고 합니다.

1. 클라이언트 계층은 사용자 인터페이스입니다. 이는 HTML 페이지가 전송되는 웹 브라우저이거나 JavaFX를 사용하여 작성된 GUI 애플리케이션일 수 있습니다. 가장 중요한 것은 도움을 받아 사용자가 서버에 요청을 보내고 응답을 처리할 수 있다는 것입니다.

2. 논리 계층은 요청/응답이 처리되는 서버입니다. 흔히 서버 계층이라고도 합니다. 수학적 계산, 데이터 작업, 다른 서비스 호출 또는 데이터 저장 등 모든 논리적 작업도 여기에서 수행됩니다.

3. 데이터 계층은 데이터베이스 서버입니다. 우리 서버가 여기에 액세스합니다. 이 계층은 애플리케이션이 작동하는 동안 사용하는 모든 필수 정보를 저장합니다.

따라서 당사 서버는 사용자가 데이터에 직접 액세스하는 것을 허용하지 않고 데이터 액세스에 대한 모든 의무를 집니다.

3계층 아키텍처의 이점

이러한 아키텍처를 사용하면 다음과 같은 많은 이점을 얻을 수 있습니다.

1. SQL 주입에 대한 보호 구축 기능은 SQL 코드가 전송되는 서버에 대한 공격이며, 이 코드가 실행되면 공격자가 우리 데이터베이스에 영향을 줄 수 있습니다.

2. 사용자 액세스를 규제하려는 데이터의 구분.

3. 데이터를 클라이언트에 보내기 전에 수정하는 기능.

4. 확장성 - 동일한 데이터베이스를 사용하는 여러 서버로 애플리케이션을 확장할 수 있는 능력입니다.

5. 사용자 연결 품질에 대한 요구 사항이 적습니다. 서버에서 응답을 생성할 때 우리는 종종 데이터베이스에서 다양한 정보를 가져와 형식을 지정하고 사용자에게 필요한 것만 남겨 둡니다. 이렇게 하면 클라이언트에 대한 응답으로 보내는 정보의 양이 줄어듭니다.

아키텍처 패턴을 얼마나 자주 사용해야 합니까?

예를 들어 팩토리 메소드(Factory Method) 디자인 패턴 에 익숙하다면 언제 사용해야 할지 궁금할 것입니다. 때로는 무엇을 해야할지 결정하기가 어렵습니다. 즉, new 연산자를 사용하거나 팩토리 메소드를 사용하여 객체를 생성합니다. 그러나 시간이 지나면 이해가 됩니다. 아키텍처 패턴의 경우 상황이 약간 다릅니다. 엔터프라이즈 프레임워크는 프로그래머가 일반적으로 허용되는 패턴을 기반으로 프로젝트를 생성하는 데 사용할 수 있도록 설계되었습니다. 따라서 Spring Framework를 배우기 전에 클라이언트-서버 아키텍처, 3티어 아키텍처, MVC 아키텍처가 무엇인지 반드시 이해해야 합니다. 걱정하지 마십시오. MVC 아키텍처에 대해서는 나중에 이야기하겠습니다. 1부. Spring과 JavaEE를 배우기 전에 알아야 할 사항 3부. HTTP/HTTPS 프로토콜 4부. Maven 기본 5부. 서블릿. 간단한 웹 애플리케이션 작성 6부. 서블릿 컨테이너 7부. MVC(모델-뷰-컨트롤러) 패턴 소개 8부. 작은 스프링 부트 애플리케이션 작성