腾讯基础构架副总庄泗华：Web云服务是未来趋势

        9 月 9 日消息，腾讯云今天在北京·郎园 Vintage 召开以“亿万云端，信心共享”为主题的腾讯云开放战略发布会。腾讯云终于揭开面纱，正式宣布全面开放。腾讯基础构架助理总经理庄泗华先生在大会现场致辞演 讲，他表示，对于广大的合作伙伴和开发商来讲，如果能够用弹性 Web 服务，就尽量用弹性 Web 服务。

        他表示，不管是从负载均衡来说，还是从安全稳定来说，亦或是从性能、容量、速度来说，腾讯云都是具有高性价比的成熟云服务。他认为，腾讯云的核心系统是经过大规模实战考验的，而腾讯云本身也希望通过这个平台把互联网开放给整个业界同行。

腾讯基础构架副总庄泗华：Web 云服务是未来趋势

        以下是庄泗华演讲实录：

        庄泗华：大家好，非常荣幸有机会在这里和大家分享一下腾讯云的技术特点，先做一下自我介绍，我自己是 2004 年加入腾讯，头几年一直在做 QQ 的 IM 的后台，很多业务的小云合并成腾讯云这朵大云，一起参与腾讯云的建设，从刚才陈磊已经介绍过，其实腾讯云是一早就已经有了，而且可以说它在我们整个腾讯的 内部是有非常广泛的应用，这里它应用在包括腾讯自研的业务，还有很多代言的业务，包括很多平台上第三方开发者的一些游戏和应用。从技术角度来看，应用的类 型也是非常广泛的，包括 Web 类，包括 PC 客户段、包括手机客户端的应用。

        刚才陈磊从整个生态行业这个角度介绍了腾讯云的一个构成，那么我们再看一下，其实腾讯云是包括给用户用的微云，也包括计算云和数据云，我们来看 一下计算云和数据云的主要的服务，因为时间关系今天没法做一个全面的介绍，我只能从中抽几个案例来做一下介绍。从中大家可以感受到腾讯云的每个云服务都是 腾讯的技术团队倾尽心力所打造的，每个云都有自己的应用特点和业务价值。

        首先从负载均衡来说，就是一个用户他经过我们的负载均衡服务器，这里叫 TGW 腾讯网关这样一个简称，负载均衡会分发到后面的服务器，腾讯的负载均衡有什么特点呢？我们可以看到首先第一个是业务程序能获得真实的用户端 IP，我们看这样一个架构图，在 TWO 这一端除了做一个负载均衡之外，还做一个信息包编码，把用户的信息放到 IP 包的包体里面，经过内网转发到服务器，在服务器这边根据刚才说的信息进行一个 IP 包的还原，业务服务器收到的 IP 包就是原 IP 原端口，发回去的时候也会沿着原路返回给用户，我们的业务程序不仅能获得真实的用户端的 IP，它通过 Socket 来获得用户的真实的 IP，随着互联网大潮的到来，越来越多的应用不是 Http 的应用了，需要我们的应用做很多代码修改，这是非常麻烦的，用了腾讯的公网负载均衡之后，是不需要改代码的，大家原来怎么写就怎么写，非常方便。

        第二个业务架叫 ISP 的沟通，在中国 ISP 特别多，而且 ISP 之间互联互通带宽和质量都是比较差的，从架构图上大家可以看到，电信的用户我们可以经过电信的 TGW，联通的通过联通的，移动的通过移动的。还有通过 CAP 平台的，这些用户到 TGW 之间都是骨干网，任何用户只要用了腾讯的负载均衡，它的质量都是非常优异的质量。

        它还能够实现游戏的双线或者多线游戏，在 QQ 内部有一个叫 QQ 九仙的游戏，它有华南、华东电信两个大区，还有网通区，这些在我们还没有研制出公网负载均衡之前做的，按照业务的统计，在电信这个区里面开一台新的服务 器，用户大概十几个小时能把这台新的服务器填满，或者把人数达到上限。如果是在联通这里开一个新的服务器时间就更长，可能要两三天才能把服务器充满，我刚 开始几个小时的用户觉得很无聊，玩着玩着没什么意思，也许人就跑了，使用了我们公网负载均衡之后，新的区叫双线区，不止电信、联通，有了多线区之后，用户 在两三个小时就能把新服务器填满，很多腾讯自研的游戏接了我们的公网负载均衡之后对这样一个机制非常赞赏，而且像刚才说的 ISP 多通，也是业务原来怎么写代码现在怎么写代码，直接用就 OK 了。

        刚才说了公网负载均衡，现在来介绍一下中间的逻辑层，第一个叫云服务器，原来是叫 CVM 是基于 Xen 的虚拟服务，现在是有 Web 服务了，原名是 CEE，弹性服务的量远远不如云服务器，但是从技术的角度来说，弹性 Web 服务才是未来的一个趋势，大家如果对虚拟化有所了解的话，可以知道基于 Xen 的是在上面虚拟出几个物理机器，在每个虚拟的物理及其再跑几个系统，这样的话就造成什么结果呢？一台物理机虚拟出四个虚拟机，就底下母机一个操作系统，上 面每一个虚拟机一个操作系统，总共要五个操作系统，基于 LC 的概念，它是对内存使用量进行隔离，这些 OS 内河内部的机制来实现虚拟化的机制，它的内核只有一个，也没有好几个，最后的效果就是首先轻量级的虚拟化，是某一个 OS 内核，收到一个网络包只要经过传统的到网卡，到应用层就搞定了，就不用像 Xen 这里该要经过多一层的内核。腾讯云的弹性 Web 服务增加了一个附加的功能，是自动和快速扩容的服务，它没有太多时间花在监控要不要扩容，立刻登录下去，紧急申请虚拟机、紧急扩容，它可以把更多时间花在 业务级别的运营上面，业务的趋势、用户的使用情况等等，能为整个业务做出更大的贡献，所有底下的扩容都是 Web 自动服务进行的，而且速度也是非常非常之快，对用户来说没有任何影响。

        因为腾讯云 Web 服务是一个未来的趋势，我们也推荐广大的合作伙伴和开发商，如果能够用弹性 Web 服务，就尽量用弹性 Web 服务，你们会体会到比我说的更多的好处。

        刚才讲了一个业务逻辑层，现在讲存储层，第一个叫云数据库，原来叫 CDB，它有什么额外的特征呢？第一个我们的云数据库有更好的平滑切换、或者是升降级的方式，首先来分析一下最常见的一个做法，也是业界最通用的一个做 法，我们搭建数据库是怎么搭建的，包括很多应用、租用虚拟机，也是那么去搭建的，最常见的就是这样的一个架构。最上面是一个业务的虚拟主机，下面是一台服 务器，搭建一个不够再搭建一个，这之间做一个同步，一旦这台机器挂了就访问备机，这个架构跑得也挺好的，因为业界都是这么跑的，但是它有一定的缺点，什么 缺点呢？第一个要改代码，为什么呢？这台主机挂了，业务代码要探测出情况，比如发现断连了，它就要重连，就要换个 IP，这个是比较麻烦的，需要业务程序写这些代码。另外一个代码像其他的云服务提供商是那么做的，他提供一些新的 EPI，通过这些来去连下面的 Mysql，API 里面做相应的翻译，如果看到这上面还正常就连这个，面上面已经挂了，就翻译成另外一个 IP 给上面的业务层，业务层再去连这个 Slave 的 IP，所以使用门槛也是相当高了，腾讯云的云数据库没有使用这个方案。

        我们来分析一下刚才这个方案最大的问题，如果下面挂了上面要换 IP，我们就进一步推想，我现在不换 IP 怎么办呢？增加一个 TCP 的接入网关，业务 server 连上来，TCP 接入网关，对于上面主机来讲，这个方案确实比原来进步很多，但它也有一定的问题，最大的问题是 TCP 层的接入网关，这是一条业务 server 之间是一个单独的 TCP 连接，这就带来一系列很麻烦的问题，底下的团队可能想运行一个@某个用户的时候就不行了，接着更进一步的我真正的授权还要通过 TCP 接入网关，比如说我们发现这上面有一个慢查询，我们去看这个 Mysql 的数据，哪个用了什么语句，是一个慢查询，在这个架构下查出来哪个哪个 IP，也是 TCP 接入网关的 IP，所以我们还要再去查 TCP 接入网关的数据，所以腾讯云数据库也没有采用。我们把中间的从 TCP 接入网关换成了一个 TGW，它只是用在纯内网的环境里面，因为它有一个编码还原的过程，所以对于后端的业务 server，通过这样一个解决方案就能完美解决刚才的问题。

        补充一点，我们的接入网关 TGW 本身也有一个跨级架的容错，不会因为一台机器死机而影响其他的，这对于业务也是透明的。通过这些手段完美地解决了刚才说的那些问题，最后的效果就是业务 server 直接连就能连到 Mysql 了，如果这台机器挂了，就会连到 Slave 上面去，如果连接突然断了隔个两三秒重新连一下，又正常了。而且这个过程不管是对于 Mysql 挂了，还是一个应用，一开始申请了一个比较小的云数据库，比较便宜，容量也比较小，它会进行一个升级，比如说业务不稳定，进入衰退期，我们要变成一个小规 模的便宜的云数据库，不管是升级还是降级对上面的 Mysql 也是基本透明的，底下导出去的过程下面都不用管。

        刚才说的是云数据库，云数据库其实还是分好几个版本，其中最有技术特点的是高性能版，上面那些层次跟刚才说的是一样的，中间有一个接入网关 TGW，下面那里就不一样了，普通版的云数据库落地存储是落到这台机器上面，对于高性能版来说是落到云储存集群，我们会把它虚拟成一个网络硬盘，在 Mysql 看来本地有一块网络硬盘，这块硬盘不对于任何设备，它可以通过网络都存到后面的云集群里面来。首先我们通过云存储集群就能减少云数据库存储成本，也能降低 价格。

        第二个，我们还做了一个很重要的优化，就是优化 Mysql 把最后对云存储集群的高并发转化为 DB 高性能，我们来算一下首先 Mysql 的这台机器到现在为止都是跑在一个千兆网络下面的，在千兆网络下面我们可以看到它理论上这台 Mysql 最大的带宽是多少？也就一千兆 Mbps，意味着每秒钟可以穿 128 兆除以 16KB，每秒钟最多八千次的 IOPS。我们实测出来，每秒钟的 QPS 只有约 2200，这个数值是比较低，跟原来普通版没有太大的区别，问题在哪儿？我们仔细分析，有好几个瓶颈，第一个网络带宽是一个瓶颈，这个八千是理论上算出来 的值，也是按理论的最大带宽去算的，真正的千兆网络不可能跑到太满，真的跑到太慢延时会非常高，比较正常的情况跑到带宽 80% 的容量是比较正常的情况，这个地方先打个八折，接着网络包 Overhead，IP 层有 Overhead，TCP 也有一个 Overhead，应用层本身也有一些 Overhead，所以这里又打了一个折扣，接着 Doublewrite，平时磁盘的大小是 4K，甚至是 0.5K，Mysql 是考虑到这种情况的，如果我不做处理，这 16K 里面只写成功了 8K，另外两个物理页就没有写成功，导致这个没有一致性地写到物理设备上，那 Mysql 的团队是考虑过这个情况，它的应对措施就是 Doublewrite，它会写两次，第一次先写到一个地方，必须写到底下落盘成功了，再写第二次，首先它写两次对网络带宽造成了额外不必要的占用。 Mysql 为了进行一些数据恢复是有打流水日志的，另外还有一个日志，这两个日志都是要占磁盘的，我们怎么办呢？就是针对这几个进行相应的修改。

        首先，我们来想想页大小真的需要 16KB 吗？其实不需要，据我们的统计至少在腾讯内部的业务，99% 左右的业务它一行的大小远远不到 4KB，比较长的也就几百个字节，所以我们把 16KB 改成 4KB，这意味着对 Mysql 的每次查询每次读写流量会变成原来的四分之一，接着改成 4KB 之后，就省了一半的写流量。

        然后，对本地磁盘来说访问顺序是比较差的，而这个机械硬盘的顺序读写能力跟云集群的读写能力是不相上下的，同时机械硬盘的优点在于单位储量的成 本，我们研究 Binlog 和 Relaylog，其他还有一些配套机制的修改。因为时间关系就不进一步展开了。做了这些修改之后效果是什么呢？每秒查询数提高到了 9000，这个提高了大概四倍的样子，这个架构已经是通过腾讯云已经是对整个行业开放了，大家如果在腾讯云上申请一个云数据库高性能版能申请到的就是这样 一个架构。

        从最后的数据来说是不是真的那么值得去用呢？比如说最普通的情况，我们的开发商、合作伙伴租一个云服务器，租一个大硬盘种型的云服务器，要租两 台云服务器，它的价格是多少？两台服务器加起来每天是 75 块钱，因为云服务器本身是 350G，它包括了 Binlog 和 Relaylog。当然如果使用云数据库跟它相近的一个机型，叫高性能版A型，它是 400G，它价格是 105 块钱，我们来看这几个参数云数据库到底是自建的多少倍呢？1.33 倍，价格 1.39 倍，我们可以看到存储量 1.3 几倍，价格也是 1.3 几倍，单位存储量的价格是基本一致的，可能云数据库要稍微高一点点。所以云数据库高性能版是很有价值的，对用户很活跃的应用会有非常大的帮助。我们的团队 是不是就止步于此了呢？我们还在进一步地追求卓越，我们刚才看性能指标，已经达到了一万五的 AOPS，每一页有多少呢？4KB，一万乘以 4KB 是 60 兆字节每秒，我们只用了一半的网络能力，大家看到这个明显是有空间可以挖掘的，我们进一步分析，我们可以看一下这台蓝色的是 Mysql 这台机器，上面 Mysql 是应用层，下面是内核层的，在内核层通过一个系统调用 VFS，虚拟文件系统层，磁盘文件系统 EXT3 等，缓存通用块层，我们经过调研研究发现就在快速驱动层里面我们所使用的设备驱动是只有 32 个并发。意味着我们打个比方，这一层上面有 32 个人在处理上层的请求，每的请求来了一个人把它接到手，扔到云存储集群，等到回应这个就成功了，这个人把这个请求的回应给它算成，这个人才会再接下一个。 我们在这一层测它的延迟是两到三毫秒，意味着一个人每秒处理五百个请求，就是五百乘以 32，就是一万六千，这一层最多处理一万六千个请求，IOPS 最多就是一万六千的，我们实测是一万五千，基本上就达到这个瓶颈了。这一个方案我们已经研发成功，而且是在腾讯的自研业务里面在应用，我们希望把它变成一 个稳定的版本之后就可以通过腾讯云开放给整个业界。

        另外一个方面我们看一下 IOPS 除以 QPS 是 1.67，它是先查询一些索引页，再读取真正的数据页，如果这两页比如说都在云存储集群没有在内存里面缓存，一个点查询对应两个请求。但是实际上索引页占 总的数据量的比例是比较小的，我们正在研究可不可以把所有的索引页读到云集群，那个时候 IOPS 和 QPS 的必须能降到零点几。这个我们还是在研究中，具体的方案等以后希望它成熟了，对整个业界开放之后我们再进行一个相应的分享。

        接着我们再介绍 NosQL 的高速存储的技术特点，它原名叫 CMEM，每次读看是否能读到数据，属于能读到直接就处理了，如果读不到再去 DV 那里读一下，这样在编程上就会非常麻烦，每次读都要读两回，写也要写两回，还要保持一致性。而且有些情况对于架构和运营也产生很大的问题，比如说有一个应 用它的写访问量比较大，以至于每次直接写 DB，DB 也撑不住，所以很多数据容易丢掉，那就造成了很大的业务损失，用了这个 NosQL 高速存储之后这些问题都解决了。第二个很方便的就是我们快速成长的业务，如果用 DB 的话，经常要进行一些 DB 的扩容，扩到最后最贵的 DB 都满足不了要求了，这时候还要把一些数据倒到别的上面，搞得运营团队非常痛苦、开发也非常团苦，用了 NosQL 高速存储可以解决这个痛苦了。我们也非常高的单表的存储量和性能，我们一个表可以达到 TB 级别的数据量，而且访问量每秒达到千万级，所以基本上那些业务不需要再去做分表啊，其他的还有提高性价比，我们兼容 Memcache 等协议等等这些都是业务的价格所在。

        刚才说过腾讯云是很成熟的云服务了，在腾讯的自研业务和代理业务中都有了，结构化存储，包括云数据库等等这些总共有好几个 TB 的存储量，现在算起来已经有上万亿的文件，我们的 CDN 超过两百个加速点，还有包括小的运营商，比甚至上市的厂商，比他们的带宽都要大一些。我们的移动腾讯分析覆盖了两亿的终端，分析云也是有超过一百个 PB 的存储量，所以从这里大家可以看到不管是对腾讯自研业务还是对开放平台，还是对腾讯云这样的客户，不管是对内还是对外，我们云服务的系统都是几乎完全一样 的，有哪些不同呢？比如说计价这些运营系统是不同的，开发商管理是不同的，里面核心系统肯定都是一样的。而且就像刚才我们前面陈磊所说的，我们的对外开放 的云服务都是自研业务是有特性的，所以我们的业务都是经过验证的。所以我们可以看到腾讯云的核心系统是经过大规模实战考验的，我们也是希望通过腾讯云把互 联网开放给整个业界同行。

        刚才啰里啰嗦讲了很多，故事只讲了一半，要成为可信赖的服务商还有另外一半，另外一半就请大家静待另一个环节，谢谢大家。