"오늘은 로드 밸런싱 구축의 날입니다.

소개하다.
로드 밸런싱은 백엔드 서버 그룹 간에 전송되는 네트워크 트래픽을 효과적으로 할당하는 방법입니다. 따라서 일반적으로 서비스에서는 클라이언트가 있고 클라이언트의 요청을 처리하는 서버가 있습니다. 확장을 원할 때 클라이언트가 서비스를 받을 수 있도록 더 많은 서버를 추가하기만 하면 됩니다.로드 밸런서는 클라이언트로부터 요청을 받고 이를 서버로 라우팅하여 이 프로세스의 중간에 놓임으로써 속도를 최적화하고 효율적으로 활용하는 방식으로 이를 실현하며 서버 중 한 대가 고장나도 일이 정상적으로 진행될 수 있도록 한다.
내가 읽은 아주 멋진 유형은 지원 센터이다. 우리는 고객이고 지원 인원은 서버이다. 우리가 그들에게 전화를 할 때, 전화선은 본질적으로 부하 균형기이다. 왜냐하면 우리의 호출 경로를 사용할 수 있는 지원 인원 중 한 사람에게 전달해야 하기 때문이다.
이제 우리는 부하 균형기가 부하를 분배하는 것을 알았으니, 부하를 어떻게 분배하는지 이야기합시다

리그전
여기, 우리는 순서대로 서버 간에 부하를 분배한다.
이런 전략에서 우리는 모든 백엔드가 같은 처리 능력을 가지거나 처리 능력 설정에 대한 권한을 사용한다고 가정할 수 있다

최소 연락처
우리는 클라이언트와 가장 적게 연결된 서버를 더 좋아한다.각 서버의 상대적인 컴퓨팅 성능도 고려되어 가장 적은 수의 서버를 연결할 수 있음

최소 시간
공식이 선택한 서버에 요청을 보냅니다. 이 공식은
가장 빠른 응답 시간과 가장 적은 활동 연결.
우리는 사용자 정의 정책을 정의할 수 있다. 이것은 우리가 무엇을 하고 싶은지에 달려 있다. 나에게 있어서 이것은 주로 기본 상태로 돌아가는 것이다.

실행
그래서 저희의 최종 결과는 이렇습니다.
https://hub.docker.com/r/strm/helloworld-http/
이것은 Hello World 서버와 요청을 나누는nginx loadbalancer를 포함하는 docker compose 파일입니다. 따라서 새 것으로 바꾸기만 하면 됩니다.
실제 구축 전에 절차를 정의합시다

저희 서비스는 Huzzah를 실행하고 있습니다!!

Hoomans가 저희 서비스를 호출하기 시작했습니다. 때로는 여러 개, 때로는 동시 호출

모든 요청이 저희 서비스를 사용하는 사람에게 먼저 요청을 받고 요청 서비스를 필요로 하는 서버를 확정하기 시작했습니다. 저희는 magic()를 만들어서 데이터 서비스를 필요로 하는 서버를 얻었습니다(저희가 소개에서 마법에 대해 논의했습니다)

그리고 우리는 이 서버를 통해 데이터에 서비스를 제공합니다. 호만은 지금 매우 기쁩니다!!

우리 의 부하 균형기 를 명명하자. 하느님 이 영혼 과 그들 의 가치 를 잘 균형 을 맞췄기 때문 에, 나 는 당신 anubis을 선포한다
현재 명명식이 끝났습니다. 우리가 이전에 논의한 '마법' 을 실현하기 위해서는 모든 서버의 메타데이터가 필요합니다. 이 서버들은 실제적으로 요청에 서비스를 제공하고 있습니다. 예를 들어 활동 여부, 계산 능력, 클라이언트와의 연결수, 심지어 더 많습니다.

# Servers have the same computing capacity
class Server:
    url: str # localhost:8080
    alive: bool # Dead or Alive

마지막으로, 우리는 클라이언트를 위해 서비스할 수 있는 서버 목록을 가지고 있을 것이다.[Server1, Server2, Server3] <========>✨ 매직✨ <========> Route to Server1이 마법을 쓰자. 우리는 이성을 유지하기 위해 Strategy라고 부른다.

class Strategy:
    servers = [Server1, Server2, Server3]
    alive_servers = get_alive_servers(servers)
    def round_robin(self):
        robin_goes_round(self.alive_servers)

마지막 단계는 클라이언트 루트를 사용하여 출력으로 되돌아오는 서버입니다. 이를 위해 우리는 간단한 역방향 에이전트를 사용합니다. 이것은 부하 균형기와 유사합니다. 기본적으로 클라이언트의 요청을 받아들여 요청을 완성할 수 있는 서버로 전송하고 서버의 응답을 클라이언트에게 되돌려줍니다.서버가 한 대일 때, 역 에이전트를 배치하는 것은 보통 의미가 있습니다. 왜냐하면 요청을 나누어 줄 필요가 없기 때문입니다.
https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/
우리는 requests로 간단한 역방향 에이전트를 작성할 수 있다

"""Reverse Proxy."""
import http.server  
import socketserver
from requests import Session
class Handler(http.server.BaseHTTPRequestHandler):
  session = Session()
  def do_GET(self):
    resp = session.get("www.google.com", allow_redirects=True)
    self.send_response(resp.status_code)
    self.send_header('Content-Length', len(resp.content))
    self.end_headers()
    self.wfile.write(resp.content)
# Fetches content from localhost:8000
httpd = socketserver.TCPServer(('', 9000), Handler)
httpd.serve_forever()

이 프로그램을 실행하면localhost:8080으로 이동하면 구글로 다시 지정됩니다!구글은 내 로컬 호스트에서 실행된다.엄마 인터넷 가.그러나 이것은 GET 요청과 동적 요소가 없는 페이지에서만 일하는 매우 어리석은 역방향 에이전트이다
그러나 나는 왜 우리가 방향을 바꾸지 않는지, 역방향 대리와 무엇이 다른지 질문이 있다.나는 인터넷에서 Stackoverflow에 대한 설명을 찾았다.따라서 리셋을 통해 서버는 클라이언트에게 다른 곳에서 자원을 찾으라고 알려준다.고객은 이 새로운 위치를 알게 될 것이다.새 위치는 클라이언트에서 접근할 수 있어야 합니다.반대로 역방향 에이전트는 클라이언트의 요청을 다른 위치로 전송하고 이 위치의 응답을 클라이언트에게 보냅니다.이것은 클라이언트가 새로운 위치를 모르고 클라이언트가 직접 새로운 위치에 접근할 필요가 없다는 것을 의미한다
비밀번호
나는 즉시 파이톤의 http를 알아차렸다.서브 속도가 매우 느려서 내가 여러 개의 라벨을 열려고 했을 때, 그것은 내 몸에서 사라졌다. 이것은 좀 엉망이었다. 이것은 내가 ThreadedHTTPServer 와 ForkingMixIn 을 발견했을 때였다.따라서 우리는 여러 개의 루트나 프로세스를 생성하여 요청을 처리할 수 있다https://github.com/Sangarshanan/anubis
지금은 좀 나아졌지만 무섭지도 않아요. 우리는 https://pymotw.com/2/BaseHTTPServer/index.html#module-BaseHTTPServer 이런 물건을 비동기 IO를 충분히 이용하여 요청을 병발 처리해야 해요.우리는 이렇게 많은 서열화 요청을 확장할 수 있을 뿐이고python을 사용하면 GIL에 의해 항상 막히기 때문에 이것은 완벽한 선택이 아니지만, 여전히 재미있는 연습이다.
https://github.com/http-party/http-server
수영 선수

https://www.nginx.com/resources/glossary/load-balancing/