수동 소득 아이디어 2023
그럼에도 불구하고 Spring의 프로그래밍 모델과 부분적으로는 구문도 유지되어야 합니다. 이는 AoC(Ahead of Time Compilation)를 사용하는 기본 플랫폼으로 GraalVM에 중점을 두어 가능합니다.
Spring – 함정이 있는 효율적이고 수용 가능한 프레임워크
Spring Framework는 15년 이상 전 세계의 소프트웨어 개발자에게 영감을 주고 있습니다. Spring의 역사는 Java Enterprise 솔루션의 상대적으로 복잡한 개발에 대한 대안을 만들겠다는 주장으로 시작되었습니다.
이 기본 원칙은 복잡한 구성이 필요하지 않은 간단한 프로그래밍 모델을 제공하는 것이었습니다. Spring은 최근 몇 년 동안 이러한 요구 사항을 확실히 충족했으며 Java Enterprise 애플리케이션에 가장 널리 사용되는 프레임워크 중 하나를 제공했습니다.
그러나 소프트웨어 개발의 최적화 개념은 커뮤니티에서 널리 수용되는 Spring의 효율적인 프로그래밍 모델에도 불구하고 해결되지 않은 단점을 드러냈습니다. 이러한 단점은 Spring이 내부적으로 사용하는 Java Reflection API의 자유로운 사용으로 광범위하게 추적될 수 있습니다.
여기에는 대규모 엔터프라이즈 응용 프로그램의 일반적인 성능과 관련된 두 가지 주요 단점이 있습니다. 한편으로는 시작 시간이 길어지고 다른 한편으로는 런타임 시 더 높은 메모리 요구 사항이 발생합니다. Spring의 이러한 단점은 마이크로서비스 환경에서 특히 고통스럽습니다.
서버리스 및 IoT 영역에서 마이크로서비스로 사용하기 위한 Micronaut
이 시점에서 Micronaut가 무대에 들어갑니다. Micronaut는 이러한 문제를 피하고자 하므로 서버리스 및 IoT 영역에서 마이크로서비스로 사용하기에 이상적입니다.
Micronaut는 어떻게합니까?
리플렉션은 대체로 피하고 종속성 주입은 컴파일 타임에 발생합니다. 이것은 컴파일 시간이 더 길지만 시작 시간은 더 빠르고 응용 프로그램의 크기에 관계없이 일정하게 유지됨을 의미합니다. 런타임 중 메모리 소비도 훨씬 적습니다.
변경 사항에도 불구하고 Spring의 프로그래밍 스타일을 유지할 수 있습니다. 따라서 Spring에서 Micronaut로의 변경은 큰 문제 없이 가능합니다.
또한 Micronaut Framework는 리액티브 프로그래밍과 B. Service Discovery와 같은 클라우드 네이티브 기능을 지원합니다. 그러나 Micronaut Framework는 GraalVM의 도움을 받아야만 그 강점을 보여줄 수 있습니다.
GraalVM으로 Micronaut 최대한 활용
GraalVM은 최적화된 기계어 코드를 생성하는 개선된 JIT 컴파일러를 제공합니다. 따라서 JVM 애플리케이션의 최대 성능을 높일 수 있습니다. 그러나 여전히 긴 시작 시간과 높은 메모리 사용량이 있습니다.
따라서 Graal VM의 Ahead of Time 컴파일러를 사용할 가능성이 있습니다. 여기서 전체 소스 코드는 사전에 기계 코드로 변환됩니다. 이러한 소위 네이티브 이미지는 시작 시간이 훨씬 짧고 메모리 사용량이 훨씬 적습니다. 그러나 최적화로 인해 최대 성능이 저하될 수 있으며 예를 들어 반사를 사용할 때 몇 가지 제한 사항이 있습니다.
다음 그래픽에 설명된 이점은 특히 마이크로 서비스 및 서버리스 환경에서 매우 중요합니다.
이 프레임워크는 마이크로서비스 아키텍처 또는 서버리스 인프라에서 사용하기 위해 개발되었습니다. 위에서 설명한 것처럼 이것은 GraalVM과 관련하여 매우 성공적이었으며 수많은 이점과 새로운 기능으로 이어졌습니다.
모든 크기의 애플리케이션은 시작 시간과 메모리 소비가 매우 낮은 반응성 스택을 사용하여 평소와 같이 개발할 수 있습니다. 또한 기본 제공 기능은 클라우드 환경용으로 개발할 때 도움이 됩니다.
Micronaut 대 Spring 대 Quarkus – 비교
마이크로넛의 단점
Micronaut는 여전히 일부 영역에서 따라잡아야 할 부분이 있습니다.
일반적으로 Spring보다 적은 기능을 제공합니다. 예를 들어 이것은 Hibernate에서 눈에 띕니다. Spring과 같은 확립된 프레임워크에서 사용했던 전체 기능은 아직 여기에서 사용할 수 없습니다. 또한 속성 및 구성에 대한 옵션은 그다지 광범위하지 않습니다.
빌드 도구에는 단점도 있습니다. 여기에서 Maven 지원은 일반적으로 마이너 버전에 의해 Gradle보다 뒤떨어집니다. 또한 Maven 구성은 Micronaut가 Kotlin 및 Graal VM과 결합될 때 복잡성이 증가함을 보여줍니다. Gradle을 사용하면 좀 더 쉽게 할 수 있을 것 같습니다.
물론 Ahead of Time 컴파일의 장점은 특히 대규모 애플리케이션의 경우 컴파일 시간이 길어진다는 단점으로 가려집니다. 이것은 때때로 대규모 프로젝트에 많은 시간을 의미할 수 있습니다. Micronaut를 작고 가벼운 애플리케이션으로 적절하게 사용한다면 이러한 단점은 그리 심각하지 않다는 점에 유의해야 합니다.
불행하게도 GraalVM의 지원은 아직 100% 완성되지 않았습니다. 최근에야 공식적으로 생산 준비 상태로 분류되었으며 버그를 배제할 수 없습니다.
Micronaut 및 Kotlin – 개인적인 경험
우리는 프레임워크 분석을 위한 프로그래밍 언어로 Kotlin을 사용했으며 확실히 추천할 수 있습니다. 언어의 기능은 Micronaut의 프로그래밍 모델과 완벽하게 일치합니다. 빌드 도구로서의 Gradle과의 연결도 좋은 조합으로 밝혀졌습니다. Java만 사용했을 때와 비교할 때 코드 줄이 줄어든다는 점은 Kotlin으로 전환하는 데 좋은 근거가 됩니다. 그러나 코루틴 및 단순화된 null 안전과 같은 수많은 기능은 개발자의 삶을 더 쉽게 만듭니다.
짧은 요약
경량 마이크로서비스 애플리케이션을 위한 Java 환경에서 새로운 기술이나 대안을 찾고 있다면 연구에서 Micronaut Framework를 잊어서는 안 됩니다.
이 프레임워크는 바로 여기에서 Spring의 좋은 대안이 되기 위해 노력하고 있으며 언급된 개선 사항과 기능을 통해 첫 번째 단계는 분명히 성공했습니다. Spring을 강력하게 만드는 커뮤니티는 아직 없으며 성숙도는 아직 Spring 수준에 미치지 못합니다.
그럼에도 불구하고 서로 대립할 필요는 없다. 두 프레임워크는 미래에 서로 엄청난 이점을 얻을 수 있습니다. 모든 마이크로서비스가 동일한 기술을 사용해야 하는 것은 아니기 때문에 개발자는 두 프레임워크를 병렬로 매우 쉽게 사용할 수 있고 애플리케이션 영역에 따라 변경할 수 있습니다.
Micronaut 프레임워크는 자세히 살펴볼 가치가 있으며 Spring에서 전환하는 것은 정말 쉽습니다.
