InfoQ：我是InfoQ主持人，我们现在在腾讯大厦，很高兴腾讯大讲堂帮我们邀请了孙超。孙超请您先做一下自我介绍？
孙超：大家好，我是来自于Qzone的孙超。我从2006年毕业就加入了腾讯，一直从事和Qzone平台建设相关的一些工作，现在也正在负责整个Qzone品牌这块的一些业务。其实这里也面临着比较大的一些挑战，包括当时Qzone从一个比较小量级的几百万，然后到现在亿级的一个平台，过程中整个平台存在几次大的架构调整和优化。我非常荣幸正好参与了这样一个产品的快速发展阶段。
InfoQ：我们在Qzone中经常了解到的一个名词就是SET，能够为我们介绍一下SET是怎样一个形式？
孙超：说到SET，我先说一个比较简单的比喻：你可以把它理解成一个集装箱，一个SET是一个壳子，它里面装着很多货物；拿到Qzone这来说，其实SET就是把Qzone的某些服务放到一个小的盒子里面，这样来进行分布部署。
当时为什么要有这个SET，当时存在一个背景，就是Qzone从05年诞生，后面到06年、07年快速的发展，机器的整个规模从原来的一二百台快速的膨胀到了上千台，机房的建设其实对于业务的发展是有点滞后的，所以当时存在这种情况，比如说我们一个服务，从逻辑层到数据层可能分布在深圳的几个机房，这样的话，我们就会存在大量的穿越。当网络之间的专线，不管是因为变更也好，还有意外也好——比如挖断的专线等等这种情况，导致了我们整个的服务受到非常大的波动。
另外像这种用户的行为，尤其是SNS平台，它存在着很多的一些，我要拉取我好友的信息，其实有很大的扩散存在里面，所以一个简单的请求可能到下面就扩散成了几十倍、上百倍，这样对专线形成一个相当大的依赖。所以在06年、07年的时候，如果出现了一些专线的，比如交换机一些问题，或者是专线的抖动，整个Qzone就打不开。所以当时可以看到，在百度上，空间打不开的抱怨是排名非常靠前。
所以我们经过分析这些原因之后，就针对于这样的一个背景，来做了一次大的部署优化。其实SET可以认为是一个部署优化，我们的目的就是减少对专线的各种依赖，来保证在我们的核心服务当进入这样的一个SET之后，可以完整的来启用整个的功能。可以认为这个集装箱，就在这样的一个部署之后，所有的请求不需要去集装箱外面来访问了。
我刚才介绍了整个的一个背景，和当时的一个目的，SET其实我们在当时建设的时候，其实要把它建设好，要考虑比较多的因素。比如说对一个SET，我们要覆盖多大的范围，因为Qzone整个业务是非常大的，包括里面的一些基础功能，日志相册，然后还有一些平台级的服务。最终，我们经过这种圈定，当时把整个的Qzone SET定义成空间的首屏。因为空间的首屏——就是进入空间之后第一屏看到的一些业务，它这里的访问量是非常大的。而且，为了当时做整个Qzone的平台化，我们还有一个用户必须要先进入这样一个首屏才能去玩其他的一些业务的设定。既然有这样一个非常关键的点，所以我们必须要保证用户的第一跳是成功的，所以我们把所有的精力都聚焦在一定要把首屏的可用性和质量提上去。所以我们当时的SET，圈定的就是空间的整个首屏业务，它包括，比如说你有没有QQ空间，你的关系链，你的权限，你的一些底层数据等等。
还有，首屏当时在07年的时候，我们的那个空间做了一个大的改版，从原来一个主要以装扮为主的、面向客人的模式，转向了一个以好友动态为主的、个人中心的模式，所以里面又会把好友的feeds当成了数据，核心数据，统一的都放到了这个SET里面去。
所以我们当时就是，SET解决空间首屏的速度和质量，圈定了平台级的核心服务在里面，这样的话范围就出来了，第二个，我们还有一些SET的标准，就是这个SET也不是无限大就好，除了满足刚才的那一个，就是这么多的核心业务在里面，还有这个SET要提供多少用户在使用，因为你提供用户越多，扩容的频率就会越少，但是要扩一次的规模就很大，所以当时我们经过推算，发现其实在一个交换机下，当时因为交换机的一些限制，下面大概有四百多台的服务器，我们不希望一个访问跑出这个交换机，所以我们就在一个交换机内的一些机器把它充分使用，大概建立了一个当时的标准，是五百万在线的情况，这样的一个SET标准。
而后面的话，就是考虑一些容错容灾，部署的情况来建立这样一个SET。
所以刚才提到那个SET的概念，主要是当时的一个思考过程，包括上述这几点。
InfoQ：我听说还有一些去SET化的过程？
孙超：是这样，去SET化，首先是SET比较多了，就有一个去SET化的问题。随着我们当时从08年开始做了SET化，这样的方式不管是扩容还是运营成本都大幅下降，而且服务质量也提升非常快，所以在整个的业务中开始大量的采用这种模式，最多的时候我们的SET有30多个。
30多个SET存在一个问题：当时这个30多个SET包括后面的IDC分布之后，存在着三地，每个地方都有几个SET，合起来有30多个，这30多个里面就存在着一些配置管理，因为相当于一份数据我在三十多个SET里边都同时存在，而我访问的路由肯定是不一样的，这样路由管理的成本就变得非常的大。为了解决路由管理的问题，我们希望用去SET化的方式，让 前端 在使用服务的时候，不需要区分它到底是在哪里，他只需要调一个统一名字的服务，我们会根据它就近的部署的情况，自动的给他去路由到那里。
所以，这就是后面的去SET化，相当于前面使用方不用关心SET这个概念了。
InfoQ：能不能介绍一下，承载这些SET的IDC这些是怎么来做的？因为这些SET全都是在IDC中来做承载的，来部署在IDC中，我们了解到现在是一点写多点读的方式，全国有多个IDC机房，能不能介绍一下这块的详细情况？
孙超：这个问题很好，是这样，SET承载方式其实跟我们部署的考虑关系非常大的，首先，在一个SET中，其实核心是解决容灾问题，而容灾的话，比如说像现在的机房的故障非常的，就是多种多样，包括机架交电、交换机故障，所以我们一个SET情况下，其实是在交换机是双倍的，在机架上是尽量的在，因为我们要解决SET内的容灾，就是一个数据总共有两份数据分别存在两个机架上，往再大里来看，它还是在一个机房，所以我们像深圳的话，之前Qzone是从深圳的这里发展出去的，所以它很多的服务都是在深圳，而且它跟QQ的依赖非常的多，所以QQ上也会调Qzone的一些服务，而QQ当时主机也是在深圳，所以我们在深圳这边，为了解决这样的一个单机房的风险，在深圳我们部署多个机房，多个机房就形成了一个相互之间，既使有一个故障，我们把它去来调度走就好，但是随着后面的发展， Qzone又要走出去，因为要解决北方用户的使用体验，包括华东地区，所以我们也是采用了三点分布，像北方、华东，还有那个华南用深圳来覆盖，每个地区也都有这样的一些情况，所以我们后面就产生了多个SET多个IDC。
InfoQ：然后因为你是多个SET跟IDC这样的分布最主要面临的一个问题，就是数据同步的问题，然后现在我们的Qzone是怎么来解决这个问题的？
孙超：不管是SET也好，还是IDC分布也好，其实都是把一个数据分布到多地，它必然存在的数据一致性、效率和最终一致性这样的一个问题，其实用那个CAP理论来说，的确想满足三个是做不到的。
所以刚才说的挺好的，就是我们采用的一点写多点读，但是这样的话，用户会有一些滞后感，所以我们在过程中是通过这种方式来解决：
第一是我们在所有的定义好的主写点，因为要分布的数据，我们是知道的，所以把他所有的写点集中在一个SET，我们称之为数据源SET，然后当产生数据源之后，他又会把这个数据的操作指令，或者最终的数据，通过我们做的分发系统（我们叫做同步中心），把它同步到全国的各个机房，然后重新再执行一次，就相当于把用户的行为重录了一次，当时的这个系统，这样就把那多个拷贝的数据变成最新的。
但这里的确存在一个延时和网络抖动的情况，所以我们这个同步中心里面做了很多的一些工作，比如说我们虽然公司里面有很多专线，但是这个专线的确有一些流量限制，比如说他的整个带宽因为公司全在用，也不可能一个业务全占掉，所以我们还是采用了大量的宽带业务，比如说像Feeds，这种富媒体的是采用外网传输，紧急情况下可能会切到内网，像一些底层的基础数据数据量非常小，又非常重要，比如说我加了一个好友，这样的情况下，就采用了公司的专线来做，当异常情况下，就会调度到外网去，这样就形成多个的传输通道。
然后对于时延，的确在 互联网 上来说，我看我好友的Feeds，虽然说他对时间性的要求不是那么高，比如说我的好友发了一个Feed，我可能不会马上就能收到，但是随着我们对用户的触达的方式越来越多，的确希望用户能快速的得到，这样跟我们的分布，其实是有一定的冲突的，但是过程中，我们做了很多的一些工作，比如说，我们刚完成了一个操作之后，会把用户重新定向他的数据源，来读取数据，这样就避免了他的数据是不完整的，而且在传输的过程中，我们保证了传输的时间都是在毫秒级的，这样用户就不会有太多的一些感知，当网络传输比如出现拥塞的情况，我们也会帮用户再重新去执行，保证数据不会丢失，等等的一些策略来，比说流量控制，SOA的一些服务质量的保证，包括网屏对我们的一些支持来保证了我们整个传输过程中的质量，还是现在做的是非常可控的。
InfoQ：那么现在Qzone它自己是有一个云计算的平台，还是使用腾讯云的底层的架构？
孙超：这个问题是这样的，就是刚才提到的这个云，其实这个概念的确现在比较火，腾讯可以说有两朵云，一朵是给外部的，像第三方应用、托管，这种是叫外部云，而且正在很多的一些第三方应用正在建设。而我们内部呢，因为业务的复杂度也会大大变大，所以我们是在原来外部云的一些建设基础上，比如说存储，我们的存储也是接的公司的统一的云存储，然后像逻辑层，这种我们也是统一的使用的外部云的组件，但是管理的方式是不一样的。
因为外部的话，会有一些虚拟化的一些考虑，而内部的，都是访问量非常大的业务，所以应该说是在原来外部云的一些基础积累之上，针对云内部的这种用户专门做了更多的一些定制，然后把一些对内部需要不到的一些情况把它去掉，所以其实我们，空间来说，应该是90%的功能，其实都是在内部的这种存储云、计算云之上，还有一些少部分呢，是因为那个是老的一些系统，还没有往上来去搬迁，所以应该是一个往内部来转换的一个过程，因为对于我们的运营效率和质量其实帮助是非常大的。
InfoQ：Qzone经过好几次改版，每次改版我相信后台的架构也会有相应的变化，您也负责整个SOA的整个系统的一个架构建设，能不能和我们分享一下，整个Qzone、SOA它是怎么来做得，有没有哪些新的体验，因为SOA它这个历史也比较久了吗。
孙超：那是这样的，这个词其实最大的一个感触是在09年，当时和电商，就是腾讯内部的拍拍，我们做了一次技术交流，其实SOA做的最好的国外的亚马逊，在国内的话应该是淘宝，当然那个拍拍也是在参考类似的模式，因为他们能把这个整个的一个事务的管理，包括一些整个的事务流程做成这种服务化，而那个对于Qzone这么大的一个服务，其实当初我们并没有提出过概念，虽然我们在做的时候，也是一个模块、一个功能，都采用一些网络传输这种低耦合的方式，但是它还的确没有做成服务化，当时遇到的，经过一次交流之后呢，感受到就是其实我们的功能复杂度，其实比那个电商来说要更加复杂一些，因为模块非常的多，这样我们的运营成本和管理成本其实非常高的。
所以在这个一个背景下，当时想就是我们一定要把空间的平台的这个服务，因为我们云做成平台了，外面支撑了非常多的一些业务，我们一定要这块一些质量和管理做好，所以当时启动了一个Qzone，SOA的一个优化项目。其实这个优化项目呢，我们当时考虑，第一，我们对外提供了哪些核心的服务，第二是我们这些服务有没有一些共性，还有呢，就是当前我们遇到了哪些一些问题，经过这几方面呢，我们梳理完之后发现其实我们整个的服务还是有很多的共性的。
第一是我们提供出去的很多的服务都是平台级的，像关系链资料、权限、这种底层的Qzone的基础数据，包括APP，还有Feeds，这些呢，其实我们可以用统一的一个网关，然后来管理。这样的，比如包括它的频率控制也好，容错，容灾也好，包括调度，完全不需要让外部的业务能了解我们内部的部署情况，用这么之间的一个统一的叫Qzone的接入网管这一层，把所有的外部的服务给它屏蔽起来，这是第一，做了第一步对外统一的屏蔽，其实一个初级化的一个大的服务，基本上是建立起来了。
第二，我们发现我们的协议其实也是非常多样的，这样的话呢，使用起来也非常的方便，而且其实在SOA里面，协议的一个标准是非常重要的一点，所以呢，我们也针对了我们对外的协议，统一改成了，当时因为那个腾讯内部有一个叫WP的协议，从无限延伸过来的，类似于Google的protobuf，也是一种字节性的协议，就发现外面在增加字段，减少字段的时候非常方便，所以我们把对外的所有的协议，统一的换了这样一个协议。
第三，我们又整理了一下，虽然我们做了第一层网络，但是后面发现内部的模块非常非常的多，像分布就是一个大的一个公共服务，因为支撑着那个几十个业务，上百个业务的分布情况，所以我们就把这种非常重要的，像分布服务，存储服务，还有这种抽象出来的，比如说评论系统，然后还有关系链的服务，因为有正向关系、反向关系，等等这些的，都是可以抽象成一些服务化的形式。
通过这种抽象，我们就把原来的上百个模块减少到了几十个模块，这样就大大减少了我们整个一个维护成本，其实我们的SOA的建设呢，虽然名字叫SOA，其实不完全等同于拍拍，类似跟亚马逊一样的，这是比较有空间自己特色的，就是把我们的更多的服务、更多的一些功能抽象服务化，在上一个新功能的时候，能通过快速搭建，像搭建积木一样，而不是再多的，从原始的组建上，比如说我们有网络框架、有存储服务，如果从那上面再重新建设，其实成本还是蛮高的，所以经过这种服务化，建设之后，我们再做一个功能，时间就大大减少了，所以呢，我们整个的SOA，其实是为了解决效率和对外的平台服务的问题来产生的。
InfoQ：最后一个问题就是下一步会做哪些工作来做优化？
孙超：这个问题其实也是我们最近一直在思索，也是想到了几个点，现在已经有一部分在实施了。
第一是刚才提到了像我们已经做完的工作，像我们Qzone平台级的一些基础数据的一些服务化，而现在，像Qzone的核心的动态像Feeds其实它跟业务之间，像多个业务都在接入空间，他很多的方式采用了Qzone的Feeds这种暴光展示的方式来介入的，而不仅仅是接入一个入口，而是更多的参与到用户内容里去，而Feeds这个平台涉及到的服务非常多，所以第一步，我们会把这个更核心的业务Feeds做成一个服务化的一个模式。
第二，像用户，我们之前，空间可能针对于不同的用户，他看到东西其实一样的，现在呢，我们也正在做这种精细化的运营，尤其是像不同的用户，他可能有不同的一些喜好特点，然后他可能进来之后我们给他推荐不同的一些内容，像热点的一些Feeds，就是挖掘出来的，然后呢，像那个Feeds的一些排序，Facebook很早就已经做了，然后我们也正在做这方面的事情，第二点，就是我们正在做这种智能Feeds，这种精细化运营的一些事情。
第三，我觉得还是回到我们Qzone一定要解决用户的基本的整个服务质量的问题，像Qzone的盘子也是非常大，功能也非常多，我们要压缩成本，解决用户的那个速度，因为在不同的环境里面，访问空间的速度虽然有很多优化，但是还是有用户访问慢，所以我们还重点解决这个慢的问题，还有这个如何能把这个内部的所有的这种情况更好的能完全监控到，等等的一些情况，能做到，尽量的能发现用户使用服务中的存在的一些体验的一些问题，而不等用户来投诉，我们及时通过这种问题发现之后快速去解决它，所以大概也就这三部分的事情。
孙超：大家好，我是来自于Qzone的孙超。我从2006年毕业就加入了腾讯，一直从事和Qzone平台建设相关的一些工作，现在也正在负责整个Qzone品牌这块的一些业务。其实这里也面临着比较大的一些挑战，包括当时Qzone从一个比较小量级的几百万，然后到现在亿级的一个平台，过程中整个平台存在几次大的架构调整和优化。我非常荣幸正好参与了这样一个产品的快速发展阶段。
InfoQ：我们在Qzone中经常了解到的一个名词就是SET，能够为我们介绍一下SET是怎样一个形式？
孙超：说到SET，我先说一个比较简单的比喻：你可以把它理解成一个集装箱，一个SET是一个壳子，它里面装着很多货物；拿到Qzone这来说，其实SET就是把Qzone的某些服务放到一个小的盒子里面，这样来进行分布部署。
当时为什么要有这个SET，当时存在一个背景，就是Qzone从05年诞生，后面到06年、07年快速的发展，机器的整个规模从原来的一二百台快速的膨胀到了上千台，机房的建设其实对于业务的发展是有点滞后的，所以当时存在这种情况，比如说我们一个服务，从逻辑层到数据层可能分布在深圳的几个机房，这样的话，我们就会存在大量的穿越。当网络之间的专线，不管是因为变更也好，还有意外也好——比如挖断的专线等等这种情况，导致了我们整个的服务受到非常大的波动。
另外像这种用户的行为，尤其是SNS平台，它存在着很多的一些，我要拉取我好友的信息，其实有很大的扩散存在里面，所以一个简单的请求可能到下面就扩散成了几十倍、上百倍，这样对专线形成一个相当大的依赖。所以在06年、07年的时候，如果出现了一些专线的，比如交换机一些问题，或者是专线的抖动，整个Qzone就打不开。所以当时可以看到，在百度上，空间打不开的抱怨是排名非常靠前。
所以我们经过分析这些原因之后，就针对于这样的一个背景，来做了一次大的部署优化。其实SET可以认为是一个部署优化，我们的目的就是减少对专线的各种依赖，来保证在我们的核心服务当进入这样的一个SET之后，可以完整的来启用整个的功能。可以认为这个集装箱，就在这样的一个部署之后，所有的请求不需要去集装箱外面来访问了。
我刚才介绍了整个的一个背景，和当时的一个目的，SET其实我们在当时建设的时候，其实要把它建设好，要考虑比较多的因素。比如说对一个SET，我们要覆盖多大的范围，因为Qzone整个业务是非常大的，包括里面的一些基础功能，日志相册，然后还有一些平台级的服务。最终，我们经过这种圈定，当时把整个的Qzone SET定义成空间的首屏。因为空间的首屏——就是进入空间之后第一屏看到的一些业务，它这里的访问量是非常大的。而且，为了当时做整个Qzone的平台化，我们还有一个用户必须要先进入这样一个首屏才能去玩其他的一些业务的设定。既然有这样一个非常关键的点，所以我们必须要保证用户的第一跳是成功的，所以我们把所有的精力都聚焦在一定要把首屏的可用性和质量提上去。所以我们当时的SET，圈定的就是空间的整个首屏业务，它包括，比如说你有没有QQ空间，你的关系链，你的权限，你的一些底层数据等等。
还有，首屏当时在07年的时候，我们的那个空间做了一个大的改版，从原来一个主要以装扮为主的、面向客人的模式，转向了一个以好友动态为主的、个人中心的模式，所以里面又会把好友的feeds当成了数据，核心数据，统一的都放到了这个SET里面去。
所以我们当时就是，SET解决空间首屏的速度和质量，圈定了平台级的核心服务在里面，这样的话范围就出来了，第二个，我们还有一些SET的标准，就是这个SET也不是无限大就好，除了满足刚才的那一个，就是这么多的核心业务在里面，还有这个SET要提供多少用户在使用，因为你提供用户越多，扩容的频率就会越少，但是要扩一次的规模就很大，所以当时我们经过推算，发现其实在一个交换机下，当时因为交换机的一些限制，下面大概有四百多台的服务器，我们不希望一个访问跑出这个交换机，所以我们就在一个交换机内的一些机器把它充分使用，大概建立了一个当时的标准，是五百万在线的情况，这样的一个SET标准。
而后面的话，就是考虑一些容错容灾，部署的情况来建立这样一个SET。
所以刚才提到那个SET的概念，主要是当时的一个思考过程，包括上述这几点。
InfoQ：我听说还有一些去SET化的过程？
孙超：是这样，去SET化，首先是SET比较多了，就有一个去SET化的问题。随着我们当时从08年开始做了SET化，这样的方式不管是扩容还是运营成本都大幅下降，而且服务质量也提升非常快，所以在整个的业务中开始大量的采用这种模式，最多的时候我们的SET有30多个。
30多个SET存在一个问题：当时这个30多个SET包括后面的IDC分布之后，存在着三地，每个地方都有几个SET，合起来有30多个，这30多个里面就存在着一些配置管理，因为相当于一份数据我在三十多个SET里边都同时存在，而我访问的路由肯定是不一样的，这样路由管理的成本就变得非常的大。为了解决路由管理的问题，我们希望用去SET化的方式，让 前端 在使用服务的时候，不需要区分它到底是在哪里，他只需要调一个统一名字的服务，我们会根据它就近的部署的情况，自动的给他去路由到那里。
所以，这就是后面的去SET化，相当于前面使用方不用关心SET这个概念了。
InfoQ：能不能介绍一下，承载这些SET的IDC这些是怎么来做的？因为这些SET全都是在IDC中来做承载的，来部署在IDC中，我们了解到现在是一点写多点读的方式，全国有多个IDC机房，能不能介绍一下这块的详细情况？
孙超：这个问题很好，是这样，SET承载方式其实跟我们部署的考虑关系非常大的，首先，在一个SET中，其实核心是解决容灾问题，而容灾的话，比如说像现在的机房的故障非常的，就是多种多样，包括机架交电、交换机故障，所以我们一个SET情况下，其实是在交换机是双倍的，在机架上是尽量的在，因为我们要解决SET内的容灾，就是一个数据总共有两份数据分别存在两个机架上，往再大里来看，它还是在一个机房，所以我们像深圳的话，之前Qzone是从深圳的这里发展出去的，所以它很多的服务都是在深圳，而且它跟QQ的依赖非常的多，所以QQ上也会调Qzone的一些服务，而QQ当时主机也是在深圳，所以我们在深圳这边，为了解决这样的一个单机房的风险，在深圳我们部署多个机房，多个机房就形成了一个相互之间，既使有一个故障，我们把它去来调度走就好，但是随着后面的发展， Qzone又要走出去，因为要解决北方用户的使用体验，包括华东地区，所以我们也是采用了三点分布，像北方、华东，还有那个华南用深圳来覆盖，每个地区也都有这样的一些情况，所以我们后面就产生了多个SET多个IDC。
InfoQ：然后因为你是多个SET跟IDC这样的分布最主要面临的一个问题，就是数据同步的问题，然后现在我们的Qzone是怎么来解决这个问题的？
孙超：不管是SET也好，还是IDC分布也好，其实都是把一个数据分布到多地，它必然存在的数据一致性、效率和最终一致性这样的一个问题，其实用那个CAP理论来说，的确想满足三个是做不到的。
所以刚才说的挺好的，就是我们采用的一点写多点读，但是这样的话，用户会有一些滞后感，所以我们在过程中是通过这种方式来解决：
第一是我们在所有的定义好的主写点，因为要分布的数据，我们是知道的，所以把他所有的写点集中在一个SET，我们称之为数据源SET，然后当产生数据源之后，他又会把这个数据的操作指令，或者最终的数据，通过我们做的分发系统（我们叫做同步中心），把它同步到全国的各个机房，然后重新再执行一次，就相当于把用户的行为重录了一次，当时的这个系统，这样就把那多个拷贝的数据变成最新的。
但这里的确存在一个延时和网络抖动的情况，所以我们这个同步中心里面做了很多的一些工作，比如说我们虽然公司里面有很多专线，但是这个专线的确有一些流量限制，比如说他的整个带宽因为公司全在用，也不可能一个业务全占掉，所以我们还是采用了大量的宽带业务，比如说像Feeds，这种富媒体的是采用外网传输，紧急情况下可能会切到内网，像一些底层的基础数据数据量非常小，又非常重要，比如说我加了一个好友，这样的情况下，就采用了公司的专线来做，当异常情况下，就会调度到外网去，这样就形成多个的传输通道。
然后对于时延，的确在 互联网 上来说，我看我好友的Feeds，虽然说他对时间性的要求不是那么高，比如说我的好友发了一个Feed，我可能不会马上就能收到，但是随着我们对用户的触达的方式越来越多，的确希望用户能快速的得到，这样跟我们的分布，其实是有一定的冲突的，但是过程中，我们做了很多的一些工作，比如说，我们刚完成了一个操作之后，会把用户重新定向他的数据源，来读取数据，这样就避免了他的数据是不完整的，而且在传输的过程中，我们保证了传输的时间都是在毫秒级的，这样用户就不会有太多的一些感知，当网络传输比如出现拥塞的情况，我们也会帮用户再重新去执行，保证数据不会丢失，等等的一些策略来，比说流量控制，SOA的一些服务质量的保证，包括网屏对我们的一些支持来保证了我们整个传输过程中的质量，还是现在做的是非常可控的。
InfoQ：那么现在Qzone它自己是有一个云计算的平台，还是使用腾讯云的底层的架构？
孙超：这个问题是这样的，就是刚才提到的这个云，其实这个概念的确现在比较火，腾讯可以说有两朵云，一朵是给外部的，像第三方应用、托管，这种是叫外部云，而且正在很多的一些第三方应用正在建设。而我们内部呢，因为业务的复杂度也会大大变大，所以我们是在原来外部云的一些建设基础上，比如说存储，我们的存储也是接的公司的统一的云存储，然后像逻辑层，这种我们也是统一的使用的外部云的组件，但是管理的方式是不一样的。
因为外部的话，会有一些虚拟化的一些考虑，而内部的，都是访问量非常大的业务，所以应该说是在原来外部云的一些基础积累之上，针对云内部的这种用户专门做了更多的一些定制，然后把一些对内部需要不到的一些情况把它去掉，所以其实我们，空间来说，应该是90%的功能，其实都是在内部的这种存储云、计算云之上，还有一些少部分呢，是因为那个是老的一些系统，还没有往上来去搬迁，所以应该是一个往内部来转换的一个过程，因为对于我们的运营效率和质量其实帮助是非常大的。
InfoQ：Qzone经过好几次改版，每次改版我相信后台的架构也会有相应的变化，您也负责整个SOA的整个系统的一个架构建设，能不能和我们分享一下，整个Qzone、SOA它是怎么来做得，有没有哪些新的体验，因为SOA它这个历史也比较久了吗。
孙超：那是这样的，这个词其实最大的一个感触是在09年，当时和电商，就是腾讯内部的拍拍，我们做了一次技术交流，其实SOA做的最好的国外的亚马逊，在国内的话应该是淘宝，当然那个拍拍也是在参考类似的模式，因为他们能把这个整个的一个事务的管理，包括一些整个的事务流程做成这种服务化，而那个对于Qzone这么大的一个服务，其实当初我们并没有提出过概念，虽然我们在做的时候，也是一个模块、一个功能，都采用一些网络传输这种低耦合的方式，但是它还的确没有做成服务化，当时遇到的，经过一次交流之后呢，感受到就是其实我们的功能复杂度，其实比那个电商来说要更加复杂一些，因为模块非常的多，这样我们的运营成本和管理成本其实非常高的。
所以在这个一个背景下，当时想就是我们一定要把空间的平台的这个服务，因为我们云做成平台了，外面支撑了非常多的一些业务，我们一定要这块一些质量和管理做好，所以当时启动了一个Qzone，SOA的一个优化项目。其实这个优化项目呢，我们当时考虑，第一，我们对外提供了哪些核心的服务，第二是我们这些服务有没有一些共性，还有呢，就是当前我们遇到了哪些一些问题，经过这几方面呢，我们梳理完之后发现其实我们整个的服务还是有很多的共性的。
第一是我们提供出去的很多的服务都是平台级的，像关系链资料、权限、这种底层的Qzone的基础数据，包括APP，还有Feeds，这些呢，其实我们可以用统一的一个网关，然后来管理。这样的，比如包括它的频率控制也好，容错，容灾也好，包括调度，完全不需要让外部的业务能了解我们内部的部署情况，用这么之间的一个统一的叫Qzone的接入网管这一层，把所有的外部的服务给它屏蔽起来，这是第一，做了第一步对外统一的屏蔽，其实一个初级化的一个大的服务，基本上是建立起来了。
第二，我们发现我们的协议其实也是非常多样的，这样的话呢，使用起来也非常的方便，而且其实在SOA里面，协议的一个标准是非常重要的一点，所以呢，我们也针对了我们对外的协议，统一改成了，当时因为那个腾讯内部有一个叫WP的协议，从无限延伸过来的，类似于Google的protobuf，也是一种字节性的协议，就发现外面在增加字段，减少字段的时候非常方便，所以我们把对外的所有的协议，统一的换了这样一个协议。
第三，我们又整理了一下，虽然我们做了第一层网络，但是后面发现内部的模块非常非常的多，像分布就是一个大的一个公共服务，因为支撑着那个几十个业务，上百个业务的分布情况，所以我们就把这种非常重要的，像分布服务，存储服务，还有这种抽象出来的，比如说评论系统，然后还有关系链的服务，因为有正向关系、反向关系，等等这些的，都是可以抽象成一些服务化的形式。
通过这种抽象，我们就把原来的上百个模块减少到了几十个模块，这样就大大减少了我们整个一个维护成本，其实我们的SOA的建设呢，虽然名字叫SOA，其实不完全等同于拍拍，类似跟亚马逊一样的，这是比较有空间自己特色的，就是把我们的更多的服务、更多的一些功能抽象服务化，在上一个新功能的时候，能通过快速搭建，像搭建积木一样，而不是再多的，从原始的组建上，比如说我们有网络框架、有存储服务，如果从那上面再重新建设，其实成本还是蛮高的，所以经过这种服务化，建设之后，我们再做一个功能，时间就大大减少了，所以呢，我们整个的SOA，其实是为了解决效率和对外的平台服务的问题来产生的。
InfoQ：最后一个问题就是下一步会做哪些工作来做优化？
孙超：这个问题其实也是我们最近一直在思索，也是想到了几个点，现在已经有一部分在实施了。
第一是刚才提到了像我们已经做完的工作，像我们Qzone平台级的一些基础数据的一些服务化，而现在，像Qzone的核心的动态像Feeds其实它跟业务之间，像多个业务都在接入空间，他很多的方式采用了Qzone的Feeds这种暴光展示的方式来介入的，而不仅仅是接入一个入口，而是更多的参与到用户内容里去，而Feeds这个平台涉及到的服务非常多，所以第一步，我们会把这个更核心的业务Feeds做成一个服务化的一个模式。
第二，像用户，我们之前，空间可能针对于不同的用户，他看到东西其实一样的，现在呢，我们也正在做这种精细化的运营，尤其是像不同的用户，他可能有不同的一些喜好特点，然后他可能进来之后我们给他推荐不同的一些内容，像热点的一些Feeds，就是挖掘出来的，然后呢，像那个Feeds的一些排序，Facebook很早就已经做了，然后我们也正在做这方面的事情，第二点，就是我们正在做这种智能Feeds，这种精细化运营的一些事情。
第三，我觉得还是回到我们Qzone一定要解决用户的基本的整个服务质量的问题，像Qzone的盘子也是非常大，功能也非常多，我们要压缩成本，解决用户的那个速度，因为在不同的环境里面，访问空间的速度虽然有很多优化，但是还是有用户访问慢，所以我们还重点解决这个慢的问题，还有这个如何能把这个内部的所有的这种情况更好的能完全监控到，等等的一些情况，能做到，尽量的能发现用户使用服务中的存在的一些体验的一些问题，而不等用户来投诉，我们及时通过这种问题发现之后快速去解决它，所以大概也就这三部分的事情。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
