What
- 云原生是一种构建和运行应用程序的方法,也是一套技术体系和方法论.
- Cloud 表示应用程序位于云中而不是传统的数据中心
- Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计并充分利用云计算优势对应用程序进行设计、实现、部署、交付、和操作的应用架构方法
- 符合云原生架构的应用程序
- 采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率
- 云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API
云原生关键技术
容器
容器技术是一种相对于虚拟机来说更加轻量的虚拟化技术,能为我们提供一种可移植、可重用的方式来打包、分发和运行应用程序。容器提供的方式是标准化的,可以将不同应用程序的不同组件组装在一起,又可以将它们彼此隔离。
容器的基本思想就是将需要执行的所有软件打包到一个可执行程序包中,比如将一个 Java 虚拟机、Tomcat 服务器以及应用程序本身打包进一个容器镜像。用户可以在基础设施环境中使用这个容器镜像启动容器并运行应用程序,还可以将容器化运行的应用程序与基础设施环境隔离
微服务
微服务是一种软件架构方式,我们使用微服务架构可以将一个大型应用程序按照功能模块拆分成多个独立自治的微服务,每个微服务仅实现一种功能,具有明确的边界。
为了让应用程序的各个微服务之间协同工作,通常需要互相调用 REST 等形式的标准接口进行通信和数据交换,这是一种松耦合的交互形式。
微服务基于分布式计算架构,其主要特点包括：
单一职责：微服务架构中的每一个服务,都应是符合高内聚、低耦合以及单一职责原则的业务逻辑单元,不同的微服务通过 REST 等形式的标准接口互相调用,进行灵活的通信和组合,从而构建出庞大的系统。
独立自治性：每个微服务都应该是一个独立的组件,它可以被独立部署、测试、升级和发布,应用程序中的某个或某几个微服务被替换时,其他的微服务都不应该被影响
Service Mesh服务网格
随着微服务逐渐增多,应用程序最终可能会变为成百上千个互相调用的服务组成的大型应用程序,服务与服务之间通过内部或者外部网络进行通信。如何管理这些服务的连接关系以及保持通信通道无故障、安全、高可用和健壮,就成了一个非常大的挑战。
服务网格可以作为服务间通信的基础设施层,解决上述问题。
服务网格是轻量级的网络代理,能解耦应用程序的重试/超时、监控、追踪和服务发现,并且能做到应用程序无感知。服务网格可以使服务与服务之间的通信更加流畅、可靠、安全,它的实现通常是提供一个代理实例,和对应的服务一起部署在环境中,这种模式我们称为 Sidecar 模式,Sidecar 模式可处理服务之间通信的任何功能,比如负载均衡、服务发现等。
服务网格的基础设施层主要分为两个部分,控制平面与数据平面,如图 1 所示。控制平面主要负责协调 Sidecar 的行为,提供 API 便于运维人员操控和测量整个网络。数据平面主要负责截获不同服务之间的调用请求并对其进行处理
DevOps
DevOps（Development & Operations,开发和运维）是软件开发人员和 IT 人员之间的合作过程,是一种工作环境、文化和实践的集合,目标是高效地自动执行软件交付和基础架构更改流程。
开发和运维人员通过持续不断的沟通和协作,可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。
开发人员通常以持续集成和持续交付（CI/CD）的方式,快速交付高质量的应用程序。
持续集成是指开发人员频繁地将开发分支代码合并到主干分支,这些开发分支在真正合并到主干分支之前,都需要持续编译、构建和测试,以提前检查和验证其存在的缺陷。
持续集成的本质是确保开发人员新增的代码与主干分支正确集成。
持续交付是指软件产品可以稳定、持续地保持随时可发布的状态,它的目标是促进产品迭代更频繁,持续为用户创造价值。
云原生应用通常包含多个子功能组件,DevOps 可以大大简化云原生应用从开发到交付的过程,实现真正的价值交付
不可变基础设施
在应用开发测试到上线的过程中,应用通常需要被频繁部署到开发环境、测试环境和生产环境中,在传统的可变架构时代,通常需要系统管理员保证所有环境的一致性,而随着时间的推移,这种靠人工维护的环境一致性很难维持,环境的不一致又会导致应用越来越容易出错。这种由人工维护、经常被更改的环境就是我们常说的“可变基础设施”。
与可变基础设施相对应的是不可变基础设施,是指一个基础设施环境被创建以后不接受任何方式的更新和修改。这个基础设施也可以作为模板来扩展更多的基础设施。如果需要对基础设施做更新迭代,那么应该先修改这些基础设施的公共配置部分,构建新的基础设施,将旧的替换下线。简而言之,不可变基础设施架构是通过整体替换而不是部分修改来创建和变更的。
不可变基础设施的优势在于能保持多套基础设施的一致性和可靠性,而且基础设施的创建和部署过程也是可预测的。在云原生结构中,借助 Kubernetes 和容器技术,云原生不可变基础设施提供了一个全新的方式来实现应用交付。
云原生不可变基础设施具有以下优势：
能提升应用交付效率：基于不可变基础设施的应用交付,可以由代码或编排模板来设定,这样就可以使用 Git 等控制工具来管理应用和维护环境。基础设施环境一致性能保证应用在开发测试环境、预发布环境和线上生产环境的运行表现一致,不会频繁出现开发测试时运行正常、发布后出现故障的情况。
能快速、可靠地水平扩展：基于不可变基础设施的配置模板,我们可以快速创建与已有基础设施环境一致的新基础设施环境。
能保证基础设施的快速更新和回滚：基于同一套基础设施模板,若某一环境被修改,则可以快速进行回滚和恢复,若需对所有环境进行更新升级,则只需更新基础设施模板并创建新环境,将旧环境一一替换
声明式API
声明式设计是一种软件设计理念：我们负责描述一个事物想要达到的目标状态并将其提交给工具,由工具内部去处理如何实现目标状态。
与声明式设计相对应的是过程式设计。在过程式设计中,我们需要描述为了让事物达到目标状态的一系列操作,这一系列的操作只有都被正确执行,才会达到我们期望的最终状态。
在声明式 API 中,我们需要向系统声明我们期望的状态,系统会不断地向该状态驱动。在 Kubernetes 中,声明式 API 指的就是集群期望的运行状态,如果有任何与期望状态不一致的情况,Kubernetes 就会根据声明做出对应的合适的操作。
使用声明式 API 的好处可以总结为以下两点：
声明式 API 能够使系统更加健壮,当系统中的组件出现故障时,组件只需要查看API服务器中存储的声明状态,就可以确定接下来需要执行的操作。
声明式 API 能够减少开发和运维人员的工作量,极大地提升工作效率
云原生的优势
实现更小体积
对于微服务化架构而言,拥有了更小的体积代表了未来将会是更少的下载带宽,而且更快地分发下载速度,在工作上会提高工作效率,节省更多的工作时间。
更快的启动速度
相比传统的单体应用而言,启动速度与运行效率快慢并不是重要的指标,但是对于需要快速迭代、水平扩展的云原生微服务架构应用而言,更快的启动速度就意味着更高的交付效率,和更加快速的回滚,尤其是面对较多应用的时候,可能仅仅才500ms的反应时间也会让用户感觉到延迟,从而造成用户的体验感变差
占用资源会更少
在实际的运行中占用的资源更低的时候,也就代表了更高的部署密度和更低的计算成本,同时,在JVM启动时需要消耗大量CPU资源对字节码进行编译,降低启动时资源消耗,可以减少资源争抢,更好保障其他应用SLA
数据没有固定的存储模式
在如今的实际使用中,云原生应用和服务既可以用JSON来处理数据,也可以用protocol buffer 或传统的 XML 来构造数据。很大程度上满足了不同的用户需求,无论是操作,还是实际都带来极大的便利性
弹性扩展
云原生架构的主要特点是微服务、容器化、 DevOps 、持续交付四个主要的特点,也正因为如此它的资源是可以按照实际情况进行伸缩,这样不但提高资源的利用率,也大大降低了企业成本
系统更加安全强壮
云原生架构依托于容器编排工具（K8S）与微服务的组合,应用就拥有了自动恢复能力、容错能力、故障隔离能力,让应用时刻处于可用的状态
屏蔽底层差异
使用了容器化技术,应用运行于容器之中,应用就不需要考虑底层硬件的差异,只要是能运行容器镜像的硬件都可以运行程序,大大简化了开发工作量。对于开发者来说,云原生提供的一些开箱即用的能力比如服务治理能力、DveOps,可以帮助我们更高效地进行开发。你不需要再花精力搭建复杂的持续交付环境,敏捷基础设施（如 K8S、Docke）开箱即用,自带一站式微服务开发解决方案。
