얼마전 특별한 사정으로 인터뷰가 연달아 중단됐는데요. 지난주에 어떤 노인이 인터뷰에 나갔다가 스프링클라우드에 대한 질문을 받았습니다. 그의 피드백을 바탕으로 오늘 우리는 SpringCloud 인터뷰 시리즈를 계속합니다.
나를 팔로우하는 모든 사람을 환영합니다.
다음은 Spring Cloud 핵심 구성 요소 관계 다이어그램입니다.
from 이 사진에서 실제로 많은 정보를 얻을 수 있으니, 차분히 감상해보시길 바랍니다.
다음은Spring Cloud Netflix和Spring Cloud Alibaba핵심 구성 요소를 요약한 것입니다.
더 이상 고민하지 말고 직접 Spring Cloud 시리즈를 시작해보세요.
Spring 클라우드 스트리밍 애플리케이션 스타터는 외부 시스템과의 통합을 제공하는 Spring Boot 기반의 Spring 통합 애플리케이션입니다. 제한된 데이터 처리를 수행하는 애플리케이션을 빠르게 구축하기 위한 단기 마이크로서비스 프레임워크인 Spring Cloud Task.
마이크로서비스 아키텍처는 단일 애플리케이션을 일련의 작은 서비스로 나누는 것을 옹호합니다. 각 서비스는 서비스 간에 서로 조정하고 협력하여 사용자에게 최고의 서비스를 제공합니다. 값. 서비스는 경량 통신 메커니즘을 사용하여 서로 통신합니다(일반적으로 HTTP 기반 RESTful API). 각 서비스는 특정 비즈니스를 중심으로 구축되며 프로덕션 환경, 프로덕션과 유사한 환경 등에 독립적으로 구축될 수 있습니다. 또한 특정 서비스의 경우 이를 구축하기 위해 비즈니스 상황에 따라 적절한 언어와 도구를 선택해야 합니다. , 다양한 언어를 사용하여 서비스를 작성할 수 있으며 다양한 데이터 저장소를 사용할 수 있습니다.
일반인의 용어로:
마이크로서비스는 단일 책임을 가진 독립적인 서비스 애플리케이션입니다. intellij idea 도구에는 maven을 사용하여 개발된 독립적인 모듈이 있습니다. 구체적으로는 단일 전문 비즈니스 로직을 처리하기 위해 springboot를 사용하여 개발된 작은 모듈입니다.
마이크로서비스는 서비스의 크기를 강조하고, 특정 지점에 초점을 맞추고, 구체적으로 특정 문제를 해결/해당 서비스 애플리케이션을 구현하는 것을 아이디어의 모듈이라고 볼 수 있습니다.
Spring Boot를 사용하여 분산 마이크로서비스를 개발할 때 다음과 같은 문제에 직면합니다
동기 통신: dobbo는 RPC 원격 프로시저 호출을 사용하고 springcloud는 REST 인터페이스 json 호출 등을 사용합니다.
비동기: 메시지 대기열(예:RabbitMq、ActiveM、Kafka및 기타 메시지 대기열)
회로 차단기 메커니즘은눈사태 효과를 처리하기 위한 마이크로서비스 링크 보호 메커니즘입니다. 특정 마이크로서비스를 사용할 수 없거나 응답 시간이 너무 길면 서비스 성능이 저하되어 노드에서 마이크로서비스 호출이 중단되고 "오류" 응답 정보가 빠르게 반환됩니다. 노드의 마이크로서비스 호출 응답이 정상인 것으로 감지되면 호출 링크가 복원됩니다. Spring Cloud 프레임워크에서 회로 차단기 메커니즘은 Hystrix를 통해 구현됩니다. Hystrix는 실패한 호출이 특정 임계값에 도달하면 기본적으로 5초 내에 20번의 호출을 수행합니다. 활성화됩니다.
서비스 다운그레이드는 일반적으로 전체 부하를 기준으로 고려됩니다. 즉, 서비스 연결이 끊어지면 더 이상 서버가 호출되지 않습니다. 이때 클라이언트는 로컬 대체 콜백을 준비하고 기본값을 반환할 수 있습니다. 이렇게 하면 레벨이 낮아지더라도 계속 사용할 수 있으니 직접 죽는 것보다는 낫습니다.
Hystrix相关注解@EnableHystrix：开启熔断@HystrixCommand(fallbackMethod=”XXX”)，声明一个失败回滚处理函数XXX，当被注解的方法执行超时（默认是1000毫秒），就会执行fallback함수는 오류 메시지를 반환합니다.
Zookeeper는 CP를 보장하고 Eureka는 AP를 보장합니다.
A: 고가용성
C: 일관성
P: 파티션 내결함성
1. 등록 센터에 서비스 목록을 쿼리할 때 등록 센터가 몇 분 전부터 정보를 반환하는 것은 용납할 수 있지만 직접 다운을 허용할 수 없으며 사용할 수 없습니다. 즉, 서비스 등록 기능은 상대적으로 고가용성에 대한 요구 사항이 높지만 ZooKeeper에서는 네트워크 장애로 인해 마스터 노드가 다른 노드와의 연결이 끊어지면 나머지 노드가 리더를 다시 선출하는 상황이 발생합니다. 문제는 리더 선택 시간이 30~120초로 너무 길고, 선택 기간 동안 zk 클러스터를 사용할 수 없어 선택 기간 동안 등록 서비스가 마비되는 현상이 발생한다는 점이다. 클라우드 배포 환경에서는 네트워크 문제로 인해 zk 클러스터가 마스터 노드를 잃을 가능성이 높습니다. 서비스는 복원될 수 있지만 긴 선택 시간으로 인해 장기간 등록이 불가능해지는 것은 용납할 수 없습니다.
2. Eureka는 가용성을 보장합니다. 여러 노드의 장애가 발생하더라도 나머지 노드는 계속해서 등록 및 쿼리 서비스를 제공할 수 있습니다. 유레카 클라이언트가 특정 유레카를 등록하거나 발견할 때 연결 실패가 발생하면 자동으로 다른 노드로 전환됩니다. 하나의 유레카가 남아 있는 한 등록 서비스는 보장될 수 있지만 발견된 정보는 제공되지 않을 수 있습니다. 최신. 또한 Eureka에는 자체 보호 메커니즘도 있습니다. 15분 이내에 노드의 85% 이상이 정상적인 하트비트를 가지지 않으면 Eureka는 이때 클라이언트와 등록 센터 사이에 네트워크 오류가 발생한 것으로 간주합니다. , 다음 상황이 발생합니다:
①. Eureka는 오랫동안 하트비트를 받지 못해 만료되어야 하는 서비스를 등록 목록에서 더 이상 제거하지 않습니다.
②. Eureka는 새로운 서비스에 대한 등록 및 쿼리 요청을 계속 수락할 수 있지만 다른 노드와 동기화되지는 않습니다(즉, 현재 노드를 계속 사용할 수 있는지 확인)
③ 네트워크가 안정되면 현재 인스턴스의 새로운 등록 정보가 다른 노드에 동기화됩니다.
그러므로 Eureka는 Zookeeper
SpringBoot는 개별 마이크로서비스를 빠르고 쉽게 개발하는 데 중점을 둡니다.
SpringCloud는 전반적인 상황에 초점을 맞춘 마이크로서비스 조정 및 거버넌스 프레임워크입니다.
각 마이크로서비스에 대한 구성 관리, 서비스 검색, 회로 차단기, 라우팅을 제공합니다. 이벤트 버스, 글로벌 잠금, 의사 결정 선택, 분산 세션 및 기타 통합 서비스
SpringBoot는 개발 프로젝트에서 SpringCloud 없이 독립적으로 사용할 수 있지만 SpringCloud는 SpringBoot와 분리될 수 없으며 종속 관계입니다.
SpringBoot는 빠르고 편리한 개발에 중점을 둡니다. 개별 마이크로서비스인 SpringCloud는 글로벌 서비스 거버넌스 프레임워크에 중점을 둡니다.
컴퓨팅에서 로드 밸런싱은 컴퓨터, 컴퓨터 클러스터, 네트워크 링크, 중앙 처리 장치 또는 디스크 드라이브와 같은 여러 컴퓨팅 리소스 전반에 걸쳐 작업 부하 분산을 개선합니다. 로드 밸런싱은 리소스 사용 최적화, 처리량 최대화, 응답 시간 최소화 및 단일 리소스 과부하 방지를 목표로 합니다. 로드 밸런싱을 위해 단일 구성 요소가 아닌 여러 구성 요소를 사용하면 중복성을 통해 안정성과 가용성이 향상될 수 있습니다. 로드 균형 조정에는 일반적으로 다층 스위치나 도메인 이름 시스템 서버 프로세스와 같은 특수 소프트웨어나 하드웨어가 포함됩니다.
Hystrix는 액세스 포인트를 원격 시스템, 서비스 및 타사 라이브러리에 격리하고, 오류가 불가피할 때 연쇄 오류를 중지하고 복잡한 분산 시스템 탄력성을 구현하도록 설계된 대기 시간 및 내결함성 라이브러리입니다.
일반적으로 마이크로서비스 아키텍처를 사용하여 개발된 시스템의 경우 많은 마이크로서비스가 관련됩니다. 이러한 마이크로서비스는 서로 협력합니다.
다음 마이크로서비스에 대해 생각해 보세요.
위 그림의 마이크로서비스 9가 실패하면 전통적인 방법을 사용하여 예외를 전파한다고 가정해 보세요. 그러나 이로 인해 여전히 전체 시스템이 충돌하게 됩니다.
마이크로서비스 수가 증가함에 따라 이 문제는 더욱 복잡해집니다. 마이크로서비스의 수는 최대 1000개까지 가능합니다. 여기서 hystrix가 등장합니다. 이 경우 Hystrix의 Fallback 방식 기능을 사용하겠습니다. 직원-소비자가 제공하는 서비스를 사용하는 직원-소비자라는 두 가지 서비스가 있습니다.
간단한 다이어그램은 아래와 같습니다
이제 어떤 이유로든 직원 생산자가 노출한 서비스에서 예외가 발생했다고 가정해 보겠습니다. 이 경우 Hystrix를 사용하여 대체 방법을 정의했습니다. 이 대체 메소드는 공개 서비스와 동일한 반환 유형을 가져야 합니다. 노출된 서비스에서 예외가 발생하면 fallback 메서드는 일부 값을 반환합니다.
어떤 이유로 직원-소비자 공공 서비스에서 예외가 발생합니다. 이 경우 Hystrix를 사용하여 대체 방법을 정의합니다. 노출된 서비스에서 예외가 발생하면 fallback 메서드는 일부 기본값을 반환합니다.
firstPage 메서드()에서 예외가 계속 발생하면 Hystrix 회로가 중단되고 직원 소비자는 firtsPage 메서드를 모두 건너뛰고 fallback 메서드를 직접 호출하게 됩니다. 회로 차단기의 목적은 첫 번째 페이지 메서드 또는 첫 번째 페이지 메서드가 호출하여 예외 복구를 발생시킬 수 있는 다른 메서드에 시간을 허용하는 것입니다. 발생할 수 있는 상황은 부하가 적을 때 예외를 발생시킨 문제가 복구될 가능성이 더 높다는 것입니다.
먼저 네트워크 연결 통신을 처리하는 모듈이 있는데, 연결 설정, 관리, 메시지를 담당한다. 전염. 둘째, 네트워크 통신은 모두 바이트코드로 전송되고 우리가 사용하는 객체는 직렬화 및 역직렬화되어야 하기 때문에 코딩 및 디코딩 모듈이 필요합니다. 나머지는 클라이언트와 서버 부분입니다. 서버는 서비스 인터페이스를 공개합니다. 클라이언트는 서비스 인터페이스의 프록시 구현을 호출합니다. 이 프록시 구현은 데이터를 수집하고 이를 서버에 전송한 후 대기합니다. 반환될 결과.
유레카 서버 노드가 짧은 시간 내에 너무 많은 인스턴스에 대한 연결이 끊어지는 경우(예: 네트워크 장애 또는 클라이언트의 잦은 시작 및 종료) 노드는 자체 보호 모드에 들어가 등록 정보를 보호하고 더 이상 등록 데이터를 삭제하지 않으며 오류 복구가 발생하면 자동으로 자체 보호 모드를 종료합니다.
ribbon은 http 및 tcp의 일부 동작을 잘 제어할 수 있는 로드 밸런싱 클라이언트입니다.feign은 기본적으로 리본을 통합합니다.feign默认集成了ribbon。
Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。
Feign 的第一个目标是将约束分母的复杂性统一到 http apis，而不考虑其稳定性。
特点：
使用方式
@EnableFeignClients
@FeignClient(name=“xxx”)
@EnableFeignClients
@FeignClient(name="xxx")호출할 서비스 지정 15. 리본과 리본의 차이점은 무엇인가요? 그리고 가짜? 1. 리본은 다른 서비스를 호출하지만 방법은 다릅니다. 2. 시작 클래스 주석이 다릅니다. 리본은 @RibbonClient이고 feign은 @EnableFeignClients입니다. 3. 지정된 서비스 위치가 다릅니다. 리본은 @RibbonClient 주석에 선언되어 있는 반면, Feign은 추상 메소드를 정의하는 인터페이스에서 @FeignClient를 사용하여 선언됩니다. 4. 호출 방법이 다릅니다. 리본은 자체적으로 http 요청을 구성하고 http 요청을 시뮬레이션해야 합니다.
Spring Boot는 중복된 기존 프레임워크 구성 파일과 복잡한 어셈블리 구성 요소 문제를 해결하기 위해 Spring에서 출시한 Maven 기반 솔루션입니다. 단일 마이크로서비스를 빠르게 구축하기 위해 Spring Cloud는 다양한 마이크로서비스 간의 조정 및 구성, 서비스 간 통신, 회로 차단기, 로드 밸런싱 등을 해결하는 데 중점을 둡니다. 기술적 차원이 같지 않고 Spring Cloud는 Spring Boot에 의존하지만 Spring Boot는 Spring Cloud에 의존하지 않고 Dubbo와 함께 뛰어난 통합 개발도 수행할 수 있습니다
Summary
은 우리가 흔히 서비스 등록 및 검색이라고 부르는 것인데, 원격 프로시저 호출을 통해 직접 다른 서비스에 액세스할 수 있습니다.
장점: 단순하고 일반적이며 미들웨어 프록시가 없기 때문에 시스템이 더 간단합니다.
단점: 요청/응답 모드만 지원하고 알림, 요청/비동기 응답, 기타 모드는 지원하지 않습니다. 게시/구독, 게시/비동기 응답은 요청 중에 클라이언트와 서버를 모두 사용할 수 있어야 하므로 가용성을 줄입니다.
서비스 간 통신에 비동기 메시지를 사용하세요. 서비스는 메시지 파이프를 통해 메시지를 교환하여 통신합니다.
장점: 메시지 미들웨어는 소비자가 메시지를 사용할 수 있을 때까지 메시지를 캐시하고 알림, 요청/비동기 응답, 릴리스/구독과 같은 다양한 통신 메커니즘을 지원하므로 클라이언트와 서버를 분리하고 결합을 느슨하게 하며 사용성을 향상시킵니다. , 게시/비동기 응답.
단점: 메시지 미들웨어는 더욱 복잡합니다.
서비스가 출시되면 해당 서비스 이름을 지정하고 등록 센터에 서비스를 등록합니다(유레카, Zookeeper).Eureka 、Zookeeper)。
注册中心加@EnableEurekaServer，服务用@EnableDiscoveryClient
@EnableEurekaServer, service
@EnableDiscoveryClient, 그런 다음 리본 또는 가장을 사용합니다. 직접 서비스 호출 검색을 수행합니다.
이 질문은 면접 질문을 외웠는지에 따라 더 실용적입니다.
유레카 서버 노드가 짧은 시간 내에 너무 많은 인스턴스에 대한 연결이 끊어지면(예: 네트워크 장애 또는 클라이언트의 잦은 시작 및 종료 등) 등록 정보를 보호하기 위해 노드가 자체 보호 모드로 전환되며 더 이상 삭제되지 않습니다. 데이터를 등록하고 오류를 복구하면 자동으로 자체 보호 모드가 종료됩니다.
spring cloud 버스는 분산 노드를 경량 메시지 브로커로 연결하거나 구성 파일 변경을 직접 전달하는 데에도 사용할 수 있습니다. 모니터링. 구성 파일이 수정되고 요청이 전송되면 모든 클라이언트는 구성 파일을 다시 읽습니다.
서비스가 다른 서비스를 호출할 때 네트워크 문제나 자체적인 문제로 인해 호출자는 호출 수신자의 응답을 기다립니다. 더 많은 서비스 이러한 리소스를 요청하면 더 많은 요청이 대기하게 되어 연쇄 효과(눈사태 효과)가 발생합니다. 일정 시간 내에 일정 횟수 호출할 수 없고, 다중 모니터링 후에도 복구의 징후가 없는 경우에는 회로 차단기가 완전히 개방되어 다음 번에는 서비스를 요청하지 않습니다.
반개방 : 짧은 시간 안에 회복의 조짐이 보입니다. 정상적으로 호출되면 회로 차단기가 서비스에 일부 요청을 보냅니다. Closed : 서비스가 항상 정상상태에 있어 정상적으로 호출이 가능한 상태.
분산 시스템에서는 수많은 서비스로 인해 서비스 구성 파일의 통합 관리와 실시간 업데이트를 용이하게 하기 위해 분산 구성 센터를 운영하고 있습니다. 구성요소가 필요합니다. Spring Cloud에는 분산 구성 센터 구성 요소봄 구름 구성 서비스의 메모리(즉, 로컬)에 배치되는 구성 서비스를 지원하고 원격 Git 저장소에 배치되는 것도 지원하는 Config.Spring Cloud Config，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。
在Spring Cloud Config
Spring Cloud Config구성 요소, 거기 두 가지 역할이 있습니다. 하나는 구성 서버이고 다른 하나는 구성 클라이언트입니다.
사용 방법:
참고자료; http://1pgqu.cn/M0NZo
Summary위 내용은 인터뷰 피드백 Spring Cloud의 25샷 시리즈의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
