当前位置:网站首页>Thinking about quarkus

Thinking about quarkus

2021-05-04 16:52:07 Jiedao jdon

Quarkus, This new “ Supersonic , Subatomic ”Java Frameworks are getting a lot of attention right now . Use Quarkus What are the advantages and disadvantages ?

Get rid of the dynamic

Quarkus Think , In a containerized world , Enterprises Java Most of the dynamic features of the runtime are not really needed . After building the application into the container image , It doesn't usually change features . All the dynamics that enterprise containers bring allow for very powerful and flexible programming and deployment models , But once our application starts in the container , They usually don't change anymore .

Quarkus The approach is to customize a runtime that contains only what the application needs , And simplify most of the dynamics of enterprise runtime . Enterprises Java Code relies heavily on inversion of control (IoC), also called “ Don't call us , We will call you ”. Think about dependency injection  @Inject,HTTP Resources @Path and @GET, Or event observers @Observes. We developers declaratively specify what should happen , And make sure it happens . This can have a very efficient programming model , But it also brings heavy work at runtime , Because someone has to put all these loose ends together . Now? , Our idea is , If our application should not mutate at runtime , So most of the dynamics can be solved at build time . The result code can mainly include direct call ;  All the magic was destroyed .

Quarkus Also supports the use of GraalVM Build native executables . In this way , We use advance (AOT) Compile to pre build and compile our application into the native executable , These executables don't need to scan dynamically and load all classes into JVM in . And Convention JVM comparison , The generated executable starts very fast , And the resource consumption is low .

The power of standards

have a look Quarkus, What I find most fascinating is that it's built on known enterprise standards , for example CDI,JAX-RS wait . We're not using mature application servers , But through the native executable or using Java The runtime runs the application in an optimized runtime .

Many enterprise development frameworks require developers to learn new API, Sometimes even less , Or reinvent the wheel , For example, how to achieve REST Endpoint . however , From a developer and project perspective , When the existing API And solutions are enough , I don't see the benefits of relearning and rewriting applications . adopt Quarkus The method adopted , Developers can write and get the CDI,JAX-RS and JPA Applications for , And by changing the runtime to Quarkus To optimize it .

Enterprises Java An extension of

except Java Enterprise Beyond the content contained in ,Quarkus It also extends the available functions that may be needed in the project . Except for the supported Java EE and MicroProfile Beyond the norm , There's also for responsive messaging Quarkus Expand ,Vert.x or Camel.EventBus for example ,Vert.x The type of is injectable @Inject. This is in line with the fact that we are in EE The experience of developers used to .

I like to learn from known businesses API The way to start , And extend them to what your application needs by maintaining the same declarative methods .

No server enterprise Java

Quarkus One of the unique selling points of , The machine is running Java Applications are extremely short startup times . Just as seriously , Everything that starts in a few milliseconds is a game converter of demand , We need to quickly start and dismantle our applications .

This is still the other fit for almost all Java One of the biggest limitations of the world . In terms of performance ,JVM It takes a lot of time to start , Not to mention preheating HotSpot Engine and achieve its full throughput . Very fair , There's a reason , Because the runtime optimizes the throughput of long-running processes . With the need for applications to start quickly , And a quick start so users can wait for it , Just start in the normal way JVM It's not enough. .

As mentioned above AOT The compiler method enables us to compile Java Write applications when they execute as native images . By doing so , We make our Java The workload can be “ There is no server ” Execution in the environment , We can scale the workload to zero , And it can start quickly without punishing users in the initial startup time .

However , Usually , In practice, life is not so easy .GraalVM Regular... Is not supported JVM The entire feature set of , for example , It doesn't support... In the usual way Reflection, And many enterprise runtimes don't run as native executables .

That being the case , By developing an implementation with this runtime constraint ,Red Hat My friends for Quarkus How much work has been put into the development of , It's impressive . Only in this way can we combine these parts and run our Java Enterprise Applications .Quarkus Application in common JVM Up running well , Starting speed “ Fast enough ”, At least in my opinion , In less than a second .

Although for Enterprise Java It's all good news for me , And it's required to shrink to zero and therefore start quickly , From my point of view , Startup time is not everything . Although this new sport is certainly interesting , But we should not forget , Most businesses are running , And may continue to run their workload longer . However , Get rid of most... At run time “ dynamic ” It also has a positive impact on overall resource consumption , And there must be hope .

however , in my opinion , Native boot time is not even the biggest benefit .

Minimum turnaround time

Quarkus Allows our developers to modify and test our business code through extremely fast hot reloading .quarkus:devMaven The goal of the plug-in is to enable us to change and save files , The framework reloads classes and automatically exchanges behavior within running applications . We can in a few milliseconds , That is, in human reaction time , Immediately re execute and test the changed function . therefore , The turnaround time of the development cycle and feedback loop is getting shorter and shorter . Just like my friend Edson · What Yanaga said :“ That's the coding , Inspired joy ”. I totally agree .

in general , I'm a big fan of the short delay . The battle delay mantra is what I think makes a lot of Google The fun of using services . Generally speaking , When coding , We want to get and stay in the process . Developers' thinking time is precious , We don't want to be interrupted by this process and wait more than a few seconds ;  Otherwise one will be distracted , Pick up another cup of coffee , Or worse , On social media , And get your attention .

in my opinion , This The minimum turnaround time is Quarkus The biggest advantage of the framework . however , Even without Quarkus, If you use modern application containers and tools , You can also achieve hot redeployment time , So as to maintain the streaming development mode . for example ,Open Liberty Applications can be deployed in less than a second , When and WAD And so on , We can really improve turnaround time , Such as This video describes .

Some notes on integration testing : There is also a very useful point , Whole Quarkus The quick start of the application makes testing actually more suitable for deployment level integration testing , Not at the code level . in other words , Deploy a single application using the application's communication interface and conduct end-to-end testing . however , One of the main reasons for the slow build time is the long running test phase , That is to start the application or part of the application . single . test run . Even if Quarkus The startup time provided is very short , And the impact will be huge , Once more and more test scenarios become part of the pipeline . What should we do , Generally speaking , Is to define a single or at most several deployments during the execution of our test suite , We test the application end-to-end , Without having to restart the running test application . Whether we use Quarkus The test function of , Or use a special test project to destroy the launched application .

Continuous delivery turnaround time

This organization has established alàGraalVM One of the disadvantages of this is that it takes a lot of time to build . Depending on your machine, 30 seconds or more . Even more than we are in Java The world should be used to longer . In our development process , That means we don't want to be just Continuous Delivery Each code change in the pipeline is performed by our organization . Even so , We also need to consider that this will slow down our overall pipeline execution time , Otherwise, it can be executed faster . Follow the mantra of building our application only once and testing it thoroughly before we go into production , It means end to end / System / Acceptance test turnaround time will also increase .

In addition to the native executable ,Quarkus It also supports thin deployment artifacts , As thin JAR, It contains only the actual business logic classes developed by us .Quarkus This can be done , Because it separates the focus of the library from our own code . Look at the built-in size and content *-runner.jar. The implementation and required libraries are included in lib/ Catalog . And Convention Java Enterprise The application is the same , This allows us to take advantage of... By optimizing the copy file system image layer at write time Docker The advantages of .

If you know something about these mirror layers , You will find this in Docker It does make sense in a globalized world . The build and transfer time of container image will also affect the whole build execution time . under these circumstances , Thin deployment artifacts provide the best experience . According to my experience , The overall mirror size is rarely important ;  What matters is how quickly we can rebuild and retransmit the layers that actually change . Even with tiny native images , Compared to thin deployment artifacts , These sizes and times are still orders of magnitude larger .

In the project , We need to trade off between pipeline execution time and container start time . In addition to extending to zero , Deployment scenarios should use some form of blue-green deployment , To avoid user downtime . Consider this , Production start-up time becomes less problematic , Because the old version will always remain active , Until the new version is ready to roll . If you're involved in an enterprise project with enough users , So that you don't have to think about scaling to zero , But quickly release the new version to production , Then it may be more appropriate to streamline the deployment of artifacts .

The current limitations

One of the limitations of the current framework is Quarkus We don't support some EE The standard set . for example , I won't support it EJB. however , Support transactions , Other functions can be used Quarkus Their own functions replace . One example is scheduling Quarkus Publish your own @Scheduled notes . It seems to be a reasonable way , Trying to implement functions that the project may need , And from my point of view, provide a framework that already supports most of the required functions .

However ,Quarkus We're moving very fast , So let's see how these gaps close . Once again, , I believe this framework is mature and detailed , It's very impressive .

Maven Plug in declaration , Especially how it works in Quarkus Advertising in documents is something else that can be improved . A lot of people seem to like to put a lot of XML Into it pom.xml, however , I don't have that much . I prefer to keep Java A clear separation of application concerns , Rather than let Maven“ Build everything ”. If we allow projects to use Maven The default value of , We will need LoC Stay in pom.xml At least , And let everything be written by CI Infrastructure processing . Use Quarkus, You can at least get rid of most of it pom.xml Definition , And only in CI Defining and building native images in pipelines . Then you can pom.xml To sum it up a little bit .

however , The document promises to have a local CLI“ Soon to launch ”, That sounds promising .


Quarkus Bring the cloud to the original Enterprise Java To a new level , And support solutions that couldn't be implemented before , Especially when it comes to application startup time . If you plan to scale to zero , So this is definitely the technology you want to understand .

I like it very much Quarkus How to follow up some of the techniques used before , Further more , And provide a single framework , An umbrella . This makes it easy for developers to get started , Use enterprise standards that they may already be familiar with , for example CDI or JAX-RS. in my opinion , This is a great advantage : Not trying to reshape the corporate world , Using familiar technology , But through highly optimized implementation .

As a developer , I find AOT Compilation and other JVM Optimization is generally very interesting . You may also have a look at OpenJ9 JVM And its optimization ;  Connect the runtime with Quarkus Application's JVM The combination of execution patterns can be interesting .

With “ Ordinary ”Java EE Fast turnover developer experience , You can view WAD as well as How to integrate it To Docker in .

本文为[Jiedao jdon]所创,转载请带上原文链接,感谢