从混合云到分布式云 （下篇）
三、混合云案例
《从混合云到分布式云 （上篇）》（以下简称《上篇》）发出来后，有位老友转发了文章并添加了评论“混合云除了出现在PPT，现实是不存在的”。所以，在谈混合云案例之前，得首先回答一个问题：混合云在现实中存在吗？
1、混合云到底是什么？是一种用云模式，还是一种云产品？
从客户视角来看，我在《上篇》中开宗明义，“混合云是一种云服务的使用模式，即用户同时使用私有云和公有云。” 也就是说，混合云是一种用户（企业）使用云服务的模式，而不是一种云产品。如果一个企业同时使用私有云和公有云，那么我们就可以说，这个企业采用的是混合云模式。
从厂商视角来看，如果一个厂商同时提供公有云服务和私有云产品，那么我们可以说，这个厂商的云产品支持混合云场景。从产品视角来看，如果一个产品既支持公有云服务模式，也支持本地化部署，我们就可以认为该产品支持混合云场景。
笔者同时认为，不存在一个云产品叫混合云。但是，因为混合云这种用云模式的存在，导致出现了一些相关产品，比如《上篇》中提到的混合云管理平台。这种平台面向企业云服务和资源的管理者，向他们提供一个集中的平台，展示私有云和所使用的公有云上的资源，以及部署在其上的应用。
但是，这里又引申出另一个经久不衰的话题，“私有云是云吗？”。好吧，这个话题其实和“混合云存在吗？”是同一个类型。就像莎士比亚的名言：“一千个读者眼中就会有一千个哈姆雷特”，也就是说，每个立场不同的人可以在《哈姆雷特》这本书里看出完全不同的意境。对私有云和混合云这两个概念同样如此。笃信公有云是最佳甚至唯一云模式的人会认为，私有云不完全具备云计算的特性，比如足够的弹性和规模性，因此不能称为云。但是，笔者认为，实际上，私有云是客观存在的，这是无法回避的事实。国内大型企业，比如大型银行的私有云，可能会拥有几千甚至几万台服务器，其实也拥有不错的弹性和规模性了。
2、如果一个应用无法同时使用私有云和公有云，混合云还有存在的意义吗？
《上篇》中也提到，Flexera发布的《State of the Cloud Report 2022》报告中，在接近一半（45%）的场景中，用户的单个应用都是部署在一个云环境上。是的，在实际案例中，一个应用跨两种云环境进行部署的案例确实不多。
但是，这种部署案例即使是少数，但仍是客观存在的。在《上篇》中笔者提到了灾备、数据库等后端服务放在私有云上而应用放在公有云上、为了应对洪峰流量而做的弹性扩容等典型场景。这说明，即使从单个应用角度来看，混合云部署模式也是客观存在的。下面笔者再举一个单个应用跨私有云和公有云部署的真实案例。
在这个混合云案例中，这家大型互联网企业的的安全设备和安全服务，以及后端服务都部署在自己的IDC中，而应用部署在公有云上的容器集群中，充分利用容器平台的弹性和规模性。公网用户的访问入口在IDC，经过安全设备和服务后，通过专线分发到公有云上的容器集群中部署的应用中，应用再访问IDC中的后端服务。
图1 一混合云案例
现代应用往往是分布式的，包括多个模块，每个模块可独立地部署成一个服务。比如一个应用的灾备模块，同样是这个应用的一个重要组成部分。在一些场景中，我们会看到，一个应用的有些模块，部署在私有云上，而其它模块部署在公有云上。
3、针对混合云模式的各种支撑产品也是在不断演进的。
针对混合云模式的各种支撑产品也是在不断演进的。
混合云管理平台是初代支撑产品的典型，相信很多人都很熟悉。但是，就像笔者在前文所说的，这种管理平台是面向混合云管理人员的，目的是为了在一个平台中集中管理在两种云环境中的云资源和所部署的应用。它的短板在于，它不是面向应用和开发人员的，这往往被人诟病。但是，还是那句话，产品是需要时间来成长换代的。
新一代混合云支撑产品中的一个典型，就是跨云容器云平台。比如谷歌的多容器集群管理平台Anthos和华为的Karmada。以Karmada为例，它是华为开源的云原生多云容器编排平台，目标是让开发者像使用单个K8S集群一样使用多K8S环境。这类平台弥补了传统混合云管理平台的不足，屏蔽多种异构云环境的差异，面向开发者和应用提供一致的环境和体验。
图2 华为的Karmada
来源：华为官网
四、分布式云典型案例 - AWS
笔者认为，AWS具备了分布式云当下几乎所有特性。下文从几个方面来进行介绍。
- 地理上广泛分布
- 统一的管理平面
- 统一的网络平面
- 统一的应用平台
（一）地理上广泛分布
1、AWS 中心节点 - 区域 Region
AWS 区域概念，是其在世界各大城市聚集数据中心的物理位置。每个 AWS 区域由一个地理区域内的多个隔离的且在物理上分隔的可用区组成。每个可用区都有独立的电力、冷却和物理安全性，并通过冗余的超低延迟网络连接。AWS在其Region中运行着最全面、最大规模、最可靠的云服务。每个Region至少由三个可用区组成。
AWS 官网（https://aws.amazon.com/cn/about-aws/global-infrastructure）上持续更新AWS Region的数量和分布。截至2022年10月，AWS 在全球 27 个地理区域内运营着 87 个可用区。从列表上，能看出来这些区域基本上都在全球大型和中心城市中，比如弗吉尼亚、加利福尼亚、圣保罗、法兰克福、伦敦、巴黎、首尔和北京等。
图3 AWS区域和可用区
2、AWS Region 延伸到非中心城市 - 本地区域 Local Zone
本质上来讲，每个AWS Local Zone 都是一个特定AWS Region向更靠近用户方向上的延伸，该Region称为Local Zone的父区域。以在洛杉矶的两个本地区域为例，其名字分别为 us-west-2-lax-1a 和 us-west-2-lax-1b。从名字上就可以看出，它们的父区域为us-west-2，即AWS美国西部（俄勒冈州）区域；“lax”表示其所在地区为洛杉矶；“1a”和“1b”是本地区域的编号，类似可用区的编号。
AWS Local Zones 是AWS基础设施部署的一种形式，可将计算、存储、数据库和其它某些 AWS 服务放置在更靠近大量人口聚居的位置，或者靠近行业中心的位置，从而在更靠近终端用户的位置运行对延迟敏感的应用程序。Local Zone 能够访问互联网，支持专线接入。在Local Zone 中创建的资源，能更低延迟地服务本地用户。
截至2022年10月，AWS在全球运行着17 个本地区域。在 https://aws.amazon.com/cn/about-aws/global-infrastructure/localzones/locations/?nc=sn&loc=3 网页上可查看完整列表。从该列表可以看出，目前除了洛杉矶有两个本地区域外，其它地区的本地区域都只有1个。
图4 AWS 本地区域
3、AWS Region 延伸到5G网络 - Wavelength Zone
AWS Wavelength Zone的性质类似于Local Zone，本质上都是一个AWS Region在更靠近用户方向上的延伸。不同的是，AWS Wavelength Zone 部署在5G运营商的机房内。每个AWS Wavelength Zone同样都有一个父区域，并且被该区域内的控制平面所管理。AWS Wavelength Zone的命名也包括其父区域的名字，比如在波士顿的us-east-1-wl1-bos-wlz-1 ，其父区域是us-east-1，“bos”表示其地区，“wlz”表示这是其性质是AWS Wavelength Zone。图5表示AWS Region us-west-2，它拥有两个可用区，以及一个Wavelength区。
图5 AWS Wavelength区域
因此，AWS Wavelength 是一款针对移动边缘计算应用程序优化的基础设施产品。如图6所示，它是一种 AWS 基础设施部署，在5G 网络的通信服务提供商 (CSP) 中嵌入 AWS 计算和存储服务，因而来自 5G 设备的应用程序流量可以在不离开移动通信网络的情况下到达 Wavelength 区域中运行的应用程序服务器。这就避免了因应用程序流量遍历互联网中的多个跃点才能达到其目的地而导致的延迟，从而使客户能够充分利用现代 5G 网络提供的低延迟和带宽优势。
图6 AWS Wavelength参考架构
截至2022年10月，AWS在全球已推出28 个 Wavelength 区域。在https://docs.aws.amazon.com/wavelength/latest/developerguide/available-wavelength-zones.html上，可以查看所有的Wavelength 区。图7和8显示了其典型应用场景：
图7 AWS Wavelength典型场景
图8 AWS Wavelength车联网场景示意
4、AWS Region延伸到客户的数据中心 - Outposts
与前两种区域类似，Outposts环境本质上也是一个AWS可用区的延伸，该可用区被称为“anchor AZ（锚AZ）”。AWS通过其父区域对Outposts环境进行运维、监控和管理。
AWS Outposts 是一系列完全托管式解决方案，可为几乎任何本地或边缘站点提供 AWS 基础设施和服务，以获得真正一致的混合体验。Outposts 解决方案允许用户在本地扩展和运行原生 AWS 服务。
使用 AWS Outposts，用户可以在本地运行一些 AWS 服务并连接到本地 AWS 区域中提供的各种服务。使用熟悉的 AWS 服务、工具和 API 在本地运行应用程序和工作负载。Outposts 支持需要以低延迟访问本地系统、本地数据处理、数据驻留以及具有本地系统相互依赖性的应用程序迁移的工作负载和设备。
图9 AWS Outposts 架构示意
Outposts使得客户可以在自己的数据中心内运行一些AWS服务，可运行的服务类型在不断增长中，包括EC2计算和EBS/S3存储服务、VPC和ALB等网络服务、RDS数据库服务、ECS和EKS容器服务、EMR大数据服务等。
Outposts的典型案例包括低延迟访问、应用现代化、数据本地处理和合规性等。
图10 AWS Outposts使用场景
5、延伸至网络边缘 - CDN边缘站点、CDN 区域性边缘站点、Direct Connect站点和PoP点
AWS CloudFront边缘站点（Edge Location）：Amazon CloudFront 是一项加快将静态和动态 Web 内容（例如 .html、.css、.js 和图像文件）分发给用户的速度的 Web 服务。CloudFront 通过全球数据中心（称作边缘站点）网络传输内容。当用户请求用 CloudFront 提供的内容时，请求被路由到提供最低延迟（时间延迟）的边缘站点，从而以尽可能最佳的性能传送内容。因此，边缘站点是 AWS 的网络端点，用于缓存内容并用作内容交付网络(CDN)。除了CloudFront，边缘站点还为Route 53 的请求提供服务，它是AWS提供的托管DNS 服务。发送到这些服务的请求将自动路由到最近的边缘站点。截至2022年10月，AWS已推出超过 400 个边缘站点。
AWS CloudFront 区域边缘站点（Regional Edge Caches）：Amazon CloudFront 区域性边缘缓存站点位于来源 Web 服务器和 AWS全球边缘站点之间。随着内容主题的热门程度降低，单个边缘站点可能会移除这些主题，从而为更热门的内容主题腾出空间。区域性边缘缓存的缓存宽度比任何单个边缘站点都更大，因此主题会在这些站点保存更长时间。这有助于让更多内容更为靠近读者，减少 CloudFront 返回原始 Web 服务器的需要，提升读者阅读体验。截至2022年10月，AWS已推出13 个区域性边缘缓存站点。
图11 AWS CloudFront 示意场景
AWS CloudFront PoP站点（Point of Presence）：对AWS CloudFront 边缘站点和区域边缘站点的统称。截至2022年10月，AWS已推出超过 410 个PoP节点，包括400多个边缘站点和 13 个区域性边缘缓存站点。
AWS Direct Connect站点（AWS Direct Connect Location）：AWS Direct Connect服务能够建立从客户环境（例如数据中心、办公室或托管环境）到AWS的专用网络连接。它提供了比基于 Internet 的连接更一致的网络体验。AWS Direct Connect 站点就是AWS提供专线接入服务的站点，它提供 1Gbps、10Gbps、100 Gbps等多种型号的专线连接，让用户通过专线直接连接到AWS网络。截至2022年10月，AWS已推出115 个 Direct Connect 站点。
图12 AWS Direct Connect场景示意
（二）统一的管理平面
这个很好理解，就是AWS控制台（AWS Management Console）能统一管理各类站点及站点内的服务。本地区域、Wavelength区域和Outposts环境都被它们的父区域中的控制平面所管理。比如在Region的管理界面中管理本地区域和Wavelength区域：
图13 AWS Management Console截图
（三）统一的网络平面
VPC可以延伸从中心区域，延伸至该区域所拥有的本地区域、Wavelength 区域和Outposts环境。
VPC从父区域延伸至其本地区域的示意：
图14 跨父区域和本地区域的VPC示意
VPC从父区域延伸至其Wavelength 区域的示意：
图15 跨父区域和Wavelength区域的VPC示意
VPC从父区域延伸至其Outposts环境的示意：
图16 跨父区域和Outposts环境的VPC示意
（四）统一的应用平台
AWS Elastic Kubernetes Service （EKS）是AWS托管的K8S集群，是其面向云原生应用的主要平台之一。AWS EKS 具备从中心区域延伸至其管理的本地区域、Wavelength区域和Outposts环境的能力，从而在这些环境之间，构建起同一个面向应用和开发者的平台。
以Outposts为例，AWS EKS从父区域延伸至其所管辖的Outposts环境支持两种方式。
一种是将Amazon EKS Cluster部署在父区域，在Outposts 中部署自管理的节点组（self-managed node groups）。这些节点运行在Outposts中并注册到EKS控制平面。
图17 跨父区域和Outposts环境部署EKS集群示意
另一种方式是AWS刚刚（2022.09.30）宣布的支持在Outposts中部署本地EKS集群（local cluster）。详情可参考官宣文档 https://aws.amazon.com/cn/blogs/containers/amazon-eks-on-aws-outposts-now-supports-local-clusters/。
图18 在Outposts环境中部署本地EKS集群示意
这两种EKS延伸模式，对本地区域和Wavelength区域也都适用，不再赘述。
五、分布式云典型案例 - GCP Anthos
GCP Anthos 是一个支持多云和混合云场景的多K8S集群管理平台，支持在GCP、客户本地环境和其它公有云中运行的多个K8S集群中构建、部署和运行云原生应用。
图19 GCP Anthos平台架构示意
如图19所示，可将Anthos看做一个多层平台。基础架构层包括计算、网络和存储资源，支持资源位于GCP、客户本地和其它公有云上。在容器管理层中，Antohs自带K8S发行版（Anthos Cluster），可部署在基础架构之中，还支持将兼容的K8S集群注册到Anthos平台之上。Anthos Service Mesh负责进行服务管理。Anthos Config Management组件负责策略管理。CGP Cloud Run 和 GCP Cloud Code 等服务负责应用管理。再上面是监控和管理层。
下面提供几张界面截图，详细情况请读者自行研究。
图20 GCP Anthos平台界面 - 主界面
图21 GCP Anthos平台界面 - 集群列表
图22 GCP Anthos平台界面 - 集群管理
图23 GCP Anthos平台界面 - 服务网格界面
六、写在最后
从诞生到目前这短短不到20年间，云计算始终在高速发展，云服务和产品在不断演进，用户的用云模式也在不断演进，云计算理念在逐步深入人心。公有云、私有云、混合云、分布式云等等，云计算行业一直在推陈出新，各种云计算形态层出不穷，让云计算业态变得越发五彩斑斓、丰富多彩。
让云计算的发展来得更猛烈些吧！