文章目录
一、什么是云原生?
"云"表示应用程序位于云(即云服务器)中,而不是传统的应用数据中心,"原生"可以理解为 “土生土长”,指一出生便有这个大环境,如互联网原住民从一出生就有已经有互联网环境的存在。
云原生(Cloud Native)是基于微服务原理而开发的应用,以容器的方式进行打包,在运行时,容器由运行于云基础设施之上的平台进行调度,应用开发采用持续交付和 DevOps
实践。总结来说,云原生就是基于云计算而来的技术,对云计算技术的不断精进和细化。
云原生架构则是开发云原生应用所用到的架构,核心有两点:
- 一是应用要以微服务的方式进行构建
- 二是应用架构方式一开始就要面向容器云部署。
二、“云”演进史
🕛 2000 年以前,还没有虚拟化技术,企业计算直接采用硬件服务器。当时 sun 公司就是专门提供中高端的企业应用服务器。
🕐 2001 年,VMware 推出了虚拟化技术,可以使用软件方式按需创建虚拟机,之后的时间里 VMware 一直是虚拟化技术的行业领导者。
🕑 2006 年,亚马逊研发了 Iaas(基础设施即服务),此技术将计算网络存储封装成了可以按需使用的资源,基于此亚马逊将 Iaas 进行商业化,推出了 AWS 公有云,直至今日 AWS 仍是公有云行业龙头。
🕒 2009 年,HEROKU 推出了商业化平台 Paas(平台即服务),抽象层次高于 Iaas,用户可以直接在 Paas 部署应用,无需关心底层计算资源。HEROKU 可认为是现代云原生平台的鼻祖。
🕓 2010 年,行业出现了开源的 Iaas 产品,主要满足了一些中大型企业自建私有云的需求。
🕔 2011 年,行业出现了开源的 Paas 平台。
🕕 2013 年,docker 容器技术诞生并从一开始就走上了开源路线,使得容器化在行业得到了快速普及。
🕖 2015 年,随着 docker 等技术的普及,谷歌、微软等大厂开始了立标准的过程,成立了 Cloud Native computing foundation(CNCF),旨在推动云原生项目的治理、推广和应用,标志着云原生时代的到来。
> Cloud Native Computing Foundation
https://www.cncf.io/
三、云原生核心技术及概念
1. 微服务
传统的大的单体应用拆分为更小的组件或模块,这个组件或者模块就叫做微服务,拆分为纵向拆分,从底层的IT基础设施到数据库,到应用中间件,再到软件程序部署包都能做到完全独立,可以单独的进行需求设计,开发,测试,打包和部署,实现各个微服务之间一个彻底的松耦合,同时各个微服务之间又能够通过轻量的 HTTP rest 接口进行交互和协同。总结来说微服务的核心为两点:大的单体拆小、拆小的微服务之间通过接口进行交互和协同。
2. DevOps
DevOps是一组过程,方法和系统的统称,用于促进开发、技术运营、质量保障(QA)部门之间的沟通、协作与整合。可以理解为持续交付和持续集成,将软件生命周期过程中的需求分析到程序设计、开发、编译、构建、打包和部署,从测试环境到生产环境整个过程实现全部的自动化。
3. 容器云
容器云的核心有两个,一个是 Docker 容器、一个是 Kurbernetes 的容器资源调度和编排。容器本身是一个比虚拟机更轻量化的资源隔离单位。区别在于虚拟机是独享一个操作系统,而容器是架在操作系统之上的,多个容器可以共享操作系统。体积要比虚拟机小且创建、销毁、调度的速度也比传统虚拟机快。但容器本身是一个 Iaas 层的内容,需要结合 Kubernetes 来向上层 Paas 层提供服务能力。
4. 服务网格
服务网格就是一个去中心化的服务治理框架。在以往的操作中对微服务或 API 接口进行治理和管控时,一般会用类似于 esb 总线、API 网关的设施,将 API 接口注册和接入到 API 网关。API 网关本身是一个中心化的架构,所以所有的请求、流量都可以通过 API 网关,这时 API 网关就容易对流量进行拦截,然后对拦截的流量进行管控。而在去中心化的架构中就没有这种集中化的流量管控了,对于流量的拦截,会从 esb 总线或者 API 网关下沉到各个微服务当中,这时需要在微服务端增加一个代理包,通过代理包做流量拦截和流量管控。
5. Serverless 无服务器架构
“无服务器” 即几乎不接触 IT 基础设施。要知道云原生的核心就是要实现从资源到服务不断的向上抽象,在这个抽象的过程中 IT 基础设施的接触则会越来越少,接触更多的是各种技术服务能力。这些技术服务能力在 Serverless 架构中称为 Baas 后端能力及服务。
Serverless 对于开发流程有着很大的改变:
传统开发流程(前端工程师、后端工程师、运维工程师)
- 设计 → 服务端/前端开发 → 服务端部署 → 前后端联调 → 测试 → 上线 → 运维
Serverless 开发流程(前端工程师、后端工程师)
- 设计 → 应用开发 → 测试 → 上线
可以看到 Serverless 无服务器化以后,一些重的开发框架、环境、多层架构等都被抛弃掉了,此时任何一个功能的实现全部变成一个个代码片段(只需要写一些函数,开发较为简单),然后通过代码片段的组合安装来实现复杂的流程。
6. 不可变基础设施
传统软件部署中,当程序部署到一个生产环境或者 tomcat 中间件以后,如果需要去做变更,无论任何变更都需要在原来的生产环境上进行重新部署。而在云原生的概念中强调任何一个应用部署到生产环境,形成一个容器实例之后,这个容器实例本身不应该再做任何的变化,如果程序需要修改,则基于容器镜像重新去生成一个容器实例,同时销毁旧的容器实例。
7. 声明式 API
声明式 API 是和命令式 API 相对应的一个概念,传统方式创建或者操作一个容器需要去执行一个命令行。但是在声明式 API 中,对于容器的创建,首先应该先写一个 yaml 配置文件,在这个配置文件当中声明出要做的操作和操作完成之后的状态,然后平台底层拿到这个声明式配置文件之后,解释该文件内容,做出相应的后端操作,操作结束之后将各个底层的技术组件协调到需要的状态。这样的操作流程便于生产环境出现问题时快速找到自己所做了什么操作。
四、云原生对程序员来说意味着什么?
距字节跳动 | 火山引擎副总经理张鑫介绍,云原生为程序员带来的首先是编程范式的改变,以往从开发到编译、测试、发布,都有着一整套的流程和体系,云原生的到来则定义了一种新的规范,程序员就需要掌握一种新的技能。其次也是最重要的就是思维模式的改变,以前写软件会想着怎么把他运行在一个 Server 服务器上,k8s 云原生出现以后从一开始设计的时候就需要考虑到未来将它运行到一个可扩展性、可弹性自动化管理的云端。
五、云原生对 IT 岗位会有什么样的影响?
云原生对 IT 岗位的影响是全方位并且深入的,所以人人去学云原生也是必要的。
- 技术栈:后端研发需要关注大量用到的技术,比如容器、微服务、Serverless、Paas 云服务等;
- 分布式设计模式:云原生技术体系包含了大量已经存在的分布式设计模式;
- 业务开发:云原生技术和云服务采用的越多,开发人员在非功能特性开发方面花费的经历就越少,从而有更多的时间关注业务本身的功能性设计;
- 测试方式:传统是基于预测来设计测试案例的方式进行测试,这样效率太低,解决方式是利用主动故障注入和馄饨工程进行疲劳测试,真实模拟现实世界可能发生的故障;
- 软件研发和运维流程:DevOps 和 DevsecOps 不仅要求企业做到安全的持续发布,还要求企业重新定义和规范开发人员接触的研发流程和工具,实现开发运维岗位一体化;