云计算架构学习整理（十）：多重云多重云的应用场景，以及如何实现多重云，围绕多重云的两个关键因素展开：云间的网络连接、云间

前言

云计算架构作为一种基础设施服务几乎已经成为了现代Web开发的标配，它显著地降低了 DevOps（Development and Operations）的门槛，通过云服务商提供的管理平台，Web应用开发人员可以轻松地在云上搭建自己的系统。作为一名云时代的全栈开发工程师，了解云计算架构背后的机制可以让我们更好地利用这个强大的基础设施，在设计、开发、部署和维护应用程序时做出更明智的决策。同时云计算是互联网技术的延伸，通过学习云计算架构，可以更深入地掌握互联网基础知识，这对于个人的技术水平也是一个很大的提升。

为了对云计算有一个全面的了解，最近在读 《图解云计算架构——基础设施和API》 一书，这本书主要以OpenStack和AWS为例，通过API来重点讲解IaaS云服务的本质。下面是边读边整理的学习笔记，一方面可以随时回顾，另一方面希望通过输出来促进自己思考。

正文

本章的主题是多重云和生态系统。将私有云和公有云连接在一起形成的是混合云，而多个云环境的组合就是多重云。随着云的普及，很多大型IT供应商都成了云服务供应商，多重云也日益成为企业的重要战略选择。

1. 多重云的简介

配置多重云的目的

人们使用多重云时可能考虑的因素包括：

成本优化：在不同的云之间灵活选择性价比最高的资源和服务，实现成本的精细化管理，避免被单一云供应商锁定而支付过高的费用。
获得更广泛的服务和功能：弥补单一云功能短板，或者在不同的云环境中进行创新技术尝试
提高业务连续性和灾难恢复能力：单一云平台可能会出现故障、网络中断或遭受安全攻击等问题，导致业务中断。使用多重云可以将业务分布在多个不同的云环境中，在不同云之间制定灵活的备份和恢复策略，确保业务的连续性。
满足合规性要求：使用不同的云环境，满足不同地区和行业的法规和合规要求

多重云的兼容性

资源可以划分为云环境特有的资源，以及不依赖于特定云的共有资源。

云环境特有的资源：云组件、API。
不依赖于特定云的共有资源：操作系统、容器、中间件和应用程序等。无论在哪个云环境中，都可以使用Chef、Docker Hub、Git等管理脚本和工具。这些资源不用担心兼容性和可移植性。

设计多重云时需要考虑的事项

使用多重云时，需要考虑的事项有以下两点：

云之间的网络连接：实现云环境之间的相互通信
云之间的可移植性和兼容性：需要一种机制来抹平组件和API在不同云中的差异

多重云的模式

多重云是多种云环境的组合，根据组合的方式可以有以下的模式：

1. 使用配置在另一个IaaS上的SaaS
1. 使用配置在IaaS上的软件
1. 使用配置在另一个IaaS上的PaaS
1. 不同IaaS之间的无缝连接

前面三种模式是不同的层与IaaS的组合，IaaS层对于用户是透明的，即使切换IaaS也不受影响，因此从用户的角度来看，配置在IaaS上的SaaS、软件和PaaS并不算是多重云，但是从内部看它确实是多重云。而模式4则需要用户关注每个IaaS环境中的数据中心和网络，因此需要关注不同IaaS之间的API差异。

2. 专用网络

为了在多个IaaS之间配置多重云，首先要考虑如何实现云间互连，而连接的关键在于云环境中的区域和可用区的物理位置。用网络来连接云的方式主要有两种：

通过电信运营商或云供应商提供的专用网络连接
通过互联网连接

在介绍这两种连接方法之前，先简单讲讲广域网的基础知识。

2.1 广域网：BGP和AS

广义上的广域网包括互联网和专线，由称为AS（Autonomous System，自治系统）的网络群组成，并使用BGP协议（Border Gateway Protocal，边界网关协议）在这些AS之间进行路由，从而建立通信路径。这样的连接方式也称为对等连接。

路由协议可以分为内部路由协议（IGP）和外部路由协议（EGP）。内部网关协议（如 OSPF、IS-IS 等）可以在AS内部进行路由选择和优化，而BGP属于外部路由协议，用于在不同云的AS之间建立直接的网络连接和路由通信。
BGP支持CIDR，所以在一个云环境中定义的网络的CIDR也可以广播到另一个云中。
AS编号：每个AS都有唯一的AS编号。和IP地址一样，AS编号也分为公有编号和私有编号。对于接入互联网的服务（如Amazon S3），我们不能使用私有AS编号进行对等连接，而对于使用私有IP地址配置的服务（如Amazon VPC），则可以使用私有AS编号。

2.2 专线

使用专线连接云的步骤大致可以分为两步：

物理布线：如果是新建专线，则需要进行线路铺设和物理布线
逻辑布线：使用API在专用网络和云的网关之间进行逻辑布线

线路的选择和物理布线

在开始铺设路线前，首先要选择线路运营商。需要考虑的因素包括运营商的运营区域，以及运营商是否有云服务端授权。

专线大体可以分为以下两种，我们可以按需选择：

网络节点间的专线连接：只适用于需要在两个网络节点之间进行对等连接的情况。
接入广域以太网的连接：使用现有的广域以太网将网络节点和云连接起来。广域以太网之间的通信控制采用了先划分AS再通过BGP路由的方式。

逻辑布线

完成物理布线后，就要进行逻辑布线。

1. 建立对等连接

如果两个环境是通过私有网络连接的，那么就要在虚拟网络的私有网关之间建立连接。以AWS为例：

虚拟接口构成了逻辑布线的单位，虚拟接口由私有AS编号、VLAN编号、双方的CIDR和私有网关ID等属性构成，并与连接相关联。
Direct Connect组件是使用API进行逻辑布线的专用组件，通过向Direct Connect组件的端点发送请求，就可以调用API建立虚拟接口，然后调用API完成逻辑布线。

在私有网络之间建立连接时，要避免使用重复的私有IP地址。虽然在路由器中启用NAT可以解决IP地址重复问题，但是这会导致结构复杂，且NAT会受到虚拟网络的限制。所以设计时尽量避免使用NAT，避免使用重复的私有IP地址。

AWS也提供了使用公有AS编号建立虚拟接口的API。也是先调用API建立虚拟接口，然后调用API完成逻辑布线。

2. 路由配置

建立好对等连接后，还需要在各环境的虚拟路由器上配置以各网络节点的CIDR为目标地址的路由，这样网络节点之间的路径就建立好了。

在AWS中，由于虚拟私有网关（VGW，Virtual Private Gateway）就是接口，所以配置以网络节点的CIDR为目标地址的路由时，只需配置指向私有虚拟网关的路由即可。

2.3 互联云

上一节的布线过程针对的是物理网络节点位于固定场所且首次连接的情况，而在大规模的公有云服务商之间通信时，直接使用现有供应商之间的线路效率更高。这种无需关注网络即可无缝使用云环境的方式就是”互联云“。

连接线路提供商：比如Cisco Intercloud Fabric，Equinix Cloud Exchange
AWS支持使用API在同一区域下的不同账户的VPC建立对等连接

2.4 互联网VPN

前面两节讲的都是通过专线进行连接的示例。在远程访问等对性能要求不高的场景下，也可以使用互联网VPN进行连接。典型的VPN有IPsec VPN与SSL-VPN两种。

VPN路由器：在云环境中，一般是通过在服务器上配置VPN软件的方式使用VPN路由器
在AWS中，虚拟私有网关（VGW）可以支持主流的VPN路由器提供商的IPsec通信，因此可以通过VGW建立IPsec VPN通信。此外，还可以使用CloudHub配置，通过VGW中继通信路径，从而建立多个IPsec VPN通信。

3. CDN

前面讲的专用网络连接方式是以某个区域附近的封闭网络为前提的，而对于散布在多个区域中的多个云环境，往往要使用CDN（Contents Delivery Network，内容分发网络）来连接。

一个典型的CDN使用场景：在云计算架构中，我们可以使用DNS为对象存储中的文件进行优化路由控制。而随着网络访问量的日益增加，往往还会在DNS和对象存储或负载均衡之间加入CDN的配置。

CDN最适合进行HTTP通信，且具备基于最近边缘站点实现的缓存功能、网络路由功能和安全功能。CDN在跨区域的全球配置中发挥着重要作用，它也非常适用于多重云环境。

本节先介绍构成CDN的基本组件和API，然后再介绍CDN在多重云中的重要性。

3.1 从互联网的机制来看CDN的基本架构

网络架构层级

按照互联网服务提供商（ISP）的层级划分，可以分为Tier1、Tier2和Tier3:

Tier1：在网络服务提供商（ISP）的层次结构中，Tier1 ISP 是指那些具有全球覆盖范围和大量网络基础设施的大型 ISP，它们直接连接到互联网的骨干网络，拥有自己的国际传输链路和大量的 IP 地址资源，能够提供大规模的互联网接入和数据传输服务。
Tier2：Tier2 ISP 通常是从 Tier1 ISP 那里购买网络带宽和转接服务，然后再向本地或区域内的用户和企业提供互联网接入和相关服务。它们的网络覆盖范围相对较小，主要集中在特定的地区或城市。
Tier3：Tier3 ISP 一般是指那些更小的、面向特定社区或特定用户群体的网络服务提供商，它们可能从 Tier2 ISP 那里获取网络连接，然后为当地的小型企业、居民用户等提供有限范围的互联网接入和基本的网络服务。

CDN的工作流程如下所示，它涉及边缘节点和源站节点：

sequenceDiagram 
participant User as 用户 
participant CDNNode as CDN边缘节点 
participant OriginServer as 源站 
User->>CDNNode: 请求内容
CDNNode->>CDNNode: 检查本地缓存 
CDNNode-->>User: 返回内容（如果缓存命中） 
CDNNode->>OriginServer: 请求内容（如果缓存未命中） 
OriginServer-->>CDNNode: 返回内容 
CDNNode-->>User: 返回内容 
CDNNode->>CDNNode: 缓存内容

将CDN工作过程与Tier网络架构层级结合起来看，我们会发现：

当用户从源站请求资源时，如果要跨多个AS进行通信，那么访问带有完整路由的Tier1网络的概率就会上升，此时需要经过多个路由器和链路，增加了数据传输的复杂性和延迟。
当用户从最近的边缘节点获取到数据，那么大多只需访问Tier3网络，此时大大减少了网络跳数，缩短了数据传输的总时长。

所以，我们可以认为CDN是一种使用逻辑线路连接的网络，它由网络路由器以及这些路由器附近的带有复杂控制的服务器构成，从而提升互联网访问速度。

3.2 构成CDN的组件

边缘站点

在CDN中，我们将带有缓存服务器的数据中心称为边缘节点（edge location），而非区域。

CDN的机制是根据请求的源IP地址将其路由到最近的边缘站点
影响性能的重点就在于是否存在靠近发送方的边缘节点。为了提升竞争力，各CDN服务都在不断增加边缘站点的数量和部署位置。

源站

CDN既然是一种网络，那就少不了存储原始内容的服务器，这种服务器称为源站。

CDN是基于HTTP通信的，因此源站由HTTP服务器构成
对于动态网站，往往会在Web服务器前面部署负载均衡器，此时源站主要由HTTP负载均衡器构成；对于静态网站，源站主要由内置了HTTP服务器的对象存储构成。

边缘主机名

CDN存在于DNS和源站之间，用户通过URL访问网站时，由DNS解析结果决定访问的站点，所以用户很难感觉到CDN的存在。

CDN具有用于定义规则的逻辑单位，以此来控制最佳的边缘站点。这个逻辑单位在Amazon CloudFront中称为分发（distribution），在Akamai中称为边缘主机名（Edge Hostname），它会被关联到源站上。

由CDN定义的一个CNAME记录会被关联到边缘主机名（分发）中，它对应多个边缘站点的IP地址。这是CDN的核心机制。在Amazon CloudFront中，可以通过POST请求创建分发，有Web分发（Web distribution）和串流分发（streaming distribution）两种类型：

Web分发：主要用于加速静态和动态网页内容的分发，包括 HTML文件、CSS样式表等各类常见的网页资源
串流分发：主要用于实时或按需传输视频、音频等流媒体内容，能够确保流畅的播放体验，减少卡顿和缓冲时间。

缓存行为

对于URL请求而言，边缘主机名负责的是前面FQDN域名的部分，缓存行为负责的是后面的路径部分。缓存行为决定了从边缘主机名到源站的分发功能。

白名单、错误页和自定义证书

CDN是专门为HTTP设计的网络，因此它工作在HTTP协议所在的第七层架构，具有七层的控制功能。

在Amazon CloudFront中，可以配置HTTP消息头的白名单，或者根据HTTP错误码将请求重定向到错误页。此外，CDN还提供了具备Web Application Firewall（Web应用防火墙）功能的服务。

此外，使用HTTPS协议通信时，在CDN中还要配置自定义域名证书。由于CDN是与域名相关的唯一入口，所以它是配置证书的最佳场所。一方面可以将证书上传到分发并进行配置，另一方面由于自定义域名对应着多个边缘站点的IP地址，所以也可以将证书发放到对应的边缘站点中。

证书可以分两种：

使用一般的证书：即传统 SSL 证书，它是基于 IP 地址或域名绑定的，一个证书通常对应一个域名。此时，一个边缘站点的IP地址会被特定分发的CNAME占用。
使用SNI证书：即服务器名称环境证书，SNI 证书允许 CDN 服务器根据用户请求的不同域名，从同一个 IP 地址上提供多个不同域名的加密服务。此时，可以在多个分发的CNAME间共享边缘站点的IP地址。SNI证书广泛应用于 CDN、共享主机等环境。

3.3 CDN与DNS结合使用

CDN（内容分发网络）与 DNS（域名系统）通常通过CNAME记录紧密结合，以实现高效的内容分发和快速的域名解析。

CNAME记录

CNAME即Canonical Name，CNAME记录是一种DNS记录类型，也被称为别名记录，用于将一个域名指向另一个域名。
基本原理：当用户在浏览器中输入设置了CNAME记录的域名时，DNS服务器会查找该域名对应的CNAME记录，然后将请求重定向到CNAME记录所指向的另一个域名。

sequenceDiagram 
participant User as 用户 
participant DNS_Resolver as DNS解析器（本地或递归DNS服务器） 
participant Authoritative_DNS as 权威DNS服务器（域名对应的权威服务器） 
participant Target_Server as CNAME指向的目标服务器 
User->>DNS_Resolver: 请求解析域名（如example.com） 
DNS_Resolver->>Authoritative_DNS: 向权威DNS服务器查询域名解析信息
Authoritative_DNS->>Authoritative_DNS: 查找域名对应的CNAME记录（如果有） 
Authoritative_DNS-->>DNS_Resolver: 返回CNAME记录指向的目标域名（如alias.example.net） 
DNS_Resolver->>Authoritative_DNS: 再次查询目标域名（alias.example.net）的A记录（获取IP地址） 
Authoritative_DNS->>Authoritative_DNS: 查找并返回A记录对应的IP地址（假设为192.0.2.1） 
Authoritative_DNS-->>DNS_Resolver: 提供IP地址信息 
DNS_Resolver-->>User: 将目标服务器的IP地址返回给用户 
User->>Target_Server: 根据IP地址发起请求访问目标服务器 
Target_Server-->>User: 返回相应内容

CNAME记录的主要作用：

域名别名管理：方便网站所有者在不改变域名的情况下，更改网站的实际服务器地址或域名指向。用户仍然可以使用原来的域名访问网站，不会受到影响。
负载均衡：可以将多个域名指向同一个服务器或服务器集群，实现负载均衡和流量分发。例如，可以设置不同的域名并将它们的CNAME记录指向同一个后端服务器集群，也可以根据不同的域名将用户流量均匀地分配到各个服务器上，提高系统的可用性和性能。
CDN 加速：在内容分发网络（CDN）中广泛应用。网站所有者将自己的域名通过CNAME记录指向 CDN服务提供商提供的域名，如Akamai 或 Amazon CloudFront的边缘主机名，这样用户访问网站时，请求会被路由到离用户最近的CDN边缘服务器，从而加速内容的分发和访问速度。
隐藏真实域名：通过使用CNAME记录，可以将对外公开的域名指向内部真实的域名或服务器，从而起到一定的隐藏作用，增加安全性。

CNAME 记录与其他 DNS 记录的区别：

A 记录：A 记录将域名直接指向一个 IP 地址，而 CNAME 记录是指向另一个域名，再由该域名通过 A 记录或其他记录指向具体的 IP 地址。
MX 记录：MX 记录用于指定邮件服务器的域名

CDN如何使用CNAME记录

配置 CNAME 记录
- 获取 CNAME 域名：用户在 CDN 服务提供商处注册并配置好加速域名后，CDN 会为该加速域名分配一个特定的 CNAME 域名，如 “alias.example.cdn.com”。
- 添加 CNAME 记录：用户需要登录自己的域名解析管理控制台，在相应域名的 DNS 记录中添加一条 CNAME 记录，将自己的源域名或需要加速的域名（如 “www.example.com”）指向 CDN 分配的 CNAME 域名。这一步骤实际上是在 DNS 系统中建立了域名到 CDN 服务的映射关系，使得对源域名的请求能够被引导到 CDN 网络中。
请求路由与智能解析
- 用户发起请求：当用户在浏览器中输入源域名（如 “www.example.com”）时，浏览器会首先向本地 DNS 服务器发起域名解析请求，请求获取该域名对应的 IP 地址。
- DNS 解析流程：本地 DNS 服务器会按照常规的 DNS 解析流程进行查询，当查询到该域名的 CNAME 记录时，会根据记录将请求转发到 CDN 的 DNS 服务器，由 CDN 的 DNS 服务器进行进一步的解析和处理。
- 智能解析：CDN 的 DNS 服务器会根据用户的地理位置、网络状况等多种因素进行智能解析，从 CDN 遍布全球的众多边缘服务器中选择一个最适合的服务器来响应用户的请求，比如选择距离用户最近、网络延迟最低或者带宽最充足的服务器。
内容缓存与分发
- 缓存检查：用户的请求被路由到选定的 CDN 边缘服务器后，该服务器首先会检查自己的缓存中是否已经存在用户所请求的内容，如网页、图片、视频等。
- 缓存命中：如果缓存中存在所需内容，边缘服务器会直接从缓存中提取并快速返回给用户，大大减少了内容的传输延迟和源站的负载。
- 缓存未命中：如果边缘服务器在缓存中未找到用户请求的内容，它会向源站服务器发起请求，获取相应内容，然后在将内容返回给用户的同时，将其缓存到本地，以便后续其他用户请求相同内容时能够直接从缓存中获取，提高访问效率。
动态内容处理
- 动态内容请求：对于动态内容，如实时更新的网页、在线交易数据等，CDN 同样可以通过 CNAME 记录将用户请求引导到 CDN 网络中。
- 回源获取：CDN 边缘服务器在收到动态内容请求后，会根据一定的策略判断是否需要回源获取最新内容，通常会在缓存过期或者源站有更新时回源。获取到最新内容后，会及时返回给用户，并根据需要更新缓存。

3.4 云私有网络

CDN能够在边缘主机名和源站之间配置私有网络，这样一来，源站就只能通过CDN访问，而无法直接从互联网（ISP）访问。此外，只要将其他云环境定义为源站，就能以CDN为入口实现云之间的切换或通信。该功能在Amazon CloudFront中称为私有内容，在Akamai中称为Site Shield。

3.5 CDN 的动态与静态内容分离技术

CDN 的动态与静态内容分离技术是一种优化内容分发的策略。它将网站或应用程序中的内容划分为动态内容和静态内容，然后分别采用不同的处理和分发方式，以提高内容分发的效率和用户体验。

静态内容处理：CDN 对于静态内容主要是进行缓存处理。静态资源如图片、CSS文件和JavaScript文件被缓存到距离用户最近的节点。当用户请求静态资源时，CDN从最近的缓存服务器提供，减少了服务器负载和响应时间。
动态内容处理：对于动态内容，如由数据库生成的个性化页面或实时信息，需要根据具体情况实时生成或更新，不能简单地进行缓存并长期使用。CDN通过智能调度系统，根据内容的实时性和更新频率选择最优节点进行处理，确保内容的及时性和准确性。另外，一些高级的 CDN 还支持在边缘服务器上运行部分逻辑，对动态内容进行预处理，如进行简单的格式转换或者数据聚合等操作，以提高性能。

3.6 CDN中的缓存控制机制

作为CDN核心的缓存控制取决于HTTP消息头与边缘主机名中的各种配置。

用于控制缓存的HTTP消息头有两个：

Expires：用于配置缓存的过期时间，它是HTTP/1.0标准定义的，一般只用于兼容一些只支持 HTTP/1.0 的古老客户端或者服务器。
Cache Control：用于配置缓存的有效时长，以及其他提供了精细的缓存控制方式。它是HTTP/1.1 标准定义的，在现代的网络环境和大多数浏览器、服务器以及 CDN 系统中都得到了很好的支持。

优先使用Cache Control消息头，如果两个消息头同时配置了，则以Cache Control的配置为准。

边缘主机名中的缓存控制配置主要是各种TTL值。

如果要根据URL的查询参数值来判断是否有缓存，可以启用边缘主机名中的Forward Query Strings配置，以此来定义更精细的缓存条件。
如果想根据HTTP消息头的Cookie值来判断有无缓存，还可以启用Forward Cookies配置。

如果同时提供了HTTP消息头和边缘主机名中的配置，那么边缘站点服务器的缓存控制基本上以边缘主机名上的配置为准，而浏览器缓存只采用HTTP消息头中的配置值。

Amazon CloudFront还提供了手动禁用边缘站点服务器上的缓存数据的API。注意，通过这种方式只是禁用了边缘站点服务器上的缓存，并不会禁用浏览器缓存。

3.7 CDN中的路由

CDN除了用于缓存优化，还可以用于路由优化。

随着CDN的广泛应用，很多CDN供应商打破了ISP之间的界限，部署了跨多个ISP的边缘站点服务器，由此能够算出比跨多个ISP的BGP更短的路由。

为什么CDN优化的路径更短

在前面的3.1中提到，按照传统的BGP路径，如果跨多个AS进行通信，往往需要经过从Tier3到Tier1网络的长路径；而当CDN中存在不同ISP的边缘节点AS时，如果从当前的边缘节点AS可以路由到另一个ISP的边缘节点AS，就只需在Tier3网络中进行路由，路径就大大缩短了。此外，边缘服务节点还可以根据网络拥堵情况等其他因素选择最短路径的路由。

总之，CDN的缓存优化主要以提升HTTP的GET请求的响应速度为核心目的；而CDN还可以增强安全性和优化网络，HTTP的PUT和DELETE方法也能从中受益。

3.8 CDN在多重云中的作用

CDN具有在HTTP层面上优化数据中心之间的网络的特性，因此CDN是多重云中极为重要的组件。

内容分发优化：在多重云环境中，企业可能会使用多个云服务提供商的资源，数据和应用程序分布在不同的云环境中。CDN 可以根据用户的地理位置和网络状况，从距离用户最近的边缘节点缓存和分发内容，提高内容的访问速度。
负载均衡与资源优化：CDN 能够在不同的云环境之间实现负载均衡。当某个云服务提供商的资源负载较高时，CDN 可以将部分用户请求导向负载较低的云环境，充分利用各个云的资源，避免单点过载。
提高系统可靠性和冗余性：在多重云架构下，CDN 作为一个额外的分发层，增加了系统的冗余。即使某个云服务提供商出现故障或网络问题，CDN 可以将用户请求切换到其他可用的云资源，确保服务的连续性。
加速动态内容交付：对于存储在不同云环境中的动态内容，如实时更新的金融数据、新闻资讯等，CDN 可以通过在边缘节点进行部分处理和缓存，加速内容交付给用户。
跨云安全防护：CDN 可以在一定程度上提供跨云的安全防护。一些高级的 CDN 服务提供 DDoS 防护、WAF（Web 应用防火墙）等功能，保护分布在不同云环境中的内容和应用免受网络攻击。

4. API的通信路径和兼容性

在配置多重云时，我们需要考虑两种云在API上的差异。

4.1 API的通信路径

跨云通信时，首先需要建立跨云API调用的通信路径，建立过程的重点就是DNS和认证。下面就以OpenStack环境调用AWS环境中的API为例介绍这两点。

DNS

路径

FQDN域名解析：在AWS环境内部，那么VPC中默认就有能够对amazonaws.com进行域名解析的机制。但如果从其他云环境使用AWS的端点，由于命名空间不同，就需要先解决域名解析的问题；具体做法就是，当目标地址为amazonaws.com时，最好在OpenStack的DNS服务器上加上转发（forward）到AWS的DNS服务器的配置。这样随后的域名解析就能在AWS内部处理了。
隐藏IP：需要用DNS或CDN来隐藏IP地址的差异，以免申请的公有IP地址范围发生重复

路由

由于BGP对等连接只会广播邻近的VPC的CIDR，所以只有目标地址属于邻近VPC的请求才能通过专线。因此还要配置代理将请求送达这个VPC的端点。
另外，设置允许通过的请求的域名白名单时，也要考虑API服务的端点和域名，从而灵活地配置允许条件。

认证

认证有两种方式：

直接输入用户的密钥信息
将IAM角色分配给服务器，在内部进行认证

如果使用IAM角色进行内部认证，那就只能在相同的云中才能进行。从不同的云环境调用API时，只能输入密钥信息。

4.2 API的兼容性

云环境之间的组件差异是广泛存在的，为了让用户能无缝管理不同云环境之间的资源，就要尽可能统一API，对具体的操作进行抽象处理。常见的API兼容工具有jclouds、Ansible和Teraform等。

除了直接调用API，还可以通过Console、SDK、CLI间接调用API。下面就看看这四种调用方法在AWS和OpenStack的兼容性。

API：由于是直接调用API，所以不存在兼容工具层，就很难隐藏云环境之间的差异
CLI：OpenStack中的CLI支持以Amazon EC2和S3为核心的兼容套件，比如euca2ools、S3cmd、Terraform。这些工具都需要AWS的标准密钥信息（访问密钥和秘密访问密钥）。
SDK：SDK对多重云的支持日渐增强。典型的工具有：Apache jclouds（Java）、Libcloud（Python）、fog（Ruby）、pkgcloud（Node.js）。这些工具都支持AWS和OpenStack。在SDK中，兼容API的问题往往需要通过导入用于兼容各种云的模块来解决，此外还要花费精力修改不同云环境的参数定义。
Console：Console提供了将页面操作转换成API调用的功能。它在可视化与可操作性上面表现十分出色，市面上相继出现了多款Console工具，比如RightScale、Scalr、Hinemos。

4.3 将环境和数据迁移到云中的难易程度

前面主要说了API的兼容性，如果需要实现多重云之间的“无缝相互操作”，我们还要衡量将环境和数据迁移到云中的难易程度。

”5R“迁移策略

典型的迁移方案中，由Gartner公司提出的五种迁移策略“5R”较为出名。 5R 分别代表 Rehost、Replatform、Repurchase、Retire 和 Retain。

Rehost（重新托管）：这是一种相对简单直接的迁移策略。主要是将应用程序及其相关数据从当前的云环境或本地数据中心原封不动地迁移到另一个云环境中。在迁移过程中，只是将操作系统、应用程序文件和数据库等整体迁移，不进行架构或代码层面的修改。适合在IaaS间迁移时使用。
Replatform（平台重构）：这种策略涉及对应用程序进行一定程度的修改，以适应新的云平台的特性和功能，但不会对应用的核心架构进行大规模的重写。比如将应用从使用传统的关系型数据库迁移到新云平台提供的托管的 NoSQL 数据库，以提高数据处理的效率。
Repurchase（重新采购）：企业放弃现有的软件解决方案，转而采购新云平台提供的类似软件即服务（SaaS）产品。
Retire（退役）：在迁移过程中，企业对一些不再使用、过时或者与业务目标不相符的应用程序、服务或数据进行清理和停用。通过退役这些内容可以降低迁移成本，简化新云环境中的系统架构，提高系统的整体效率和安全性。
Retain（保留）：企业在多重云迁移过程中，暂时不改变某些应用程序或数据的位置和状态，仍然保留在原有的云环境或本地数据中心。这些内容可能由于合规性、业务连续性或者其他特殊原因暂时不能迁移。

云中不同层的迁移难度

我们可以把云环境自上而下分为数据、环境、IaaS三层，每一层又可以进一步细分层级：

我们整体看看每一层的迁移难度：

数据：如果用到存储协作或存储介质的迁移会受到限制，还需要考虑云之间的网络带宽
环境：如果迁移目标是IaaS且具有兼容的操作系统，则可以直接迁移；如果迁移目标是PaaS还需要确认兼容性。使用容器与操作系统分离，降低了它在云间进行迁移的难度，这也是容器的一大优势。
IaaS（云供应商的提供范围）：迁移操作系统时会受到底层虚拟化环境的限制
- 完全虚拟化环境：可借助虚拟机的迁移功能迁移操作系统，但是如果操作系统的版本受限于虚拟机管理程序的类型和版本，则无法直接迁移。
- 半虚拟化环境：操作系统已经过云供应商的虚拟管理程序的改造，迁移起来十分困难。

以上是整体的分析，下面具体分析数据、环境层的迁移难度。

迁移数据的难度

首先是数据的存储副本或安装存储介质受限的问题。

在相同的云间：只需要使用快照副本就能解决数据迁移的问题
在不同的云间：快照缺乏兼容性会导致存储功能无法使用，所以在迁移数据时原则上只能以文件为单位，不能以块为单位。

然后要考虑网络带宽问题。有些云间只有有限的网络带宽，当迁移大量数据时，需要事先考虑迁移所需的网络吞吐量。在实际中，如果全量迁移的数据量很大，花费的时间很长，可以考虑分阶段迁移：先进行预迁移，然后在每天凌晨增量同步尚未迁移的少量数据。

迁移环境的难度

在IaaS中，位于容器层之上的那些层只依赖于独立于云的操作系统环境，如果迁移目标具备兼容的操作系统环境，那么直接迁移即可。位于虚拟机管理程序之下的各层都是由云提供的，无法迁移，也无须关注。剩下的层中要考虑的、比较麻烦的就是操作系统层。

首先，操作系统迁移的具体方法是很直截了当的，只需要使用VM Export/Import功能导出导入镜像即可。然而，操作系统的迁移往往会受到底层环境的限制。

在IaaS中，操作系统是归用户负责的，操作系统的命令不受云环境的影响。然而，操作系统是运行在虚拟化环境中的，不同的虚拟化模式有不同的工作方式：

半虚拟化（Para - Virtualization）：半虚拟化需要对操作系统进行修改，使其意识到自己运行在虚拟化环境中。在这种环境下，操作系统内核经过特殊的修改后，能够与虚拟机管理程序（Hypervisor）进行高效协作。例如，在半虚拟化环境中，操作系统会将一些关键的系统调用（如 I/O 操作、内存管理等）通过特定的接口直接与 Hypervisor 进行通信，减少虚拟化带来的一些开销，使得 I/O 性能更接近物理硬件环境。它提供了更高的性能。
完全虚拟化（Full - Virtualization）：完全虚拟化不需要对操作系统进行修改。它通过在硬件和操作系统之间插入一层虚拟机管理程序（Hypervisor）来模拟出完整的硬件环境，使得操作系统以为自己运行在真实的物理硬件上。例如，Hypervisor 会拦截操作系统对硬件的所有指令，包括 CPU 指令、I/O 操作等，然后进行模拟或者转发，让操作系统能够在虚拟的硬件环境中正常运行。它提供了很好的兼容性。

我们看看这两种虚拟化模式对操作系统迁移会造成哪些限制：

操作系统在半虚拟化模式下运行：操作系统依赖于云提供的虚拟机管理程序，由于经过虚拟机管理程序的改造，这时候就无法迁移到运行在其他虚拟机管理程序的云环境中。
操作系统在完全虚拟化模式下运行：如果操作系统的版本受限于虚拟机管理程序的类型和版本，也是无法直接迁移的。比如旧版Windows或RHEL操作系统在很多虚拟机管理程序上是不支持的；另外像Oracle Solaris或IBM AIX这这种强烈依赖于自定义CPU和虚拟机管理程序的Unix操作系统，或者像Amazon Linux这种只能在AWS环境中运行的操作系统，都是无法直接迁移的。

可以看到，与虚拟机管理程序或云环境紧密相关的操作系统使得环境迁移的复杂性大大增加了。而Docker等容器虚拟化技术的应用则可以很好地避免这个问题，从而大大降低迁移IaaS和迁移PaaS的难度。容器层在操作系统层之上提供了一个隔离的容器环境，通过将应用及其依赖打包在一起，由于它抽象了底层操作系统的差异，因此环境的可移植性大大提升了。不仅如此，容器虚拟化技术在云环境中还带来了很多额外的好处。关于容器化技术的内容我们在下一章不可变基础设施中展开。

小结

本章主要讲了多重云环境的场景，以及如何实现多重云。主要围绕多重云的两个关键因素展开：云间的网络连接、云间的可移植性和兼容性。

云间网络连接：关键组件是CDN
云间无缝互相调用：需要考虑API的兼容性，抹平API差异
云间迁移：分析了IaaS、PaaS和SaaS各层的可移植性和迁移难度