云计算服务器技术市场分析

云计算服务器技术市场分析

云服务器哪家强？AWS、Azure、阿里云、腾讯云、华为云深度评测

上云在几乎已经成了很多企业的标配，云服务器因为不需要运维人员去机房维护，也不需要企业去建设机房等，大大降低了企业的IT资源门槛，可以帮助用户快速实现业务部署。云服务器的随需随买、灵活弹性也让企业可以从容应对流量高峰。

随着云计算行业发展越发成熟，厂商们服务器迭代越来越快、服务器的种类也是五花八门，不同的厂商的云服务器性能也让企业们非常关注。

在国际市场，亚马逊AWS、微软Azure和阿里云分列前三。在国内市场，阿里云占据了近一半份额，紧随其后的是腾讯云和华为云等。

因此，笔者选取了上述几家云厂商的主力产品，分别从计算、网络、存储等多维度进行深度分析，并在MySQL、Redis和Ngnix等典型场景下进行测试。

准备：机型选定

此次评测我们选取了各家云厂商最新CPU对应的规格，均为搭载英特尔的Cascade Lake CPU的中主频机型，同样选择8核32G的机型，这是一般企业在平日业务中用得最多的规格，最接近实际业务需要。操作系统也都选择了一样的CentOS 7.4。

目前谷歌云并未进入中国市场，对于国内用户来说，使用非常不方便，因此就不进行评测了。

我们分别选定了AWS的通用实例m5、微软Azure常规用途系列 Ddv4、阿里云六代增强型实例g6e、腾讯云的标准型 S5、华为云通用计算增强型c6s。由于华为没有32G内存的，我们选择了8核16G的c6s。这里没有选择华为的c6型是因为其c6的vCPU不与物理CPU的超线程绑定，无法保证稳定的计算性能。

服务器最重要的无非是计算、存储、网络性能，接下来，我们会这三大方面去评测。最后，我们还会看下特定业务运行在几家的服务器上的情况。

一、计算性能

1、整体性能

首先我们对五款云服务器做整体计算性能的跑分。做任何的业务计算都需要占用大量CPU的运算能力，比如直播等视频编解码等，业务高峰期CPU的利用率经常会达到90%以上。

测试工具：我们选择了评测工具SPEC CPU。SPEC CPU是标准性能评价机构 (Standard Performance Evaluation Corporation，简称SPEC)开发的用于评测CPU性能的基准程序测试组，是一套CPU子系统测试工具。处理器、内存和编译器都会影响最终的测试结果，而I/O（磁盘）、网络、操作系统和图形子系统对SPEC CPU2000的影响非常小。目前，SPEC CPU是业界首选的CPU评测工具。我们使用了其中的SPECint基准测试程序来评测各家云服务器的整型处理性能。

结果：我们可以看到，Azure的计算性能分最好，阿里云排名第二，腾讯云和AWS次之，华为云的c6s分数最低。

2、浮点计算能力/CPU性能

接下来，我们看下浮点运算能力，包括单核、多核浮点性能。使用的工具是Super Pi，这是一个比较聚焦和简单的算例，专门算圆周率，跟CPU的主频密切相关，耗时越短性能越高。

结果：我们可以看到，这个结果跟CPU主频确实是密切相关的。在多核性能下，耗时最短的是Azure和华为云，然后是阿里云，最后分别是AWS和腾讯云。

除了CPU之外，内存的性能在一定程度上决定系统表现，特别是针对大量访问内存的场景，如关系型数据库。而几乎所有的业务，都会用到关系型数据库。内存性能主要分为两个方面，内存带宽和内存延迟。

3、内存带宽

测试工具：Stream是业内公认的用于内存性能评估的基准测试软件，其包括Copy（复制）、Scale（乘法）、Add（加法）以及Triad（三者复合）四种不同操作情况下的内存带宽表现。

测试结果：阿里云g6e与华为云c6s差不多，算并列第一，腾讯云第二，AWS第三，Azure明显落后。

4、内存延迟

测试工具：MLC为 Intel官方提供的免费内存测试工具，可以有效方便地测试内存延时。

测试结果：华为云的内存延时最低，仅为85ns；阿里云、腾讯云也在90ns左右，剩下分别是Azure、AWS。

二、网络性能

接下来是网络性能，我们主要看PPS和时延。

1、PPS

PPS是每秒传输的数据包数量，直播等网络要求较高场景对PPS要求比较高。单实例PPS越大，网络性能越强，往往意味着可支撑更大的业务量。

在业务运行过程中，如果PPS比较高，QPS也会相对应更高。比如在非常常见的发弹窗场景，PPS高的机器能承载的发弹窗数量更高，有利于节省业务成本。

测试工具：Netperf是一种网络性能的测量工具，主要针对基于TCP或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即批量数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统发送数据，以及另外一个系统能够以多块的速度接收数据。

测试方法：在云主机A上安装netperf的netserver作为服务器端，云主机B上安装netperf作为客户端，在不运行应用情况下，云主机B压测云主机A（数据包大小1），测试云主机A的网络 UDP 收PPS性能。

网络压力持续时间为5分钟，取云主机A收到压力50秒后持续200秒的PPS平均值。

测试结果：阿里云g6e的网络PPS上明显领先，AWS m5和华为云c6s居中，腾讯云S5次之，Azure Ddv4明显落后。

这里除了AWS厂商没有对实例规格做了QOS规定，可能就是没有限速，而其他云厂商都做了QoS（质量控制）限制，且是符合QoS要求的，所以我们更应该看下面一定压力下的延迟数据，这个对于用户来说更有意义。

2、网络延迟

延迟是大多数企业非常关注指标。因为比如在游戏和直播的业务，对延迟是十分敏感的，这是最关键的指标之一。

测试工具：sockperf，是基于套接字API的网络基准测试实用程序，旨在测试高性能系统的性能（延迟和吞吐量）,也适用于测试常规网络系统的性能。它涵盖了大多数套接字API调用和选项。

测试方法：用sockperf测试服务器在PPS 5000压力环境下的时延。

测试结果：阿里云的网络延时非常出色，AWS的也不错，微软和华为的机器延迟在40-50us左右，腾讯云S5的延时则明显高于其他厂商。

三、存储性能

存储性能取决于不同的存储实现，现阶段不同的云服务器厂商会提供不同的存储解决方案以应对各种使用场景，目前SSD已经成为趋势，Ddv4 暂时不能挂载超级SSD盘，无法测试。

对存储需求最大主要是跑MySQL的场景，只需要用到一块ESSD云盘。但一般来说厂商们出于QoS（质量控制）的原因，即为了保证每台实例的体验（以免有用户买了小规格云盘，却占用了大量带宽），会根据磁盘大小对云盘性能进行限制，因此我们选择了比较大的1.1T的云盘来测试，主要测的是IOPS和延迟。

1、IOPS

存储IOPS影响着单台机器能承载的业务量。电商场景就是非常典型的高IOPS的场景：用户下单，业务场景一般有查询和写入两种情况，查询一般会用很多缓存；写入场景就需要数据及时落盘，要求提高数据的写入并发能力，需要很高的存储IOPS。尤其在大促场景下，单盘更大的IOPS可以支撑更多用户下单。

测试工具：fio是IO性能测试工具，可以运行在Linux、Windows等多种系统之上，可以用来测试本地磁盘、网络存储等的性能。

测试方法：我们在不运行应用情况下，云主机挂载1100G的 SSD云盘，并通过fio压测（4K数据块，随机写、随机读，队列深度为64，numjobs为8）。对存储持续压测一段时间，取write/read的iops值。

结果：阿里云最好，领先其他几乎一倍，华为云次之， AWS和腾讯云则是差不多。

2、读写延迟

存储延迟则影响着用户的体验，比如在电商场景下，延迟越低用户下单的响应速度越快。

测试工具：fio

测试方法：Linux 云主机安装 fio，在不运行应用情况下，云主机挂载1100G的 cloud_essd 硬盘，并通过fio压测（4K数据块，随机写、随机读，队列深度为1，numjobs为1）。存储压力持续时间一段时间，取write/read的lat值。

结果：综合来看，阿里云延时最小，之后分别是AWS、Azure和华为云。

四、特定场景测试

即便跑分性能在高，云服务器毕竟是用来跑业务的，机器的性能最终还是要看E2E的性能。因此，我们选择了最为常用的几项应用。

1、MySQL

MySQL 是最流行的RDBMS(Relational Database Management System：关系数据库管理系统)，在WEB应用方面 MySQL 是最好的RDBMS应用软件之一。

其因为开源、速度、可靠性和适应性而被广泛使用。因而，运行MySQL的能行，也是衡量云服务器表现的一个重要指标。

测试工具：sysbench是跨平台的基准测试工具，支持多线程，支持多种数据库；主要包括以下几种测试：cpu性能、磁盘io性能、调度程序性能、内存分配及传输速度、POSIX线程性能、数据库性能(OLTP基准测试)。这里主要使用对数据库性能的测试。

测试方法：选取相同配置的2台Linux云主机进行配置：云主机A上安装 mysql 作为服务器端，云主机B上安装mysql client 及 sysbench 作为客户端，在不运行其它应用情况下，云主机B压测云主机A，测试云主机A的 mysql 服务性能，结果为取 QPS。网络压力持续时间为10分钟，使用 sysbench 进行压测，获取平均每秒请求数QPS。

结论：阿里云在 MySQL的场景下性能表现突出，AWS和华为的次数不相上下，腾讯明显落后。

由于微软Azure本规格并不支持超级SSD盘，挂载普通云盘测试MySQL意义不大，因此略去。

2、Redis

Redis 是一款开源、高性能的key-value分布式内存数据库，基于内存运行并支持持久化的NoSQL数据库，当前最热门的NoSql数据库之一。

缓存系统、排行榜（如微博的热搜）、最新列表（如最新的视频或新闻列表）、分布式锁和单线程机制（如秒杀系统）等，都是Redis应用的典型场景，在大多数互联网业务中都非常常见。

测试工具：Redis 自带了一个叫 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求。

测试方法：与MySQL的类似，配置两台云主机，分别作为客户端与服务器端进行压测，获取平均每秒查询数，分别压测 get 、set、sadd、mset 四种方式。

结论：综合来看，阿里云g6e跑Redis的性能同样是一骑绝尘，华为云和AWS不相伯仲，华为云险胜，腾讯次之，微软Azure排名最后。

3、Ngnix

Nginx是一款被广泛应用的高性能的http服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。cpu、内存等资源消耗却非常低，运行非常稳定。

测试工具：使用wrk进行压测，wrk是一款简单的HTTP压测工具，能用很少的线程压出很大的并发量。

测试方法：与上类似，在不运行其它应用情况下，作为客户端的云主机B 启动wrk 压测作为服务器端的云主机A，测试云主机A的 nginx服务接受性能。

压测 wrk的测试参数设定，-c参数连接数设为1000, -t线程数根据云主机B的核数计算得出（2倍核数）， 获取平均每秒查询数，分别压测长连接和短连接两种场景。

结论：华为云在长连接的QPS上稍胜一筹，短连接则略有逊色；阿里云则相反；接下来是AWS和腾讯云；微软Azure再次排最后。

总结：综合打分

我们可以根据上述跑分的排名，将各厂商每一项的排名记录下来，并加总，最后总分最小的，就是服务器总排名最高的厂商。

根据得分表来看，阿里云位列综合排名第一，在PPS、存储IOPS上有相当大的领先优势。在基础性能（CPU、内存）部分，每个厂商各有千秋，这个是硬件选型决定的，测出来的数据符合各个厂商硬件预期。

综合来看，阿里云的g6e的表现还是非常出色的，搭载的CPU虽然不是频率最高的，但存储和网络占据绝对性能优势，这依赖于阿里云在服务器架构上的创新，对网络硬件加速及存储技术都做了创新优化。

需要特别指出是，阿里云g6e在E2E方面的表现不俗，已领先国际友商一大截。E2E展现在使用云服务器时上层业务的表现，是最能体现综合性能优势的。最终对比下来，阿里云这款g6e实例确实达到了不错的效果。

其次是华为云，华为云在内存性能这块非常突出，如果内存时延敏感可以考虑选择华为云。其综合能力也不错，同样的CPU性能没拿到第一，但在E2E性能方面排名基本靠前。

接下来就是云计算祖师爷祖AWS，整体测试下来的感觉是比较均衡发展的，各方面都OK，唯独在内存延迟这里明显落后，主频的话由搭载的CPU决定，表现一般。

微软Azure在CPU这块性能第一，网络延时也还可以，不过因为没法挂载高性能云盘不好判断存储性能，其他性能表现一般，而且考虑到Azure在国内的布点，对用户又不太友好，着实不大推荐，如果业务对主频敏感可以考虑。

最后是腾讯云，腾讯云的S5在计算性能、内存带宽和内存延时上的跑分还不错，Ngnix的性能表现也OK，浮点运算方面它虽然排第二，其实各家相差不大，但网络延时方面S5显然与其他实例差距有点大。

各家表现都已经一目了然，在买的的时候可能还得考虑性价比。由于价格取决于各家云厂商折扣活动非常多，对不同用户也有不同的优惠政策，大家可以选购的时候结合自己的折扣考虑。

百度知道上云与架构演进

百度知道作为上线十多年的老产品线，业务场景多、架构老旧、代码风格不统一，同时业务迭代较快，整体承载流量大，稳定性要求高，给业务全面上云带来不小的挑战。本文基于实践，介绍知道如何进行上云方案的选型和落地，并同步进行架构演进，提升线上服务稳定性和容灾能力。

背景与挑战 

1.1 背景 
随着集团PaaS化战略和云上百度战略推进，当前在线运行平台ORP已正式进入维稳阶段，不再进行功能更新和安全修复；同时ORP接入层在稳定性、变更效率等方面也无法满足云上部署要求。OXP逐渐成为业务发展和迭代的瓶颈。为了解决这一问题，同时增强资源弹性，降低业务资源成本，接入各类云原生能力，提升部署效率，保障线上服务稳定性，知道启动去OXP专项，将逐步完成整体上云及架构演进工作。 
1.2 挑战 
1、知道产品线老旧，历史债务多。百度知道是一个已有十八年历史的老产品线，业务模式繁杂，上下游依赖较多，不同时期的重点方向不一样，架构老旧，代码风格不统一，改造成本高； 

2、知道业务发展快，迭代变化快。虽然产品线历史久远，为了适应新变化，业务迭代敏捷，核心场景更新换代频繁，年均上线业务需求780+个，需在保证业务目标达成前提下完成上云迁移，使业务全程无感；

3、知道流量大，商业收入多，稳定性要求高。作为知识类流量收入双TOP产品线，知道日均pv过亿，迁移过程中不能影响任何流量和商业收益，核心服务稳定性目标需在四个9以上；

4、上云同时架构合理演进。上云迁移作为知道历史上一次重大技术变革，除了能给老产品线带来先进的云原生能力，优化IT成本以外，还希望借此推动知道整体架构优化演进，提升容灾能力及线上服务稳定性。 

1.3 收益 
1、全部流量上云，为知道带来先进的资源弹性供给能力，大幅提升扩缩容效率，避免流量波动带来的线上容量风险，提升在线服务稳定性； 

2、引入容器弹性售卖能力，按需使用、按量付费、动态调整，优化线上服务整体资源量级；腾退大批量OXP机器，大幅降低知道IT成本；

3、知道架构随上云持续演进，将0到1实现核心流量三地四机房云上部署，降低核心页端到端耗时，使核心页面具备N+1冗余灾备能力，提升业务抗风险能力。 

GEEK TALK 
概念介绍 
2.1 知道业务简介 
知道是传统的图文知识类内容生产业务。首先通过用户自发提问，或者对搜索每日query筛选挖掘，获取到待解决问题；其次引导各类生产者，在不同页面、后台对问题进行解答，生产回答内容；再次将生产好的问答对推送至搜索、Feed等场景供用户浏览消费，用户点击进入问答页后获得解答，同时靠广告点展为知道带来商业收入。 

知道经过多年经营，积累了海量问答资源，在搜索生态中稳定覆盖了众多长尾需求；同时通过识别用户需求，挖掘高价值线索，引入机构或MCN账号，建设了多垂类优质内容，逐渐形成了相对稳定的多层次内容生态和品牌认知。

2.2 业务架构 

知道整体业务架构如下图所示：

 2.3 流量架构 

上云前知道整体流量架构如下图所示：

 GEEK TALK

上云设计与实践

3.1 上云方案选型
知识垂类内php模块广泛使用的PaaS平台orp已公告于2022年底停止维护，同时现有的orp系统在容器编排管理层面存在一些问题，预算资源管理也和现有公司的机制流程不通。知道的现有架构基于odp原生实现，更多体现成一个大型大单体应用，通过本次升级，知道需迁移至更加接近云原生环境的PaaS平台上，进行新一轮的架构迭代，打造符合业务现状的架构理想态。

虽然管理容器化应用程序的开源系统Kubernetes作为社区和未来发展趋势，但综合考虑改造成本、时间节点、开发人力等因素，知道本次上云与其他知识垂类产品线迁移最终选型保持一致：底层使用pandora，资源管理及上线使用“知云平台”。

3.1.1 why pandora

主要有几个方面考虑：

1、pandora适应公司内主要的C端业务，如大搜、feed、手百、百家号、视频（好看）等，这些业务在场景上与知识体系更加接近，详细调研和评估可支持现有变更方案；

2、pandora在现有PaaS内唯一能够支持较多模块同时部署（最大支持2K），而无需业务过多改造合并，更适应现odp大单体的架构；

3、易用性层面pandora暂时不及opera，但已通过知云解决；同时知云会提供orp的包括接入、静态资源、代理、数据配送等服务，故不影响最终选型结论。

3.1.2 why 知云

知识垂类及其他oxp-based业务有个比较明显的架构：大单体模式下的多APP同构，这部分需求在现有的PaaS平台均无支持。同时，因为pandora底层对打包和服务的规范，业务线需要针对性的进行代码改造和回归，这部分工作存在明显的重复性。知云平台旨在提供一套更符合知识业务（及oxp-based）的上云解决方案，主要具备以下几类优势：

1、上线变更：除基础上线、配置管理及回滚等外，核心支持多APP同构的模式，及支持多模块部署。可以做到oxp项目迁移至知云成本降低，理想情况下无需合并/拆分代码库，可以平移支持；

2、平台服务：对标oxp现有服务，提供包括日志切分、定时任务、接入层、静态资源、飞线、中控等的支持和解决方案，同时基于云原生思想开放服务模式，支持业务部署自定义服务；

3、业务运行时环境：odp基础运行环境快速部署和定制；

4、基础环境（容器）：整合入口，在日常运维时提供更方便的操作方案。

3.2 切流与扩量实践
3.2.1 上云前改造

对各流量集群，在迁移Pandora之前，主要涉及以下几方面工作：

1、知云创建产品线及应用。需在知云平台搭建知道产品线基础环境，创建APP基础信息，申请ECI各机房资源2及实例配置，添加ODP基础运行环境及数据配送容器相关信息，创建容器组件相应配置，添加静态文件存储地址，修改部署路径及配置派生conf，创建上线模板等；

2、接入层改造及授权。接入层创建对应新APP的BNS变量，并针对新的BNS进行各类DB、redis授权，涉及新机房，还需要对各mysql及redis配置进行升级适配；

3、业务层改造及测试。知道本次上云会同步完成后端语言HHVM->PHP7升级改造，语言版本更新会带来安全及性能方面的进一步提升，同时PHP7还提供了众多新的语法特型，老旧版本无法使用。需完成对应模块PHP7兼容性问题改造，并完成线下测试；

4、添加监控及日志采集。需添加对应APP的各级noah、sia监控，对各监控项进行调整，对监控阈值进行优化；修改相应日志采集路径，合并各服务组，并离线进行入库效果验证。

3.2.2 切流方案

• 小流量实验方案如下图所示：

  

   接入层改造：

可借助接入层的lua脚本实现小流量切流，脚本实现了以下规则：

['strategy_1_1_98']   = {1, 1, 98},

['strategy_5_5_90']   = {5, 5, 90},

['strategy_10_10_80'] = {10, 10, 80},

['strategy_20_20_60'] = {20, 20, 60},

.....,

['strategy_80_20_0']  = {80, 20, 0},

['strategy_95_5_0']   = {95, 5, 0},

['strategy_100_0_0']  = {100, 0, 0}

返回值有三种结果："opera", "abtest", "orp"，从左到右分别对应三段数字，即每种结果出现的概率，从而可以根据返回的结果实现流量控制；

使用新增变量$upstream_target来标记最终proxy值，四种取值分别对应pc端和移动端实验组/对照组流量：

#设置最终proxy的值：pc_orp、pc_pandora、wap_orp、wap_pandora

set $upstream_target "${terminal_target}_${target_cluster}";

#知道上云切流实验配置结束

新增给业务传递标记，取值为"pandora"、"abtest"、"orp"，分别用来标识实验组、对照组、无关组流量。

业务层改造

业务层捕获上述流量标记，分别创建并使用新的Eid发起商业请求，即可获得当前实验组/对照组各页面商业流量数据。

if ($_SERVER['HTTP_X_BD_TARGET'] == 'pandora') {

    $adsEids = array(

        'asp'  => array(50001),

    );

} else if ($_SERVER['HTTP_X_BD_TARGET'] == 'abtest') {

    $adsEids = array(

        'asp'  => array(50002),

    );

}

3.2.3 扩量相关

以知道核心问答页为例，扩量的每个阶段都有该阶段需重点关注的工作内容，及进入下一个阶段的准入list，需要list内容全部达标，才可开启下一阶段扩量实验。具体说明如下：

3.2.4 云上网关切换

在业务层上云后，网关下游由原本几乎不发生迁移的orp环境，变成了迁移频繁的云上环境，原orp接入层对频繁的下游变化无法做到灵敏感知，因此需对原orp接入层进行上云切换。Janus网关已经广泛使用在了如手百、百科、问一问、经验、百家号等产品线中，与原inrouter对比具有以下优势，同时经过了大量的实践验证，因此知道上云选择了知云体系中的Janus来进行网关切换。

知道经历了18年的迭代，网关的路由转发规则已经臃肿不堪，逻辑繁琐，维护成本非常高，稍有不慎就会引发严重线上事故。网关作为对流量转发控制的服务，应当尽可能地简单、清晰，具备较好的可读性和可维护性。因此在网关上云切换时，应当同步进行路由的深度重构治理，而不是简单的平迁。迁移重构核心流程如下：

最终达到的效果：

1、下游感知灵敏：新网关对下游实例漂移感知灵敏，叠加重试策略，实例漂移对业务SLA几乎无影响；

2、大大增强可维护性：将预览、内网、外网三类域名隔离建设，划分清晰，使用和维护都一目了然。将原nginx转发规则2768行conf文件整合收敛至18条规则，清理了18年来的历史包袱；

3、安全性得到进一步增强：上线细化至每个服务、每条路由、每条转发规则，影响面可控。除了分级发布，叠加checker、上线巡检、测试用例等手段，大大增强了网关上线变更的安全性。

3.3 架构演进

3.3.1 现状&问题

知道长久以来95%以上主体流量集中在北方，核心流量打到tc+jx机房，非核心流量打到yq机房。从外网接入点，到实际业务层，到底层依赖基础服务，再到重要的第三方依赖服务，均没有搭建其他地域资源和服务。这就造成一个非常明显的安全隐患，一旦华北地域出现故障，无法进行彻底的切流来规避线上损失。

3.3.2 演进方案 

1.知道三端QB页核心流量，占知道总体流量80%以上，是知道99%以上商业收入来源，自然流量大，用户交互多，对线上事故敏感，稳定性要求四个9以上。这部分是知道的生命线，本次伴随上云迁移，会同步建设三地四机房，使QB页具备单地域故障快速切流其他两地能力，提升系统整体可靠性； 

2.除QB页以外非核心流量，由于时间久，涉及模块多，底层资源类型繁杂，同时又基本不贡献商业收入，各子系统流量占比较低，考虑改造成本及性价比，本次上云迁移将非核心流量迁至华北双机房，具备同地域不同机房冗余灾备能力，暂不建设其他地域；

3.针对核心流量，需进行“外网接入点->BFE->接入层->业务层->依赖自身服务->依赖三方服务->依赖底层存储”全链路三地资源建设，并进行连通性测试；

4.针对核心流量，各级服务资源到位后，需进行全方位压测及灾备演练，确保新地域机房流量承压能力，并达到单地域故障时可自由切换至其他两地域状态。针对重要的、且无法线上压测演练的三方服务例如商业广告请求，协同对方OP、RD、QA等角色共同制定切流观察方案，以免流量分布改变后造成线上安全隐患；

5.针对核心流量，设计切流方案并建立各三方服务同步机制，切流期间共同观察，上下游各子系统是否符合预期。 

3.3.3 具体实现

知道核心流量三地域建设完成后流量架构演进如下所示：

 GEEK TALK 

总结与收益

1.截至23年3月31日，知道云上流量占比已达100%，知道业务已全面上云。

 2.2022年Q3知道开始切流上云，连续三个季度SLA满足四个9，由上云引入线上问题数0。

3.知道核心页已完成三地四机房建设，知道线上核心流量分布比例为华北:华中:华南=4:3:3，知道历史上首次具备了N+1跨地域冗余灾备能力。

4.小程序QB核心接口端到端耗时均值下降12%，FMP80分位稳定1S内，不需要其他技术优化即达成秒开。

 

 5.完成GTC接入点三地调整，公网IP均摊费用自2023年以来逐月下降，同时批量交付下线OXP机器，节省了大量研发成本。

 

 

 

参考文献链接

https://mp.weixin.qq.com/s/jOYYpyPtNzKeicLixYRVfQ

https://mp.weixin.qq.com/s/P-P3PFS-M0iPEZFY5fpZ1A