不好意思说自己不知道云原生了
前言
随着云原生技术的火热发展，云原生这个词经常会在耳边出现，作为技术线的同学已经不好意思说自己不了解什么是云原生了。简单跟大家聊聊一些粗浅的认识，有时候抬头看看天，挺好的。
为什么需要云原生
在如今的流量时代，单机架构已经不能满足系统的容量和吞吐，于是有了分布式架构。应用被拆分成多个服务，服务之间通过 RPC、HTTP、MQ 通信。为了实现无状态服务，需要依赖一些中央存储，例如分布式缓存、数据库、文件系统等。然而分布式系统也带来了新的问题：
- 架构的复杂性，运维成本高。
- 为了应对流量峰值，需要部署充足的资源，造成一定的资源浪费。
对于小企业而言，运维复杂的分布式系统成本是非常昂贵的。然而大企业可以提供商业化的基础设施和服务，获取更多的收益，小企业可以利用计算资源的弹性降低自己的成本。于是架构步入了云时代，大家互利共赢。以亚马逊和阿里云为例，我们可以直接购买云产品，例如 RDS、MQ、对象存储、日志服务等等，快速搭建自己的业务应用，无需关注底层的基础设施。
云原生的价值：
- 跨平台可移植
- 弹性，可自动化伸缩
- 可管控，自动化运维
- 快速响应，交付效率高
理想与现实：
- 用户上云，需要按照云产品的规范进行改造，学习和改造成本高。
- 如何适配用户不同开发语言的系统，每个都需要提供 SDK，开发成本和出错概率都比较高。
- 不同类型的客户需要更加灵活的计费方式。
- 秒级的市场响应任重而道远。
- 。。。。。。
什么是云原生
云原生还是一个崭新的概念，每个人对它的理解和定位都是不同的。以容器、服务网格、微服务、Serverless 为代表的云原生技术，为应用的构建、部署、运维带来了全新的认知和改变。来看看社区的“大咖们“是如何解释的。
Pivotal的定义
- DevOps
- 持续交付
- 微服务
- 容器
CNCF的定义
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
云原生技术栈有哪些
容器化
Docker 是近几年最受欢迎的虚拟化技术，通过共享宿主机的硬件和操作系统来实现资源的动态分配以及环境隔离。镜像是 Docker 的标准化交付物，可以说是 Docker 的灵魂，它包含了应用程序及其所依赖的运行环境，Build once, Run anywhere，大幅度提高了交付效率。
容器和虚拟机的区别：
- 虚拟机有 Hypervisor 层，Hypervisor 是整个虚拟机的核心，用于管理虚拟机操作系统运行时。容器没有 Hypervisor 这一层，并且每个容器是和宿主机共享硬件资源及操作系统。
- 容器消耗的资源更少，它是在操作系统级别进行虚拟化，性能优于通过 Hypervisor 层与内核层的虚拟化。
- 容器的隔离性较弱，它是进程级别的隔离，虚拟机是系统级别的隔离。
- 容器启动是秒级的，虚拟机通常是分钟级。
Kubernetes
众所周知，Kubernetes 已经是业界最火热的容器编排平台，主要用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
Kubernetes 的核心组件：
- kube-apiserver：资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制。
- controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。
- kube-scheduler：负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上。
- kubelet：负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理。
- Container runtime：负责镜像管理以及 Pod 和容器的真正运行（CRI）。
- kube-proxy：负责为 Service 提供 Cluster 内部的服务发现和负载均衡。
- etcd：保存整个集群的状态。
Service Mesh
ServiceMesh 核心是业务逻辑与非业务逻辑解耦，将传统 RPC 的逻辑从业务逻辑中剥离出来，如服务发现、路由、负载均衡、限流降级等，以单独 Sidecar 的形式下沉到基础设施中，使得 Serverless 架构的推动变得更加便利。
Istio 提供了服务网格的完整解决方案，从架构上可以分为数据面和控制面。
-
数据面：由一组 Sidecar 组成，Sidecar 用于代理所有服务之间的网络通信。在 Istio 中，默认的 Sidecar 实现是 Envoy。
-
控制面：负责管理和配置代理路由流量。
重点提下 Pilot 组件：
- 路由
- 服务发现和负载均衡
- 故障处理
- 故障注入
- 配置下发
Serverless
Serverless（无服务器架构）指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理。
Serverless 优势：
- 降低开发和运维成本
- 降低系统风险
- 降低资源开销
- 弹性、可扩展
Knative 是基于 Kubernetes 的 Serverless 解决方案，它的目标是在基于 Kubernetes 基础上标准化整个开发的生命周期，降低运维的成本，让研发人员更加专注于开发工作，减少对基础设施的关注。
Knative 三个核心组件：
- 构建 Build：通过插件化的构建系统将用户源码构建成容器。
- 服务 Serving：部署和运行 Serverless 的工作负载，可根据负载弹性伸缩，甚至在没有负载时可以缩减为 0，利用 Istio 可以在各个版本之间轻松路由。
- 事件 Event：对事件源进行抽象，实现可插拔的消息传递层，允许用户选择自己的消息传递层，达到解耦的目的。
声明式 API
在 Kubernetes 中，声明式 API 到处可见，这也让它在容器编排领域立于不败之地，成为行业标准。
声明式 API 是告诉计算机是什么（what），让计算机去思考如何实现。是对编程思维的一种刷新，它可以方便地定义出一套标准，对接不同的实现方案。
典型案例
阿里云与微软联合推出开放应用模型 Open Application Model （OAM）开源项目。OAM 的愿景是以标准化的方式沟通和连接应用开发者、运维人员、应用基础设施，让云原生应用管理与交付变得更加简洁，高效，并且可控。
OAM 核心概念：
- 应用边界 Application Scopes
- 应用配置 ApplicationConfiguration
- 服务组件 Component
- 运维特征 Traits
参考链接：
不可变基础设施
可以说是我们运维的思路上需要做一定的改变，在之前一旦生产环境的机器出现问题，我们需要尽可能去恢复机器。有了云原生之后，基础设施实例一旦创建就是不可变的，如果想对实例做状态更改，那么就去启动新的实例去替换它，这样可以减轻运维同学的压力。
Helm Chart
Helm 是云原生领域最火热的应用管理工具，Helm 采用 Chart 的格式来标准化描述一个应用（K8S 资源文件集合），Chart 有自身标准的目录结构，可以将目录打包成版本化的压缩包进行部署。就像我们下载一个软件包之后，就可以在电脑上直接安装一样，同理 Chart 包可以通过 Helm 部署到任意的 K8S 集群中。
关于 Helm 的使用可以参考我之前的文章：Helm V3使用指北
对我有啥用
在云原生时代考虑系统架构设计可以作为一些参考：
- 系统尽可能不强依赖 IP，需要能够弹性伸缩。
- Run Anywhere。
- 采用微服务架构，系统之间解耦。
- 适用于云原生可以给系统带来哪些新的需求，以及架构应当如何调整。
- 自助运维如何向自动化运维转变。
- 如何做到可移植，API 接口是否标准化。
未来的一些思考
- 面向 Kubernetes 编程：Kubernetes 逐渐成为云原生体系的操作系统。
- Serverless 将成为未来云计算采用的主流技术，为 PaaS DevOps 注入了新的活力和方法。
- OAM 可以成为云原生应用标准，能够具有普适性，被外界认可。
