云原生从字面意思上来看可以分成:
云原生计算基金会(Cloud Native Computing Foundation,CNCF)成立于2015年12月11日,由谷歌与Linux基金会联合创办,成立这个非盈利组织的目的是为了推广、孵化和标准化云原生相关的技术。
云原生计算基金会(Cloud Native Computing Foundation,CNCF)认为:云原生是一类技术的统称,通过云原生技术,我们可以构建出更易于弹性扩展的应用程序,其包含容器、服务网格、微服务、不可变基础设施和声明式API等相关技术,这些技术能够构建容错性好、易于管理和便于观察的松耦合系统,结合可靠的自动化手段,相关工程师能够轻松对系统作出频繁和可预测的重大变更。
1)服务编排要实现计算资源弹性化
2) 服务构建和部署要实现高度自动化
3)事件驱动基础设施标准化
微服务的定义:原有单体应用拆分为多个独立自治的组件,每个组件都可以独立设计、开发、测试、部署和运维,这个组件可以单独提供对外服务,我们称之为微服务。
例如:早期的LNMT WEB部署架构,使用微服务后,每一个组件都可以独立自治、运行、扩容、缩容等
各组件之间可通过轻量的Restful风格接口进行交互和协同
Docker容器,容器属于it基础设施层概念,是比虚拟机更轻量化的隔离工具,是微服务最佳载体。
使用kubernetes的资源调度与容器编排,可以实现Docker容器更优管理,进一步实现其PaaS层能力。
服务网格存在的目的,就是去中心化的服务治理框架。
以往需要对微服务或对api接口去做治理和管控,一般会用类似于ESB服务总线或 API网关,将API接口注册和接入到API网关,由于API网关本身是一个中心化的架构,所以所有的请求流量都可以通过API网关,由API网关实现对流量拦截,同时对拦截以后的流量进行安全,日志,限流熔断,链路监控等各种管控治理,去中心化以后就没有这种集中化的流量管控点了,所以对流量的拦截就从ESB服务总线或API网关下沉到各个微服务中去了,这就是为什么我们需要在微服务端增加一个代理包的原因,通过这个代理包来做流量的拦截,同时实现对流量的管控,当前在微服务网格中也是用同样的思路来对服务进行治理的。例如:istio服务治理,它会在微服务应用中添加一个边车容器(Envoy)来实现流量的拦截和管控。这个属于微服务服务网格治理的核心技术。
去中心化的服务治理依然有一个控制中心,而控制中心依然是中心化的,但实际的控制流和接口数据访问的消息流是实现分离的,控制中心仅处理服务注册发现,实际的接口调用、服务访问是不通过控制中心的,即使控制中心出现问题,例如控制中心服务不可用等,也不会影响实际服务接口调用。
传统开发过程中,做一个软件程序的部署,当它部署到一个生产环境,如果我们要做变更,不管是程序的变更还是配置的变更,都需要在原来的生产环境上面重新部署或对某一个配置直接进行修改,但是在云原生应用中,任何一个应用当你部署到生产环境中,形成一个容器实例以后,这个容器实例不应该再做任何变化,如果软件程序需要重新部署或修改配置时怎么办呢?可以利用基础容器镜像,重新生成一个新的容器实例,同时把旧的容器实例销毁掉,这个就是云原生技术中要求的不可变技术点。
应用部署大体上分为两种执行方式:命令式和声明式。
# kubectl run -it busyboxapp --image=busyboxapp:1.28.4
创建yaml资源清单文件
# cat nginx.yaml
---
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
imagePullSecrets:
- name: huoban-harbor
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "managed-nfs-storage"
resources:
requests:
storage: 1Gi
应用yaml资源清单文件
# kubectl apply -f nginx.yaml
IT基础设施获取声明式文件的后续操作
当IT基础设施获取到声明文件后,首先要解析声明式文件中声明的内容,再去后端做出相应的操作,操作完成后,把各个底层技术组件协调到应用需要的一个状态。
使用声明式API,任何对生产环境、配置都不是操作一条命令来完成的,都需要先写声明,或配置文件,这些操作都可以纳入配置管理中进行集中管理,这样有利于在生产环境出现问题时,能够快速了解前述操作,及对生产环境产生的影响,易于做版本回退、回滚等操作。
借助于云原生相关技术,DevOps时代才真正地到来了。
我们知道计算资源应用技术一直是在不断地往前发展的,从物理机演进为虚拟机,从虚拟机再演进到容器化,由容器化再演变到我们今天所看到云原生技术,其中充满了机会与竞争,就拿容器化技术演进过程来说:
在这个发展历程中, 各家公司都出现了商业竞争:
在竞争合作之间寻找平衡从而导致了标准规范的诞生,而标准规范的诞生是整个云原生生态最重要的基石。
2015年6月,Docker带头成立OCI,旨在“制定并维护容器镜像格式和容器运行时的正式规范(OCI Specifications)”,其核心产出是OCI Runtime Spec(容器运行时规范)、OCI Image Spec(镜像格式规范)、OCI Distribution Spec(镜像分发规范)。所以OCI组织解决的是容器的构建、分发和运行问题。
一个月之后,Google带头成立了Cloud Native Computing Foundation(CNCF),旨在“构建云原生计算 :一种围绕着微服务、容器和应用动态调度的、以基础设施为中心的架构,并促进其广泛使用”。所以CNCF组织解决的是应用管理及容器编排问题。
网址:https://www.cncf.io/
CNCF的项目全景图网址链接: https://landscape.cncf.io/
云原生应用生态已覆盖到:大数据、人工智能、边缘计算、区块链等领域。
基础设施安全:存储安全(加密存储、容灾备份)、网络安全(网络策略管理、访问控制)、计算安全(系统加固、资源隔离)
应用安全:应用数据安全、应用配置安全、应用环境安全
云原生研发安全:代码托管、代码审计、软件管理、可信测试、可信构建
容器生命周期安全:运行时安全、容器构建(镜像扫描、镜像签名)、部署安全(合规部署)、组件安全
安全管理:身份认证、访问授权、账号管理、审计日志、密钥管理、监控告警
以上所有云原生相关技术都是围绕着Kubernetes展开。
云原生2.0时代,由On Cloud变为In Cloud,生于云,长于云,且立而不破。
由于业务的逐利性,我们需要对计算资源和服务进行不断的抽象,在抽象的过程中我们会发现越来越少的能够接触到IT基础设施层,仅能够接触到各种技术的服务能力,这种服务能力我们称之BaaS后端能力及服务,对于开发人员来说,不要去接触到最底层的资源,这也不是其应该去做的事,开发人员应该专注于代码业务逻辑的实现即可。
其实在从IT基础设施层(IaaS)到PaaS层,我们一直在强调这种变化,那么serverless能够给我们带来了什么呢?
在传统的云原生架构开发下面,我们基于DevOps,基于微服务和容器云,开发应用的时候,你依旧会选择一个开发框架,开发所使用的底层的基础平台,依旧会涉及到开发一个应用的时候的数据层,逻辑层,展现层,例如我们常说的三层架构和五层架构:
进入serverless时代后,对于开发人员来说不需要去了解底层的基础设施及多层架构,全部不需要了解,任何一个功能的实现,简单来说,就变成一个个代码片段,通过代码片段去实现功能,通过代码片段的组合组装,来实现复杂一点的流程,这就是serverless所要达到的目的,因此Serverless有两个部分组成,一个是前面我们提到的BaaS,另一个是FaaS(funtion as a Service)层,函数即服务,当我们的BaaS能力足够强以后,我们去实现代码的功能非常简单,只要写一个个函数,并让其执行即可,即可达到项目上线的目的。