Java 아키텍처가 다양한 제품에 적용되는 방식

시스템을 설정할 때 일반적으로 다른 시스템과 어떻게 상호 작용할지 고려해야 하기 때문에 먼저 다양한 시스템이 서로 어떻게 상호 작용하고 이를 구현하는 데 어떤 기술이 사용되는지 알아야 합니다.

1. 서로 다른 시스템과 서로 다른 언어 간의 상호 작용 ​​

요즘에는 서로 다른 시스템과 서로 다른 언어 간의 일반적인 상호 작용에는 WebService 및 Http 요청이 사용됩니다. WebService, 즉 "웹 서비스"를 줄여서 WS라고 합니다. 문자 그대로 이해하면 실제로는 "웹 기반 서비스"입니다. 그러나 서비스는 양쪽 모두를 위한 것입니다. 서비스 수요자가 있으면 서비스 제공자가 있게 마련입니다. 서비스 제공자는 외부 세계에 서비스를 게시하고, 서비스 요구자는 서비스 제공자가 게시한 서비스를 호출합니다. 좀 더 전문적으로 말하면 WS는 실제로 이기종 시스템 통신을 구현하기 위해 HTTP 프로토콜을 기반으로 구축된 도구입니다. 좋아요! 직설적으로 말하면 WS는 HTTP 프로토콜을 기반으로 합니다. 즉, 데이터는 HTTP를 통해 전송됩니다. 처음에는 CXF를 사용하여 WS를 구현하기 위한 SOAP 서비스를 개발했고, 나중에는 REST 서비스를 사용하여 WS를 구현했습니다(현재는 이 방법이 더 자주 사용되며 제가 가장 많이 사용하는 방법이기도 합니다). REST 서비스는 CXF를 기반으로 개발될 수도 있지만 일반적으로 REST 서비스를 구현하기 위해 springMVC나 다른 MVC 프레임워크를 직접 사용합니다.

그러나 많은 사람들이 생각하는 웹 서비스는 일반적으로 10여년 전 IBM이 주도한 다양한 XML 기반 대화형 기술을 지칭합니다. 요즘에는 일부 회사를 제외하고 이를 사용하는 사람이 거의 없습니다. 넓은 의미에서 Webservice는 웹 서비스이며 모든 것이 서비스입니다.

2. 동일한 언어를 사용하는 서로 다른 시스템 간의 상호 작용

동일한 언어를 사용하는 서로 다른 시스템 간의 일반적인 상호 작용은 물론 외부 서비스를 제공하지 않고 RPC(Remote Procedure Call) 또는 RMI(Remote Method Invocation)를 사용하여 구현됩니다. 위에서 언급한 방법은 동일한 언어 간의 상호 작용에도 사용할 수 있지만 저는 주로 RPC를 사용합니다.

다른 제품의 아키텍처

3. 단일 제품의 아키텍처 진화

일반적으로 제품이 하나만 있을 때 아키텍처의 진화 과정은 외부 세계에 webService를 제공해야 하는 경우 일반적으로 REST를 사용합니다. 달성하기 위한 서비스입니다.

다음 내용은 Zhihu

1) 분산 아키텍처의 진화 시스템 아키텍처 진화 - 초기 단계 아키텍처

초기 단계의 소규모 시스템 애플리케이션, 데이터베이스, 파일 등 모든 리소스 일반적으로 LAMP

로 알려진 하나의 서버에 모두 포함 특징: 애플리케이션, 데이터베이스, 파일 등과 같은 모든 리소스가 하나의 서버에 있습니다.

설명: 일반적으로 서버 운영 체제는 Linux를 사용하고 애플리케이션은 PHP를 사용하여 개발한 다음 Apache에 배포하고 데이터베이스는 Mysql을 사용하며 다양한 무료 오픈 소스 소프트웨어와 저렴한 서버를 사용하여 시스템 개발을 시작할 수 있습니다.

2) 시스템 아키텍처의 진화 - 애플리케이션 서비스와 데이터 서비스의 분리

좋은 시절은 오래가지 못했다. 시스템 방문 횟수가 다시 증가할수록 웹서버 시스템에 부담이 가중되는 것으로 나타났다. 피크 기간에는 상대적으로 높은 수준으로 올라갈 것입니다. 이제 웹 서버 추가를 고려해야 할 때입니다

특징: 애플리케이션, 데이터베이스 및 파일이 독립적인 리소스에 배포됩니다.

설명: 데이터 양이 늘어나고 단일 서버의 성능 및 저장 공간이 부족하며 애플리케이션과 데이터를 분리해야 하는 경우 동시 처리 기능 및 데이터 저장 공간이 크게 향상되었습니다.

3) 시스템 아키텍처의 진화 - 캐시를 활용한 성능 향상

특징: 데이터베이스에서 더 집중적으로 접근하는 데이터 중 일부를 캐시 서버에 저장하여 데이터베이스 접근 횟수를 줄입니다. 데이터베이스에 대한 액세스 압력을 줄입니다.

설명: 시스템 액세스 특성은 80/20 규칙을 따릅니다. 즉, 비즈니스 액세스의 80%가 20%의 데이터에 집중됩니다. 캐시는 로컬 캐시와 원격 분산 캐시로 구분됩니다. 로컬 캐시는 액세스 속도가 빠르지만 동시에 캐시되는 데이터의 양이 제한되어 있습니다.

4) 시스템 아키텍처의 진화 - 애플리케이션 서버 클러스터를 활용

서브 데이터베이스 및 테이블 작업을 마친 후 데이터베이스에 대한 부담이 상대적으로 낮은 수준으로 떨어지면서 지켜보기 시작했습니다. 매일 다시 접속이 되던 어느 날 갑자기 시스템 접속이 다시 느려지기 시작했는데 이때 먼저 데이터베이스를 확인해 보니 압력이 정상인 것을 확인하고 나서 웹서버를 확인해 보니 아파치가 차단되어 있는 것을 발견했습니다. 요청이 많고 애플리케이션 서버도 상대적으로 빠른 편입니다. 요청 수가 너무 많아 줄을 서서 기다려야 하고 응답 속도도 느린 것 같습니다. 특징: 여러 서버가 제공됩니다. 로드 밸런싱을 통해 동시에 외부로 서비스를 제공함으로써 단일 서버의 처리 용량과 저장 공간 상한 문제를 해결합니다.

설명: 클러스터를 사용하는 것은 시스템이 높은 동시성 및 대규모 데이터 문제를 해결하는 일반적인 방법입니다. 클러스터에 리소스를 추가함으로써 시스템의 동시 처리 능력이 향상되므로 서버의 부하 압력이 더 이상 전체 시스템의 병목 현상이 되지 않습니다.

5) 시스템 아키텍처의 진화 - 데이터베이스 읽기 및 쓰기 분리

한동안 시스템 방문의 급속한 증가를 즐기다가 시스템이 다시 느려지기 시작했다는 것을 발견했습니다. 이것은 무엇입니까? 데이터베이스 쓰기 및 업데이트 작업을 검색한 후 데이터베이스 연결 리소스에 대한 경쟁이 매우 치열하여 시스템 속도가 느려집니다

특징: 여러 서버가 로드 밸런싱을 통해 동시에 외부에 서비스를 제공하여 문제를 해결합니다. 단일 서버의 처리 능력과 저장 공간의 문제.

설명: 클러스터를 사용하는 것은 시스템이 높은 동시성 및 대규모 데이터 문제를 해결하는 일반적인 방법입니다. 클러스터에 리소스를 추가하면 서버의 로드 압력으로 인해 더 이상 전체 시스템의 병목 현상이 발생하지 않습니다.

6) 시스템 아키텍처 진화 - 역방향 프록시 및 CDN 가속

기능: CDN 및 역방향 프록시를 사용하여 시스템 액세스 속도를 높입니다.

설명: 복잡한 네트워크 환경과 다양한 지역의 사용자 액세스에 대처하기 위해 CDN 및 역방향 프록시를 사용하여 백엔드 서버의 부하 부담을 줄이면서 사용자 액세스 속도를 높입니다. CDN과 역방향 프록시의 기본 원칙은 캐싱입니다.

7) 시스템 아키텍처의 진화 - 분산 파일 시스템과 분산 데이터베이스

시스템이 계속 실행되면서 데이터의 양이 크게 증가하기 시작합니다. 이때 쿼리 이후의 쿼리는 다음과 같습니다. 데이터베이스 분할이 아직은 좀 느린 편이라 서브 데이터베이스 아이디어에 따라 테이블 샤딩 작업을 시작했습니다

특징: 데이터베이스는 분산 데이터베이스를 사용하고, 파일 시스템은 분산 파일을 사용합니다. 체계.

설명: 강력한 단일 서버는 지속적으로 증가하는 대규모 시스템의 비즈니스 요구 사항을 충족할 수 없습니다. 그것을 지원하는 데 사용됩니다. 분산 데이터베이스는 시스템 데이터베이스를 분할하는 유일한 방법입니다. 단일 테이블 데이터의 규모가 매우 큰 경우에만 사용됩니다. 보다 일반적으로 사용되는 데이터베이스 분할 방법은 서로 다른 비즈니스 데이터베이스를 서로 다른 물리적 서버에 배포하는 것입니다. . 우수한.

8) 시스템 아키텍처 진화 - NoSQL 및 검색 엔진 사용

특징: 시스템에는 NoSQL 데이터베이스 및 검색 엔진이 도입되었습니다.

설명: 비즈니스가 점점 더 복잡해짐에 따라 데이터 저장 및 검색에 대한 요구 사항도 점점 더 복잡해지고 있습니다. 시스템은 NoSQL과 같은 일부 비관계형 데이터베이스 및 검색 엔진과 같은 하위 데이터베이스 쿼리 기술을 사용해야 합니다. 애플리케이션 서버는 통합된 데이터 액세스 모듈을 통해 다양한 데이터에 액세스하므로 애플리케이션이 많은 데이터 소스를 관리하는 수고를 줄여줍니다.

9) 시스템 아키텍처의 진화 - 업무 분할

특징: 업무에 따라 시스템을 분할, 변형하고, 업무 차별화에 따라 애플리케이션 서버를 별도로 구축합니다.

설명: 점점 더 복잡해지는 비즈니스 시나리오에 대처하기 위해 일반적으로 전체 시스템 비즈니스를 여러 제품 라인으로 나누는 데 분할 정복 방법이 사용됩니다. 하이퍼링크를 통해 애플리케이션 간에 관계가 설정되고 데이터는 메시지 대기열을 통해 배포될 수도 있습니다. 물론, 동일한 데이터 저장 시스템에 접근하여 연결된 완전한 시스템이 더 많이 형성됩니다. 수직 분할: 대규모 응용 프로그램을 여러 개의 작은 응용 프로그램으로 분할합니다. 새 비즈니스가 상대적으로 독립적인 경우에는 이를 독립적인 웹 응용 프로그램 시스템으로 직접 설계하고 배포합니다. 관련 사업을 더 작은 규모로 분할할 수 있습니다. 수평 분할: 재사용된 비즈니스를 분할하여 분산 서비스로 독립적으로 배포합니다. 새로운 비즈니스에서는 이러한 분산 서비스만 호출하면 됩니다. 수평 분할에는 재사용 가능한 비즈니스 식별, 서비스 인터페이스 설계 및 서비스 종속성 표준화가 필요합니다.

10) 시스템 아키텍처 진화 - 분산 서비스

Q: 분산 서비스 애플리케이션은 어떤 문제에 직면하게 될까요?

(1) 서비스가 많아지면 서비스 URL 구성 관리가 매우 어려워지고 F5 하드웨어 로드 밸런서에 대한 단일 지점의 부담도 커집니다.

(2) 더 발전할수록 서비스 간의 종속성이 너무 복잡해져서 어떤 애플리케이션을 시작하기 전에 어떤 애플리케이션을 시작해야 하는지조차 불분명해지고, 아키텍트는 애플리케이션의 아키텍처 관계를 완전히 설명할 수 없습니다.

(3) 그러면 서비스의 호출량이 점점 더 커지고 서비스의 용량 문제가 노출됩니다. 이 서비스는 몇 대의 시스템을 지원해야 합니까? 언제 기계를 추가해야 합니까?

(4) 서비스가 많아지면서 통신 비용도 오르기 시작했습니다. 특정 서비스 조정이 실패하면 누구에게 연락해야 하나요? 서비스 매개변수에 대한 규칙은 무엇입니까?

(5) 서비스에는 여러 비즈니스 소비자가 있는데, 서비스 품질을 보장하는 방법은 무엇입니까?

(6) 지속적인 서비스 업그레이드로 인해 항상 예상치 못한 일이 발생합니다. 예를 들어 캐시가 잘못 작성되어 메모리 오버플로가 발생하는 것은 불가피합니다. 사람들은 그것을 어떻게 통제할 것인가? 실패의 영향은 무엇인가? 서비스가 기능적으로 다운그레이드될 수 있나요? 아니면 자원 저하?

이것이 대규모 웹 사이트 기술 아키텍처의 핵심 원리와 사례 분석의 시작인 것 같은데, 저자가 잘 요약해 놓았으므로 다시 인쇄해 보겠습니다.

4. 제품 라인 구조

또 다른 옵션은 위에서 언급한 사업 분할입니다. 이제 제품 라인을 구축해야 합니다. 앞에는 데이터 계층, 일반 비즈니스 로직 계층, 다양한 애플리케이션 및 인터페이스 계층만 있으면 됩니다. 과거에는 일반적으로 EJB를 사용하여 분산 애플리케이션을 구축했지만 이제는 dobbo, thrift, avro 및 hessian과 같은 RPC 프레임워크를 사용하여 분산 애플리케이션을 구축하여 다양한 애플리케이션과 데이터 소스 간의 상호 작용을 달성할 수 있습니다. 이러한 구조 모델에서는 다른 회사에 서비스를 제공해야 하는 경우 전용 애플리케이션을 작성하여 외부 시스템에 휴식 서비스를 제공할 수 있습니다. 일반적으로 대부분의 인터넷 서비스는 수십 개, 심지어 수백 개의 내부 서비스에 액세스해야 하며 이들 간의 통신 방법은 일반적으로 RPC입니다. 원격 메서드에 액세스하는 것과 마찬가지로 매개 변수를 입력하고 결과가 반환될 때까지 기다립니다. 이는 복잡한 시스템을 구축하는 가장 이해하기 쉬운 방법입니다.

아래 그림과 같이 모델, 파일 시스템, 캐시가 표시되지 않아 누구나 쉽게 이해할 수 있습니다.

위 내용은 Java 아키텍처가 다양한 제품에 적용되는 방식의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!