리본은 스프링 클라우드 넷플릭스 패밀리 버킷에서로드 밸런싱을 담당하는 구성 요소입니다. 클래스 라이브러리 모음입니다. 리본을 통해 프로그래머는 프로젝트에서로드 밸런싱을 구현하기 위해 너무 많은 코드를 작성하지 않고도 특정 구현 세부 정보를 포함하지 않고 "투명하게"로드 밸런싱을 사용할 수 있습니다.
예를 들어, Eureka 및 Ribbon이 포함 된 클러스터에서 서비스 (JAR 패키지로 이해 될 수 있음)는 여러 서버에 배포됩니다. 여러 서비스 사용자가 동시에 서비스를 호출하면 합리적인 전략을 사용하여 이러한 동시 요청을 각 서버로 전달할 수 있습니다.
실제로, 스프링 클라우드의 다양한 다른 구성 요소를 사용할 때, 우리는 유레카와 같은 흔적의 흔적을 리본과 통합 할 수 있으며, 게이트웨이 기능을 제공하는 Zuul 구성 요소는 요청을 전달할 때 리본과 통합 될 수 있습니다.
코드 레벨에서 리본에는 다음 세 가지 중요한 인터페이스가 있습니다.
먼저, Iloadbalancer는로드 밸런서라고도합니다. 이를 통해 특정 규칙에 따라 프로젝트의 요청을 합리적으로 전달할 수 있습니다. 일반적인 구현 클래스는 Baseloadbalancer입니다.
둘째, Irule 에서이 인터페이스에는 RandomRule 및 Roundrobinrule과 같은 여러 구현 클래스가 있습니다. 이러한 구현 클래스는 구체적으로 "랜덤"및 "폴링"과 같은로드 밸런싱 전략을 정의합니다.이 인터페이스의 메소드를 다시 작성하여로드 밸런싱 전략을 사용자 정의 할 수도 있습니다.
Baseloadbalancer 클래스에서 IRULE 구현 클래스를 통해로드 밸런싱 정책을 설정하여로드 밸런서가이를 기반으로 요청을 합리적으로 전달할 수 있도록합니다.
셋째, IPPER 인터페이스는이 인터페이스를 통해 현재 사용 가능한 서버를 얻을 수 있으며 규칙을 사용자 정의 하여이 인터페이스에서 메소드를 다시 작성하여 서버를 사용할 수 있는지 여부를 결정할 수도 있습니다. Baseloadbalancer 클래스에서는 IPPING 구현 클래스를 통해 서버를 사용할 수 있는지 여부를 결정하는 정책을 설정할 수도 있습니다.
1 Iloadbalancer : loadbalancer 인터페이스
리본에서는 Iloadbalancer 인터페이스를 통해 특정로드 밸런싱 정책을 기반으로 서버를 선택할 수도 있습니다.
아래의 iloadbalancerdemo.java를 통해이 인터페이스의 기본 사용법을 살펴 보겠습니다. 이 클래스는 4.2 부에서 생성 된 RabbionbasicDemo 프로젝트에 배치되며 코드는 다음과 같습니다.
// 필요한 패키지를 생략하고 코드 가져 오기 공개 클래스 iloadbalancerdemo {public static void main (String [] args) {// iloadbalancer 객체 생성 iloadbalancer loadbalancer = new Baseloadbalancer (); // 서버 목록을 정의합니다. 목록 <Server> myServers = new ArrayList <Server> (); // 두 개의 서버 객체 생성 서버 S1 = 새 서버 ( "ekserver1", 8080); 서버 S2 = 새 서버 ( "ekserver2", 8080); // 두 서버 객체를 목록 유형에 넣습니다. myservers 객체 myservers.add (s1); myservers.add (S2); // myServers를로드 밸런서에 넣습니다. loadBalancer.addservers (myservers); // for for for (int i = 0; i <10; i ++) {// 기본 부하 밸런싱 규칙을 사용하여 서버 유형 객체 서버를 얻으려면 s = loadbalancer.chooseserver ( "default"); // 출력 IP 주소 및 포트 번호 System.out.println (s.gethost () + ":" + s.getport ()); }}}5 행에서, 우리는 유형 Baseloadbalancer의 loadbalancer 객체를 생성하고 Baseloadbalancer는로드 밸런서 Iloadbalancer 인터페이스의 구현 클래스입니다.
6 ~ 13 행에서는 두 개의 서버 유형 객체를 만들어 마이저에 넣습니다. 15 행에서, 우리는 LIST 유형의 myServers 객체를로드 밸런서에 넣습니다.
17 ~ 22 행의 FOR 루프에서로드 밸런서를 통해 서버 선택을 10 번 시뮬레이션했습니다. 구체적으로, 19 행에서 LoadBalancer의 ChoicesErver 메소드를 통해 기본 부하 밸런싱 규칙이있는 서버를 선택합니다. 21 행에서는 "인쇄"동작을 사용하여 실제 "서버 객체를 사용하여 요청 처리"작업을 시뮬레이션합니다.
위 코드의 실행 결과는 다음과 같습니다. LoadBalancer Load Balancer가 10 개의 요청을 2 개의 서버에 배포하고 실제로 "로드 밸런싱"의 효과를 볼 수 있습니다.
둘째, Irule 에서이 인터페이스에는 RandomRule 및 Roundrobinrule과 같은 여러 구현 클래스가 있습니다. 이러한 구현 클래스는 구체적으로 "랜덤"및 "폴링"과 같은로드 밸런싱 전략을 정의합니다.이 인터페이스의 메소드를 다시 작성하여로드 밸런싱 전략을 사용자 정의 할 수도 있습니다.
Baseloadbalancer 클래스에서 IRULE 구현 클래스를 통해로드 밸런싱 정책을 설정하여로드 밸런서가이를 기반으로 요청을 합리적으로 전달할 수 있도록합니다.
셋째, IPPER 인터페이스는이 인터페이스를 통해 현재 사용 가능한 서버를 얻을 수 있으며 규칙을 사용자 정의 하여이 인터페이스에서 메소드를 다시 작성하여 서버를 사용할 수 있는지 여부를 결정할 수도 있습니다. Baseloadbalancer 클래스에서는 IPPING 구현 클래스를 통해 서버를 사용할 수 있는지 여부를 결정하는 정책을 설정할 수도 있습니다.
EKSERVER2 : 8080 EKSERVER1 : 8080 EKSERVER2 : 8080 EKSERVER1 : 8080 EKSERVER2 : 8080 EKSERVER1 : 8080 EKSERVER2 : 8080 EKSERVER1 : 8080 EKSERVER2 : 8080 EKERVER1 : 8080 EKSERVER1 : 8080
2 IRULE :로드 밸런싱 규칙을 정의하는 인터페이스
리본에서는 Irule 인터페이스의 구현 클래스를 정의하여로드 밸런서에 해당하는 규칙을 설정할 수 있습니다. 다음 표에서, 우리는 일반적으로 사용되는 IRULE 인터페이스의 일부 구현 클래스를 볼 수 있습니다.
구현 클래스의 이름 | 로드 밸런싱 규칙 |
무작위 | 무작위로 선택된 전략을 채택하십시오 |
라운드 로빈 룰 | 설문 조사 전략을 채택하십시오 |
리틀 룰 | 이 전략을 사용할 때는 재시험 조치가 포함됩니다 |
가용성 filterrule | 여러 연결 고장 및 과도한 요청 동시성으로 서버를 필터링합니다. |
가중치 반응성 | 평균 응답 시간에 따라 각 서버의 가중치를 설정 하고이 가중치 값에 따라 평균 응답 시간이 작은 서버를 선택하십시오. |
ZoneAvoidancerule | 요청과 동일한 영역을 가진 서버에 요청을 할당하는 데 우선 순위가 부여됩니다. |
다음 iruledemo.java 프로그램에서 Irule의 기본 사용법을 살펴 보겠습니다.
// 필요한 패키지를 생략하고 코드 가져 오기 공개 클래스 IRULEDEMO {public static void main (String [] args) {// 이것은 iloadbalancer 인터페이스가 아닌 Baseloadbalancer에 사용됩니다. // 폴링 irule 규칙을 기반으로로드 밸런싱 정책을 선언합니다. // 정책 loadBalancer.setRule (RUL)을 설정합니다. // 3 서버를 다음과 같이 정의하고 목록 유형 목록 <Server> myServers = new ArrayList <Server> ()에 넣습니다. 서버 S1 = 새 서버 ( "ekserver1", 8080); 서버 S2 = 새 서버 ( "ekserver2", 8080); 서버 S3 = 새 서버 ( "ekserver3", 8080); myservers.add (S1); myservers.add (S2); myservers.add (s3); // 서버의 목록을 설정하면 loadbalancer.addservers (myservers); // (int i = 0; i <10; i ++) {Server s = loadBalancer.chooseserver (null); System.out.println (s.gethost () + ":" + s.getport ()); }}}이 코드는 위의 기사에서 iloadbalancerdemo.java와 매우 유사하지만 다음과 같은 차이점이 있습니다.
1 라인 5에서 클래스에는 setrule 메소드가 포함되어 있기 때문에 인터페이스 대신 Baseloadbalancer 클래스를 통해로드 밸런서를 정의합니다.
2 라인 7의 폴링 규칙에 따라 규칙 객체를 정의하여 9 행의로드 밸런서로 설정하십시오.
3 라인 19에서, 우리는 3 개의 서버를 포함하는 목록 객체를 이전 두 대신로드 밸런서에 넣습니다. 시연 목적으로 여기에 저장되므로 전혀 존재하지 않는 "ekserver3"서버를 넣을 것입니다.
프로그램을 실행 한 후 10 개의 출력이 있음을 알 수 있으며 실제로 "폴링"규칙에 따라 3 개의 서버의 이름을 순서대로 출력합니다. 7 행의 코드를 다음으로 변경하면 서버 이름이 "무작위로"출력됩니다.
irule rule = new RandomRule ();
3 iping : 서버를 사용할 수 있는지 여부를 결정하는 인터페이스
이 프로젝트에서는 일반적으로 Iloadbalancer 인터페이스가 서버를 사용할 수 있는지 자동으로 결정할 수 있도록합니다 (이러한 서비스는 리본의 기본 코드에 캡슐화됩니다). 또한 리본 구성 요소의 IPIP 인터페이스를 사용 하여이 기능을 구현할 수도 있습니다.
다음 iruledemo.java 코드에서는 IPPER 인터페이스의 일반적인 사용법을 보여줍니다.
// 필요한 패키지를 생략하고 코드 클래스를 생략하고 CODE CLASS MYPING IMPERMENTS IPING {public boolean isalive (Server Server) {// 서버 이름이 ekserver2 인 경우 retud false if (server.gethost (). equals ( "ekserver2")) {return false; } true를 반환합니다. }}2 행에 정의 된 Myping 클래스는 IPPER 인터페이스를 구현하고 3 행에서 ISALive 메소드를 대체합니다.
이 방법에서는 서버 이름을 기준으로 판단합니다. 구체적으로, 이름이 ekserver2 인 경우 false를 반환하므로 서버를 사용할 수 없음을 의미합니다. 그렇지 않으면 true를 반환하므로 현재 서버를 사용할 수 있습니다.
public class iruledemo {public static void main (String [] args) {Baseloadbalancer loadbalancer = new Baseloadbalancer (); // iping type iping myping = new myping ()의 iping 객체를 정의합니다. // myping 객체를 사용합니다. loadBalancer.setping (myping); // 3 개의 서버 객체를 만들고로드 밸런서 목록에 넣습니다. <Server> myServers = new ArrayList <Server> (); 서버 S1 = 새 서버 ( "ekserver1", 8080); 서버 S2 = 새 서버 ( "ekserver2", 8080); 서버 S3 = 새 서버 ( "ekserver3", 8080); myservers.add (S1); myservers.add (S2); myservers.add (s3); loadbalancer.addservers (myservers); // (int i = 0; i <10; i ++) {server s = loadbalancer.chooseserver (null); System.out.println (s.gethost () + ":" + s.getport ()); }}}12 행의 주요 함수에서, 우리는 15 행에 iping 유형 마이핑 객체를 생성 하고이 객체를 17 행의로드 밸런서에 넣습니다. 18 ~ 26 행의 코드를 통해 세 개의 서버를 생성하고로드 밸런서에도 넣습니다.
28 행의 FOR 루프에서 우리는 여전히 서버 이름을 요청하고 출력합니다. 여기에로드 밸런서에는 IPing 유형 객체가 포함되어 있으므로 정책에 따라 서버를 얻은 후 MyPing의 Isactive 메소드를 기반으로 서버를 사용할 수 있는지 여부를 결정합니다.
이 방법에서 서버 ekserver2를 사용할 수 없음을 정의하기 때문에로드 밸런서로드 볼 캔자 객체는 요청을 서버로 보내지 않습니다. 즉 출력 결과에서 "ekserver2 : 8080"의 출력은 표시되지 않습니다.
이것으로부터 우리는 iping 인터페이스의 일반적인 사용법을 볼 수 있습니다. isalive 메소드를 다시 작성하여 "서버를 사용할 수 있는지 판단"의 논리를 정의 할 수 있습니다. 실제 프로젝트에서 판단의 기초는 "서버가 너무 오랫동안 응답하는지"또는 "서버로 전송 된 요청 수가 너무 많는지 여부"에 지나지 않습니다. 이러한 판단 방법은 IRULE 인터페이스 및 구현 클래스에 캡슐화되므로 일반적인 시나리오에서는 IPPER 인터페이스를 사용합니다.
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.