云原生入门到进阶，1篇就够了！

开始阅读文章前，请角色切换：设想你作为一位中小型IT公司CTO，面对云原生技术决策，你需要回答两个问题：

为什么需要上云？

上云有何弊端？

作为一家公司的技术决策者，必须理解上云的利与弊，并结合公司各阶段发展目标给出最适合的技术方案。

云原生-概述

（一） 云原生-定义

云原生的定义，业界也是“百家争鸣”各持观点，从技术视角理解云原生会相对清晰。云原生的关键技术包括：

• 微服务架构：服务与服务之间通过高内聚低耦合的方式交互。

• 容器：作为微服务的最佳载体，提供了一个自包含的打包方式。

• 容器编排：解决了微服务在生产环境的部署问题。

• 服务网络：作为基础设施，解决了服务之间的通信。

• 不可变基础：设施提升发布效率，方便快速扩展。

• 声明式API：让系统更加健壮

命令式API：可以直接发出让服务器执行的命令，例如：“运行容器”、”停止容器”等。

声明式API：可以声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。

• DevOps：缩短研发周期，增加部署频率，更安全地方便：

Culture ：达成共识

Automation：基础设施自动化

Measurement：可度量

Sharing：你中有我，我中有你

【私人观点】

云原生的定义：应用因云而生，即云原生。

应用原生被设计为在云上以最佳方式运行，充分发挥云的优势，是上云的最短路径。

（二）云原生-技术生态

（三） 云原生-关键技术

云原生关键技术包括：微服务，容器，容器编排，服务网络，不可变基础，声明式API。

（1）微服务

微服务是一种用于构建应用的架构方案。

将一个复杂的应用拆分成多个独立自治的服务，服务与服务间通过“高内聚低耦合”的形式交互。

微服务典型架构包括：

• 服务重构：单体改造成符合业务的微服务架构。

• 服务注册与发现：微服务模块间的服务生命周期管理。

• 服务网关：身份认证、路由服务、限流防刷、日志统计。

• 服务通信：通信技术方案如，RPC vs REST vs 异步消息。

• 可靠性：服务优雅降级，容灾，熔断，多副本。

（2）容器

容器是一种打包应用的方式，可以打包应用中的所有软件和软件所依赖的环境，并可实现跨平台部署。

容器关键技术：namespac视图隔离，cgroups资源隔离 ，Union File System联合文件系统。

容器优势：

• 更高效的利用资源。
• 更快速的启动时间。
• 一致性的运行环境。

（3）容器编排

容器编排包括：自动化管理和协调容器的系统，专注于容器的生命周期管理和调度。

核心功能：

• 容器调度：依据策略完成容器与母机绑定。
• 资源管理：CPU、MEM、GPU、Ports、Device。
• 服务管理：负载均衡、健康检查。

（4） 服务网格

服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。

• Service Mesh应对云原生应用的复杂服务拓扑，提供可靠的通信传递。
• 通过一组轻量级网络代理（Sidecar
  proxy），与应用程序代码部署在一起来实现，且对应用程序透明。

Service
Mesh 特点：

• 应用程序间通讯的中间层。
• 轻量级网络代理，应用程序无感知。
• 解耦应用的重试、监控、追踪、服务发现。

Service Mesh主流组件：Istio、MOSN（Modular Open
Smart Network）Linkerd。

（5）不可变基础设施

不可变基础设施（Immutable Infrastructure）（宠物VS牲畜）

• 任何基础设施实例（服务器、容器等各种软硬件）一旦创建之后便成为一种只读状态，不可对其进行任何更改。
• 如果需要修改或升级实例，唯一方式是创建一批新实例以替换。

不可变基础设施的优势：

• 提升发布应用效率。
• 没有雪花服务器。
• 快速水平扩展。

（6）声明式API

• 命令式API：可直接发出让服务器执行的命令，例如：“运行容器”、“停止容器”等。
• 声明式API：可声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。

为什么声明式使系统更加健壮？

可以类比理解成自动化工程学的闭环自适应模型。

（7） DevOps

DevOps目标：缩短开发周期，增加部署频率，更可靠地发布。

从历史上开发和运维相对孤立到开发和运维之间建立合作，可以增加信任，更快速地发布新版本。

DevOps是一组过程，方法和系统的统称包括：

• Culture：

文化是DevOps 中的第一成功要素。

由于目标不同，开发和运维形成一堵墙，DevOps通过建立开发和运维之间合作和沟通的文化来消除墙。

• Automation：

自动化软件的开发和交付，通常包含持续集成，持续交付和持续部署，云原生时代还包括基础架构的自动化，即IaC(Infrastructureas code)。

• Measurement：

度量尤其重要，通过客观的测量来确定正在发生的事情的真实性，验证是否按预期进行改变。并为不同职能部门达成一致建立客观基础。

• Sharing：

1.开发和运维团队之间长期存在摩擦的主要原因是缺乏共同的基础。

2.开发参与运维值班，参与软件的部署和发布，运维参与架构设计。

容器-Docker

（一）Docker概述

为什么学习容器技术?

云时代从业者：Docker已成云平台运行分布式、微服务化应用的行业标准。

作为有技术追求的程序员，有必要理解云原生的关键技术：容器。

Docker核心概念：镜像、容器、仓库。

镜像(Image)：

• 一个只读模板。
• 由一堆只读层（read-only
  layer）重叠。
• 统一文件系统（UnionFileSystem）整合成统一视角。

容器(Container) ：

• 通过镜像创建的相互隔离的运行实例。
• 容器与镜像区别：最上面那一层可读可写层。
• 运行态容器定义：一个可读写的统一文件系统，加上隔离的进程空间，以及包含在其中的应用进程。

仓库（Repository）：

• 集中存放镜像文件的地方。
• Docker Registry 可包含多个仓库（Repository），每个仓库可包含多个标签（Tag），每个标签对应一个镜像。

（二）Docker关键技术

（1）Namespace视图隔离

Linux
namespace 是一种内核级别的环境隔离机制，使得其中的进程好像拥有独立的系统环境。

Network
namespace在Linux中创建相互隔离的网络视图，每个网络名字空间都有自己独立的网络配置，包括：网络设备、路由表、IPTables规则，路由表、网络协议栈等。（默认操作是主机默认网络名字空间）

（2） control
groups（资源隔离）

Linux
Control Group是内核用于限制进程组资源使用的功能。资源包括：CPU，内存，磁盘IO等。

（3） Union
File System（联合文件系统）

Union
File System， 联合文件系统：将多个不同位置的目录联合挂载(union
mount)到同一个目录下。

• Docker利用联合挂载能力，将容器镜像里的多层内容呈现为统一的rootfs(根文件系统)。
• Rootfs打包整个操作系统的文件和目录，是应用运行所需要的最完整的“依赖库”。

（三） Docker-网络技术

Bridge模式：Docker0充当网桥，在默认情况下，被限制在Network Namespace里的容器进程，是通过 Veth Pair设备 + 宿主机网桥的方式，实现跟同其他容器的数据交换。

一旦一张虚拟网卡被“插”在网桥上，它就会变成该网桥的“从设备”。

从设备会被“剥夺”调用网络协议栈处理数据包的资格，从而“降级”成为网桥上的一个端口。

而这个端口唯一的作用，就是接收流入的数据包，然后把这些数据包全部交给对应的网桥，由网桥完成转发或者丢弃。

veth提供一种连接两个network namespace的方法。

Veth 是Linux中一种虚拟以太设备，总是成对出现常被称为Veth pair。

可以实现点对点的虚拟连接，可看成一条连接两张网卡的网线。一端网卡在容器的Network Namespace上，另一端网卡在宿主机Network

Namespace上。任何一张网卡发送的数据包，都可以对端的网卡上收到。

在物理网络中，如果需要连接多个主机，会用交换机。

在 Linux 中，能够起到虚拟交换机作用的网络设备，是网桥（Bridge）。

它是一个工作在数据链路层的设备，主要功能是根据MAC 地址学习来将数据包转发到网桥的不同端口（Port）上。

Bridge网桥类似交换机，两个以上namespace接入同一个二层网络。

veth
pair一端虚拟网卡加入到namespace，另一端到网桥上。

路由（routing）是通过互联的网络把信息从源地址传输到目的地址的活动，发生在OSI模型的第三层（网络层）。Linux内核提供IP Forwarding功能，实现不同子网接口间转发IP数据包。

路由器工作原理：

• 路由器上有多个网络接口，每个网络接口处于不同的三层子网上。
• 根据内部路由转发表将从一个网络接口中收到的数据包转发到另一个网络接口，实现不同三层子网间互通。

容器编排-Kubernetes

（一）概述&架构&核心组件

我认为Kubernetes最大成功：让容器应用进入大规模工业生产。

Kubernetes的提供特性，几乎覆盖一个分布式系统在生产环境运行的所有关键事项。包括：

• Automated
  rollouts and rollbacks(自动化上线和回滚)

使用Kubernetes 描述已部署容器的所需状态，受控的速率将实际状态更改为期望状态。

• Self-healing(自我修复)

Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

• Service
  discovery and load balancing(服务发现与负载均衡)

Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而实现部署稳定。

• Storage
  orchestration(存储编排)

Kubernetes 允许你自动挂载选择的存储系统，例如本地存储、公厂商等。

• Automatic
  bin packing(自动装箱)

Kubernetes 允许指定每个容器所需 CPU 和内存（RAM）。当容器指定资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• Secret
  and configuration management(安全和配置管理)

Kubernetes 允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。你可在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

API
Service：Kubernetes 各组件通信中枢。

• 资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制。
• 为Pod， Deployment，Service等各种对象提供Restful接口。
• 与etcd 交互的唯一组件。

Scheduler：负责资源调度，按照预定调度策略将Pod调度到相应的机器。

• Predicates(断言)：淘汰制
• Priorities（优先级）：权重计算总分。

Controller
manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。

etcd：分布式的K-V存储，独立于Kubernetes的开源组件。

• 主要存储关键的原数据，支持水平扩容保障元数据的高可用性。
• 基于Raft算法实现强一致性，独特的watch机制是Kubernetes设计的关键。

kubelet ：负责维护Pod的生命周期，同时负责Volume（CVI）和网络（CNI）的管理。

kube-proxy：负责为 Service 提供 cluster 内部的服务发现和负载均衡

• kube-proxy通过在节点上添加 iptables规则以及从中移除这些规则来管理此端口重新映射过程。

控制器模式的设计思想：

容器类比集装箱，集装箱固然好用，但是如果它各面光秃秃的，吊车还怎么把它吊起来摆放好呢？

Pod对象其实就是容器的升级版，对容器进行组合，添加更多属性和字段。就好比在集装箱上安装了吊环，Kubernetes这台“吊车”可以更轻松操作容器。

然而Kubernetes操作这些“集装箱”的逻辑都是由控制器完成的。

Kubernetes通过“控制器模式” 的设计思想，来统一编排各种对象和资源。

（二）部署&资源控制&存储

Kubernetes-集群部署架构

• 所有组件通过kubelet static pod的方式启动保证宿主机各组件的高可用，systemd提供kubelet的高可用。

• 每个Master的使用hostNetwork网络，controller-manager和scheduler通过localhost连接到本节点apiserver。
• controller-manager和scheduler的高可用通过自身提供的leader选举功能（--leader-elect=true）。

• apiserver高可用，可通过经典的haporxy+keepalived保证，集群对外暴露VIP。
• 外部访问通过TLS证书，在LB节点做TLS Termination，LB出来http请求到对应apiserver实例。apiserver到kubelet、kube-proxy类似。

（三）Kubernetes-网络技术

（1）对外服务

Service是一个逻辑概念，一组提供相同功能Pods的逻辑集合，并提供四层负载统一入口和定义访问策略。

交互流程：Service可通过标签选取后端服务。匹配标签的Pod IP 和端口列表组成endpoints，有kube-proxy负责均衡到对应endpoint。

为什么需要service？

• 对外提供入口（容器如何被外部访问）。
• 克服Pod动态性（Pod IP不一定可以稳定依赖）。
• 服务发现和稳定的服务（Pod服务发现、负载、高可用）。

Service
Type四种方式

• Cluster
  IP：配置endpoint列表。
• NodePort：默认端口范围：30000-32767，通过nodeIP：nodePort访问 。
• LoadBalancer：适用于公有云，云厂商实现负载，配置LoadBalance到podIP 。
• ExternalName：服务通过DNS CNAME 记录方式转发到指定的域名。

Service
Type为Cluster IP：

• Kubernetes的默认服务，配置endpoint列表，可以通过proxy 模式来访问该对应服务。
• 类似通过Nginx实现集群的VIP。

Service
Type为Node Port：

在集群所有节点上开放特定端口，任何发送到该端口流量借助Service的Iptables规则链发送到后端Pod。

注意事项：

• 每个服务对应一个端口，端口范围只有30000–32767。
• 需要感知和发现节点变化，流量转发增加SNAT流程，Iptables规则会成倍增长。

适用场景：服务高可用性要求不高或成本不敏感，例如：样例服务或临时服务。

Service
Type为Load Balancer：

对公网暴露服务建议采用此方式，Service没有对其行为做任何规范，依赖云厂商LB具体实现（云厂商收费服务）如：腾讯公有云：CLB。

Service
Type为External Name ：

DNS作为服务发现机制，在集群内提供服务名到Cluster IP的解析。

CoreDNS ：DNS服务，CNCF第04个毕业项目，KUBERNETES的1.11版本已支持。

CoreDNS实现的高性能、插件式、易扩展的DNS服务端，支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS。

Ingress Controller：定义入流量规则，可做七层HTTP负载君合。

Egress Controller：定义出流量规则。

交互流程：通过与Kubernetes API 交互，动态感知集群Ingress 规则，按照自定义的规则生成（负载均衡器）配置文件，并通过reload来重新加载。

（2）Underlay与Overlay网络

Underlay网络模式: 底层承载网络，是网络通信的基础。

• 优势：复用基建，网络扁平，性能优势。
• 劣势：协作复杂，安全问题，管理成本。

很多场景下业务方希望容器、物理机和虚拟机可以在同一个扁平面中直接通过IP进行通信，通过Floating-IP网络实现。

Floating-IP模式将宿主机网络同一网段的IP直接配置到容器中。

这种模式为了保证容器与宿主机的交换机二层连通，需要在物理机上搭一个虚拟网桥。

具体选择哪种网桥，主流有：Linux bridge、MacVlan、SRIOV 三种模式。

• BridgeBridge：设备内核最早实现的网桥，性能与OVS相当，可以使用到所有场景。
• MacVlan：一个简化版的bridge设备，为了隔离需要内核，实现时不允许MacVlan容器访问其宿主机IP和Service
  Cluster IP。
• SR-IOV 技术：一种基于硬件的虚拟化解决方案，可提高性能和可伸缩性。

SR-IOV标准允许在虚拟机之间高效共享 PCIe（快速外设组件互连）设备，并且它是在硬件中实现的，可以获得能够与本机性能媲美的 I/O 性能。

Overlay网络：是一种建立在另一网络之上的计算机网络。

• 优势：独立自治，快速扩展，网络策略。
• 劣势：复杂层级，性能损失，定制成本。

Kubernetes相当于云原生的操作系统。

有人会问，凭什么云原生的操作系统这杆大旗？

主要原因是：Kubernetes解决了一个分布式操作系统最核心的计算、存储、网络三种资源。

CNI容器网络统一标准

1. CNCF项目，为Linux容器提供配置网络接口的标准和以该标准扩展插件提供基础函数库。
2. CNI命令行调用规范，其插件在主机上直接切换进入容器网络命名空间，为容器创建网络设备，配置IP，路由信息。

CNI规范内容：

1. 输入：ADD/DEL控制指令，CNI目录，容器ID，网络命名空间，网卡名称。
2. 配置文件：标准部分：cniVersion，Name，Type，IPAM。
3. 输出：设备列表、IP资源列表、DNS信息。

插件应用如：

1. Bridge：Linux网桥CNI实现，采用网卡对链接网桥和容器。
2. Host-device：将主机设备直接移动到容器命名空间中。
3. PTP：创建虚拟网卡对，采用路由方式实现对外互联。
4. MacVlan：网卡多Mac地址虚拟技术完整支持vlan。
5. Vlan：Vlan设备CNI实现，允许容器和主机分属不同LAN。
6. IPVlan：网卡上基于IP实现流量转发。

（3）Overlay网络-Flannel方案

CoreOS（被Red Hat收购）为 Kubernetes专门定制设计的overlay网络方案。

03层网络方案实现：在每台主机部署flanneld进程实现网段分配，路由控制，采用多种转发机制实现流量跨机交互。

Flannel职责：

1. 子网管理：每个主机分配唯一的子网。
2. 互联方式：为同Overlay平面容器分配唯一IP。

Etcd存储：容器之间路由映射。

SubNetManager：子网资源划分、IP资源申请释放的接口定义。

Backend：针对网络互联方式的接口定义。

1. UDP，UDP封包转发，建议仅调试使用。
2. VxLAN(建议)，使用内核vxlan特性实现封包转发。
3. Host-GW，主机2层互联情况下较高性能互联方式。
4. IPIP，使用IPIP隧道完成封包和转发。
5. IPSec，使用IPSecurity实现加密封包转发。
6. AliVPC，对接阿里云VPC路由表实现网络互联。
7. AWSVPC，对接Amazon VPC路由表实现网络互联。

Flannel的单机互联方案：

子网分配：充当虚拟交换机/网关角色，连接所有本机容器，完成虚拟子网构建。

Bridge：通过NAT借助主机网络实现外部服务访问。

Veth pair：一端设置到容器网络namespace，一端链接bridge实现容器接入网络。

对外访问：为每个节点分配独立不冲突的24位子网。

Overlay解决方案：跨Node的Pod之间通信通过Node之间的Overlay隧道。

职责：路由控制，数据转发。

主要流程：

• 本节点设置：设备创建、本地路由创建、回写本地信息。
• 监听其他节点信息：更新ARP信息、更新FDB、更新路由信息。

（4）Overlay网络-Calico方案

Calico项目：是纯三层的虚拟网络解决方案，旨在简化、扩展和保护云网络的容器方案。

Calico优势：

• 可扩展性：采用IP路由支持大规模网络。扩展便利，容错性高。
• 网络安全：支持Kubernetes 网络策略，支持自定义网络策略。
• 广泛集成：集成Kubernetes ，Mesos，支持OpenStack，AWS，GCE，Azure。

Calico不足：

• BGP支持问题：需要网路设备支持BGP协议，否则需要追加IPIP隧道。
• 规划2层直连：需要节点做良好的规划实现2层网络直接互联。
• 大规模配置复杂：网络规划，手动部署Route
  Reflector，增加API代理。

关键组件：

• BGP
  Client：和其他节点互联，发布当前节点路由并学习其他节点路由。
• Confd：同步节点配置信息启动BGPClient。
• Felix：负责虚拟设备监控，ACL控制、状态同步的agent。
• Calico：CNI插件，负责容器设备创建。
• Calico-IPAM：CNI插件，负责容器网段管理与IP地址管理。
• RouteReflector：对接BGPclient实现路由中转。
• Etcd/Kube-apiserver：Calico数据存储。
• typha：应对大规模节点接入时作为数据缓存proxy。
• RouteReflector安装：集群超过100个节点时强烈建议启用，通过RR中转全局路由信息。

Calico单机互联方案：

• Veth-pair：一端设置到容器，一端放置在主机上，为容器提供网络出入口。
• 路由策略：针对IP和设备设置路由条目，在主机上实现互联。

Calico跨机互联方案：

• 同网段/BGP支持：主机之间通过2层直连或者网络支持路由转发至目标主机。
• 跨网段IPIP互联：网络设备不支持BGP协议情况下，采用IPIP隧道实现跨网段互联。
• 跨网段VxLAN互联（Cannel）：集成flannel，底层通过VxLAN实现跨机转发。

服务网格Istio

（一）服务网格概述

（二）Istio控制面

（三）Istio数据面

云原生-主流组件

（一）Prometheus

（二）Grafana

（三）Elasticsearch + Fluentd + Kibana

（四）Jaeger

（五）Chaos Engineering

云原生-常用网络技术

（一）主机网络

iptables是运行在用户空间的应用软件，通过控制Linux内核netfilter，来管理网络数据包的处理和转发，存在“表（tables）”、“链（chain）”和“规则（rules）”三个层面。

• 每个“表”指的是不同类型的数据包处理流程，例如filter表表示进行数据包过滤，而NAT表针对连接进行地址转换操作。
• 每个表中又可以存在多个“链”，系统按照预订的规则将数据包通过某个内建链，例如将从本机发出的数据通过OUTPUT链。
• 在“链”中可以存在若干“规则”，这些规则会被逐一进行匹配，如果匹配，可以执行相应的动作，例如修改数据包，或者跳转。

（二）Underlay网络技术

VLAN虚拟局域网：是将一个物理LAN在逻辑上划分成多个广播域的通信技术。每个VLAN是一个广播域，VLAN内的主机间通信就和在一个LAN内一样。

没有划分VLAN：LAN局域网：

• 优势：简单，静态，IP地址与交换机关联。
• 劣势：迁移域受限，不能机房内随意迁移。交换机下IP需要提前规划好，约束虚拟比。

划分VLAN：虚拟局域网：

优势：IP地址与交换机无关，虚拟机可以在机房范围内迁移。

VLAN间则不能直接互通，这样广播报文就被限制在一个VLAN内。

有人会问，交换如何区分不同VLAN？

交换机能够分辨不同VLAN的报文，需要在报文中添加标识VLAN信息的字段。数据帧中的VID（VLAN ID）字段标识了该数据帧所属的VLAN，数据帧只能在其所属VLAN内进行传输。

（三）Overlay网络技术

VXLAN虚拟扩展局域网：

• 是对传统VLAN协议的一种扩展。
• 是一种网络虚拟化技术，试图改善云计算部署的可扩展性问题。

解决哪些问题？

• vlan的数量限制（12bit->24bit），VLAN报文Header预留长度只有12bit，只支持4096个终端。
• VNI（VXLAN Network Index）标识某条指定隧道。
• 不改变IP实现服务器迁移。

传统二三层网络架构限制了虚拟机的动态迁移范围。

VXLAN在两台TOR交换机之间建立一条隧道，将服务器发出的原始数据帧加以“包装”，好让原始报文可以在承载网络（比如IP网络）上传输。

当到达目的服务器所连接的TOR交换机后，离开VXLAN隧道，并将原始数据帧恢复出来，继续转发给目的服务器。VXLAN将整个数据中心基础网络虚拟成了一台巨大的“二层交换机”。

VXLAN网络模型

• UDP封装（L2 over L4）：将L2的以太帧封装到UDP报文即（L2overL4）中，并在L3网络中传输。
• VTEP，VXLAN隧道端点，对VXLAN报文进行封装和解封装。
• VNI，VXLAN隧道标识，用于区分不同VXLAN隧道。

• 矢量性协议：使用基于路径、网络策略或规则集来决定路由。
• AS（自治域）：AS是指在一个实体管辖下的拥有相同选路策略的IP网络。

BGP网络中的每个AS都被分配一个唯一的AS号，用于区分不同的AS。

• eBGP（域外BGP）：运行于不同AS之间的BGP，为了防止AS间产生环路。为了防止AS间产生环路，当BGP设备接收EBGP对等体发送的路由时，会将带有本地AS号的路由丢弃。

• iBGP（域内BGP）：运行于同一AS内部的BGP，为了防止AS内产生环路。
• RR（路由反射器）：通过集中反射同步，解决全连通的网状网格结构路由同步问题。

EBGP+IBGP实现AS间的路由传递：一个常见的IP骨干网的拓扑结构，骨干层和汇聚层分别是两个自治系统，AS100有两个出口设备SwitchC和SwitchD，两个AS之间需要进行路由互通。

总结-云原生

云原生应用：docker应用打包、发布、运行，Kubernetes服务部署和集群管理，Istio构建服务治理能力。

云计算以“资源”为中心，关键技术：

• 虚拟化：SDX，NFV。
• 资源池化：弹性快速扩缩容。
• 多租化：提升云厂商的资源利用率。

典型代表：计算、网络、存储三大基础设施的云化。

云计算以“应用”为中心，关键导向：

• 设计之初，关注更好适应云，充分发挥云优势。
• 云原生已成为企业数字创新的最短路径。
• 云原生一系列IAAS、PAAS、SAAS层技术，支撑产品高效交付、稳定运维、持续运营。

【私人观点】

• 以“资源”为中心的云，将成为“底层基础设施”，利用云原生以“应用”为中心赋能自身业务。
• 云的时代，已经来临。作为云的使用者、从业者，更多思考如何利用云赋能业务产品。
• 商业市场模式从“大鱼吃小鱼”靠信息不对称，向“快鱼吃慢鱼”转变。我们必须利用趋势，拥抱云原生。

阅读原文