Java 애플리케이션 분산 아키텍처의 진화 과정에 대한 간략한 논의

1. 분산 아키텍처의 개발 역사

1946년 미국 펜실베니아 대학교에서 이름이 ENICAC으로 탄생한 컴퓨터입니다. 빠르지는 않지만 컴퓨터 시대의 도래를 의미하며 향후 인터넷 발전에 있어서도 근본적인 의미를 갖습니다.

컴퓨터의 구성은 입력 장치, 출력 장치, 메모리의 다섯 부분으로 구성됩니다. 메모리에는 연산 장치와 컨트롤러가 포함되어 있습니다. 컴퓨터의 구성을 매우 생생하게 설명하는 폰 노이만 모델이 있습니다. 그러나 컴퓨터에는 계산을 수행하고 정상적으로 작동하기 위한 데이터 흐름, 명령 흐름 및 제어 흐름도 있습니다. 그림과 같이:

ENIAC 이후 전자 컴퓨터는 IBM이 지배하는 메인프레임 시대에 돌입했습니다. 1946년 최초의 IBM 메인프레임 SYSTEM/360이 탄생하여 1950년대와 1960년대에 IBM이 되었습니다. 메인프레임 컴퓨터 산업 전체를 지배했습니다. 메인프레임 시대에는 컴퓨터 아키텍처가 두 가지 방향으로 발전했습니다. CISC(컴퓨터 언어 명령 집합이 마이크로프로세서에 의해 실행됨) CPU 기반의 저렴한 개인용 PC 및 RISC(축소 명령 집합 컴퓨터) 가격이 높은 고급형 소형 UNIX 서버 .

컴퓨팅 성능과 처리 능력, 높은 안정성과 보안을 갖춘 메인프레임의 등장은 오랫동안 컴퓨팅 분야의 발전을 이끌어 왔습니다. 그러나 중앙 집중식 컴퓨터 시스템은 몇 가지 문제를 가져왔고 다음과 같은 사용자 요구를 점점 더 충족시킬 수 없습니다.

1. 대규모 호스트는 매우 비싸고 일반 소규모 기업에서는 이를 감당할 수 없습니다.

2. 메인프레임은 더 복잡하고 인재 교육 비용이 상대적으로 높습니다.

3. 메인프레임 장애와 같은 단일 지점 문제로 인해 전체 시스템이 다운되고 작동할 수 없게 되어 기업에 막대한 손실이 발생합니다.

4. 기술의 발전으로 개인용 PC의 성능은 점점 높아지고, 가격은 점점 낮아지고 있습니다.

알리바바는 2009년에 “IOE”를 없애기 위한 운동을 시작했습니다

IOE는 IBM의 미니컴퓨터, Oracle의 데이터베이스 및 EMC의 고급 스토리지 장치를 의미합니다. 2009년 IOE에서 벗어나는 움직임은 Alipay의 마지막 IBM 미니컴퓨터가 2003년 오프라인이 될 때까지 계속되었습니다.

IOE로 가는 이유

알리바바는 과거 데이터베이스로 오라클을 사용했으며, 고성능 데이터 처리 및 저장 서비스를 제공하기 위해 미니컴퓨터와 고급 저장 장치를 사용했습니다. 회사의 비즈니스 규모가 증가하고 사용자 수가 계속 증가함에 따라 기존의 중앙 집중식 아키텍처 Oracle 데이터베이스는 확장 시 병목 현상에 직면하게 됩니다. 기존 Oracle에 비해 DB2는 주로 중앙 집중식입니다. 중앙 집중식 확장은 주로 수평 확장이 아닌 상향 확장을 채택합니다. 이는 시스템 병목 현상이 조만간 발생합니다.

1. 분산 아키텍처의 공통 개념

Cluster

그 작은 식당은 야채를 자르고, 야채를 씻고, 재료를 준비하고 요리하는 요리사로 밝혀졌습니다. 나중에 손님이 많아지자 주방의 한 셰프가 너무 바빠서 다른 셰프를 고용해 두 셰프가 같은 요리를 할 수 있게 됐다.

Distributed

셰프가 요리에 집중하고 요리를 완벽하게 만들기 위해 야채를 자르고, 야채를 준비하고, 재료를 준비하는 일을 담당하는 셰프를 고용합니다. 셰프와 셰프가 분산되어 있어서 반찬 셰프 한 명이라도 너무 바쁘고, 반찬 셰프를 고용하면 두 셰프의 관계가 클러스터가 된다. 따라서 분산 아키텍처에도 클러스터가 있을 수 있지만 클러스터가 분산을 의미하는 것은 아닙니다.

Node

노드는 분산 프로토콜에 따라 일련의 로직을 독립적으로 완성할 수 있는 개별 프로그램을 말합니다. 특정 프로젝트에서 노드는 운영 체제의 프로세스를 나타냅니다.

복제 메커니즘

복제란 분산 시스템에서 데이터 또는 서비스에 대한 중복성을 제공하는 것을 의미합니다.

데이터 복사는 동일한 데이터를 다른 노드에 유지하는 것을 의미하며, 특정 노드의 데이터가 손실되면 복사본에서 데이터를 읽을 수 있습니다. 데이터 복사본은 분산 시스템에서 데이터 손실을 초래하는 유일한 수단입니다.

서비스 사본은 여러 노드가 동일한 서비스를 제공하고 마스터-슬레이브 관계를 통해 서비스의 고가용성을 달성하는 것을 나타냅니다.

Middleware

Middleware는 운영체제에서 제공하는 서비스에 추가되며, 애플리케이션에 속하지 않습니다. 애플리케이션 및 시스템 개발자를 위해 계층 간 통신, 입력 및 출력을 편리하게 처리하여 사용자가 애플리케이션의 일부에 신경 쓸 수 있도록 하는 소프트웨어 유형입니다.

아키텍처의 개발 과정

성숙한 대규모 웹사이트 시스템 아키텍처는 처음부터 완벽하게 설계되지도 않고, 처음부터 고성능, 고가용성을 갖추지도 않습니다. 사용자 수가 증가하고 비즈니스 기능이 확장됨에 따라 보안 및 기타 기능은 점차 개선되고 진화됩니다. 이러한 개발 과정에서 개발 모델, 기술 아키텍처 등은 큰 변화를 겪게 됩니다.

시스템에 다음 기능이 있는 경우:

사용자 모듈: 사용자 등록 및 관리#🎜🎜 ## 🎜🎜#

제품 모듈: 제품 표시 및 관리

거래 모듈: 거래 및 결제 정산 생성

1단계: 단일 애플리케이션 아키텍처

시스템 시작 시 애플리케이션과 데이터베이스가 모두 하나의 서버에 배치됩니다.

2단계: 애플리케이션 서버와 데이터베이스 서버의 분리

웹사이트 사용자 수가 증가하고 트래픽이 증가함에 따라 애플리케이션 서버와 데이터베이스 서버를 별도로 배포하는 시스템을 사용하면 시스템 성능을 높이고 성능을 향상시킬 수 있습니다. 액세스 효율성을 높여 단일 시스템의 로드 용량과 재해 복구 기능을 향상시킵니다.

3단계: 애플리케이션 서버 클러스터 - 애플리케이션 서버 로드 경보

방문 횟수와 트래픽이 증가함에 따라 데이터베이스에 병목 현상이 발생하지 않는다고 가정하면 애플리케이션 서버 클러스터를 사용하여 요청을 오프로드하여 프로그램 성능을 향상시킵니다. 기존 문제: 사용자의 요청을 누가 전달할 것인지, 세션을 어떻게 관리할 것인지.

4단계: 데이터베이스 압력 증가 - 데이터베이스 읽기 및 쓰기 분리

읽기와 쓰기가 분리되면 향후 요청 및 쿼리 요청은 슬레이브 라이브러리에서 데이터를 읽을 수 있고 작성된 데이터를 메인 라이브러리로 보낼 수 있습니다. 하지만 이는 몇 가지 문제를 가져올 것입니다:

1. 마스터와 슬레이브 데이터베이스 간의 데이터 동기화: 마스터-슬레이브 복제를 달성하기 위해 mysql과 함께 제공되는 마스터-슬레이브 방법을 사용할 수 있습니다.

2 해당 데이터 소스 선택: 다음과 같은 타사 데이터베이스 미들웨어: mycat

5단계: 검색 엔진을 사용하여 데이터베이스를 읽는 부담을 완화하세요

데이터베이스를 사용하여 데이터베이스를 읽는 경우 퍼지 쿼리의 성능이 좋지 않은 경우가 많습니다. 특히 대규모 인터넷 회사의 경우 검색하려는 모듈이 검색 엔진을 사용하는 것이 가능하지만 쿼리 속도를 크게 향상시킬 수 있지만 인덱스 구성과 같은 몇 가지 문제도 발생합니다.

6단계: 데이터베이스에 대한 부담을 완화하기 위한 캐싱 메커니즘 도입

일부 핫 데이터의 경우 redis 및 memcache를 애플리케이션 계층 캐시로 사용할 수 있으며 일부 시나리오에서는 mongodb를 사용하여 대체할 수 있습니다. 저장할 관계형 데이터베이스입니다.

7단계: 데이터베이스의 수평/수직 분할

수직 분할: 데이터베이스에 있는 서로 다른 비즈니스 데이터를 서로 다른 데이터베이스로 분할합니다.

수평 분할: 동일한 테이블의 데이터를 두 개 이상의 데이터베이스로 분할하는 이유는 데이터 양이 많은 일부 기업이 단일 데이터베이스의 병목 현상에 도달했기 때문입니다. 여러 데이터베이스에 테이블을 추가합니다.

8단계: 애플리케이션 분할

비즈니스가 발전함에 따라 비즈니스가 점점 더 많아지고 애플리케이션에 대한 부담도 커지고 있습니다. 프로젝트 규모도 점점 커지고 있다. 이때 도메인 모델에 따라 애플리케이션을 분할하고 사용자, 제품 및 트랜잭션을 하위 시스템으로 분할하는 것을 고려할 수 있습니다.

이러한 분할 후에는 사용자 작업 및 제품 거래 쿼리와 같은 일부 동일한 코드가 있을 수 있으며 이로 인해 각 시스템에서 사용자 쿼리 및 액세스 관련 작업이 발생하게 됩니다. 이러한 동일한 코드와 모듈은 추상화되어야 합니다. 이는 유지보수 및 관리를 용이하게 합니다.

서비스가 분할된 후 서비스 간 통신은 RPC 기술을 통해 이루어질 수 있습니다. 대표적인 기술로는 webservice, hession, http, RMI 등이 있습니다.

위 내용은 Java 애플리케이션 분산 아키텍처의 진화 과정에 대한 간략한 논의의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!