云原生时代下的Java"拯救者"
在云原生时代，其实Java程序是有很大的劣势的，以最流行的spring boot/spring cloud微服务框架为例，启动一个已经优化好，很多bean需要lazy load的application至少需要3-4秒时间，内存需要几百M，业务逻辑稍微复杂一点点，没有1G以上的内存是很难满足业务的需要呢？
在讨论夸克斯（Quarkus）之前，我们先了解一下什么是云原生。为什么说下一代Java云原生服务就是Quarkus？
云原生架构简介
Cloud Native（云原生），这是一个既陌生又熟悉的名词，它是 Matt Stine提出的一个概念，它是一个思想的集合，包括： DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等。
Cloud Native（云原生）准确来说也是一种文化，更是一种潮流，它是云计算的一个必然导向，意义在于让云成为云化战略成功的基石，而不是障碍。
Cloud Native（云原生）的特点和方面：
- 技术（微服务，敏捷基础设施）
- 管理（DevOps，持续交付，康威定律，重组等）
Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。
Cloud Native（云原生）的定义和概念
Cloud Native（云原生）是更好的工具、自我修复系统、和自动化系统的集合，可以让应用和基础设施的部署和故障修复更加快速和敏捷，极大的降低企业在云计算方面的部署成本。
目前业界公认的云原生主要包括以下几个层面的内容。
- 容器，服务网格，微服务，不可变的基础设施，公开的API都接近云原生相关概念。
- 云原生技术可以让系统松耦合，支持弹性伸缩、可管理的、清晰的。
随着容器、kubernetes、Serverless、FaaS技术的演进，CNCF（Cloud Native Computing Foundation ，云原生计算基金会）把云原生的概念更广泛地定义为"让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等"，希望能够让开发者最好的利用云的资源、产品和交付能力。
云原生的发展历程
- 2004 年 ~ 2007 年，Google 已在内部大规模地使用像 Cgroups 这样的容器技术；
- 2008 年，Google 将 Cgroups 合并进入了 Linux 内核主干。
- 2013 年，Docker 项目正式发布。
- 2014 年，Kubernetes 项目也正式发布。
- Kubernetes项目发布的原因也非常容易理解，因为有了容器和 Docker 之后，就需要有一种方式去帮助大家方便、快速、优雅地管理这些容器，这就是 Kubernetes 项目的初衷。在 Google 和 Redhat 发布了 Kubernetes 之后，这个项目的发展速度非常之快。
- 2015 年，CNCF 成立。
- 由 Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了 CNCF 云原生基金会。CNCF 成立之初，就有 22 个创始会员，而且 Kubernetes 也成为了 CNCF 托管的第一个开源项目。
- 2017 年，CNCF 达到 170 个成员和 14 个基金项目。
- 2018 年，CNCF 成立三周年有了 195 个成员，19 个基金会项目和 11 个孵化项目，如此之快的发展速度在整个云计算领域都是非常罕见的。
云原生技术生态现状
因此，如今我们所讨论的云原生技术生态是一个庞大的技术集合。CNCF 有一张云原生全景图（github.com/cncf/landsc... 200 多个项目和产品了，这些项目和产品也都是和 CNCF 的观点所契合的。所以如果以这张全景图作为背景，加以思考就会发现，我们今天所讨论的云原生其实主要谈论了以下几点：
云原生基金会 —— CNCF
CNCF是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会。
云原生技术社区
比如像 CNCF 目前正式托管的多个项目共同构成了现代云计算生态的基石，其中像 Kubernetes这样的项目已经成为了世界首屈一指，非常活跃的开源项目；目前从 CNCF 毕业的项目有很多，例如Kubernetes 、Prometheus、Envoy、CoreDNS、containerd、Fluentd 。
云原生服务架构的原则
高可用架构设计的原则
- 可观测：可以通过运行状态和数据分析，实现可观测模式下的运行状态和运行数据分析。
- 可灰度：可以实现蓝绿发布、AB测试、金丝雀发布机制等，实现数据服务的流量控制。
- 可回滚：可以实现服务的fallback和reback回滚方式。
提高架构可用性的设计原则
- 解耦：消息队列、分布式队列、服务拆分
- 冗余：异地容灾、多点部署、主从切换
- 异构：sidercar模式进行分析和实现
- 异步：消息队列、异步调用、响应式编程
微服务设计原则
盗用官方图片一个：
原则一：完整性
功能完整性：功能内部逻辑独立，外部依赖较少。
微服务完整性：服务里面的每个微服务都应能独立完成具体的业务操作或者流程，都有明确的输入、输出和处理逻辑。
原则二：技术限制
需要使用事务一致性的功能需要放在一个微服务内，尽量避免分布式事务问题。
原则三：性能扩展
对于用户使用频率较高，性能要求较高的功能可单独作为一个微服务，以便做多节点扩展提升性能。
原则四：耦合性
微服务和微服务之间尽量避免相互调用依赖。可以通过 RPC 远程调用接口的方式，对于关联性较高的功能，应放在同一个微服务内。
公共使用的功能可设计在一个公共微服务。比如日志功能，文件上传功能以及一些底层技术组件等，可设计在一个微服务中。
回到Quarkus上面来
Quarkus云原生的标准
Quarkus可与常用Java标准、框架和库协同工作，例如 Eclipse MicroProfile、Spring（作为 2020 年红帽峰会追踪的一个环节一起演示）、Apache Kafka、RESTEasy (JAX-RS)、Hibernate ORM (JPA)、Spring、Infinispan、Camel 等。
Quarkus上下文和依赖注入
Quarkus 的依赖注入解决方案基于 CDI（上下文和依赖注入），且包含一个扩展框架来扩展功能并将其配置、引导并集成到您的应用中。添加扩展就像添加依赖项一样容易；或者，您可以使用 Quarkus 工具。
Quarkus多语言扩展支持
它还向 GraalVM（一种通用虚拟机，用于运行以多种语言（包括 Java 和 JavaScript）编写的应用）提供正确信息，以便对应用进行原生编译。
惊人的快速启动时间，极低的RSS内存（不仅是堆大小！）在容器编排平台（如Kubernetes）中提供了近乎即时的向上扩展和高密度的内存利用率
双模式进行运行方式
Quarkus的设计从一开始就立足于简单易用，其功能几乎不需要配置即可正常使用。
开发人员可以为其应用选择所需的Java框架，而这些应用可以在JVM模式下运行，也可以在原生模式下进行编译和运行。
为了方便开发人员的工作，Quarkus 还包含以下功能：
- 实时编码，旨在让开发人员能够即时检查代码更改的影响并快速进行故障排除
- 带有嵌入式托管事件总线的统一命令式和响应式编程
- 统一配置
- 简单的原生可执行文件生成
容器优先
无论是将应用托管在公共云上还是内部托管的Kubernetes集群中，快速启动和低内存消耗等特性对于降低总体主机成本来说都至关重要。
Quarkus 的开发遵从了容器优先的原则，这意味着它已通过以下方式针对降低内存使用和加快启动时间进行了优化：
- 鼎力支持 Graal/SubstrateVM
- 构建时元数据处理
- 减少反射的使用
- 本机映像预启动
因此，Quarkus 构建的应用其内存消耗只有传统 Java 的 1/10，而且启动时间更快（快了 300 倍），这些都大大降低了云资源的成本。
夸克斯六步
- 快速搭建属于Quarkus的应用微服务骨架（为构建应用服务奠定基础）
- Quarkus微服务应用的（开发模式）实现实时热部署能力（改动实时生效）
- 通过集成多个开源库以及相关业务需求进行开发相关的程序代码
- 当开发编码完成之后建立版本，进行开发层面集成化测试阶段
- 建立CLI程序以及创建云原生可执行包文件，并建立对应的容器服务
- 将对应的云原生文件包直接集成部署到Kubernetes集群中
分享资源
扫码关注发送:资源 获取以上资源
