분산 서비스 거버넌스에 대한 설계 문제가 있습니까?

마이크로서비스의 [등록 센터]를 구현하기 위해 C++를 사용했으며 이 등록 센터에 대한 고가용성을 구현했습니다. 내 서비스 네트워크는 TCP를 통해 통신하며 서비스가 온라인 상태가 되면 [등록 센터]에 등록됩니다. 등록 센터]가 푸시됩니다. 이 서버 주소는 [서비스 소비자]로 이동합니다. 이런 식으로 [서비스 소비자]는 모든 [마이크로서비스 맵]을 보유합니다. 내 로드 밸런싱은 [서비스 소비자]에서 수행됩니다. 직설적으로 말하면 [서비스 소비자]는 메모리에 상주해야 하므로 매우 중요합니다. Python에서는 Java가 더 쉽지만 FPM을 사용하는 PHP에서는 사형 선고와 같습니다. 기존 FPM PHP가 이 아키텍처를 지원할 수 있도록 PHP를 변환하는 방법입니다. Dubbo도 비슷한 방식으로 하는 것 같은데, 프론트엔드를 PHP로 하면 좀 골치아프지 않을까요?

답글 내용:

로드 밸런싱에는 두 가지 방법이 있습니다.

클라이언트 로드 밸런싱(일반적으로 Finagle 및 Dubbo) 구현이 간단하고 서비스가 직접 연결되어 성능이 좋은 것이 장점이다. 단점은 여러 언어를 사용하는 경우 언어별로 클라이언트를 구현해야 한다는 점입니다.

서버 측 로드 밸런싱, 일반적인 로드 밸런서는 Nginx 및 HAProxy입니다. 일반적으로 역방향 프록시가 서비스 앞에 추가됩니다. 클라이언트는 역방향 프록시를 통해 서버와 통신하며, 특정 로드 밸런싱 논리는 로드 밸런서에 의해 구현됩니다. 로드 밸런서 자체도 레지스트리에 등록할 수 있습니다. 장점은 클라이언트가 매우 간단하고 여러 언어를 지원한다는 것입니다. 단점은 약간의 성능 저하가 있다는 것입니다.

구체적인 선택은 비즈니스와 회사의 기술 선택에 따라 다릅니다. 다국어 시나리오에서 서버 측 솔루션은 유지 관리 비용을 많이 절약해 줄 것입니다. 물론 클라이언트를 유지 관리할 팀이 있다면, 결국 팀이 해야 할 일은 무엇인지는 언급하지 않겠습니다.

순수 Java 시나리오의 경우 Dubbo 또는 유사한 프레임워크가 이미 사용되었습니다. 프레임워크가 이미 지원을 제공한다면 신경쓰지 마세요.

주요 시나리오로 돌아가서, PHP 서비스에서 서비스 검색을 구현해야 하는 경우 Memcache에 넣는 등 서비스 레지스트리를 캐시하고 가끔씩 다시 가져올 수 있습니다.

이상 가장 간단하고 아마도 가장 안정적인 솔루션은 PHP 서버에서 에이전트를 실행하여 등록 센터를 모니터링하는 것입니다. 이 에이전트는 FPM에서 PHP를 호출한 후 PHP 구성 파일을 수정합니다. .

일반적으로 거의 모든 프레임워크에는 구성 파일이 있습니다. 이 파일을 직접 수정하면 됩니다(구성 파일도 읽어야 하기 때문에). 이 설계 방법에는 이제 특정 장점이 있습니다. 즉, 서비스 버스에 속한 일부 기능이 완전히 서비스 소비자 노드로 하위 계층화되었습니다. 이러한 방식으로 버스 자체는 더 가벼운 기능을 가지며 서비스 등록 및 등록 배포만 관리합니다. 정보. 등록 센터의 가동 중지 시간은 기본적으로 서비스 소비 및 호출에 영향을 미치지 않습니다.

방금 언급한 문제에 대한 해결책은 두 가지가 있습니다. 하나는 라우팅 및 로드 밸런싱을 포함하여 버스로 돌아가는 서비스 에이전트의 기능을 향상시키는 것입니다. 이를 원하지 않는 경우 별도의 서버를 설정하여 이 서버에서 서비스 소비 및 라우팅 균형 조정 논리를 구현하는 것도 고려할 수 있습니다. 이 서버는 PHP 애플리케이션에 해당하는 백엔드 프록시로 간주될 수 있습니다. 마이크로서비스에서 클라이언트 로드 밸런싱을 사용하는 것이 주요 추세라고 생각합니다. 첫째, 성능 이점이 있고, 둘째, 등록 센터가 다운되더라도 여전히 정상적으로 실행될 수 있습니다. 클라이언트 자체에서 회로 차단기 및 서비스를 구현해야 합니다. 다운그레이드와 같은 로직의 경우 간단한 로드 밸런싱 로직을 구현하는 것이 좋습니다. 저는 PHP에 익숙하지 않습니다. 서비스 구성을 service_config.php 파일에 작성하고 이 service_config.php를 다른 파일에 포함시키는 것이 가능합니까? 이전에 감지된 파일의 타임스탬프가 포함되어 있습니다. 특정 시간(예: 1분)을 초과하면 등록 센터에서 구성 쓰기 파일을 다시 가져옵니다. 두 가지 솔루션

1. Swoole
Swoole: PHP의 비동기식, 병렬, 고성능 네트워크 통신 엔진
Swoole을 사용하여 영구적인 내부 테스트 PHP 서버를 작성할 수 있습니다

2. 캐시
APCu(PHP: APCu - 수동) 또는 redis를 사용하여 서버 주소 목록을 캐시합니다
서비스 목록의 특정 성능 요구 사항 및 일관성 요구 사항을 확인하세요. 일관성 요구 사항이 상대적으로 높고 캐시가 더 짧을 수 있으며 Redis 캐시를 읽고 쓰는 데 따른 네트워크 오버헤드가 걱정된다면 APCu와 같은 로컬 캐시를 사용할 수 있습니다. 스울