Java "savior" in the cloud native era
In the cloud-native era, Java programs actually have a big disadvantage. Taking the most popular spring boot/spring cloud microservice framework as an example, it takes at least 3-4 seconds to start an application that has been optimized and many beans require lazy load. Time, the memory needs hundreds of M, and the business logic is a little more complicated. Without more than 1G of memory, it is difficult to meet the needs of the business?
Before discussing Quarkus, let's first understand what cloud native is. Why is Quarkus the next generation Java cloud native service?
Introduction to Cloud Native Architecture
Cloud Native (cloud native), this is a strange and familiar term, it is a concept proposed by Matt Stine , it is a collection of ideas, including: DevOps, Continuous Delivery (Continuous Delivery), Microservices (MicroServices), Agile Infrastructure, Conways Law, etc.
To be precise, Cloud Native is also a culture and a trend. It is an inevitable direction of cloud computing. Its significance is to make the cloud the cornerstone of the success of the cloud strategy, rather than an obstacle.
Features and aspects of Cloud Native:
- Technology (microservices, agile infrastructure)
- Management (DevOps, Continuous Delivery, Conway's Law, Restructuring, etc.)
Cloud Native can also be said to be a collection of a series of Cloud technologies and enterprise management methods.
Definition and concept of Cloud Native
Cloud Native (cloud native) is a collection of better tools, self-healing systems, and automated systems that can make deployment and fault repair of applications and infrastructure faster and more agile, and greatly reduce the deployment cost of cloud computing for enterprises .
Currently recognized in the industry, cloud native mainly includes the following levels.
- Containers, service grids, microservices, immutable infrastructure, and exposed APIs are all close to cloud-native related concepts.
- Cloud native technology can make the system loosely coupled, support elastic scaling, manageable, and clear.
With the evolution of container, kubernetes, Serverless, and FaaS technologies, CNCF (Cloud Native Computing Foundation, Cloud Native Computing Foundation) defines the concept of cloud native more broadly as "the basis for making applications more elastic, fault-tolerant, and observable." Technology, the basic software that makes it easier to deploy and manage applications, the running framework that makes it easier to write and orchestrate applications, etc.", hoping to enable developers to make the best use of cloud resources, products, and delivery capabilities.
The development history of cloud native
- From 2004 to 2007, Google has used container technologies such as Cgroups on a large scale internally;
- In 2008, Google merged Cgroups into the Linux kernel backbone.
- In 2013, the Docker project was officially released.
- In 2014, the Kubernetes project was also officially released.
- The reason for the release of the Kubernetes project is also very easy to understand, because with containers and Docker, there needs to be a way to help everyone manage these containers conveniently, quickly, and elegantly. This is the original intention of the Kubernetes project. After the release of Kubernetes by Google and Redhat, the development of this project has been very fast.
- In 2015, CNCF was established.
- The CNCF Cloud Native Foundation was established jointly by large cloud computing vendors such as Google, Redhat, and Microsoft, as well as some open source companies. When CNCF was founded, there were 22 founding members, and Kubernetes became the first open source project hosted by CNCF.
- In 2017, CNCF reached 170 members and 14 fund projects.
- In 2018, the third anniversary of CNCF has 195 members, 19 foundation projects and 11 incubation projects. Such a fast development speed is very rare in the entire cloud computing field.
Ecological Status of Cloud Native Technology
Therefore, the cloud native technology ecosystem we are discussing today is a huge collection of technologies. CNCF has a cloud-native panorama ( github.com/cncf/landsc… more than 200 projects and products, and these projects and products are also in line with CNCF's point of view. So if you use this panorama as the background, add If you think about it, you will find that the cloud native we are discussing today mainly talks about the following points:
Cloud Native Foundation - CNCF
CNCF is currently one of the most successful open source foundations in the field of cloud computing. It is the hosting foundation for well-known open source projects such as Kubernetes, etcd, and Envoy.
Cloud Native Technology Community
For example, multiple projects currently officially hosted by CNCF together form the cornerstone of the modern cloud computing ecosystem. Among them, projects like Kubernetes have become the world's leading and very active open source projects; there are currently many projects that have graduated from CNCF, such as Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd.
Principles of Cloud Native Service Architecture
Principles of High Availability Architecture Design
- Observable: Through the operation status and data analysis, the operation status and operation data analysis in the observable mode can be realized.
- Grayscale: It can realize blue-green release, AB test, canary release mechanism, etc., and realize flow control of data services.
- Rollback: The fallback and reback rollback methods of the service can be realized.
Design Principles for Improving Architecture Availability
- Decoupling: message queues, distributed queues, service splitting
- Redundancy: remote disaster recovery, multi-point deployment, master-slave switching
- Heterogeneity: sidecar mode for analysis and implementation
- Asynchronous: message queue, asynchronous call, reactive programming
Microservice Design Principles
Stealing one of the official pictures:
Principle One: Integrity
Functional integrity: the internal logic of the function is independent, and there are fewer external dependencies.
Microservice integrity: Each microservice in the service should be able to independently complete specific business operations or processes, with clear input, output, and processing logic.
Principle Two: Technical Limitations
Functions that need to use transactional consistency need to be placed in a microservice to avoid distributed transaction problems as much as possible.
Principle 3: Performance Expansion
For functions that are frequently used by users and have high performance requirements, they can be used as a separate microservice for multi-node expansion to improve performance.
Principle 4: Coupling
Microservices and microservices should try to avoid mutual call dependencies. The interface can be called remotely through RPC, and functions with high correlation should be placed in the same microservice.
Functionality for common use can be designed in a common microservice. For example, the log function, file upload function, and some underlying technical components can be designed in a microservice.
Come back to Quarkus
Quarkus Cloud Native Standards
Quarkus works with common Java standards, frameworks and libraries such as Eclipse MicroProfile, Spring (demonstrated as part of the Red Hat Summit 2020 track), Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA), Spring , Infinispan, Camel, etc.
Quarkus context and dependency injection
Quarkus' dependency injection solution is based on CDI (Context and Dependency Injection) and includes an extension framework to extend functionality and configure, bootstrap, and integrate it into your application. Adding extensions is as easy as adding dependencies; alternatively, you can use the Quarkus tools.
Quarkus multilingual extension support
It also provides the correct information to GraalVM, a general-purpose virtual machine for running applications written in many languages, including Java and JavaScript, to natively compile applications.
Incredibly fast startup times, extremely low RSS memory (not just the heap size!) provides near-instant scale-up and high-density memory utilization in container orchestration platforms such as Kubernetes
dual-mode operation
The design of Quarkus has been based on simplicity and ease of use from the beginning, and its functions can be used normally without configuration.
Developers can choose the required Java framework for their applications, and these applications can run in JVM mode, or they can be compiled and run in native mode.
To facilitate developers' work, Quarkus also includes the following features:
- Live coding, designed to allow developers to instantly inspect the impact of code changes and troubleshoot quickly
- Unified imperative and reactive programming with embedded managed event bus
- Unified configuration
- Simple native executable generation
container first
Whether you host your application on a public cloud or in an in-house Kubernetes cluster, features such as fast startup and low memory consumption are critical to reducing overall hosting costs.
Quarkus has been developed container-first , which means it has been optimized for low memory usage and fast startup times in the following ways:
- Full support for Graal/SubstrateVM
- Build-time metadata handling
- Reduced use of reflection
- Native Image Preboot
As a result, applications built with Quarkus consume only 1/10 the memory of traditional Java and have faster startup times (300 times faster), which greatly reduces the cost of cloud resources.
Quarks Six Steps
- Quickly build an application microservice skeleton belonging to Quarkus (laying the foundation for building application services)
- Quarkus microservice application (development mode) realizes real-time hot deployment capability (changes take effect in real time)
- Develop related program codes by integrating multiple open source libraries and related business requirements
- After the development and coding are completed, the version is established, and the stage of integration testing at the development level is carried out
- Create CLI programs and create cloud-native executable package files, and create corresponding container services
- Directly integrate and deploy the corresponding cloud-native file package into the Kubernetes cluster
share resources
To obtain the above resources, please visit the open source project and click to jump