随着云原生技术的火热发展,云原生这个词经常会在耳边出现,作为技术线的同学已经不好意思说自己不了解什么是云原生了。简单跟大家聊聊一些粗浅的认识,有时候抬头看看天,挺好的。
在如今的流量时代,单机架构已经不能满足系统的容量和吞吐,于是有了分布式架构。应用被拆分成多个服务,服务之间通过 RPC、HTTP、MQ 通信。为了实现无状态服务,需要依赖一些中央存储,例如分布式缓存、数据库、文件系统等。然而分布式系统也带来了新的问题:
对于小企业而言,运维复杂的分布式系统成本是非常昂贵的。然而大企业可以提供商业化的基础设施和服务,获取更多的收益,小企业可以利用计算资源的弹性降低自己的成本。于是架构步入了云时代,大家互利共赢。以亚马逊和阿里云为例,我们可以直接购买云产品,例如 RDS、MQ、对象存储、日志服务等等,快速搭建自己的业务应用,无需关注底层的基础设施。
云原生的价值:
理想与现实:
云原生还是一个崭新的概念,每个人对它的理解和定位都是不同的。以容器、服务网格、微服务、Serverless 为代表的云原生技术,为应用的构建、部署、运维带来了全新的认知和改变。来看看社区的“大咖们“是如何解释的。
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
Docker 是近几年最受欢迎的虚拟化技术,通过共享宿主机的硬件和操作系统来实现资源的动态分配以及环境隔离。镜像是 Docker 的标准化交付物,可以说是 Docker 的灵魂,它包含了应用程序及其所依赖的运行环境,Build once, Run anywhere,大幅度提高了交付效率。
容器和虚拟机的区别:
众所周知,Kubernetes 已经是业界最火热的容器编排平台,主要用于管理容器化的工作负载和服务,可促进声明式配置和自动化。
Kubernetes 的核心组件:
ServiceMesh 核心是业务逻辑与非业务逻辑解耦,将传统 RPC 的逻辑从业务逻辑中剥离出来,如服务发现、路由、负载均衡、限流降级等,以单独 Sidecar 的形式下沉到基础设施中,使得 Serverless 架构的推动变得更加便利。
Istio 提供了服务网格的完整解决方案,从架构上可以分为数据面和控制面。
数据面:由一组 Sidecar 组成,Sidecar 用于代理所有服务之间的网络通信。在 Istio 中,默认的 Sidecar 实现是 Envoy。
控制面:负责管理和配置代理路由流量。
重点提下 Pilot 组件:
Serverless(无服务器架构)指的是由开发者实现的服务端逻辑运行在无状态的计算容器中,它由事件触发,完全被第三方管理。
Serverless 优势:
Knative 是基于 Kubernetes 的 Serverless 解决方案,它的目标是在基于 Kubernetes 基础上标准化整个开发的生命周期,降低运维的成本,让研发人员更加专注于开发工作,减少对基础设施的关注。
Knative 三个核心组件:
在 Kubernetes 中,声明式 API 到处可见,这也让它在容器编排领域立于不败之地,成为行业标准。
声明式 API 是告诉计算机是什么(what),让计算机去思考如何实现。是对编程思维的一种刷新,它可以方便地定义出一套标准,对接不同的实现方案。
阿里云与微软联合推出开放应用模型 Open Application Model (OAM)开源项目。OAM 的愿景是以标准化的方式沟通和连接应用开发者、运维人员、应用基础设施,让云原生应用管理与交付变得更加简洁,高效,并且可控。
OAM 核心概念:
参考链接:
OAM官网
OAM Github
OAM 正式开源:全球首个云原生应用标准定义与架构模型
可以说是我们运维的思路上需要做一定的改变,在之前一旦生产环境的机器出现问题,我们需要尽可能去恢复机器。有了云原生之后,基础设施实例一旦创建就是不可变的,如果想对实例做状态更改,那么就去启动新的实例去替换它,这样可以减轻运维同学的压力。
Helm 是云原生领域最火热的应用管理工具,Helm 采用 Chart 的格式来标准化描述一个应用(K8S 资源文件集合),Chart 有自身标准的目录结构,可以将目录打包成版本化的压缩包进行部署。就像我们下载一个软件包之后,就可以在电脑上直接安装一样,同理 Chart 包可以通过 Helm 部署到任意的 K8S 集群中。
关于 Helm 的使用可以参考我之前的文章:Helm V3使用指北
在云原生时代考虑系统架构设计可以作为一些参考: