우리의 미래 아키텍처는 도커/마이크로 서비스로 이동하는 것입니다. 현재 우리는 JBoss EAP 6.4 (EAP 7로 업그레이드 할 가능성이 있음)와 Tomcat을 사용하고 있습니다.Docker 컨테이너에 더 적합한 응용 프로그램 컨테이너는 무엇입니까?
내게 따르면 JEE 컨테이너는 마이크로 서비스 환경에 비해 너무 무겁습니다 (느리고 더 많은 메모리, 높은 유지 관리 등). 그러나, 나는 EAP 7이 매우 빠르고 가벼우 며 마이크로 서비스를 개발하는데 사용될 수 있다고 들었다. Docker/Microservices 용 EAP 7 vs Tomcat 8 결정에 대한 귀하의 의견은 무엇입니까? 비용과 속도는 고려 대상입니다.
무거운 것이 아닌 기존의 Application Server를 사용하는 것 외에도 microcontainers라고 불리는 Java EE의 다양한 맛을 맛볼 수 있습니다.
Java EE는 일련의 표준입니다. API 사양의 표준 결과는 모든 사용자가 자유롭게 사양을 구현할 수 있습니다. AS (응용 프로그램 서버)는 주로이 기능의 세부 조정 모음입니다. 이러한 API는 아무런 이유없이 생명을 불어 넣지 않았습니다. 이들은 프로젝트에서 일반적으로 사용되는 기능을 나타냅니다. 응용 프로그램 서버는 이러한 기능의 "선별 된 집합"으로 볼 수 있습니다. 이 접근 방식에는 많은 장점이 있습니다. AS에는 많은 사용자가 있으므로 시간이 지남에 따라 잘 테스트됩니다. 기능을 직접 연결하면 버그가 발생할 수 있습니다.
어쨌든, Docker를 사용하면 응용 프로그램이 종속 된 새로운 시대가 도래했습니다. 대부분의 경우 응용 프로그램에 제공 할 수있는 모든 기능을 갖춘 완전한 응용 프로그램 서버가 더 이상 필요하지 않습니다. 과거에는 응용 프로그램 서버가 배포 할 응용 프로그램에 필요한 서비스를 정확하게 알지 못했습니다. 따라서 모든 것이 번들되었습니다. WildFly 같은 혁신적인 AS 중 일부는 필요한 서비스 만 인스턴스화했습니다. 또한 모노리스 Application Server를 약간 완화 한 Java EE 프로파일이 있습니다.
지금 우리는 일반적으로 응용 프로그램을 Docker 내부의 종속성 (JDK, 라이브러리, AS)과 함께 제공합니다. 또는 우리가 거기로 향하고 있습니다. 따라서 정확한 양을 묶으려는 노력은 논리적 인 선택입니다. 그러나 "큰 문제"이지만 AS의 기능에 대한 필요성은 여전히 적절합니다. 표준과 공통된 노력을 토대로 공통 기능을 개발하는 것은 여전히 좋은 생각입니다. 잠재적으로 API를 하나의 큰 패키지로 배포하여 대부분의 API를 비활성 상태로 남겨 둘 수있는 옵션이 아닌 것 같습니다. 이러한 노력은 수, 그것은 microcontainers, uberjar 제작자 ...
거기 아무것도를 사용하는 것이 의심 스럽다 자바 EE 서버가 너무 빛 그밖에. * 스프링 부트는 Java EE를 기반으로하지 않으며 시작 설명서에있는 기본 구성에서 Tomcat은 내부적으로 사용됩니다. WebSphere Liberty 중요한 점은
WildFly Swarm 또는 Payara Micro는 필요한 서비스 만 실행하는 응용 프로그램을 "검사"할 수 있습니다.실제 응용 프로그램의 경우 프로덕션 환경의 메모리 사용 공간은 실제 응용 프로그램의 경우 100MB 정도로 낮을 수 있습니다. 이것은 아마도 당신이 원하는 것입니다. Spring Boot가 필요한 경우 비슷한 일을 할 수 있습니다. 그러나 내 경험으로 볼 때 봄 부팅은 much more heavyweight이고 메모리는 현대 Java EE보다 굶주려 있으므로 분명히 스프링이 포함되어 있으므로 메모리 사용량면에서 seeking lightweigtness이면 Java EE, 특히 WildFly Swarm (또는 WildFly) 및 Payara 마이크로. 저것은 나의 마음에 드는 것 및 진짜로, 진짜로 작을 수 있는다. WildFly Swarm이 시작하기가 훨씬 쉽다고 Payala micro는 더 많은 독서가 필요하지만 흥미로운 기능을 제공합니다. 둘 다 래퍼로 작동 할 수 있습니다. 빌드 단계가 끝나면 현재 프로젝트를 래핑 할 수 있으며 아무 것도 변경할 필요가 없습니다.
Payara Micro even provides Docker images! 보시다시피, Java EE는 성숙해 Docker 토지를 입력 할 준비가되었습니다.
매우 우수하고 신뢰할 수있는 리소스 중 하나는 Adam Bien입니다 (예 : Java EE micro/nanoservices video). 봐.
, 제 생각에는 애플리케이션 서버/마이크로 서버/출시주기가 짧은 것이 Docker의 시대에 더 좋습니다. 개발자는 관리자와 달리 종속성을 빠르고 쉽게 교환 할 수 있습니다. 이렇게하면 최신 기능으로 업데이트 된 버전이 거의 즉시 생산에 들어갑니다. WildFly는 출시주기가 비교적 짧은 컨테이너 중 하나이며 다른 컨테이너는 확실하지 않습니다. –
WildFly는 연 2 회, WF는 연간 12x, Payara는 4x (지원 suscribers는 12x), TomEE는 4x로 매년 출시됩니다. 짧은 릴리스주기를 원한다면 요즘에는 다양한 옵션이 있습니다. – OndrejM
2 년마다 1 개의 주요 릴리스가 없으므로 이는 앞으로 전진 할 것입니다. –
EAP7 vs Tomcat 8은 여러 번 답변 된 답변입니다. here, here 및 here.
Tomcat은 EAP7이 지속성, 메시징, 웹 서비스, 보안, 관리 등과 같은 모든 Java EE 7 기능을 제공하는 응용 프로그램 서버 인 웹 컨테이너 일뿐입니다. EAP7은 웹 프로필과 전체 프로필의 두 가지 프로필 . 웹 프로파일은 많은 트리머 버전이며 일반적으로 웹 응용 프로그램을 작성하는 데 필요한 관련 구현 만 포함합니다. 전체 프로필은 기대했던대로 플랫폼의 완전한 영광을 담고 있습니다. 따라서 EAP 7 웹 프로파일을 사용하면 부풀어 오름을 상당히 줄일 수 있습니다.
Tomcat을 사용하면 동등한 기능을 제공하고 모든 관련 JAR을 응용 프로그램과 함께 패키징하기 위해 Spring과 같은 것을 사용해야 할 것입니다.
이 토론은 새로운 프로젝트를 시작하고 Java EE 또는 Spring 리소스를 모두 가지고있을 때 일반적으로 유용합니다. 다음은 EAP7 사용을 고려할 수있는 이유입니다.
TomEE도 고려해 볼 수 있습니다. Tomcat과 통합 된 Java EE 스택을 제공합니다.
@ Federico가 권장하는 또 다른 옵션으로는 WildFly Swarm을 사용하는 것이 좋습니다. 그런 다음 Java EE 플랫폼의 원하는 부분을 실제로 사용자 정의 할 수 있습니다. 또한 배포 모델에서 JAR 파일을 사용하고 있습니다.
Docker를 사용한 패키징은 모두 기본 이미지를 제공하므로 애플리케이션을 묶어야합니다. 도커 이미지의
저는 개인적으로 Tomcat/Spring보다 Java EE 스택에 익숙하며 WildFly는 자주 사용되는 응용 프로그램 서버입니다.
어쩌면 도움이 될 수 있습니다. http://wildfly-swarm.io 예 : https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/master/docker/docker-jaxrs –