百度贴吧王伟冰：跳出历史技术栈，谨慎寻找最佳优化思路

从2003年诞生到现在，基于兴趣聚合的百度贴吧已经走过了13年，随着用户、流量的不断增长，业务的不断复杂化，研发团队的规模不断扩张，百度贴吧这13年经历了LAMP化、服务化、私有云化等阶段。然而面对每一次架构调整，贴吧是如何在无数优化方向中选择最适合现状同时又兼容未来的技术方案？其中贴吧团队又需要经过多少调研多少试验才能进行判断与落实？

2016年7月15-16日，ArchSummit全球架构师峰会将在深圳举行。本届大会，我们邀请了百度贴吧架构师王伟冰，前来分享《百度贴吧性能优化之路》的内容，讲述的是站在历史13年的视角上看百度贴吧是如何一点一滴归纳总结得来不易的性能优化思路和经验的。

现在我们就来采访王伟冰老师，让我们提前预览每一次架构变动背后的细节与故事吧。

受访嘉宾介绍：

王伟冰，2010年加入百度，参与设计开发百度Memcached、Redis、通用反作弊等通用服务，服务百度50+产品线，日pv上万亿。负责百度LNMP基础设施（Nginx、PHP、HHVM、RPC中间件、扩展、基础库等）开发维护；负责百度OXP私有云平台建设； 负责百度贴吧性能优化；优化PC、移动、Native客户端的用户访问速度；建立了全面的性能评估、分析、监控体系等工作。

InfoQ： 您从2010年开始加入百度至今已经6年了，能否谈谈这些年您经历了哪些团队变化和成长，这些年给您最大的收获和教训是什么？

王伟冰：前四年我一直在社区基础技术-架构团队，做过各种通用服务和通用组件，如Memcached、Redis、Antispam、HHVM等等，服务于百度内部的各种业务，包括知识、贴吧、移动云等。近两年也参与了贴吧业务，做过性能优化、业务监控等。

基础技术的视角和业务的视角是很不一样的，两方面都做过之后看问题会更全面。比如做基础技术的时候会从业务的角度去想，业务为什么需要这样的技术，为什么会用你提供的东西；而做业务的时候也会想，这个东西如何抽象，做成更通用的技术让更多人可以使用。

InfoQ： 您曾参与开发设计百度Memcached、Redis等数据缓存技术方案，能否谈谈它们各自的业务范围以及为什么选用了它们？能否简单介绍百度的存储架构设计经历了怎样的迭代与发展？

王伟冰：做Memcached是2011年，当时公司内不少业务在用Memcached来做缓存，但都各自运维，在集群化方案、高可用方案、一致性方案上都有一些缺陷，所以我们就做了一个基于Memcached的通用缓存服务，并提供封装好的客户端，用户不需要再关心分布式、高可用上的细节，并提供延迟删除的功能来解决Cache与DB数据不一致的问题。

当时我们也有高写入性能、持久化存储的需求，比如浏览计数、最近访问列表，那时Redis还没有火，我们基于Berkeley DB做了一套小数据kv、klist存储服务，解决了当时的业务问题。到了2012年，我们有了一些更复杂的需求，比如列表top排序、过期自动失效，这时我们发现有Redis这个东西，非常适合做这个事情，而且性能很高，所以开始做Redis存储服务。

百度的存储架构，这个Topic太大了，比如网页库存储就是一套非常复杂的体系。具体到社区业务而言，主要是经历了3个阶段：08年以前，是专有C模块存储；08-12年，逐步LAMP化，Mysql+Cache成为主流；12年到今，则是Mysql+Nosql并存，Nosql除了Memcached/Redis, 还有各种百度内部实现的kv、klist、table系统，满足各种不同的业务需求。

InfoQ： 你们逐渐从LAMP架构转移至OXP私有云架构，能否简单介绍开发OXP的初衷和背景分别是什么？OXP是如何统筹兼顾开发框架、测试环境、运维平台、监控系统等模块以及各模块之间是如何联系如何协同工作的？

王伟冰：LAMP化、服务化、私有云化是贴吧架构的3个重要的变革点，LAMP化是提升单个模块开发效率，服务化是提升大团队协作开发效率，而私有云化则是提升运维效率。

在LAMP化的过程， 我们抽取出一套通用的开发框架和平台，称为ODP(Online Develop Platform)，用这套框架业务可以快速地开发新应用。但是随着业务规模越来越复杂，机器规模越来越大，测试、运维方面的问题变得越来越突出，开发人员更多的时间都花在搭建测试环境、上线、处理线上问题。我们意识到要提升全流程的效率，而不仅仅是开发阶段的效率。因此我们做了全流程的解决方案，包括开发(Develop)、测试(Testing)、运维(Operation)、监控与问题定位(Monitor)，这就是OXP私有云。

在OXP私有云中，我们通过定义一系列的规范，比如目录规范、日志规范、RPC规范，把整个流程串起来。只要用我们的开发框架进行开发，应用就是符合规范的，我们就可以按照这个规范去运维、去构建测试环境、去采集日志进行监控分析。规范就像一个协议，每个服务、每个平台都遵守这个协议，那么整个流程就可以很好地串起来。

在迁移私有云的过程中，难点在于如此庞大的业务如何平滑地进行迁移。每一次架构的大改动，都需要花费数月的时间。在这个期间，新老系统是并存的，我们设计了一些方案，保证一个业务可以同时存在新系统和老系统，代码自动同步，流量可以自由切换，然后再逐个业务去切换。

InfoQ： 服务端上，贴吧分别在Native端和WebApp上的优化思路有什么不同，在各端上贴吧应该分别侧重哪些环节和服务？

王伟冰：Native和WebApp存在很大的不同，Native的行为更可控，我们在网络协议上做了很多优化。WebApp的优势在于渲染上比较灵活，所以我们做在延迟加载、分段加载等方面做更多功夫。

Native和WebApp的融合也是近年的一个趋势。我们也在尝试多个思路，比如用配置来控制Native的展现、用脚本来控制Native展现（如React Native)、嵌入浏览器内核的Hybrid模式，这些方法都各有各的优缺点：

1. 配置方式的性能最好，但灵活性差;
2. 浏览器方式的灵活性最好，但性能差；
3. 脚本方式兼顾了性能和灵活性，但实现成本又较高，更容易出问题。

目前来说还没有看到哪一种有特别明显的优势，所以目前是根据不同业务的需求场景来选择合适的技术，比如产品核心页面更重性能，可以用配置方式； 运营类页面更重灵活性，可以用浏览器方式；脚本方式作为一种比较新的技术，可以在新业务上进行尝试。

InfoQ： 您曾负责百度贴吧性能优化，节约过半服务器，能否具体谈谈该阶段的优化背景，你们团队在各环节做了哪些优化以达到这个效果？在贴吧性能优化上有没有长期的指导思想（优化思路）？

王伟冰：14年初的时候，贴吧流量涨得很厉害，服务器规模大涨，所以决定做性能优化。最主要是做了两件事情，RPC中间件优化和迁移HHVM，这个优化效果是贴吧历史上优化最好的，节省了过半的前端服务器。性能优化最主要有两个思路，一是尝试引入新技术（如HHVM），二是分析业务的性能瓶颈并做针对性的优化，这两个方案往往是最有效的。

新技术的引入是需要比较谨慎的，选择HHVM我们也是观察了较长时间，在内部做了很多试点，发现HHVM性能确实很高，兼容性、稳定性也还不错，同时社区很活跃，所以才决定全面迁移。除了主动地做性能优化，更重要的是防止退化。我们现在设计了一些监控算法，能够实时地发现性能的变化。当发现性能变化时，我们会对比分析性能的构成，看看哪部分的模块或者哪部分的函数耗时发生了变化，同时我们也会查找当时的变更事件，看看是否是有相关的上线变更操作，导致性能发生了变化。

InfoQ： 贴吧已经是13岁的“老”产品了，您和您的同事是否遇到过不敢处理的“似是而非”的代码？遇到这种情况应该怎么处理？能否分享面对具有大量历史代码的产品的处理经验？

王伟冰：老代码肯定是存在的。不过由于贴吧历史上经历了多次大规模的架构改造，大部分代码都被重写了，剩下小部分，也是一些很边缘、不重要的功能，平时并不怎么会接触到。

在性能优化的过程中，我们是尽量避免去改业务代码的。即使要改，也会尽量地兼容以前的逻辑，不管这些代码是新的还是老的。当做大的重构项目的时候，我们会去梳理所有的业务逻辑，对于不再有用的代码，和产品确认之后，就会去掉。

InfoQ： 从13年开始贴吧已经面临100亿流量的规模了，能否谈谈现在移动化+社交背景下，贴吧架构现在面临了哪些瓶颈、遇到了哪些新的挑战并且如何应对？

王伟冰：性能优化是无止境的，一方面业务还在变得更复杂，流量还在涨；另一方面，比较好做的优化我们都已经做了，未来的优化将会更难，这对我们是很大的挑战。这时候需要跳出原来的技术栈，从更上层或者更低层的技术栈来看优化。比如从上层角度看，业务需求本身是可以优化的，例如有些需求不一定合理，有些功能不一定有用，把这些干掉性能就上去了；从低层角度看，资源层还有较大的优化空间，通过资源的合理混布、智能调度可以让资源更加节省。

除了性能之外，研发效率是更大的挑战。从业务上看，贴吧的产品形态正在变得越来越多元化，对研发效率的要求也越来越高，我们也在不断地完善私有云，以支撑业务更快地迭代。

InfoQ：感谢王伟冰老师接受我们的采访。期待您在ArchSummit全球架构师峰会上的分享。

感谢陈兴璐对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。