「云计算」背景知识概览 ☁️

梳理云上最具代表性的各项能力，帮助全面了解云计算，也为云上实践打下基础

云计算

云计算的演进总结：

工作负载的变化：从早期的物理服务器，通过虚拟化技术演进为虚拟机，再通过容器化技术演进为目前的容器。
隔离单元：无论是启动时间还是单元大小，物理机、虚拟机、容器一路走来，实现了 从重量级到轻量级 的转变。
供应商：从闭源到开源（从 VMware 到 KVM，到 OpenStack，再到 Kubernetes），从单一供应商到跨越多个供应商（从公有云到自建云，再到混合云）。

XaaS 的简单归纳：

IaaS（Infrastructure as a Service，基础设施即服务），指云计算所提供的计算、存储、网络等基本底层能力，客户不用关注物理机器，只需关注基础架构及应用程序；
PaaS（Platform as a Service，平台即服务），指基于云底层能力而构建的面向领域或场景的高层服务，如数据库、应用服务等，客户不用关注基础架构，只需关注应用程序；
SaaS（Software as a Service，软件即服务），指基于云构建可开箱即用的各种业务应用，此外还有 FaaS（Function as a Service）、CaaS（Container as a Service），客户只需关注功能和数据。

在过去的二十年间，云计算几乎重新定义了整个行业的格局，越来越多的企业开始降低对 IT 基础设施的直接资本投入，不再倾向于维护自建的数据中心，而是开始通过上云的方式来获取更强大的计算、存储能力，并实现按时按需付费。

这不仅仅降低 IT 支出，同时也降低了整个行业的技术壁垒，使得更多的公司 尤其是初创公司可以更快地实践业务想法并迅速推送到市场。（正是在初创公司实习才开始使用到容器服务 ☁️）

IaaS [aɪæs]

IaaS 的本质，是对云数据中心和各类 IT 基础设施的抽象，是基于软件技术对物理硬件进行的封装和虚拟。

区域

在云计算行业中，区域对应的则是云计算厂商在某个地理位置提供的所有云服务的组合，是厂商对外提供云服务的基本单位和容器。区域的设立和分布，相当程度地体现了云厂商的业务重点和地区倾向。云厂商在选址时一般会有两种思路：

一种是考虑放在 人口稠密的中心城市，离用户和商业更近，以提供较快的接入体验；
另一种则是在 相对偏远的地区，当地往往能够提供良好的气候条件、充足的建设空间，以及较低的电力、带宽等运营维护成本。

如何选择合适的区域

区域的地理位置本身。 如果场景中需要本地数据中心与云端进行互联，也就是混合云架构，其专线接入一般以同城或短距离接入为主，这样能够较好地控制费用，同时提高线路的稳定性。
区域之间云服务的差别。 换句话说，同一个云在不同的区域，所能提供的服务和规模可能是不同的。新旧区域哪个更好，需要根据服务需求和待选区域的实际情况来综合衡量。
成本因素。 即便是同一种服务的价格，在不同区域也往往是不相同的。区域的流量费用也需要注意，如果把区域作为一个有边界范围的实体圈起来，这个流量可以分为三类：入站流量、出站流量和内部流量。

多区域架构

多区域架构指的是部分关键应用，为了追求最佳的用户体验和高可用性，需要把多个区域的资源和能力结合起来进行构建。主流云厂商在跨区域方面也进行了大量建设和投资，主要体现为：

物理上，各区域之间建设有网络互联专线，一般称为骨干网（Backbone）。骨干网的存在使得同一个云在不同区域间的通信，能够有较高的带宽和较低的延时。
软件层面，允许位于不同区域的虚拟网络跨区域进行互联，使得多区域的私有内网能够借助自有骨干网无缝高速打通。
DNS 解析层面，通常会提供就近解析和智能路由能力，将分布广泛的 C 端流量引流到最近的数据中心，以获得最快的响应速度。

公有云的基础设施（尤其是骨干网的存在）能够极大地方便我们构建多区域的应用程序。通过合理架构完全可以让多个区域的云服务融为一体。借助云的力量，小厂也能轻松拥有巨头的分布式部署能力。

在应用架构层面，多区域并不意味着需要把某区域的资源复制到其他区域，而是可以根据实际情况各司其职，让不同区域担任不同的角色，联动起来达到业务目的。

比如，可以将面向消费者服务的触点部署到多个区域，就近服务各地区的互联网流量，而偏后台的数据分析和 BI（Business Intelligence）服务，则可以安置在性价比较高的非一线城市区域，业务数据可通过骨干网不断回传。这是一种经典的分工模式。

当然，也不应当走向另一个极端：轻率、随意地拓展区域。每一个区域的增加，都会相应增加应用架构的复杂性和流量费用，也给我们的维护工作带来负担，这些额外的成本可能会抵消多区域架构带来的好处。

可用区

可用区是区域的下级概念，是指一个具备完整而独立的电力供应、冷却系统、网络设施的数据中心单元。

高可用性
拓展性

尽管数据中心内部有着非常精密的运作系统和冗余机制，但地震、火灾、雷击等极端情况下，仍有可能造成数据中心级别的故障。为了避免单个数据中心故障让整个区域不可用，那自然就有必要建设多个相对独立的数据中心，也就是多个可用区了。

区域本身也有扩展的需求。一些区域由于早期的容量规划和成本控制原因，很可能在若干年的运营后就会变得资源紧张、后劲不足。这时得益于可用区的机制，区域可以通过新建可用区，不断扩展自身容量，补充新鲜血液；而老旧的可用区，则可不对新用户开放，逐步封存甚至淘汰，这让区域形成了良好的新陈代谢机制。

可用区的数量也可以成为一个衡量区域规模的重要指标。数量越多，意味着这个区域规模越大。

云虚拟机

云虚拟机即在云端虚拟出的服务器，虚拟化技术是云虚拟机服务的核心，它本身是一个非常宏大的技术领域。比如 Xen、KVM、VMWare、HyperV 等等虚拟化产品和技术。云计算中所使用的虚拟化技术，也大都是从这些虚拟化实现方式演化而来的。云端的虚拟化技术在不断进步和发展，使得云端虚拟化的性能损耗在不断减少、资源利用率不断提升。

云虚拟机与传统虚拟机的不同

云虚拟机的体系结构是全面解耦的 计算存储分离 的设计思想。传统的虚拟化，往往是对单一物理机器资源的纵向切割，计算、存储、网络等各方面的能力都是一台物理机的子集，从 可伸缩性 的角度来说，传统虚拟机存在较大的局限，当物理机的局部出现故障时，也很容易影响到里面的虚拟机。以下是简化的示意图：

这样虚拟出来的机器，我们在使用感受上其实与传统服务器并无不同，但在可扩展性和故障隔离方面，它就具有很大的优势了。各家厂商的云虚拟机服务的名称会略有不同，阿里云称为云服务器 ECS（Elastic Compute Service），AWS 称为 EC2（Elastic Compute Cloud），Azure 就叫 Virtual Machine，腾讯云则叫做云服务器 CVM（Cloud Virtual Machine）等等。

网络安全组（Network Security Group, NSG）

网络安全组可以理解为一层覆盖在虚拟机之外的网络防火墙。它能够控制虚拟机入站、出站的流量，并能根据协议、端口、流向等所设定的规则，来决定是否允许流量通过。

网络安全组并不工作在操作系统层面，而是在操作系统层之外，是额外的一层防护。非法流量在尚未到达 OS 的网络堆栈之前，就已经被它阻断了。所以 NSG 的一个优点在于，它不会影响 VM 的性能。

网络安全组是一种可复用的配置。如果有大量虚拟机适用于同样的网络控制规则，就能够很方便地让它们使用同一个网络安全组，它体现了云计算中 软件定义网络 的特点。

虚拟机类型

决定虚拟机配置的最重要的三个要素，即 类型、代别和实例大小。

云厂商会提供通用均衡型、计算密集型、内存优化型、图形计算型等常见的虚拟机类型，CPU 数和内存大小（按 GB 计算）的比例，是决定和区分虚拟机类型的重要指征之一。

通用均衡型 的比例通常是 1:4，如 2 核 8G，这是一个经典的搭配，可用于建站、应用服务等各种常见负载，比如作为官网和企业应用程序的后端服务器等。
如果 vCPU（Virtual CPU）和内存比是 1:2 甚至 1:1，那就是 计算密集型 的范畴，它可以用于进行科学计算、视频编码、代码编译等计算密集型负载。
比例为 1:8 及以上，一般就会被归入 内存优化型 了，比如 8 核 64G 的搭配，它在数据库、缓存服务、大数据分析等应用场景较为常见。
图形计算型 就是带有 GPU 能力的虚拟机，一般用于机器学习和深度学习模型的训练和推理。
本地存储型 是指带有高性能或大容量的本地存储的机型。

同类型虚拟机的更新换代，往往首先会带来相应硬件 CPU 的换代提升。随着一代新机型的推出，云厂商一般都会详细说明背后支撑的硬件详细信息。很多时候也伴随着底层软硬件架构的更新和提升，尤其是 虚拟化技术 的改进。

实例大小（Size），也就是硬件计算资源的规模。业界常常使用 medium、large、xlarge 等字眼来进行命名区分，标准 large 对应的是 2vCPU 的配备，xlarge 则代表 4 个 vCPU，而更高的配置一般用 _n_xlarge 来表达，其中 n 与 xlarge 代表的 4vCPU 是乘法关系。

因为超线程（HyperThreading）技术的普遍存在，常常一个核心能够虚拟出两个 vCPU 的算力，但也有些处理器不支持超线程

在某些场景下，可能还会看到“metal”或者“bare metal”这样的描述规格的字眼，中文称为“裸金属”。它们就是云服务商尽最大可能 将物理裸机以云产品方式暴露出来 的实例，主要用于一些追求极致性能，或是需要在非虚拟化环境下运行软件的场景。

云硬盘

云硬盘，又叫做“云盘”或者“云磁盘”，就是云虚拟机上可以挂载和使用的硬盘。这里，它既包含了用于承载操作系统的系统盘，也包括了承载数据的数据盘。有时还会把云端磁盘服务叫做块存储（Block Storage），因为它们与 Linux 操作系统中的块设备相对应，是云上提供的“裸盘”，可以格式化并且施加文件系统。

云硬盘与传统磁盘的真正差异在于，绝大多数的云硬盘都是远程的。在经典计算机的体系结构中，硬盘是通过本地机器内部主板的高速总线，与 CPU、内存等部件相连接；而在云端，硬盘则很可能并不在宿主机上，而是在专用的磁盘服务器阵列中，两者是通过数据中心内部的特有 IO 线路进行连接。这也正是 计算存储分离架构 的一种体现。

当下的云硬盘经过了多次的软硬件迭代，尤其是 SSD 的迅速发展，吞吐量和随机读写能力等各项性能指标都已经不再是问题了。云硬盘的性能等级的分为 HDD、SSD/HDD、SSD、高性能 SSD：

基于传统 HDD 硬盘构建而成的，性能一般，成本低，在不注重性能的测试环境，或者是个人自用的服务器；
基于混合硬盘，也就是结合 HDD 和 SSD 硬盘构建的云硬盘，比较适合像是操作系统启动盘这样的常规负载；
纯 SSD 硬盘，可以用它来承载生产环境中重要的关键业务应用，或是各类数据库等 IO 密集型应用；
进一步优化增强的 SSD 云盘，采用更新一代的企业级闪存硬件，配合改进后的底层传输协议和虚拟化技术栈的优化来提供服务。

同等的性能等级下，云硬盘的容量越大，一般来说它的性能就越高，直到达到这个等级的上限，这是由云上磁盘能力共享的底层设计所决定的，所以在某些时候，可能需要刻意地增大所申请的云硬盘的容量，以获取更高的性能，即便这些额外的空间不一定能被用上。

云盘的热挂载特性让它使用起来特别灵活方便，而且大小性能可以调度，挂载后和本地硬盘操作没有什么两样。当一些应用软件系统本身考虑到了硬件的不可靠性，设计了上层的存储冗余机制时，也可以考虑采用云虚拟机的本地磁盘，当机器关机或删除，以及出现硬件故障时，本地磁盘上的数据就可能损坏或丢失。

虚拟网络

虚拟私有网络

虚拟私有网络（Virtual Private Cloud，简称 VPC），是云计算网络端最重要的概念之一，它是指构建在云上的、相互隔离的、用户可以自主控制的私有网络环境，虚拟私有网络有时也称为专有网络或虚拟网络。

私有网络就是一张内网，内网之内的服务器和设备可以比较自由地互相通信，与外界默认是隔离的。如果外部互联网，或者其他虚拟网络需要连接，则需要额外的配置。

在传统数据中心里，经典网络架构中的概念和组件，在虚拟网络中几乎都能找到对应。比较重要的一些概念包括：

网段，私有网络的内部 IP 区段，通常用无类别域间路由（Classless Inter-Domain Routing， CIDR）形式来表达，如 192.168.0.0/16。
子网，私有网络的下级网络结构，一个私有网络可以划分多个子网，这和通常意义上的子网也是对应和一致的；
路由表，用于定义私有网络内流量的路由规则，决定着数据包的“下一跳”去向何方。每个子网都必须有一张关联的路由表，通常情况下，系统会自动创建一个默认的路由表；
网关，是对进出私有网络的流量进行把守和分发的重要节点，根据用途的不同，有多种类型；
安全组，私有网络里虚拟机进出流量的通行或拦截规则，可以起到虚拟机网络防火墙的作用。

VPC 属于局域网，按照 RFC （Request for Comments，互联网技术发展和标准化的核心资料）规范，能够使用的 IPv4 区段必须为 192.168.0.0/16、172.16.0.0/12、10.0.0.0/8 这三个或它们的子集。

如果在没有 VPC 的情况下直接创建虚拟机，公有云一般都会自动生成 VPC。

可以建立跨可用区，也就是跨同区域内不同数据中心的私有网络，这是 VPC 的一个强大的特性，能够为我们私有网络的高可用性提供保障。比如，可以让主力集群在一个可用区工作，备用集群在另一个可用区随时待命，需要时迅速切换，也可以把流量同时分发到不同的可用区，动态控制分发策略。

私有网络中的虚拟机

一个虚拟网络已经存在时，就可以 将新创建的虚拟机放置在这个虚拟网络中，虚拟机和专有网络的连接点是虚拟机的网卡，又称 弹性网卡（Elastic Network Interface，简称 ENI）。虚拟机的网卡一方面是和虚拟机的本体进行绑定，另一方面则嵌入某个私有网络的子网，也会拥有至少一个私网 IP。云上的网卡，之所以被称为“弹性”网卡，是因为它具备以下特征：

一个虚拟机可以绑定多块网卡，有主网卡和辅助网卡之分；
一块网卡隶属于一个子网，可以配置同一子网内的多个私有 IP；
辅助网卡可以动态解绑，还能够绑定到另一台虚拟机上。

当在创建虚拟机的时候，向导会询问这台虚拟机属于哪个 VPC，以及 VPC 下的哪个子网。这个选项的实质性结果，就是新虚拟机自动生成的主网卡，接入了所选 VPC 的所选子网。

对于生产环境尽量不要使用和依赖自动生成的 公有 IP，因为它本质上是一个从公有云的 IP 池中临时租用的 IP，如果机器关闭或重启，下次获得的 IP 可能就完全不同了。这时，应该用到的是弹性 IP（Elastic IP），弹性 IP 一旦生成，它所对应的 IP 是固定、不会变化的，非常适合需要稳定 IP 的生产环境，它所谓的弹性，其实是指可以非常自由地解绑和再次绑定到任意目标。

私有网络对外的出入口

如果一台云虚拟机没有被赋予公有 IP，为了安全控制，默认情况下它就失去了访问外网的能力，只能进行内网通信。但也有一些情况，希望内网的机器和外界并不完全隔离，一些互联网流量需要有序地引进来，一些内网机器也需要访问外网。

如果需要访问外网的虚拟机数量有很多，这种办法就需要很多弹性 IP，管理上就太麻烦了，成本也不划算
还有一个问题是，弹性 IP 带来的是双向的开放，有时我们只想允许单向的连接

这就是网关可以大显身手的场景了，它正是用来统一协调管理私有网络与外部通信的组件，网关有很多种类型，比如 NAT（Network Address Translation）网关，用于在私有网络与公共网络之间进行通信：

目标网络地址转换（Destination Network Address Translation，DNAT）是 NAT 的一种形式，它主要用于将外部请求的目标 IP 地址转换为内部网络中的特定 IP 地址。
源网络地址转换（Source Network Address Translation，SNAT）是 NAT 的另一种形式，它用于将内部网络中的源 IP 地址转换为公共网络可路由的 IP 地址。

还有一种网关被称为 VPN 网关，也可以帮助外界连接到 VPC，它本质上是基于 VPN 技术。由于 VPN 能够基于互联网提供私有加密的通信，因此非常适合用来从任意其他私有设施安全地连接到 VPC。这些私有设施可以小到一台个人电脑或手机终端，也可以大到是本地的数据中心，还可以是另一个 VPC。

VPN 主要用于创建安全的远程连接和加密数据传输，而 SNAT 则是一种网络地址转换技术。

当想要科学上网访问境外服务器时，需要使用 VPN 服务来连接到位于另一个国家的服务器，用户的网络流量就会通过这个远程服务器路由，从而绕过地理限制或审查制度。

使用 VPN 时，数据传输会被加密，这意味着即使数据在传输过程中被截获，第三方也无法轻易解读内容。此外，VPN 还可以隐藏用户的真实 IP 地址，只显示 VPN 服务器的 IP 地址，从而保护用户的隐私和安全

API 网关 是一个独立的 PaaS 服务，它的作用是为外界访问提供一个端点，并引流到我们的后台计算服务。有点类似传输层的负载均衡，但 API 网关是工作在网络的 应用层，它的后端可以连接指向云函数等多种服务。

另外，API 网关还能够提供不少应用层的实用功能，比如 访问鉴权、限流熔断、版本控制 等等。

多网连接的方式

公有云上是允许同时使用多个 VPC 的，这样可以构建更加复杂的网络架构，实现模块隔离和跨区域扩展等高级需求。

云端 VPC 和 VPC 的互联可以采用 对等连接（VPC Peering）的方式，能够在不添加额外设备的情况下，让两个 VPC 无缝地互联起来，对等连接甚至还能够支持跨区域的私有网络互联，但是它 不具备传递性；
如果需要多个 VPC 间任意路径的互联互通，可以考虑使用 专用网络设施，允许进行更精细的路由设置；
公有云中的私有网络，还可以和企业本地数据中心进行互联，形成 混合云架构，可以先考虑使用 VPN 这种轻量的方式，通过公网线路为两边建立连接渠道，如果应用场景要求保证延迟和带宽就需要专线进行连接，一般专线还会和 VPN 一起组合使用，来保证通道的高可用性。

混合云的构建是一项较为复杂的工程，通常需要由本地机房、云厂商、电信运营商三方配合进行，也牵涉到本地数据中心端的网络规划和路由设备适配。

故障与伸缩

服务等级协议（Service Level Agreement，SLA）主要是用来对服务的可靠性作出一个预期和保证。SLA 的可用性等级可能是 99.9%，也可能是 99.99%，再好的服务也不能达到理论上的 100%。

从架构思维的角度上来说，需要假定故障就是可能会发生，对于它的影响事先就要做好准备，事先就进行推演并设置相关的冗余和预案，AWS 有一个非常著名的架构原则，叫做 Design For Failure。

云上故障分类：

第一种故障是在宿主机的级别，这也是从概率上来说最常见的一种故障。
第二种规模更大的故障，是在数据中心，也就是可用区的层面。（火灾、雷击等物理破坏）
第三种更严重的故障，就是整个区域级别的事故了。

应对的基本思想是化单点为多点，形成不同层面、不同粒度的冗余。

弹性伸缩

弹性伸缩既可以提高工作负载洪峰来临时的吞吐和消化能力，提高业务稳定性，又能够在低谷期帮我们显著地节约成本。

在 IaaS 端，能够弹性伸缩的最实用的产品形态，莫过于 虚拟机编组 了，也就是功能相同的多个虚拟机的集合。把它们作为一个单位来创建、管理和伸缩，是一种普遍应用的最佳实践。把多个虚拟机以弹性伸缩组的方式进行统一管理，能够极大地提高效率，减轻负担。因为弹性伸缩服务，会帮我们动态地创建和销毁虚拟机实例，自动根据我们指定的数量和扩缩容规则，来协调虚拟机的生命周期。

弹性伸缩服务，在云端还有一个最佳拍档，就是 负载均衡器。将流量均匀地，或者按照一定权重或规则，分发到多台虚拟机上，正好可以和提供计算资源的弹性伸缩服务形成配合。当负载增大、虚拟机增加时，负载均衡也能够自动动态识别，将流量分发到新创建的虚拟机上。

使用弹性伸缩服务来实现云端弹性架构，用它来管理一组虚拟机，并与负载均衡一起配合。这特别适合处理无状态类的计算需求，因为它会代劳底层计算资源的管理。

云上运维

云的引入能够让我们在更高的层面去思考和解决问题，比如说，

云端基础设施的存在，可以让运维从偏硬件服务器、偏物理机房的日常繁琐工作中解脱出来，更多地基于云在软件的层面，进行部署、监控、调整。
而云上的高质量、高可用的服务，也能避免我们重复建设，不用自己造轮子，也大大减轻了运维负担。

底层的机房运维、基础架构运维仍然会继续存在，但会向头部的云供应商大规模集中，这属于云厂商的运维视角

云其实是提高了运维的效率，改变了运维的形态，与此同时，由于云上运维的软件属性显著增强了，它就自然地和研发会有更强的融合。近期 DevOps 理念和云原生热潮的兴起，就说明了这一点。许多工作慢慢地会分不清它究竟是属于运维还是研发，因为 两者的界限正在模糊。

云时代的运维利器

几乎每个云都推出了自己的命令行工具，比如 AWS CLI、Azure CLI、阿里云 CLI 等，除了命令行工具，各云还都提供了开发者工具包（SDK）。如果资源调度逻辑相当复杂，或者需要与自己的程序集成，那么可以考虑使用相应语言的 SDK，来进行云上的一些资源管理操作。

如果要频繁地在云上部署一套包含众多资源项的复杂系统，还有另外一个得力的帮手：资源编排类云服务。属于这个领域的服务包括有 AWS CloudFormation、 Azure 的 ARM Template、阿里云资源编排服务（ROS）等，它们都可以通过使用一个 JSON 格式的文本文件，来描述和定义一个系统中所有的组件，以及它们互相之间的关系。

云运维由哪些工作组成

在云端，传统的运维工作仍然存在，其中包括所熟知的 监控、部署、升级、备份 等

监控一直是运维最核心的工作之一。几乎所有的云端服务都自带有一定的监控功能，默认提供了不少内置的维度指标和可视化图表，这些开箱即用的图表要充分利用好，它们能够很好地帮助了解相关服务的状态。
备份是一个简单但又很容易被我们忽视的事项。在云上需要创造多层次的冗余，而备份在创造冗余方面也承担着重要的角色，有的时候它会是最后保障。
迁移是带有云端特色的运维任务，因为只要不是在云上创建的全新业务，传统业务在逐步上云的过程中一定会面临迁移工作。
云上的运维会包含和云厂商进行对接的工作，运维团队中需要有相应的角色对云的工单机制，以及技术支持侧的对接方式了然于胸，以备不时之需。
具有管理属性，比如对于云资源的命名、开通、清理等日常操作的规范，各类云上安全的控制和最佳实践，所有云资源的负责人、所属资源组和权限体系等，还有一项重要事务就是 成本管理。

当前业界的一个重要趋势是，运维和开发的边界正在模糊。所以我在前面提到的诸多运维工作，可能是由开发者来负责，也可能是运维人员来承担。

作为开发者，应该学习和掌握一些运维的知识和技巧，让自己变得更加全面和综合；

作为运维人员，也应该学习了解现代软件构建和系统架构方面的知识，尤其是学习云、掌握云，为云端架构的全面到来做好准备。

PaaS [pæs]

虚拟机、云磁盘、云网络等服务的特点是，和传统 IT 基础设施往往有一个对应关系，所以被称为基础设施即服务（Infrastructure-as-a-Service）。PaaS （Platform-as-a-Service），则是指云计算提供的平台类服务，在这些平台的基础上，用户可以直接开发、运行、管理应用程序，而无需构建和维护底层的基础设施。

PaaS 是在 IaaS 的基础上又做了许多工作，构建了很多关键抽象和可复用的单元，让我们用户能够在更上层进行应用的构建，把更多精力放在业务逻辑上。

PaaS 服务的优势，就在于生产力，在于效率，尤其是在搭建和运维层面。

对象存储

对象存储（Object Storage）就是在云端可以存放任意对象的存储服务。这里的“对象”指的是任意的二进制对象，保存到云上通常是以二进制文件的形式。

对象存储不但注重打造存储的核心能力，还建立了一整套成熟的管理控制机制，更能够方便地与各种应用程序集成。

对象存储和云硬盘的区别

访问的接口与形式
- 云硬盘是挂载到虚拟机的虚拟硬盘，它是通过实现操作系统级别的底层接口，作为虚拟机的 块存储设备 而存在，所以也必须连接到相关的虚拟机，才能访问它里面的数据。
- 对象存储本质是一个网络化的服务，调用方主要通过高层的 API 和 SDK 来和它进行交互。不管是面向外部公开互联网服务，还是和内部应用程序对接，对象存储都是通过提供像 HTTP 这样的网络接口来实现的。独立性很强，不需要依赖其他组件就可以运作。
对象存储内本身不存在一个真正的文件系统，而是更接近一个键值（Key-Value）形式的存储服务
- 键就是对象的路径（路径中包含斜杠符号“/”），这里的值就是存储对象的二进制文件
- 键值系统和云硬盘上经典文件系统的核心差异，就在于文件系统保存了更多的元数据，尤其是实现了目录结构和目录操作
- 键值系统中所谓的目录其实是多个对象共享的路径前缀（模拟出的目录），这样的设计也使得对象存储中的“目录”操作代价变高了，比如说目录的删除和重命名
可扩展性（Scalability）：对象存储的巨大容量
- 对象存储能够轻松地容纳上 PB 的超大容量数据，这是任何的云硬盘所不能企及的
- 对象存储本身也是非常擅长和适合处理小文件的，即便是海量的小文件，对象存储也不会像 HDFS 那样处理起来捉襟见肘
- 得益于冗余机制，一般都有高达 99.999999999%（11 个 9）的数据可靠

对象存储的高级特性

存储分层
- 可以按照访问热度，设置 从热到冷 不同的存储级别（或者叫存储类型）
- 这些存储级别其实是一种在访问效率和存储成本之间的平衡
- 很多用户上云的一个应用场景就是，把原本占用大量传统磁盘的备份文件，利用对象存储的归档能力长期保存
生命周期管理
- 生命周期管理功能允许设置一定的过期规则，当对象满足规则时，可以自动地执行一些清理操作
- 比如，要求最后修改时间超过 60 天的文件自动切换到低频访问层，超过 180 天的文件则进行归档或删除
对象的版本管理
- 对象存储系统就能够自动地记录这个对象之前的多个版本，可以按需进行回滚和恢复，避免不必要的损失
跨区域同步、访问日志分析等
- 自动对数据进行跨区域同步，常用于重要数据备份或热点数据分发
- 对已经存放了海量数据的对象存储进行管理分析

对象存储的应用场景

一切需要保存数据的地方，不论是原始数据的保留备份、中间结果的临时落地，还是处理结果数据的永久保存，都可以考虑对象存储是否适用。
对象存储可以直接面向公开互联网，作为文件服务器对外提供服务，通过妥善设置对象的 HTTP 响应头，甚至还能支撑起静态网站，免去我们创建虚拟机的麻烦。
如果下载量比较大，且对带宽延时有更高要求的话，它又能无缝地与云上的 CDN 服务进行集成，作为 CDN 的回源站点

应用托管

在云计算发展的早期，就已经出现了“建站类服务”，这正是应用托管服务的雏形。当时的建站类服务，会自动分配好服务器，安装好相应语言的 Web 环境以供使用。在部署层面，服务通常会开放 FTP 端口，以便上传服务器端的代码、脚本和资源。这是应用服务的一种轻量形式。更现代的应用托管服务，不但在细节选项、自动化程度上进步了许多，还包含了大量的增值服务。

应用服务的本质就是为应用提供一个隔离的独立运行环境，作为用户来讲，可以只专注于业务逻辑，不需要来手动创建这个环境，更不需要运维这个环境。

应用托管服务背后采用的隔离技术对用户一般是不可见的，它可能是虚拟机，可能是 Docker，或者是自研的其他容器类技术。

应用托管服务背后采用的隔离技术对用户一般是不可见的，它可能是虚拟机，可能是 Docker，或者是自研的其他容器类技术。

应用托管的增值服务

监控，针对 Web 应用的特点而进行的 HTTP 层面的应用监控
- 不仅能看到计算资源的占用率，如 CPU、内存使用率等
- 还能看到许多应用层指标，比如总请求数、错误响应数、并发连接数、响应时间等
- 基于这些监控的指标，还能够在云上制定相应的报警规则
扩展，既包含了底层机器配置的垂直扩展，也包含了机器数量层面的水平扩展
- 应用托管服务不是只能对应一台机器，而是能够创建多台机器来承接请求，并会在前端均衡地分发到多个实例上去
集成，与其他 PaaS 的集成
- 在监控数据方面，可以和云监控系统进行衔接；有些云允许 Web 应用以目录的形式，挂载对象存储中的文件
- 还可以与云上 DevOps 组件和流程无缝对接；
- 此外还有远程调试和诊断、运行环境自动补丁升级、私有网络内的部署、Web 防火墙防护等

云数据库

云上的关系型数据库

RDS（Relational Database Service）和传统关系型数据库

云数据库在外部交互的层面上，保持了和传统“原版”数据库几乎完全一致的编程接口和使用体验
- 早期比较简单的云数据库实现原理，是充分利用云上已经提供的虚拟机、云磁盘等 IaaS 层面的资源，在隔离的环境下进行数据库镜像的安装
- 后来技术实力比较强大的厂商，还能够做到对数据库源码和模块的深度定制，在保证兼容性的前提下，进行许多对用户透明的云端适配和优化
- 云数据库尽管是一个受限的 PaaS 环境（比如它通常无法直接访问底层的服务器），但在使用体验上和传统数据库是相当一致的
云数据库和传统数据库有很大的区别，指在搭建、运维、管理层面
- 比如灵活的性能等级调整、详尽的监控体系、攻击防护机制等
两个最具代表性的云上关系型数据库的高级特性
- 支持读写分离，从创建从库到建立同步，再到读写流量分发，云数据库都能自动完成
- 支持自动调优，自带的性能分析与改进模块，能够自动地发现性能热点，甚至还能够智能地给出调整建议

自研云原生数据库

云厂商们不满足于封装现有的数据库，而是极具野心地开始构建完全为云设计、能够充分发挥云的特点和优势的数据库。

出于生态发展和降低学习难度的需要，绝大多数的云原生数据库仍然保留了 SQL 等常见接口，除此以外，云原生数据库大都进行了全面革新和重新设计，有的云会大刀阔斧地改造开源代码，有的甚至脱离了现有包袱，完全重新构建。

更强的可扩展性
- 得益于原生设计的计算存储分离架构，云原生数据库可以支撑更大规模的数据量
- 云原生数据库可以利用云快速地进行水平扩展，迅速调整、提升数据库的处理能力
更高的可用性和可靠性
- 云原生数据库往往默认就是多副本高可用的，数据同步、读写分离等高级特性是作为原生机制的一部分天生存在的
- 得益于原生数据同步机制的底层设计，云原生数据库还能很方便地支持跨区域的实例复制，在进一步增强冗余的同时，还能便于就近服务全球用户
更好的弹性
- 在存储上不需要预先设置容量大小，而是会随着存储占用自动扩
- 在计算上，不需要使用固定的计算资源，这在面对间歇偶发或者难以预测的工作负载时，非常经济实用

云数据库之于传统数据库，是用完全不同的研发模式、商业模式和产品形态，从另一个层面发起了挑战，从而具备了竞争优势

大数据

云计算以存储、计算规模和弹性著称，而大数据方面的业务需求，恰恰需要大量的存储，和呼之即来的澎湃算力。云可以说是最适合运行大数据工作负载的平台了，大数据也成为了云上最需要解决的重要场景之一。

大数据主要是 技术手段，是一系列处理海量数据的方法论和技术实现的总称；而云是一种 资源和能力的载体，也是一种商业存在，是可以运行大数据负载和应用的平台。云上的大数据 PaaS 产品是云对大数据技术进行了封装和产品化的成果。

云上大数据的特点

保证兼容性（技术栈）
解耦计算和存储（不仅仅是开源大数据技术的移植和搬运）
按需启停（集群可以动态地创建，做完工作后立刻将集群删除）
增值服务（性能监控、集群交互工具）

容器服务

容器上云：从 Docker 到 Kubernetes

容器对于运行环境的极强适应性和快速启动的能力，配合云上动态扩展的庞大资源规模，让云端的容器应用可以在短时间内拓展到成千上万个实例。云可以说是容器应用的最佳载体，容器应用也非常适合在云上运行和扩展。

在 Docker 技术家喻户晓之前，云厂商已经在研究和使用类似容器的技术了，因为云本身是多租户的，需要运行环境的隔离性，所以云本身也是容器技术的用户和受益者。

随着容器应用的复杂化，编排逐渐成为了用户最急迫的需求，所以各厂商又纷纷推出和加强容器编排方面的解决方案，容器编排框架大战的结果是 Kubernetes “一统天下”，成为了事实标准。就现在最新的形势而言，如果要容器上云，直接选择各大云上最新的针对 Kubernetes 的服务即可。

相对于自建 Kubernetes 集群，云上 Kubernetes 服务的几个独有特点：

由于云端的多租户特性，可以免除在 Master 节点方面的开销，只需要创建 Worker 节点，并为之付费就行了
K8s 虽然复杂性较高，但抽象设计出色，能够支持大量灵活的扩展，云厂商能够让很多云平台上的 IaaS 或 PaaS 功能组件，渗透到 K8s 的体系中
- 引导外部流量的 Ingress Controller（入口控制器）方面，就有基于云上负载均衡器的控制器实现，它们会创建相应的 PaaS 服务实例，来为 K8s 集群服务
- 可以在 Kubernetes 中定义动态存储卷分配策略的 StorageClass 层面，指定使用云端的块存储服务，来按需创建和挂载持久化存储
- 云和 K8s 集成的方面还有很多，权限认证、日志集成、私有网络等
- 从架构灵活性的角度来看，云上 Kubernetes 服务还带来了另一个好处：多集群

容器镜像服务

容器的镜像是容器化程序封装后的基本单位，在云上也需要一个可以存储和管理自己程序镜像的地方，就像 Docker Hub 管理了很多公开镜像一样。在大多数云上都提供了自己的容器镜像服务，可以建立私有的镜像仓库，支持镜像的推送和拉取，还可以进行版本管理等操作。

全托管的容器实例服务

如果只是有一个容器镜像，想要尽快地在云上跑起来，那么这类服务很可能就是最佳选择。因为它简便易行，成本低、速度快，而且不需要操心底层的虚机和集群，也可以绕开复杂的编排系统，只需要关注 Pod 运行层面的目标就可以了。这是容器实例类云服务很大的卖点，尤其对于 无状态 的应用非常适合。

无服务器计算

“无服务器”是云计算中资源抽象的极致体现。所谓“无服务器”就是想让用户感觉不到服务器的存在，这是因为有一朵巨大的云在底层进行着支撑。这样可以完全专注于业务逻辑的编写，而不再关心任何基础设施。

无服务器查询服务、无服务器容器服务和对象存储服务理论上来说也是符合无服务器特征的，因为不用关心究竟是什么样的机器和多少机器在背后支撑它。

无服务器计算服务（Serverless Computing）

在粒度上，无服务器会允许用户拆分得更细致、更轻量，甚至可以把每一个具有独立功能的函数，来作为一个单独的服务进行部署和运行。这也是在有些云计算的分类方法下，无服务器计算被称为 函数即服务（Function-as-a-Service，FaaS） 的原因。

也正因为底层没有固化的资源，无服务器计算的计费机制是与众不同的。它一般会按照调用次数和调用时长这两个指标来计费。从成本上来看尤其适合那些偶尔触发、短时间运行的工作。这会比专门设立一台虚拟机来做同样的事情要划算很多。

无服务器计算是多面手

事件模型 是无服务器的核心编程模型和运行逻辑，所以它非常适合相当广泛的事件驱动开发场景。事件的起始，要依靠 触发器。

云上 Serverless 服务一般都配套提供了多种多样的触发器，包括 API 触发器、对象存储触发器、队列触发器 等。

较为常用的还有对象存储触发器。比如当用户上传了一个文件，后台程序把它保存到对象存储中，这时相应的无服务器函数会被这个新对象触发，就能对这个新上传的文件进行必要的处理了。

无服务器计算本身是无状态的，所有的持久化需求都要借助外部存储来实现，所以经常需要和数据库、对象存储等服务配合，这既是常用手法，也是必然选择。

在云端，一个常见的场景和架构范式是，云函数可以和消息队列服务形成一对黄金搭档：当队列中有新的消息进入，队列触发器就会触发云函数，并将消息作为事件参数传递给云函数；然后云函数进行及时处理，处理结果还能够再写入另外一个队列；队列又可以触发下一个云函数。如此层层传递，就可以形成一个 流式数据的处理管道，实现数据的实时处理和分发。
现在无服务器业界发展的又一个热点：即允许按照业务逻辑的控制处理流程，以工作流的方式，进行云函数等事件处理单元的组合和编排。

这里云函数工作流服务，和前面基于队列的流式处理的区别。工作流服务构建的是 控制流，定义事件发生的先后次序和条件依赖；而队列流式处理是 数据流，是数据的传递和流向。

在 事件机制 和 工作流服务 的加持下，无服务器计算就成为了一个真正的多面手。它在很多环节都能够扮演恰当的角色，除了自己承担的计算任务之外，它还擅长串联很多云端组件，成为系统组件间的胶水层。

AI 服务

AI 相关的 PaaS 服务。它们其实也大致分为两类：

一类是各种成熟能力的开放，是 云厂商已经构建好的现有模型和 API；
另一类则是机器学习的 全生命周期管理支撑平台，可以帮助构建属于自己的机器学习模型。

开箱即用的 AI 服务

这类服务的特点，一般是将非结构化数据处理分析的通用需求场景，进行了封装和开放。可以通过云端标准的 API 和 SDK 来进行调用，一般会按调用次数进行收费。

非结构化数据，指的是 图像、视频、语音、文本 等包含丰富信息的常见数字化内容。对于这些内容的理解，用传统的程序逻辑很难解决，但这恰好是人工智能的强项，它可以深入分析这些内容，并进行信息提取和转换。不同的非结构化数据类型，对应着不同的人工智能研究领域，也对应着相关的各种云上 AI 服务。

构建自己的 AI 模型

无论你想要构建哪种模型，包括经典机器学习和深度学习，它们共性的地方在于，都有一个类似的流程和步骤，包括数据准备和标注、模型训练、模型部署等。云上机器学习服务，它的目标就是非常精准地支撑和赋能这些重要环节，帮助你进行贯穿全生命周期的模型构建和管理。

云上还有 IoT 服务、区块链服务、DevOps 服务 等

云计算和云原生

云计算已经成为一个无所不包的信息技术服务平台，它抽象了多个大型数据中心内的海量计算存储资源，对外提供了从基础设施到托管平台不同层次、不同粒度的在线服务和组件，同时也是各个领域最新前沿技术和架构理念的最佳载体。

云计算还是一种行之有效的商业模式，是一门好的生意，能够持续有效地获得巨大营收和利润。这也是云计算行业得以聚拢人才、持续发展的原因。

云计算 其实是一个载体和平台。这个平台之上承载着从 IaaS 到 PaaS 林林总总的能力，每项能力中既包含了资源，也体现了技术，并且以产品和服务的形态开放。云的 承载性 是云得以包罗万象，并且与时俱进的根本原因。
云原生 的本质是用于构建现代云端应用的一系列架构理念，以及帮助这些理念落地的技术支撑和最佳实践。云原生的核心理念包括 无状态、分布式、服务化、弹性扩展 等等。

常见的一种狭义的云原生定义，特指的是容器化、容器编排和微服务架构，从更广义的视角来看，只要是适合在云上运行，具备和符合云上架构特点的应用，都可以说是属于“云原生”范畴。

如果通过优雅地结合使用对象存储、云数据库、无服务器计算等云端组件，开发了一个弹性可扩展的应用程序，那它当然也完全称得上是“云原生”应用。