기사 "유레카 캐싱 메커니즘은" 실시간 API 게이트웨이 인식 서비스를 오프라인으로 달성하는 방법이 문서 것이다 세부 사항, 우리가 유레카의 더 나은 이해를 믿고, 유레카 캐싱 메커니즘을 설명합니다.
I. 서론
동적으로 할당 된 마이크로 네트워크 위치 서비스 인스턴스에서 클라우드 기반 서비스 응용 프로그램. 그리고 자동 스케일링, 오류 및 업그레이드 때문에, 서비스 인스턴스는 종종 동적으로 변경됩니다. 따라서 클라이언트 코드는 더 복잡 서비스 검색 메커니즘을 사용합니다.
클라이언트 측 서비스 검색과 발견 : 현재 주로 두 가지 모드에있는 역할을합니다.
- 서버 검색이 : 서비스 레지스트리 요청에 대한 부하 분산 장치에 의해 시작된 클라이언트는로드 밸런서 조회 서비스 레지스트리는 각 요청이 가능한 서비스 인스턴스로 라우팅됩니다.
- 클라이언트 탐색 : 클라이언트는 서비스 인스턴스의 사용 가능한 네트워크 주소를 결정할 책임이 있으며, 요청로드 밸런싱, 클라이언트 액세스 서비스 등록 클러스터에서 사용할 수있는 서비스의 데이터베이스는 형태와는 클라이언트가를 선택하는로드 밸런싱 알고리즘을 사용하여 다음 사용 가능한 서비스의 예는 요청을 시작합니다.
발견 가장 큰 차이점에 대한 클라이언트 측 서비스 검색은 다음과 같습니다 클라이언트가 (캐시) 서비스를 사용할 수 레지스트리 정보를 알고있다. 서버에서 적시하지 업데이트하고 일관성 클라이언트 및 서버 캐시 데이터가 발생할 수있는 경우 클라이언트 측 캐싱.
둘째, 결합 게이트웨이 유레카
넷플릭스 OSS는 클라이언트 서비스 검색의 좋은 예를 제공합니다. 레지스트리와 같은 유레카 서버, 유레카 서버에 Zuul 상대 유레카 클라이언트, Zuul 유레카 서버가 로컬 캐시 목록에 서비스를 종료합니다이며, 지역 zuul을 통해 서비스 목록을 업데이트 일반 작업 및 기타 서비스의 형태로 리본을 사용하여 목록을 발견 클라이언트로드 밸런싱을 구현합니다.
정상적인 상황에서는 발신자는 즉각적인 응답을 얻을 수있는 게이트웨이에 요청을 시작합니다. 생산자 볼륨 감소 할 때, 조립 라인에서 인해 유레카 및 메커니즘은 정기적으로 업데이트되는이 멀티 레벨 캐시 아키텍처, 이전 기사로 상황을 (갱신하지 존재 B 서비스 목록의로드 균형 끝의 디자인에, 상황의 업그레이드 " 유레카 캐싱 메커니즘은 " 가장 긴 봉사 소비자, 소비자가 게이트웨이에 요청을 시작하는 경우 다음로드 균형이 존재하지 않는 서비스 개시 요청을, 요청이 시간 초과하는 시간 무한 240 초 접근을) 인식, 볼 수 있습니다.
셋째, 솔루션
아이디어의 3.1 실현
조립 라인 오프 생산자 후, 첫 번째는 readWriteCacheMap의 유레카 서버, 마지막으로 코어로드 균형의 게이트웨이의 인식을 얻을 수 있다는 인식을 얻을 수 있습니다. 그러나로드 균형 로컬 목록을 유지로드 균형 생산자에 발견했다.
조립 라인 오프 생산자의 실시간 게이트웨이 인식을 달성하기 위해 그래서, 당신은이 작업을 수행 할 수 있습니다 첫째, 생산자 또는 배포 플랫폼 사전 알림 유레카 서버에 대한 다음은 유레카 멀티 레벨 캐시 사이의 업데이트 시간을 건너, 유레카 클라이언트에 직접 통지 Zuul, 마지막으로, 서비스 유레카 클라이언트의 목록은 리본에 업데이트됩니다.
그러나, 생산에 오프라인 알림 로직 코드, 오염 문제, 언어의 차이가 발생합니다 코드.
유명한 속담을 빌려 :
"컴퓨터 과학의 모든 문제는 간접적 인 중간 계층을 추가하여 해결 될 수있다"
상태가 유레카 서버 및 게이트웨이 코어, 동기화 상태의 생산자에 동기화 부드러운 사물의 역할을 할 것 인 동안 오프라인, 발신자의 요청에 응답하기위한 외부 REST API를 제공하는 프록시 서비스의 상응하는 게이트웨이-SynchSpeed.
아이디어 : 생산자는 어떻게 업그레이드, 조립 라인에서, 볼륨 감소 의 인스턴스 알려 주도권을 쥐고 것입니다, 전에 스파이더 플랫폼 (거미 컨테이너 관리 플랫폼) 아래로 프로듀서를 게이트웨이를-SynchSpeed, 다음 게이트웨이 SynchSpeed 유레카을 알립니다 생산자 서버의 인스턴스가 다운, 유레카 서버 오프라인 성공, 게이트웨이 SynchSpeed 코어 게이트웨이 직접 통보됩니다.
디자인 특징
-
비 침습적, 사용하기 쉬운. 발신자, 게이트웨이 SynchSpeed만큼 호출자가 HTTP에 대한 요청이 진정한 논리의 실현하지만, 달성하기 위해 에이전트에 호출자에게 방해되지 기반으로 나머지는 시작 어떤 언어 상관 없어.
-
원 자성. 첫째 유레카 서버에서 호출자는 오프라인, 그 다음 줄은 모든 관련 핵심 게이트웨이의 최소 운영 실행 유닛이 서비스를 오프라인으로 어느 정도의 원자 특성을 보장하기 위해 "부드러운 것"에 해당 게이트웨이가-SynchSpeed입니다.
3.2 구현 단계
단계 설명
-
첫 번째 단계 : 생산자는 어떻게 업그레이드, 볼륨 감소, 오프라인 전에, 스파이더 플랫폼은 서비스 게이트웨이 SynchSpeed HTTP 요청 양식, 알림 서비스 IP 인스턴스 컨테이너의 입자 크기를 통지합니다.
-
단계 : 유레카 서버에 통지 한 후 IP의 가용성을 확인하고, 요청을받은 후 게이트웨이-SynchSpeed.
-
세 번째 단계 : 유레카 서버 제조자 실패 조건을 설정하고, 처리 결과 (2 등분 유레카 오프라인 형태 번 직접 서비스 레지스트리 목록에서 직접 제거를 반환하기 위해 상기 제 2 상태는, 오프라인 즉 프로듀서 상태가 설정
OUT_OF_SERVICE. 양식이 조립 라인에서 첫 번째의 경우,이 기간 생산자 하트 비트 유레카 서버에 동기화하면 스파이더 플랫폼 문제 단선 요청, 생산자 프로세스가 즉시 죽일 보장 할 수 없습니다, 서비스는 유레카 서버에 다시 등록됩니다 ). -
4 단계 : 결과가 성공하면 이전 단계에서 수득 게이트웨이 SynchSpeed 결과, 다음 단계가 실행되고, 그렇지 않으면 중지.
-
5 단계 : 유레카 클라이언트로 게이트웨이 SynchSpeed. IP 프로듀서 응용 프로그램 이름에서 서비스를받을 현지 등록 목록에서 게이트웨이-SynchSpeed.
-
6 단계 : 응용 프로그램 이름 핵심 라이브러리에 대한 오프라인 서비스 게이트웨이와 관련된 모든 쿼리에서 게이트웨이 SynchSpeed .
网关组名字 -
단계 세븐 :를 통해 게이트웨이 - SynchSpeed 로컬 서비스 목록 : (포트 IP) 게이트웨이 주소 IPADDRESS 그룹 아래의 모든 서비스를 찾을 수 있습니다.
网关组名字 -
단계 팔 : 모든 관련 게이트웨이 노드의 게이트웨이 SynchSpeed 비동기 알림.
-
아홉 번째 단계 : 게이트웨이 코어는 통지를받은 후, 프로듀서의 상태가 오프라인으로 수행하고, 캐시 DownServiceCache 성공의 예를 오프라인 상태 정보를 기록합니다.
-
10 단계 : 게이트웨이 코어 리본 서비스의 로컬 목록을 업데이트합니다.
넷째, 보상 메커니즘
유레카는 보안 메커니즘을 제공합니다. 전 유레카 서버 업데이트 서비스 목록에서 유레카 클라이언트, 변경 한 경우, 업데이트에서 증분 업데이트의 전액을 업데이트 할 수있는 방법이 될 것이다 관련 해시 값 변경 (클라이언트 서비스 목록이 수정되고는, 해시 값이 변경됩니다) 여부를 확인합니다합니다 ( "유레카 캐싱 " readOnlyCacheMap 30 및 readWriteCacheMap 데이터) 상이해도 내의 클라이언트 측 캐싱리스트 결국 일관성 리본 종료 서비스리스트 readWriteCacheMap 데이터가 발생할 경우, 이는 readOnlyCacheMap 덮여 있음을 보여준다.
유레카이 메커니즘의 경우, 30을 초과하지 않는 캐시 서비스에 대한 풀 이벤트의 유레카 클라이언트 전액을 청취 보상 메커니즘으로 EurekaEventListener 청취자를 도입, 그 상태를 다시 설정됩니다 . OUT_OF_SERVICE
다섯, API의 보안 설계
계정에 시스템의 보안 문제를 고려, 악의적 인 사람에 액세스하는 경우, 유레카 서버에 의해 생산을 찾을 수없는 소비자의 결과로, 유레카 서버의 조립 라인 오프 아무 이유없이 생산을 할 수 있습니다.
블랙 및 화이트리스트 필터를 사용하여 다음과 같이 보안, 기본 프로세스가 수행
-
게이트웨이 - Synchspeed 화이트리스트에 세그먼트 (IP 네트워크)
-
한편, 여과, 요청자 IP 서브넷, 방출이 경우 게이트웨이 Synchspeed는 요청자 오프라인 IP 체크섬에 대해, 필터에 첨가.
여섯째, 다시 로그인
게이트웨이 SynchSpeed 및 게이트웨이 코어가 도커 컨테이너에 배치되어 있기 때문에 컨테이너가 다시 시작되면, 그것은 잃어버린 로그 파일의 원인이됩니다. 그래서 Elasticsearch에 기록됩니다 게이트웨이 SynchSpeed 및 게이트웨이 코어 관련 로그에 대한 필요는 키바 Elasticsearch 쿼리 데이터를 표현하는 시각적 인 방법에 대한 궁극적 책임이있다.
세븐, 코드 쇼
게이트웨이 SynchSpeed 상태 동기화를 할
EurekaEventListener 처리 캐시 데이터
여덟, 보충
의 조립 라인 오프 실시간 게이트웨이 서비스의 현재 인식, Zuul 봄 클라우드 Zuul 1.3.6.RELEASE, 봄 클라우드 유레카 1.4.4.RELEASE의 유레카 버전.
현재 게이트웨이 다운 스트림 서비스의 실시간 게이트웨이 인식의 구현뿐만 아니라 다음과 같은 조건을 충족해야합니다 :
- 생산자는 Kubernetes 컨테이너 관리 플랫폼에 배포 할 필요가
- 생산자는 정상적인 할 오프라인 업그레이드하거나 부피 감소 작업을. 선박이 비정상적인 서비스 중단 및 조립 라인 오프가 아닌 다른 정상의 결과로 자원의 부족에 기인하는 경우는 지원되지 않습니다.
조립 라인 오프 게이트웨이 서비스는이 기능을 자신의 비즈니스 시스템 요구 사항에 따라 특정 구성을 결정하는 정당으로 설정되어,이 기능은 거미 플랫폼에 설정되어 있지 기본적으로 제공하는 비즈니스 게이트웨이 솔루션의 선택적 실시간으로 인식하고, 방법을 볼 API 게이트웨이 액세스 지침 "거미 실시간 게이트웨이 인식 구성 문서"이다.
저자 :시에 Guohui
출처 : 기술의 CreditEase 연구소