云原生时代下的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（云原生）是更好的工具、自我修复系统、和自动化系统的集合，可以让应用和基础设施的部署和故障修复更加快速和敏捷，极大的降低企业在云计算方面的部署成本。
目前业界公认的云原生主要包括以下几个层面的内容。
![]()
随着容器、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 有一张云原生全景图（https://github.com/cncf/landscape），在这个全景图里已经有 200 多个项目和产品了，这些项目和产品也都是和 CNCF 的观点所契合的。所以如果以这张全景图作为背景，加以思考就会发现，我们今天所讨论的云原生其实主要谈论了以下几点：
云原生基金会 —— CNCF
CNCF是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会。
云原生技术社区
比如像 CNCF 目前正式托管的多个项目共同构成了现代云计算生态的基石，其中像 Kubernetes这样的项目已经成为了世界首屈一指，非常活跃的开源项目；目前从 CNCF 毕业的项目有很多，例如Kubernetes 、Prometheus、Envoy、CoreDNS、containerd、Fluentd 。
云原生服务架构的原则
高可用架构设计的原则
-
可观测：可以通过运行状态和数据分析，实现可观测模式下的运行状态和运行数据分析。
-
可灰度：可以实现蓝绿发布、AB测试、金丝雀发布机制等，实现数据服务的流量控制。
-
可回滚：可以实现服务的fallback和reback回滚方式。
提高架构可用性的设计原则
-
解耦：消息队列、分布式队列、服务拆分
-
冗余：异地容灾、多点部署、主从切换
-
异构：sidercar模式进行分析和实现
-
异步：消息队列、异步调用、响应式编程
微服务设计原则
盗用官方图片一个：
![]()
原则一：完整性
功能完整性：功能内部逻辑独立，外部依赖较少。
微服务完整性：服务里面的每个微服务都应能独立完成具体的业务操作或者流程，都有明确的输入、输出和处理逻辑。
原则二：技术限制
需要使用事务一致性的功能需要放在一个微服务内，尽量避免分布式事务问题。
原则三：性能扩展
对于用户使用频率较高，性能要求较高的功能可单独作为一个微服务，以便做多节点扩展提升性能。
原则四：耦合性
微服务和微服务之间尽量避免相互调用依赖。可以通过 RPC 远程调用接口的方式，对于关联性较高的功能，应放在同一个微服务内。
公共使用的功能可设计在一个公共微服务。比如日志功能，文件上传功能以及一些底层技术组件等，可设计在一个微服务中。
