李庆丰：新浪微博服务高可用新技术、新架构的尝试

个人简介 李庆丰，微博研发中心高级技术经理，当前负责微博开放平台及通讯平台的技术研发工作，曾主导微博平台服务稳定性保障及SLA体系建设项目，推进微博平台化战略改造项目、微博多机房部署、微博容器化及混合云等项目。10年互联网架构研发及技术管理经验，专注高性能高可用架构及服务稳定性保障方向。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 各位InfoQ的网友大家好，现在我们在ArchSummit北京大会现场，做客我们专访间的是新浪微博研发中心高级技术经理李庆丰先生，第一个问题想请您分享一下您目前比较focus的技术领域，这个技术领域的发展趋势是什么样的？

李庆丰：我是2010年加入微博，一直从事高可用架构技术这块，负责整个微博平台技术架构发展，就像我今天演讲分享的主题一样，也是一直在关注微博高可用服务这个方向，对于这一块我们也积累了一些经验。对于这块的趋势，我觉得未来它一定是朝着自动化、弹性扩容的容器化的方向发展，让整个运维效率变得越来越高，让高可用保障这块变得越来越好。

   

2. 在保障服务高可用上面，新浪微博尝试了哪些新的技术和架构？可以分享一些案例吗？

李庆丰：保障高可用这块，在业务发展的不同阶段有不同的事情要做，也要应用不同的技术。拿微博整个高可用服务保障体系的发展来看，实际上分四个阶段：第一个阶段是发展初期，我们是由手工时代变成了开始使用工具的时代来解决我们快速发布的问题。这时候并没有运用比较先进的技术，只不过利用了比较适合我们的工具，比如用dispatch组件来分发命令；在快速发展时期我们做了不少工作，第一个我们建立了SLA的保障体系，通过SLA保障体系让内部的服务依赖变得非常明确。我们知道我们给外界都会有一个SLA很高的质量保障，但实际上在很多公司内部做的并不明确。这样会导致一个问题，内部服务之间定位不清晰，出问题的时候找不到具体瓶颈在哪儿。通过这个我们让公司内部服务变得非常明确，责任也非常明确，有问题的时候知道问题在哪儿。另外一个就是实时监控体系，实时监控体系我们应用了Scribe，能够把日志实时传送过来，这个非常关键。另外用了业界的Storm技术，Storm主要是实时分析日志，把现场情况实时拿过来，最后我们用一些graphite图形展示工具把结果非常方便的展示出来。这是第二阶段。另外就是把它系统化。

第三阶段是服务稳定性这块，我们建设了微博的多机房，多机房非常关键的一点我们做了WMB信息同步组件，它能够方便的在不同的机房之间把数据实时传送过去。这块看似非常简单，实际上是非常有挑战的一个组件，因为要保障数据实时同步还要保障数据不丢失，相关的策略要很多；最近我们做了服务容器化，包括混合云，希望通过它来达到服务弹性扩容和快速处理的能力。随着新浪微博这几年的发展，我们应用的技术也是不断的在更新。主要是解决现实遇到的这些问题，基本上是这样。

   

3. 您刚刚谈到第二阶段实时分析这边，我不是很理解为什么实时分析对微博业务会很重要？

李庆丰：因为微博业务有一个特点，它是一个社会化的媒体平台，有一些突发事件第一时间就会在微博上炸开锅，形成热点，这样对我们服务器压力是非常大的。这种突发事件和热点事件又是不可预测的，我们没法来决定什么时候该扩什么服务器，什么时候多准备一些，所以我们必须通过实时监控的方式，能够实时看到哪些流量涨上来了，在哪里可能会有瓶颈，做相应的处理。所以说实时监控对整个服务保障体系来说是非常关键的一环。

   

4. 这个跟电商的实时分析有什么不同？比如电商他们有一些交易系统的实时分析。

李庆丰：交易系统的实时分析据我了解是跟广告和推荐比较相关。对于性能分析来讲，无论是电商系统还是社交化的系统，都需要实时分析，电商也可能出现突然哪个活动热卖了，当然电商热卖一般有运营和推广活动，他提前能够知道，但是像社交媒体平台就会更随机一点，所以我们这块可能更需要。

   

5. 您刚刚讲WMB多活是同城和异地？

李庆丰：同城和异地都能支持，只不过WMB受制于一个瓶颈就是两个机房的时延，比如我们同城是一两毫秒，那WMB只能做到一两毫秒，北京和广州的延迟就是4毫秒，WLB再厉害也缩短不了，只是能保证不要在这个基础上有更多的延迟。另外一个就是保证数据的可靠性，完整性。

   

6. 您刚刚讲到最近在做容器化的设计部署，你们现在容器化规模有多大？

李庆丰：我们现在整个服务器集群，微博平台这块80%都已经容器化了。做到这个容器化之后，我们未来的目标就是百分之百，百分之百之后我们就能够把这些资源无差别的部署，就像Docker容器本身的部署模式一样，每一个服务都变成环境无差别的集装箱，这样方便我们刚才提到的那几点，第一就是能够做到快速的服务扩缩容，我们现在能够达到的是每百台5分钟，未来希望能达到更快更好更自动化一点，另外弹性扩充能力对我们服务保障来讲也会变得效率更高更稳定。

   

7. 在这几个阶段里面您记忆比较深刻的，比如每一次做大的调整或者大的功能实现的时候，有没有一些可以分享的踩过的坑，你们当时可能费了好大的劲做的，能分享一两个吗？

李庆丰：最意义深刻的就是SLA体系的构建，虽然它不是一种技术，而是一种配合协作方式的改变。当时整个微博的SLA体系的推进也是我来主导的。这个项目乍一听就是服务依赖跟被依赖之间的一个保证和约定，实际上真正推进起来就会发现这个还是比较复杂的，并且需要非常细致。为什么？因为你要知道，既然你定了SLA，你得知道你的服务能不能达到，所以就涉及测试和统计这一块。另外知道依赖方的SLA了，如何用被依赖的可用性条件来评估我们自己的容量，这是一个挺技术的活。再有一个既然你定SLA了，每一个具体的点，SLA的统计是需要非常精细化的。我们会遇到一些问题，比如说对资源我们也做SLA，但是对资源的访问次数太多了，量非常大，每一个都打日志的话服务器可能就爆了，所以我们要想一些办法。现在我们想的办法就是在内存里面做实时的分析，定期的dump到磁盘上做一些日志，我们现在会把十秒钟的请求量情况分析出来打到日志上，这样既保证我们数据能够实时准确的细化到每一个请求，又能保证量不是非常大。在这个推进过程中，包括网络各个方面我们都花了比较多的思考和经验。

   

8. 每个阶段都涉及到新技术的选型，在技术选型上你们遵循哪些原则和标准？

李庆丰：技术选型上我们一般还是业务导向，一定保证它稳定可靠我们才上，因为微博这么大的量，现在是整个中国最大的媒体社交平台，影响力也是非常大的，你要是选一个尚未成熟的技术，它可能带来的风险是非常大的，所以我们在技术选型的时候第一个要保证技术是靠谱的，业界有成熟的案例，或者是说至少在内部也要用小的业务做一些尝试。第三步就是大规模上的话也会采用灰度的策略，战术上比较激进，但是在战略上要稳健，比如Docker的选型，也是一步一步的，去年容器化一些边缘服务，最终到核心服务，用Docker方式做了2015年的峰值的抗风。今年我们看混合云方面业界也有比较好的案例，我们也想做一些尝试，借用混合云的方案来扛2016年的抗风。这是一步一步做的，很踏实。

   

9. 在您负责新浪微博高可用服务保障体系这么长的时间里您觉得比较困难的地方是什么？

李庆丰：在这个过程中我觉得比较困难，比较有挑战的还是能够灌输这种意识，还是对人的意识的管理。因为有的同学觉得服务保障就是一个体力活，或者技术性没有那么强，就是运维，但是实际上真的不是的，整个服务保障是运维和开发共同协作的一个结果，才能够更好，否则总是体力活。如果在架构上不做优化，相互协调和配合不好，或者总结不够和应用的工具不够的话，你就会陷入非常忙乱的状态。这种意识要贯彻下去，一个需要实际场景的锻炼，另外平时要多注重思考和总结。

   

10. 您刚刚也提到开发运维，您怎么看待开发和运维关系？

李庆丰：我希望他们是一对好基友，因为整个开发和运维，刚刚我也提到了，它是整个服务保障最关键的两个角色，开发多做一点，能够在架构上容错更多一点，运维就轻松很多，整个服务保障就会好很多。而运维会给开发提供一些很好的支持，运维这块如果能够支持的更快一点，我们架构改造就变得更快了，这是相互促进、相互提升的关系，两方面如果协调的好的话对整个服务保障体系就会有非常好的促进。

   

11. 一般情况下运维的压力是比较大的，你们内部有什么机制减轻运维的压力，技术上或者架构上有什么策略？

李庆丰：这方面我们开发和运维的关系处理的还是非常好的，因为运维也知道需要架构给提供更多的自动处理的方式，开发也知道如果没有运维好好地运维我们的服务，架构真正的价值也不一定能体现出来。所以现在我们会定期的交流，工位都坐在一块儿了，方便我们相互交流。再有一个我们所有的技术方案都需要运维和开发共同来参与，我们会设定一个主负责人，他也许是开发，也许是运维，但是他要把相应的运维开发一起招进来，从运维角度怎么更方便，从开发角度怎么更适合当前的业务，从中取一个比较好的点。这样确保我们整个架构是适合业务的，运维也能够接受，从中找一个平衡。

   

12. 因为我们也都是新浪微博的用户，很多时候发现两方面的现象，第一个现象就是，一开始早几年有很多第三方客户端。第二个特点是有很多第三方登陆用的也是新浪微博，这对你们架构上或者是性能上，在高可用方面有哪些影响。这是第一个问题。第二个问题是这几年下来针对对外开放的第三方API也好，或者是第三方微博客户端，你们有没有什么策略调整？

李庆丰：第一个问题是第三方对我们是否有影响，从2011年开始我们采用的就是平台化的架构，平台化架构指的是新浪微博所有的服务都是架设在微博平台之上的，包括主站包括客户端都调用的我们平台具体的接口，跟第三方调用的实际上是一样的接口。他们流量的增长，对我们服务也会产生同样的影响，他们服务量大了也会产生影响。只不过有一个不同点就是内部一般是可预期的，因为不会乱用，而第三方也不是有意的乱用，但是他一不小心可能会有误用的场景，所以我们增加了类似频率控制来防止他误用，和一些保护的策略保证不要影响到整体服务。第二个问题有关第三方的策略问题，整个产品策略我在这里作为技术来讲就不做特别的评述了，从技术上我们主要是对抓站、抓数据的恶意场景会做一些比较严格的处理策略，保证他不影响正常的用户。对于正常的守规矩的第三方，只要他按照我们开放平台原则上的策略来调用，我们还是非常欢迎跟支持的，因为它也是整个微博生态体系中的一部分，我们也是非常欢迎的。

   

13. 对于管理技术团队这方面你有什么心得呢？怎么样让团队work的更好更高效？

李庆丰：对于技术团队这块，这几年我也做了比较多的思考，因为人员会有一些变更，每个技术人员有不同的特点，总结起来我觉得一定要让大家有比较好的快乐的气氛，最重要的是找到自己的兴趣点，比如这个人喜欢技术，你就让他做技术挑战的事儿，这个人喜欢沟通，那业务协调是不是他擅长的。因为我们在技术上有各种各样的角色。第一个就是刚才说的找到兴趣点，第二个是督促大家多做总结。现在我们在内部有一个要求，你做的任何一个项目结项了你要有一个总结，你做的一个架构上线了你要有总结，你出了一个故障也要总结，这个总结不光是给我看的，是给整个团队来看的。通过总结让他重新比较细致的梳理了最近的工作，看看哪块是可以改善的，哪块做的是好的；另一方面也给其他同学带来借鉴。再有一点，让大家多做总结分享，比如我们内部每周五会有一些技术分享，你在前一段做了比较好的项目或者是看了比较感兴趣的话题，给大家分享出来，你在分享准备阶段会理解更深刻，这样也促进你们之间的交流。特别是非常好的架构，能够对我们整个团队的技术氛围包括技术能力会有非常大的提高。

Infoq:谢谢你，我的问题就到这里。谢谢您。

   

14. 另外第三方登陆，作为很大的帐号体系和帐号系统，你们单独做是怎么做的，或者说第三方应用这边你们有哪些安全方面的策略？

李庆丰：第三方登陆这块跟我们整个登陆体系都是一个大的登陆体系，我们内部会有内部更快捷的认证方式，但是在外边也是遵循严格的认证登陆流程来做的。第三方我们更多的采用OAUTH的方式，它是三方的校验认证方式，总体来说还是要通过用户授权应用能不能调用接口。因为微博对于用户数据来讲，他只是用户在微博上托管的数据，是属于用户的，我们通过这种机制确保用户知道你的数据第三方能用了，防止第三方恶用。另外授权这方面我们做了scope策略，能够细化应用能访问哪些资源。因为我们碰到过这种场景，比如说买票系统，可能他也支持这种登陆。但是这时候我就想让他拿到我基础的信息就可以了，但是有的应用利用这个特点就抓取了你更多信息，比如你的关系，你的私信什么的都弄去了，这样造成信息安全有很大的困扰，我们通过scope的方式就给你必要的信息就行了，不必要的多余的我不勾选，通过这种方式让授权登陆更安全一些。