6
포트 바인딩에 대한 12 팩터 기사에서 http://12factor.net/port-binding 모든 앱 은 자체 포함되어 있고 런타임이 삽입되지 않아야한다는 요구 사항이 있습니다. 수코양이. 에 대한 이유는 무엇입니까? 마이크로 서비스를위한 자체 포함 앱의 장점은 무엇입니까?왜 12 팩터 앱 자체가 포함되어야합니까?
A
답변
3
내 생각 엔 응용 프로그램을 확장 할 시간이되면 유연성이 뛰어나다 고 생각합니다. 바람둥이를 사용하는 경우 .war를 복사하여 다른 바람둥이에 넣은 다음 두 가지 중 하나로 부하를 분산시켜야합니다.
대신 앱에 자체 http 서버가있는 경우 다른 포트에서 다른 인스턴스를 실행하고 그 모든 바람둥이 관련 정보를 잊어 버릴 수 있습니다. 요청을 여전히 앱 인스턴스 중 하나에로드 밸런싱해야하지만 훨씬 간단합니다.
7
포트 바인딩 및 자체 포함 앱에 대한 규칙을 이해하려면 Heroku 또는 Deis과 같은 12 요소 앱을 실행하도록 설계된 플랫폼의 관점에서 볼 때 도움이됩니다.
이러한 플랫폼은 프로세스 수준에서 확장 응용 프로그램입니다. 프로세스가 확장되면 플랫폼은 이러한 추가 작업자를 라우팅 메시 뒤에 배치하여 트래픽 처리를 시작할 수 있습니다. 응용 프로그램이 자체 포함되어 있지 않고, 예를 들어 mod_jk을 사용하는 프런트 엔드 Apache 서버에 밀접하게 연결되어있는 경우, 더 격리 된 작업자 프로세스를 실행하여 확장 할 수 없습니다.
플랫폼 수준에서 "포트 중개"문제를 해결하기 위해 포트 바인딩이 있습니다. 모든 응용 프로그램 작업자가 포트 80에서 수신 대기하면 충돌이 발생합니다. 이 문제를 해결하기 위해 포트 바인딩은 응용 프로그램이 플랫폼이 할당 한 포트에서 수신 대기하고 - $PORT 환경 변수로 전달되는 규칙입니다. 이렇게하면 a) 응용 프로그램 작업자가 올바른 포트에서 수신 대기하고 b) 플랫폼이 해당 작업자로 향하는 트래픽을 어디로 라우팅 할지를 알 수 있습니다.
임베디드 톰캣 또는 임베디드 부두를 사용하여 서비스를 노출 할 수 있습니다. –