966,690 三月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
UCloud下一代VPC架构平滑演进方案和技术详解
UCloud下一代VPC架构平滑演进方案和技术详解
日. 估计阅读时间:
不到一分钟
存量机房的原地升级和新机房部署是完全不同的工作。前者要考虑复杂的现网环境，存量机房往往包含多个历史版本，还有针对某些客户做的定制化逻辑，新特性的实现要考虑到各种场景下的兼容性。现网的控制数据也要转换成新格式。网络作为系统级的底层服务，几乎被所有的云服务所使用，其原地升级要比其他产品更为复杂，堪称是云计算中的移花接木。另外，网络原地升级必须要保证用户的业务不受哪怕1秒钟的中断。为了控制风险，全网一次性的升级是万万不可的，只能通过渐进的、蚂蚁搬家式的灰度升级才能做到平稳运营，才能做到步步为赢。
接下来，一起看下UCloud VPCng平滑升级的架构方案和技术细节。
VPCng的网络架构如下图所示，主要由VPC、Subnet、RouteTable三大核心模块组成：
相关厂商内容
相关赞助商
ArchSummit深圳-8日，深圳&华侨城洲际酒店，
VPC是隶属于某一租户的虚拟网络，租户可以自定义网段。VPCng考虑到用户使用场景，对已经创建好的VPC也可以新增网段。值得一提的是，公共服务和混合云作为单独VPC来处理，从架构上清晰很多。
Subnet是VPC资源管理的最小单位，用来管理云主机、物理云主机、云数据库、容器等资源，VPCng的一大亮点是Subnet可以跨可用区，对于跨可用区灾备提供有力保障。
RouteTable是VPCng设计的核心，负责分布式虚拟路由（DVR）的管理。每个子网都需要关联一张路由表。
图1 VPCng整体架构
分布式虚拟路由（DVR）
现有的VPC网络中，部分产品在使用自定义子网时需要先去创建一个虚拟路由器（VRouter）。路由器具备三个特性：多主机共享出外网、指定端口转发、子网间内网互通。东西向和南北向的流量都要经过虚拟路由器。两个子网互通需要经过VRouter，子网访问外网也需要穿越VRouter，这样不仅物理路径上多了一跳，并且VRouter本身会成为性能瓶颈。
图2 集中式路由器架构
VPCng重构了路由定义，并抽象为分布式虚拟路由DVR。DVR的载体是分散在各个计算节点上的虚拟交换机，而路由表是其核心。如下图，东西向流量通过虚拟交换机进行分发，实现点对点通信。而NATGW只是作为外网访问的网关设备，提供多子网共享出外网能力。在路由表设计上，支持多种路由类型，包括直连路由、缺省路由、混合云路由、主机路由等等，除此之外还支持策略路由以及定义路由优先级。
图3 分布式虚拟路由（DVR）架构
DVR作为VPCng设计的核心，平滑升级尤为重要。VPCng设计之初就考虑到上线过程要做到对用户透明，在不影响现有业务情况下，平滑升级到新架构中，所以在升级方案设计上也比较复杂。
整个升级过程拆分成四个阶段。
Stage1 路由表数据迁移
大型分布式系统的平滑升级，最难做到的是控制数据的无缝迁移。VPCng的路由表结构变动很大，在此我们借鉴了可用区升级中经典的“双写方案”，先将存量数据转换为新表结构，然后改造现有管理服务模块，使其具备新老表双写能力。这个阶段数据一致性是最重要的，必须时要通过对账进行一致性校验。
Stage2 SDN转发面服务升级
转发面服务直接影响到存量用户的现网服务，所以升级过程必须慎之又慎。 路由表和控制器模块是本次SDN转发面服务升级的重心，我们通过设计一层转发Proxy实现了按用户灰度的能力，只有灰度用户才能走到新转发逻辑，有效控制灰度影响范围。
Stage3 SDN控制面服务升级
为了满足VPCng的功能和性能需求，这个阶段我们做了大量重构，原有控制面架构采用分层结构，可扩展性不好。新加特性涉及多处改动，而且容易造成脏数据。UVPCFE是一套基于Golang语言开发微服务系统，稳定、快速，可扩展性好。UVPCFE通过APIGW灰度系统同样做到用户级别的灰度。这个阶段由于前端尚未开放，所以仍然需要保证数据的“双写”。
Stage4 前端开放升级
前三个阶段完成后，存量用户后台已经运行在新的网络架构下。所以Stage4阶段要做的事情变的简单，只要把VPCng的控制台开放给用户即可。图中绿色部分表示VPCng业务逻辑，蓝色部分表示原有逻辑，这两套逻辑在灰度过程中长期存在，一旦发现新逻辑有缺陷，可以立即回滚到原有逻辑，现有业务不受影响。
图4 VPCng灰度方案
详细的升级方案让平滑升级过程变得可行、可控、可回滚，在实际操作中也会遇到各种问题。底层网络架构升级，对各个业务（云主机，云数据等）的管理服务都会产生影响，必然会存在业务间的耦合，即便是网络系统内部模块也会存在灰度时序问题。如何做到解耦合？如何控制好灰度发布节奏？这些问题都离不开系统化的统筹和精细化的运营，这是考验一支团队是否具备大型分布式系统持续运营的能力。
UCloud云平台提供了许多公共服务如内网DNS、NTP、软件源等，这些公共服务对所有租户开放。不同租户的IP可能相同，他们都可能去访问公共服务后端服务器，所以后端服务器无法通过路由表决定返回哪个租户。举例来说：租户A和租户B云主机的IP地址均为172.16.0.16，当访问内网DNS时，DNS服务器回复时无法决定是送到租户A还是B。
图5 公共服务集中式NAT架构
现有VPC网络是通过NAT转换来实现的，这也是业界主流的解决方案，这需要解决两个问题：
首先，要解决用户子网和公共服务子网网段重叠导致路由冲突问题。考虑到公共服务子网规模不大，通常采取预留网段的方式，确保公共服务网段不被用户使用。
其次，要解决NAT转换的问题。
UCloud团队论证了多种NAT可行方案，这里介绍两种：
NAT网关采用namespace方案，为每个租户创建独立的namespace，在namespace里面进行SNAT转换，通过SNAT后的IP去访问公共服务。公共服务响应的报文在namespace里面进行DNAT转换，送回给租户，从而达到访问公共服务目的。
NAT网关会将租户ID信息保存到SKB的mark上，通过内核netfilter模块做SNAT转换，同时connection track中会维护mark对应关系。NAT网关收到公共服务响应报文后匹配connection track，得到mark，然后通过netfilter做DNAT将mark对应报文返回给租户。
这些NAT方案存在两个问题，一是源地址不可见，如果公共服务依赖源地址，则此方案不可行；二是NAT网关是性能瓶颈，特别是针对大流量的公共服务（如UFile），需要搭建多台服务器方能支撑。
VPCng吸收了分布式NAT理念，将集中式的NAT网关分散到各个计算节点的虚拟交换机上，解决了网关性能的问题，并自主研发一套NAT Plugin来解决源地址问题，不同租户即使IP相同也能正常访问公共服务。分布式NAT架构图如下：
图6 公共服务分布式NAT架构
混合云连接传统IT和公有云，博采众之所长，目前已是云计算发展的主流趋势之一。在传统的混合云方案中，混合云只是作为若干网段接入公有云，用户的诸多日常需求比如路由管理、带宽容量管理，混合云日常运维需要大量人力和沟通成本，亟需优化。
在VPCng的设计方案中，混合云抽象为租户的一个独立VPC，其中包含多个子网，子网可以是托管设备网段，也可以是通过光纤、数字链路、VPN连接到公有云POP点的自建IDC网段。混合云VPC的架构图如下：
图7 混合云VPC架构
为了在功能上完全兼容VPCng，混合云需要支持用户自定义混合云网段、用户自定义混合云路由策略、用户自主控制混合云的连通权限等特性，因此混合云系统的控制面需要完全重构，另外对于作为转发面核心的混合云网关提出了转发能力、路由控制能力、鉴权能力等全方位的新需求。此外，我们还必须保证让用户无感知地从传统混合云升级到混合云VPC。
我们设计了与旧混合云控制系统完全解耦的新系统，数据库、控制程序均与旧版本独立。在用户添加路由、修改网段等动作时，API层利用消息队列对DB进行双写，同时通过DB对账保证数据的一致性。新旧系统分别拥有独立的转发面，分别独立拉取后台配置，确保新旧系统除了双写动作其他操作均解耦。
为了支持混合云VPC，我们开发了新版本的混合云网关。通过拉取后台配置，网关执行相关报文的鉴权、转发、封装和解封装等操作。同时，网关集群拥有scale out的能力，可无缝扩容，最高支持高达数百G的流量转发。
混合云网关的无缝切换是升级的核心步骤。我们开发了多个工具以辅助这个关键过程：
基于Netconf的交换机配置API，用于切换及回退交换机侧路由配置。
基于VPCng的路由切换API，VPCng控制后台结合推送与拉取，可以在10s内更新全网三层路由流表。该API用于切换及回退公有云侧的路由配置。
基于OVS PacketOut的连通性检查工具，通过拼接ICMP报文，注入到公有云宿主机的OVS Virtual Interface上，可以模拟用户的业务互通，并基本覆盖用户的连通性黑盒检查场景。
基于交换机统计数据、混合云网关统计数据的流量统计工具，可以从统计角度确认用户切换前后的流量状况。
转发面的切换过程如下图所示：
图8 混合云VPC转发面切换流程
步骤一：调用交换机侧路由切换API，切换PE的路由，此时，混合云侧向公有云侧的流量已经切换至新混合云网关，而公有云侧到混合云侧的流量则仍然给到旧混合云网关。我们在网关类产品设计的一条基本理念就是路由交换网关一定要是无状态的，因此用户的服务不会受到任何影响。切换之后，利用连通性检查工具和流量统计工具进行检查，如发现异常立即回退。
步骤二：调用公有云侧路由切换API，切换公有云侧路由。切换完成后，新混合云网关将承载全部流量。同样利用工具进行检查，发现异常则回退。
我们按照上述策略对多个用户的混合云系统进行了成功升级，从实践来看，用户完全无感知。
云网络是大型公有云平台的基石，网络架构调整是对云服务商研发、交付、运营等综合能力的考验。从系统设计、灰度方案，到每个阶段实施、变更发布、最后交付，UCloud VPCng最大化做到了平滑演进。
另外，在本篇技术分享中，我们也详细介绍了VPCng在升级过程中遇到的几个关键问题以及应对之策，当然VPCng升级复杂度还不止这些，欢迎大家就相关技术细节进行讨论。
钟春山，UCloud高级网络研发工程师，下一代VPC网络的负责人，曾参与UCloud可用区的设计和研发。在超大规模SDN网络构建、分布式系统研发、海量数据运营等方面有着丰富的实战经验。
冯业浩，UCloud网络研发工程师，混合云网络负责人，先后负责UCloud负载均衡、虚拟路由、跨域网关、混合云网关等产品的设计和研发。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。UCloud叶仲华：视频直播核心技术解析
UCloud云计算
视频直播是当下炙手可热的互联网业务，它融合了图像、文字、声音等丰富元素，是未来互联网的重要组成部分。但是，其所需的技术研发、网络带宽和服务器成本也成了阻碍直播发展的关键因素。作为国内最早提供“直播云”的云计算服务提供商，UCloud对视频直播架构的优化有着自己的理解。
本文为UCloud高级架构师叶仲华在2016全球移动技术大会上发表的演讲内容，主要介绍了视频直播重点要关注的内容以及UCloud“直播云”的平台架构，希望对正在开发直播App和想要了解云直播架构的朋友有一些帮助。
本文大纲如下：
直播业务的关注点
直播主要的技术范畴
跨网通信的优化
播放器的软硬编解码
图1：UCloud高级架构师叶仲华
首先，先来看一组数字：
200小时：这是国外Youtube每一分钟上传视频的时长。一分钟，它的用户就会上传长达200个小时的视频。
30亿：是脸书每天观看视频的次数，可以看到视频这块的活跃度。
300人：这是每分钟全球增加的视频用户数。
60%：指的是视频流量占整个互联网流量的60%。
从这些数字上来看，视频是一个非常大的市场。
图2：视频相关的数字
直播业务的关注点
第一、首屏的秒开。
大家如果使用过一些直播APP的话，会有很直接的体验。一些直播APP打开之后，可能会出现画面不能动或者是黑屏状态，要过一会儿才播放，然后你就得等。
通常打开一个APP也会有加载的过程，这个从技术上来讲大家可以理解。但是从最终用户的角度来讲，肯定倾向于打开就能播放。所以，实际上这是现在主流直播APP要实现的功能，叫做首屏秒开，基本上所需要的时间也就是一秒。
当然，首屏秒开只是说你怎样在很短时间内把视频数据快速呈现出来，是一个体验上的改进，并不包括从内容生产方传输到直播观看者应用整个业务的延迟。
第二、低卡顿率。
大家看视频的时候卡了不爽，直播卡了就更不爽。因为哪一个瞬间卡住，等会可能就看不到了，所以“卡顿率”也是大家比较关注的。这个与你后端网络的分发，客户端的设计、视频的切片间隔可能都有关系。
第三、低延时。
低延时指的是内容生产方到直播观看者之间的延时，这个延时希望做到尽量低。当你的用户在做送花、聊天等一些视频社交的时候，你的内容方可以很快对这些互动做响应。所以这个时间越短越好，如果要求一些动作在用户看来是同时发生的。那么这个对于延时的要求，可能会更苛刻。
第四、多码率和多格式。
这个主要是一个适配的问题。多码率更多是一个网络环境的适配，比如说你在WIFI环境下，在3G环境下，在4G环境下，你是在热点区域下，还是在一个信号不太好的情况下，这都对码率非常敏感。
实际上，所谓码率就是下载带宽。当带宽不大的时候，既要去保证清晰度还要流畅度，这实际上是有矛盾的。所以，什么时候去给用户更换码率，也是大家需要考虑的问题。
多格式，这个和多终端是相关的。比如说，苹果的一些设备，如果直接通过浏览器去看的话，你看不了Http Flv的视频，而像RTMP的格式，你需要有对应的播放器才能播放。
第五、多终端。
这个基本上就是移动端的iOS，安卓，包括PC端等不同方式。
图3：视频直播业务的五大关注点
直播主要的技术范畴
用户对直播往往有着不同需求，将他们的需求抽象出来，变成我们能够适配的技术和能够提供的产品很重要。所以，我们主要看几个方面：
第一个，与视频相关的协议及编解码的技术。
第二个，跟后台相关的，包括你的调度、社交因素等等。不管你是自己做，还是用云服务商提供的SDK来做，总而言之，你必须有后端逻辑系统。
对于直播，有三种协议会非常普遍。一个就是RTMP，这是Adobe的一个专利协议，目前使用比较普遍，除了有很多的开源软件适配，还有开源库的支持。这些都比较完善。
它会带来功能上的好处，但是纯从建立连接的时间上来讲，因为HTTP本身没有复杂的状态交互，所以HTTP的方式肯定会比RTMP快一些。当然这都是属于百毫秒级别的体验了。最后苹果的HLS使用也很广泛。因为在苹果的平台上，HLS的全称就叫Http Live streaming，可用HTML5直接打开播放，不管通过微信分享链接还是其他方式，无需APP都可以。
图4：直播的三种协议对比
在面对PC端和移动APP端这两个不同场景时，视频推送的过程中要做一些调整。如果说推流端是PC，一般我们认为它的网络环境会好一点。推流上来之后，直播云平台会直接分发给观看的用户。
如果推流端换成移动APP，那么对于推流的清晰度要求会下调一些。因为移动端来推的话很费流量，而对于观看的用户来讲，用这么高的清晰度传输也浪费。带宽不大的话肯定会卡顿。为了解决这些问题，必须在实时转码后再进行分发。
图5：直播协议的典型场景
此外在后台系统中，可能要需要一些截图，鉴黄，直播转存的功能。截图主要是获取主播当时的状态，你可能要将其更新到封面图片上。另外在实时截图中，鉴黄也是大家需要考虑的重点。
很多公司还在依靠人工来鉴黄，而一些直播云服务商已经开始通过机器学习来做图片识别了。通过技术的运用，可以大幅减轻人工鉴黄的压力。
直播转存是说主播直播完，可能他（她）的粉丝希望回看。这时候需要提前录制，获得一个可点播的视频文件。
图6：直播相关服务
现在监管部门要求直播类的APP必须把它的内容做一个15天的存储。主要是因为之前有一些直播网站出现“造娃”等不良事件，所以在监管上会有这样的考虑。
这些东西最终都要存下来，那就对直播存储的安全和稳定提出了要求。所以在直播后台要有相应的分布式存储集群去处理这样的数据。
图7：直播云平台架构
跨网通信的优化
在直播中，拉流端跟推流端实际上是对称的。拿着电信手机的用户在路上直播了一个视频。而观众可能是移动跟联通的用户。我们都知道，现在国内的网络基本上都有一个跨网通信的问题，所以你让移动或者联通的用户直接去看电信用户的直播效果会比较差。因为这都是跨网流量，延迟，卡顿会比较严重。
所以我们云服务商必须去建三通节点。在北京、上海、广州、成都、武汉、沈阳、南京、西安多个城市建立数据中心并连入不同的运营商，当跨运营商的场景出现时，我们会把推流送到三通节点做一个转发，然后让距离用户最近的运营商传输。这就明显提高了用户体验。
图8：直播网络与调度
播放器的软硬编解码
播放器的软硬编解码也是一个需要关注的问题。硬件编解码的时候，iOS还好，但是安卓就很难办。型号太多，硬件也是参次不齐。所以有的时候要用硬件，有的时候要用软件，当中有大量的适配过程。
区别硬件和软件很简单，主要就是看吃不吃CPU，耗不耗电。你要做多终端适配的话，可以在SDK里加一些动态调整的配置文件。这个配置文件会根据我们在后端做的终端适配来实时更新，一旦手机装上APP，就可以知道手机的版本信息。然后再匹配对应的软解、硬解。包括你后期的维护，适配的更新，都会直观的反映到你前端的APP上去。
图9：SDK软硬编解码自动适配
本文讲述了视频直播架构中需要了解的方方面面。不管是协议的选择、跨网通信的优化还是云端SDK和编解码的自动适配，囊括了视频直播业务优化的要点。此外还强调了云服务商分布式推流能力、播放能力、存储能力对视频直播业务的重要性。
——————
点击“阅读原文”了解UCloud直播云更多细节~
UCloud，国内领先的专业云计算服务商
传统企转型“互联网+”需要一次“碎骨重生“式的科技重塑，因此多数处于转型期的企业对业务上云仍持谨慎态度。针对这一市场，作为中国公有云三强之一的UCloud提出“加减乘除”四则运算的新型方法论，全力破解传统企业“云化”难题。
UCloud在技术宣讲、技术推动上已经积累了五年的宝贵经验，UCloud将继续潜心钻研核心技术、前沿技术，做好技术市场推动，与志同道合者一起推动云计算及信息科技的发展。
在前不久刚刚结束的Think in Cloud 2017大会上，关于传统行业如何进行数字化转型，企业IT如何云化，专家们给出了中肯建议。所谓“授之以鱼不如授之以渔”，那么，这次充满干货的大会，给出了哪些有价值的转型思路呢？
UCloud一直将电商行业做为重点关注行业，目前服务的各类电商企业近千家，2017年将围绕电商行业，形成更全面系统的服务链条。本文将重点从电商垂直领域—酒业B2B展开，通过实例客户业务场景，探索其背后的云计算技术服务。
QCon北京2017如期和大家见面，UCloud在QCon第一天便以UCan技术晚场吸引了众多开发者、架构师、运维人员等欢聚一堂。不仅于此，UCloud产品副总裁许杨毅先生在QCon压轴演讲，分享了UCloud云汉—逢云化雨的技术决策论。
刚刚落幕的TIC2017大会下午场——互联网专场可谓吸睛无数，到会的互联网各热点行业先锋代表认同，并分享了他们于各自行业的成功经验，究竟有哪些干货，让我们来一一盘点。
在刚刚结束的TIC 2017大会上，UCloud邀请了国内外具有代表性的先锋企业，就共享经济、企业服务、大数据、人工智能等内容进行了分享。先锋对话之下，不仅是对未来技术新风向的把握，也是共谋云时代下的各行业革新浪潮。
日，QCon在烟花四月的北京如期进行，晚场UCan技术晚场吸引了参会者的注意。
近日，2017亚太CDN峰会在北京隆重召开，UCloud多媒体事业部研发总监曾凯源先生受邀出席，并发表主题为“云+CDN 开发融合全方位蓄势新媒体”的演讲，聚焦行业痛点，创新“云+CDN”融合技术，满足视频行业不同客户的定制化需求。
第二届全球技术领导力峰会（GTLC）即将于日-7月1日在上海宝华万豪酒店盛大召开。UCloud CEO季昕华将出任“CEO碰撞CTO”专场出品人，与广大技术领导者一起碰撞思维，为大家输送精彩内容！
▽▽▽▽▽▽▽图片来源网络版权归原作者所有如有侵权；联系我们?温馨提醒：留言区已开启，欢迎吐槽！点击右下角“
收看? 惠来人 惠来人 失物认领
在惠来惠城豪庭南门一汽车服务店，捡到潮阳区城南“郑俊强”的身份证，有认识的请通知其本人前来认领！联系电话：
提供数码科技信息，涵盖新潮数码产品、笔记本电脑、办公用品、摄像器材等IT系列产品资讯。微信号：ShuMaKJ
看视频！加小编私人微信：ta556633
脸上皮肤暗黄怎么办呢？改善皮肤暗黄的美白方法有哪些呢？对于很多爱美女性来说，暗黄肌肤是一大颜值杀手，怎样美白
日晚9时，在上海结束的中国马拉松年度盛典上，万里长江第一跑——云南·水富国际半程马拉松脱颖
爆笑女神 爆笑女神 点击上面　　看劲爆视频
桃之夭夭，灼灼其华。最近大火的电视剧《三生三世十里桃花》，有多少小伙伴被剧中的十里桃林迷醉？你知道吗？谯
国际在线报道（记者 贾雪静）：正值早春时节的陇南，树木郁郁葱葱，空气清新怡人，万物生机勃发，一如陇南市势头良
哪些收入是单位必须发？哪些是不一定发的？......
UCloud(优刻得)是一家基础云计算(IAAS)专业服务商，我们专注于IAAS(基础架构云计算)的产品研发与运营服务。为您提供最新的云计算行业资讯。
感谢您的支持，请按照如下步骤取消屏蔽ABBAO的广告()：UCloud 可用区的设计理念及功能图文详解
过去的几个月内，UCloud 对自身的云计算基础架构进行了全面升级，于日前宣布基础架构全面支持地域和可用区，并将可用区项目命名为 Sixshot。通过这两层的设计架构来组织云服务，可以为用户提供高可用的云服务。随着可用区的推出，用户可以获得更灵活的资源规划能力和更强大的容灾设计能力。
UCloud 在很久之前即开始着手可用区项目 Sixshot 的整体布局。
2014年起开始致力为分布在各个地区的数据中心建设高可用高带宽的同城环网，将北京的多个主力机房的内网互相打通；其后在完善环网之余，先后对华北、华南、华东、亚太等地的网络架构进行了升级优化，完成了各地的双星型 Pop 点建设。这种设计理念充分考虑了机房内网连接的高速性、稳定性、冗余能力和可扩展性，之后各地只需选址新建机房并连入 Pop 点即可。
此次 UCloud 可用区的设计，是在原有工作基础上进行了网络基础架构的系统性升级，相比原同城环网，内网表现更加高速稳定。与此同时，伴随着产品层面的系统级重构，可用区也提供了各云产品的跨机房内网互通能力。
可用区，提供异地容灾和弹性调度能力
地域（Region）指根据地理位置不同将同一地区的云服务组成合集，构成一个地域。目前，UCloud 全球共有7个地域，其中国内有北京一、北京二、浙江、上海、广东五个地域，海外两个地域分别设在香港和美国加州。
可用区（Availability Zones）则是指在同一个地域之内的一组数据中心群，即可用区是由多个数据中心组成，一个地域内一般会有多个可用区。可用区在设计上相互独立，是不同地点的数据中心，在物理和电力上都相互隔离，有独立的安全保障，单个数据中心的故障影响范围被隔离在单个可用区范围内。同时，同一地域内的可用区之间通过高速、稳定、低延迟的网络互相连接，内网互通。
为了实现多机房的容灾部署，按传统方式，企业往往需要增加额外的容灾机房，在计算、网络和存储设备上增加上千万元的成本。另外，企业还要解决机房间的专线部署和复杂的运维问题。这样的成本和复杂度是一般企业所难以承受的。
UCloud 可用区上线后，用户对云资源的管理规划和容灾设计能力将显著提升。
用户可以把应用部署在多个可用区中运行，实现高可用性的应用架构。即使某个可用区的基础设施发生故障（例如，实例硬件故障、存储故障或网络中断），部署在另一个可用区的应用可以不受影响、继续运行。
用户可以将业务中的同种资源（例如主机）随机地创建在两个可用区内，由于可用区间的内网通信延时只有约 1.5ms，当一个可用区故障后，另一个可用区的主机仍可不受影响地继续运行，从而保证了业务的持续性。
值得一提的是，随着基础网络的改造，跨地域的内网通信质量也获得了提升，例如使用 UCloud 提供的跨域内网通道，北京到广州地域的内网延迟仅约 30ms，这为建设两地三中心的容灾方案提供了物理上的保证。
UCloud 可用区设计理念
可用区设计之初，UCloud 吸取了之前本行业内的一些经验教训，确保为用户提供更流畅的产品体验，着重体现了以下几点：
提供在原有产品上的无缝升级能力；
确保可用区的核心功能有出色的使用体验；
设计出解决用户痛点的特色功能，例如混合云的网元互通、共享带宽的自由分组等。
其中，产品的无缝升级能力一直是 UCloud 重点强调的设计理念，因为如此才能保证既有用户的权益，让他们随着 UCloud 的成长而不断获利。
以 EIP（Elastic IP，又称弹性 IP）跨可用区漂移这个功能为例，AWS 和部分国内云服务提供商，虽然具有 EIP 跨可用区使用的能力，但为此需要申请专门的 EIP，并需要将原主机上绑定的 IP 销毁，再绑上新申请的 IP 方能达到目的。使用不方便之余，旧有 IP 也无法再找回；若有备案等原因导致 IP 无法替换，则原有资源就无法享受到 EIP 漂移的便利。
然而，UCloud 设计方案之初，便考虑了已有用户的立场和便利性，确保其存量 IP 都能自由使用 IP 漂移等所有可用区功能。防火墙的设计也是秉承着同样的理念。如 UCloud 特色的共享带宽，原本只限定在单一机房内使用，随可用区上线，该功能也新增了自由编组能力，可以满足用户更加灵活丰富的使用场景。而存量的共享带宽，都可无缝的继续使用和扩展。
UCloud 可用区特色功能
1.网络接入，灵活自由
1.1 外网EIP，支持跨可用区绑定
随着网络底层的重新设计，用户的外网 IP（EIP）可以在一个地域内的任何可用区使用。为了保证业务连续性，IP 地址经常有保留的必要（如备案要求或者应用调用需要）。当需要重新规划可用区间的资源分布时，外网 IP 支持从一个可用区的资源上解绑，并在另一个可用区内使用。
1.2 带宽管理，支持多个 EIP 跨可用区及自由分组
同时，UCloud 特有的外网 IP 带宽管理产品&共享带宽&的形态也有了很大的演进。共享带宽是一种多个外网 IP 共享网络带宽总量的带宽模式。相比每个IP需要单独指定和购买带宽，多IP共享带宽大大提高了带宽使用效率，节省了用户成本。
现在，新形态的共享带宽支持用户将一个地域内的所有 EIP 自由地分组计算。例如，可以将某 10 个 EIP 划分为一个共享带宽组，共享 50M 的带宽，其他 5 个 EIP 归属于另一个共享带宽组，共享 30M 的带宽。而对于核心业务使用的某IP地址，为了保证其带宽不被其余业务抢占，该 IP 仍可以使用独立的带宽计费方式。这种 UCloud 特有的独立带宽和共享带宽协同使用的模式，进一步地满足了用户多样的场景需求，保证了用户业务的稳定性，同时也降低了用户成本。
1.3 ULB负载均衡，支持挂载跨可用区后端
一个地域内的网络设计，除了跨可用区的内网通信保障外，还提供了网络产品层面的高度灵活性。负载均衡（ULB）本次也支持了在一个地域内自由使用，ULB 支持同时挂载不同可用区内的后端实例，为实现跨可用区的资源平衡和容灾在技术上铺平了道路。
2.混合云任意点接入，享受全地域网元互通
可用区和混合云方案结合，也可以产生1+1&2的效果，创造更大的价值。UCloud 提供物理云、托管云、专线等多种云接入方式，支持用户创造公私结合的混合云方案，解决用户分步骤平滑上云的痛点。所以，在同一地域内（例如北京），UCloud 也提供了多个可供选择的托管云接入机房以及多个专线接入点，这些接入点都有完善的冗余和容灾设计。
在可用区未上线前，混合云的接入位置和公有云资源的位置存在一定的耦合关系，给用户使用带来了限制。例如，用户将自有服务器托管到 UCloud 北京 C 数据中心，则默认只能与北京 C 的公有云形成互通。这种混合云模式对用户业务扩展造成不便，若其在北京 D 又部署了公有云资源，则需要单独搭建转发集群，才能与 C 的托管云互通，增加了维护成本。
随着可用区上线，用户将混合云就近接入到任一位置，都能把其私有资源和该地域内所有可用区的公有云资源直接打通。这种一揽子解决的接入方案，提供了将混合云和公有云部署解耦的能力，大大减少了用户在上云过程中所耗费的精力和产生的顾虑。
3.两地三中心，高层次的容灾方案
传统方式的跨数据中心容灾，对用户而言是一个成本高昂且费事费力的任务。用户需要在两个数据中心都部署一套同样的系统，并通过数据中心间的专线进行数据同步等工作。对外则需要通过 DNS 解析等方式，在灾备时将业务从一处切换到另一处。
地域和可用区的产品特性，结合 UCloud 的跨域内网高速连接，可以为用户构建更高层次的容灾设计和完整的两地三中心解决方案。
由于 EIP 和 ULB 可以在地域级别存在，一个地域内可以部署一套 EIP 和 ULB，并以此固定地向外提供服务。ULB 后端可以挂载来自两个可用区的资源。因而可以将后端业务中使用的主机、数据库、内存缓存等分散地分布于多个可用区内，这样就构成了同城内双活的两个中心（生产中心和同城灾备中心）。这两个中心具有基本同等的业务处理能力，数据通过跨可用区自身的内网进行实时同步。日常情况下，两个中心可同时分担业务和管理系统的运行，并可切换运行或同时运行；灾难情况下，可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。
此外，UCloud 提供的跨域内网高速连接（UDPN），可以为相对地理位置较远的两个地域（如北京和广东）的公有云之间提供高速而稳定的内网连接。使用 UDPN 后，北京到广州的内网延迟可以稳定在 30ms 左右，而 UDPN 的成本比用户自建北京-广州的专线成本低很多，这为部署&两地三中心&中的异地灾备中心，创造了基础设施层面的条件。
同时，UDB 数据库产品支持跨可用区的数据实时同步能力，通过将主库和从库分别部署在不同的可用区内，支持业务节点和数据节点的热备能力；还可用通过跨域的内网连接实现多地的数据节点冷备。相比原来的集群，具备的指数级的容灾能力提升。
用户可以在另一地域，创建一套轻量级的灾备系统，并与主地域进行内网打通，备地域的数据进行跨地域的主从同步。当主地域发生故障时，备地域的系统可以按既定计划拉起，并暂时提供服务。
UCloud 可用区带来的更多更具体的特性提升，可参见下表。
案例解析：中国手游集团有限公司
随着可用区的发布上线，很多 UCloud 用户开始享受到可用区对其业务带来的巨大红利。中国手游集团有限公司（以下简称中手游）是一个 UCloud 典型的混合云重度用户，其有大量的服务器资源，因历史原因和系统设计，无法全部上云，为享受云计算技术的红利，他们选择 UCloud 的混合云方案，其自有的服务器接入 UCloud 北京的混合云接入点，同时在北京的 B、C、D 等多机房部署了公有云业务，两者通过北京地区的内网环网打通。
出于其自身业务和管理的需要，中手游托管云采用分批分项目的方式，分别接入了北京 B、C、D 等地的托管接入点，公有云资源也平均分布于北京 B、C、D 等处。这就造成北京 B 机房的托管云和北京 C 机房的公有云、北京 D 机房的托管云和北京 B 机房的公有云通信等需求。为应对这类通信需要，中手游使用了 UCloud 为其搭建的转发集群，但是转发集群存在一定的运维成本，而且流量有突发等情况，原有集群面临转发能力限制和扩容需求。且随其项目的增多，集群管理的复杂度也相应上升。UCloud 可用区的推出，很好地帮助中手游解决了该痛点。
伴随着网络架构的升级，混合云和跨可用区的公有云直接可以通过内网高速互通，吞吐率和稳定性直接通过 UCloud 基础架构进行保障，其性能不再依赖转发集群，也让中手游的运维成本降低至零。
运营能力保证无缝升级
可用区整体上线也体现了 UCloud强大的运营系统和运营能力。为支持可用区，UCloud 现有的所有产品和基础设施都需要进行大幅度的重构。而 UCloud 现已为3万多家企业级用户提供公有云服务，上面运行着海量的服务和数据。如何在不影响用户业务的情况下，进行全系统级的复杂重构？这就要求整个底层的业务运营系统设计，能满足无缝、透明的要求。唯有如此，底层功能大大小小的每一次迭代，才不会影响用户的数据安全和业务安全。
除运营系统设计外，UCloud 还拥有专业的运营团队和丰富的运营经验。在功能实际上线前，预先设计了详细周密的发布计划，经过了数次发布演练和压力测试，此外还有监控分析系统，不断实时监测实施状况并反馈，并分析潜在风险点。
而数万量级的用户，根据业务特性、资源种类、地域分布等，被细化拆分成上百组用户组。这些群组按事先设计的计划表，按序分批上线功能。上线前后，售前售后团队保持全程跟踪，保证用户最快的适应和使用功能。
除保证功能升级对用户业务无影响外，UCloud 还通过合理的技术方案，努力让原有的存量机房都具有产品持续升级的能力。确保不同阶段建设的机房，尽管底层的物理实现存在差异，但都能在产品层面上向同一个方面不断演进，维护原有用户的利益。
云计算是一个飞速发展的行业，新产品新特性不断涌现，UCloud 依靠强大的云平台运营能力，让每位用户安全、便利的享受云计算带来的好处，跟上云时代的步伐。
可用区体现了云服务商的更高层次的基础设施设计能力，是一个 IaaS 服务商发展到一定规模和阶段后必然的选择。UCloud 通过完善复杂的系统设计和细粒度灰度控制，向用户安全平滑地交付了可用区这一重大功能，为用户基于云平台搭建更灵活更可靠的业务系统提供了底层保障。
上一篇：下一篇：
-08%-23%34%34%-35%-37%-44%-47%-57%-75%-85%-97%
分享到微信朋友圈
打开微信，点击底部的“发现”，
使用“扫一扫”将网页分享至朋友圈。
请将我们加入您的广告过滤器的白名单，请支持开源站点。谢谢您。