원격 위치의 다중 활동 시나리오에서 Sermant의 실습

이 기사는 Huawei Cloud 커뮤니티 " 원격 다중 활성 시나리오에서 하인의 실습 "(저자: Huawei Cloud Open Source) 에서 공유되었습니다 .

Sermant 커뮤니티는 원격 다중 활성 시나리오에서 흐름 차단 및 데이터 일관성 보호 문제를 해결하기 위해 각각 버전 1.3.0 및 1.4.0에서 메시지 대기열 소비 금지 플러그인데이터베이스 쓰기 금지 플러그인을 연속적으로 출시했습니다. 이 기사에서는 원격 다중 활동 시나리오에서 Sermant의 사례를 분석합니다.

1. 다른 곳에서 더 많이 살아보세요

1.1 다른 장소에 산다는 것은 무엇입니까?

소프트웨어 시스템의 경우 시스템에 장애가 발생하더라도 외부 세계에 정상적으로 서비스를 제공할 수 있기를 바랍니다. 소프트웨어 시스템의 이러한 기능을 고가용성이라고 하며, 원격 다중 활성 아키텍처를 사용하여 고가용성 문제를 해결합니다. .

초기 시스템 아키텍처는 일반적으로 단일 시스템 아키텍처입니다. 데이터베이스에 장애가 발생하면 비즈니스가 오랫동안 중단될 수 있습니다. 이러한 문제를 해결하기 위해 데이터베이스는 마스터 데이터베이스와 슬레이브 데이터베이스로 구성되어 있으며, 마스터 데이터베이스는 읽기 및 쓰기 작업을 담당하고, 슬레이브 데이터베이스는 읽기 작업만 제공합니다. 데이터의 일관성과 무결성을 유지하기 위해 실시간으로 슬레이브 데이터베이스와 동기화됩니다. 메인 라이브러리에 문제가 발생하면 슬레이브 라이브러리가 메인 라이브러리로 전환되어 계속 작동합니다. 그러나 이러한 서비스는 동일한 컴퓨터실, 심지어 동일한 캐비닛에 배포되어도 컴퓨터실에 장애가 발생하면 시스템은 여전히 ​​정상적인 외부 서비스를 제공할 수 없습니다.

이때 같은 도시에 있는 Active-Active는 좋은 솔루션이 되었습니다. 두 개의 컴퓨터실은 동일한 소프트웨어 환경을 배포하고 서비스를 제공합니다. 컴퓨터실 중 하나에 오류가 발생하면 트래픽을 다른 컴퓨터실로 전환하여 실행을 계속함으로써 시스템의 고가용성을 보장할 수 있습니다. 그림 1에서 볼 수 있듯이 전산실 1의 데이터베이스는 주 데이터베이스입니다. 두 전산실의 모든 쓰기 작업은 전산실 1의 주 데이터베이스에서 수행되며 읽기 작업은 이 전산실의 데이터베이스를 읽을 수 있습니다. 두 컴퓨터실 사이의 물리적 거리는 상대적으로 가깝습니다. 동시에 두 컴퓨터실은 네트워크 연결을 위해 전용 회선을 사용할 수 있으므로 서로 다른 컴퓨터실의 서비스 호출에 대한 네트워크 대기 시간이 짧습니다. 컴퓨터실 2에서 컴퓨터실 1의 데이터베이스까지의 데이터가 허용 가능한 범위 내에 있습니다.

그림 1: 같은 도시의 이중 활성 아키텍처 다이어그램

동일한 도시의 액티브-액티브 아키텍처는 소프트웨어 시스템의 고가용성 문제를 해결합니다. 그러나 지진, 홍수 등의 자연재해가 도시에서 발생하는 경우 동일한 도시에 배치된 모든 컴퓨터실은 여전히 ​​​​상태가 유지됩니다. 훼손되어 서비스 제공을 중단합니다. 그리고 이러한 재난은 매우 파괴적이기 때문에 시스템 수리 주기가 상대적으로 길어지고 이는 회사의 정상적인 비즈니스 운영에 심각한 영향을 미칠 것입니다. 이 경우 이러한 전산실은 서로 다른 지역에 배치되어야 함과 동시에 해당 지역의 지리적 거리가 자연재해의 위험에 견딜 수 있을 만큼 멀어야 합니다. 이것이 바로 전산실의 기원이자 가치입니다. 원격 다중 활성 아키텍처.

위 그림에 표시된 것처럼 컴퓨터실 1과 컴퓨터실 2가 두 도시에 배포되면 원격 활성-활성 상태가 됩니다. 이러한 방식으로 컴퓨터실은 여러 지역에 배포될 수 있습니다. 활성-활성이 원격 활성-활성으로 업그레이드됩니다.

원격 멀티 액티브의 아키텍처 다이어그램은 그림 2에 나와 있습니다. 클라이언트 트래픽은 실행을 위해 라우팅 계층을 통해 여러 지역 컴퓨터실로 분산됩니다. 동일한 도시의 Active-Active 아키텍처와의 차이점은 서로 다른 지역의 컴퓨터실이 물리적으로 멀리 떨어져 있다는 점입니다. 전용 네트워크 회선을 배포하는 데 드는 비용은 엄청나고 비현실적입니다. 따라서 서로 다른 컴퓨터실 간의 네트워크 지연은 무시할 수 없습니다. 로컬 전산실에서 데이터베이스를 운영해야 합니다. 전산실을 넘나들며 운영할 수는 없습니다. 다중 활성 원격 아키텍처에서는 각 컴퓨터실의 데이터베이스가 기본 데이터베이스이며, 서로 다른 컴퓨터실의 데이터가 중앙 컴퓨터실과 동기화된 다음 중앙 컴퓨터실에서 다른 컴퓨터실로 동기화됩니다. 모든 컴퓨터실의 데이터베이스에 기록할 수 있기 때문에 서로 다른 컴퓨터실에서 동일한 데이터를 수정하면 필연적으로 데이터 충돌이 발생합니다. 데이터 충돌을 해결하기 위해 라우팅 계층의 조각화 정책에 따라 일부 트래픽을 특정 컴퓨터실로 고정적으로 전달할 수 있습니다. 트래픽 조각화 정책은 비즈니스 유형이나 지리적 위치를 기반으로 할 수 있습니다. 트래픽 샤딩을 통해 동일한 사용자의 관련 요청이 동일한 컴퓨터실로 라우팅되어 모든 비즈니스 작업이 완료되고 컴퓨터실의 트래픽이 로컬 컴퓨터실 내에서만 흐르도록 보장되어 네트워크 대기 시간이 줄어듭니다.

그림 2: 원격 다중 활성 아키텍처 다이어그램

1.2 다양한 장소에서의 다양한 활동에 대한 일반적인 시나리오

원격 멀티 액티브 아키텍처는 자연 재해로 인한 위험에 대처하기 위해 외부 서비스를 제공하기 위해 여러 지역에 컴퓨터실을 배포합니다. 이는 높은 시스템 가용성을 달성하는 효과적인 수단입니다. 그러나 원격 다중 활성 아키텍처는 시스템을 더욱 복잡하게 만들고 오류 차단 및 데이터 일관성 측면에서 새로운 요구 사항을 도입합니다.

  • 클라우드 서비스 시나리오에서 가용 영역에 오류가 발생하면 오류 영역의 소비자는 소비를 위해 메시지 가져오기를 중지해야 하며 동시에 할당된 메시지 대기열은 처리를 위해 일반 가용 영역의 소비자에게 재조정됩니다. 비즈니스 예외가 발생하지 않도록 합니다.
  • 원격 멀티액티브는 트래픽을 샤딩하여 데이터 일관성 문제를 효과적으로 해결할 수 있습니다. 단, 제품수량 등 글로벌 데이터의 경우 데이터 쓰기 시 중앙전산실에 있는 글로벌 데이터베이스만 운영하도록 허용됩니다. 일반적으로 글로벌 데이터 운영을 위한 트래픽은 중앙 전산실로 라우팅되어야 하며, 다른 전산실에서는 데이터베이스 읽기만 허용됩니다. 트래픽이 잘못 라우팅되면 중앙이 아닌 컴퓨터실의 데이터베이스에 계속 기록되어 데이터 충돌이 발생할 수 있습니다. 이때 글로벌 데이터베이스에 대한 보호를 추가하고 중앙 전산실이 아닌 곳에서 쓰기 작업 실행을 금지해야 합니다.

위의 두 가지 대표적인 문제에 대응하여 Sermant에서는 이를 해결하기 위한 메시지 대기열 소비 금지 플러그인과 데이터베이스 쓰기 금지 플러그인을 개발했는데, 이에 대해 아래에서 자세히 소개하겠습니다.

2. 메시지 큐는 플러그인 사용을 금지합니다.

2.1 메시지 대기열 소비 금지 플러그인 소개

메시지 대기열 소비 금지 플러그인을 사용하면 마이크로서비스가 실행 상태의 실제 요구에 따라 소비자의 메시지 대기열 미들웨어 소비 동작을 동적으로 조정할 수 있으므로 비정상적인 환경이나 상태에서 비즈니스 처리 프로세스의 메시지가 적절하게 관리되고 불필요한 메시지가 발생하지 않도록 할 수 있습니다. 비즈니스 영향. 예를 들어, 원격 멀티 액티브 아키텍처 시스템에서 지역 장애가 발생하여 트래픽을 차단해야 하는 경우 장애가 발생한 가용 영역에서 메시지 큐 소비 금지 기능을 활성화하여 일반 가용 영역의 소비자를 허용할 수 있습니다. 문제가 발생한 영역은 트래픽을 소비하여 비즈니스 이상을 유발하여 시스템의 고가용성을 보장합니다. 결함이 처리된 후 소비를 다시 시작할 수 있습니다.

메시지 대기열 소비 금지 플러그인은 현재 Kafka와 RocketMQ라는 두 가지 메시지 미들웨어를 지원합니다. Kafka 측에서 플러그인은 주제 수준 소비 금지 및 복구 기능을 구현합니다. RocketMQ의 경우 소비 제어 세분성은 소비자 인스턴스 수준에 있습니다. Sermant는 구성 센터를 통해 소비가 금지되어야 하는 메시지 대기열 유형 및 특정 항목 발행을 지원합니다.

대기열 소비 금지 플러그인, 구성 지침 및 장면 시연에 대한 자세한 내용은 공식 웹사이트 문서 메시지 대기열 소비 금지를 참조하세요 .

2.2 메시지 큐 소비 금지 플러그인 실패 및 흐름 차단 시나리오 적용

애플리케이션 시나리오: 소프트웨어 시스템은 Kafka를 메시지 대기열로 사용하고 생산자는 주제 테스트 주제에 대한 메시지를 생성합니다. 주제 메시지에는 4개의 파티션이 포함됩니다. 가용 영역 A와 가용 영역 B에는 각각 테스트 소비자 그룹에 가입하고 주제 테스트 메시지를 소비하는 두 명의 소비자가 있습니다. 각 소비자에는 파티션이 할당됩니다. 가용 영역 A와 가용 영역 B는 서로 다른 지역, 즉 서로 다른 위치에 배포됩니다. . 컴퓨터실이 2개 더 있습니다. 아래 그림과 같이.

이 시나리오에서는 소비자 서비스가 Sermant의 메시지 대기열을 탑재하여 소비 플러그인 실행을 비활성화한 후 소비자가 소비하는 주제를 실시간으로 제어할 수 있으므로 비즈니스 처리 프로세스의 메시지가 적절하게 관리됩니다. 비정상적인 환경이나 상태.

가용성 영역 A에 오류가 발생하면 가용성 영역 A의 소비자는 사용을 중지해야 합니다. 소비자 A와 소비자 B가 주제 테스트 주제를 소비하는 것을 금지하도록 가용 영역 A에서 전역 구성을 실행하고 할당된 메시지 대기열을 해제합니다.

메시지 대기열 소비 금지 플러그인의 구성은 다음과 같습니다. 활성화KafkaProhibition은 Kafka 대기열 소비 금지 기능을 활성화한다는 의미이며, kafkaTopics는 소비를 금지해야 하는 구독 주제를 지정합니다. 구성 전달 방법은 공식 웹사이트 문서를 참조 하세요 .

활성화KafkaProhibition: true  
두개골주제:  
 - 주제 테스트

구성이 전달된 후 다음 그림과 같이 가용성 영역 A의 소비자는 사용을 중지하고 가용성 영역 B의 소비자는 topic-test 주제의 파티션을 재할당합니다.

가용성 영역 A가 정상으로 돌아온 후 동적 구성 센터를 통해 구성이 다시 발행되어 소비자 A와 B가 주제 테스트 주제를 소비할 수 있습니다. 소비 구성 제공을 활성화한 후 Kafka는 재분배를 트리거하고 가용성 영역 A와 B의 소비자에게 파티션이 다시 할당됩니다.

메시지 대기열 소비 금지 플러그인은 원격 다중 활성 시나리오에서 메시지 대기열의 오류 차단 기능을 실현하여 시스템 가용성을 보장합니다.

3. 데이터베이스 쓰기 금지 플러그인

3.1 메시지 대기열 소비 금지 플러그인 소개

데이터베이스 쓰기 금지 플러그인을 탑재하여 서비스가 시작된 후 지정된 데이터베이스에 대한 쓰기 금지 기능을 동적으로 활성화하거나 비활성화할 수 있습니다. 원격 다중 활성 시나리오에서 사용자는 데이터베이스 시스템의 데이터 무결성, 일관성 및 보안을 보장하기 위해 개별 또는 모든 데이터베이스에 대한 쓰기 작업을 중지하고 데이터 읽기만 허용하기를 원합니다. 예를 들어, 비즈니스 데이터베이스의 글로벌 데이터 쓰기는 중앙 전산실에서만 허용됩니다. 데이터베이스 쓰기 금지 플러그인을 활성화하면 비중앙 전산실 데이터베이스에 라우팅 비정상 트래픽이 기록되지 않습니다. 다중 쓰기 시나리오에서는 트래픽이 수동으로 차단되기 전에 차단됩니다. 스트림의 컴퓨터실은 먼저 데이터베이스에 대한 쓰기를 금지하고 스트림을 차단하기 전에 다른 컴퓨터실의 데이터 동기화가 완료될 때까지 기다립니다. 위 시나리오에서 데이터베이스 쓰기 금지 플러그인을 사용하면 데이터베이스 데이터의 일관성이 보장됩니다.

데이터베이스 쓰기 금지 플러그인은 현재 MySQL, MongoDB, PostgreSQL 및 OpenGauss 데이터베이스를 지원합니다. 마이크로서비스가 실행 중일 때, 쓰기 금지된 데이터베이스 유형 및 이름은 구성 센터를 통해 발급될 수 있습니다. 쓰기 금지를 지원하는 특정 쓰기 작업 및 플러그인 사용에 대해서는 공식 웹사이트 문서 데이터베이스 쓰기 금지를 참조하세요 .

3.2 데이터베이스 쓰기 금지 플러그인으로 데이터 일관성 애플리케이션 보호

애플리케이션 시나리오: 다중 활성 원격 아키텍처에서 비즈니스 마이크로서비스는 제품 재고와 같은 글로벌 데이터를 수정하는 데 사용됩니다. 동시에 글로벌 데이터는 global이라는 MySQL 데이터베이스에 저장됩니다. 이 글로벌 데이터의 경우 중앙 전산실의 글로벌 데이터베이스에 대해서만 쓰기 작업이 허용되며, 다른 전산실의 글로벌 데이터베이스는 데이터 읽기만 가능합니다. 데이터 일관성을 보장하기 위해 글로벌 데이터가 수정되면 라우팅 계층에서 실행하기 위해 트래픽이 중앙 컴퓨터실로 라우팅되고, 기타 읽기 작업은 아래 그림과 같이 모든 컴퓨터실로 라우팅될 수 있습니다.

라우팅 계층에서 글로벌 데이터를 쓰는 트래픽에 대해 라우팅 오류가 발생하여 이를 비중앙 전산실에서 실행할 때, 중앙 전산실과 비중앙 전산실에서 동시에 동일한 제품의 수량을 수정하는 경우 데이터 충돌이 발생할 수 있습니다. 이를 방지하기 위해 비즈니스 마이크로서비스는 Sermant의 데이터베이스 쓰기 금지 플러그인을 탑재하여 중앙 컴퓨터실이 아닌 글로벌 데이터베이스에 대한 쓰기를 금지할 수 있습니다.

중앙 컴퓨터실이 아닌 곳에서는 글로벌 데이터베이스에 대한 쓰기가 금지되어 있으며 동적 구성 센터를 통해 다음 구성을 실행해야 합니다.

활성화MySqlWriteProhibition: true  
mySql데이터베이스:  
 - 글로벌

그 중, 활성화MySqlWriteProhibition은 MySQL 데이터베이스에 쓰기를 금지하는 기능을 활성화한다는 의미이며, mySqlDatabases는 쓰기 금지된 특정 데이터베이스의 이름을 지정하는 데 사용됩니다. 이 예는 전역 데이터베이스입니다.

구성이 발행된 후 중앙이 아닌 전산실의 글로벌 데이터베이스에 라우팅이 비정상적인 트래픽이 기록되면 데이터베이스 쓰기 금지 플러그인이 비즈니스 마이크로서비스에 java.sql.SQLException 예외를 발생시키고 데이터베이스에 대한 쓰기를 금지합니다. . 비즈니스 시스템은 시스템의 정상적인 작동을 보장하기 위해 트래픽을 중앙 전산실로 다시 라우팅하는 재시도 작업을 추가하는 등 이 예외를 처리해야 합니다. 실행 로직은 아래 그림과 같습니다.

데이터베이스 쓰기 금지 플러그인은 원격 다중 활성 시나리오에서 지정된 데이터베이스에 대한 쓰기를 비활성화하여 비정상적인 트래픽 쓰기 작업을 방지하고 다른 컴퓨터실에 있는 데이터베이스의 데이터 일관성을 보장할 수 있습니다.

4. 요약

원격 다중 활성 시나리오에서 Sermant의 메시지 대기열 소비 금지 플러그인은 가용성 영역에 장애가 발생할 경우 메시지 대기열 흐름 차단 문제를 실현하여 일반 가용성 영역의 소비자가 데이터베이스 쓰기 금지 플러그인을 사용할 수 있도록 허용합니다. 지정된 데이터베이스에 대한 쓰기를 금지하는 데 사용되며 데이터 충돌을 방지하기 위해 데이터베이스 읽기에는 영향을 미치지 않습니다.

Sermant는 원격 다중 활동 시나리오에서 풍부한 서비스 거버넌스 기능을 달성했습니다. 앞으로도 Sermant는 보다 완전한 서비스 거버넌스 기능 시스템을 점진적으로 구축하기 위해 열심히 노력할 것입니다.

 

서비스 거버넌스 분야에 초점을 맞춘 바이트코드 향상 프레임워크인 Sermant는 고성능, 확장 가능, 액세스하기 쉽고 기능이 풍부한 서비스 거버넌스 경험을 제공하기 위해 최선을 다하고 있으며 성능, 기능 및 경험을 관리합니다. 각 버전에서는 누구나 참여할 수 있습니다.

  • 서먼트  공식 홈페이지 : https://sermant.io
  • GitHub  창고 주소: https://github.com/huaweicloud/Sermant

화웨이 클라우드의 신기술에 대해 빨리 알아보고 팔로우하려면 클릭하세요~

1990년대에 태어난 프로그래머가 비디오 포팅 소프트웨어를 개발하여 1년도 안 되어 700만 개 이상의 수익을 올렸습니다. 결말은 매우 처참했습니다! 고등학생들이 성인식으로 자신만의 오픈소스 프로그래밍 언어 만든다 - 네티즌 날카로운 지적: 만연한 사기로 러스트데스크 의존, 가사 서비스 타오바오(taobao.com)가 가사 서비스를 중단하고 웹 버전 최적화 작업 재개 자바 17은 가장 일반적으로 사용되는 Java LTS 버전입니다. Windows 10 시장 점유율 70%에 도달, Windows 11은 계속해서 Open Source Daily를 지원합니다. Google은 Docker가 지원하는 오픈 소스 Rabbit R1을 지원합니다. Electric, 개방형 플랫폼 종료 Apple, M4 칩 출시 Google, Android 범용 커널(ACK) 삭제 RISC-V 아키텍처 지원 Yunfeng은 Alibaba에서 사임하고 향후 Windows 플랫폼용 독립 게임을 제작할 계획
{{o.이름}}
{{이름}}

추천

출처my.oschina.net/u/4526289/blog/11101736