FROM : http://www.csdn.net/article/2014-08-20/2821302-interview-tencent-b-qq-shuai-wang

对比IaaS和PaaS，SaaS得到的关注显然要少一些。究其根本，不仅因为SaaS关注的是功能方面的探索，更偏向于某个领域或层面的实际应用，还归结于相较前两者，软件的云化已基本趋于成熟，些许突破并不能带来产业上的变革。然而，较少的关注并不意味着缺乏明星产品：放眼国外，企业级SaaS服务已成为许多公司的一项重要收益来源，比如Salesforce、Oracle；而聚焦国内，同样有很多值得我们关注的产品，就比如本次我们关注的焦点——腾讯企业QQ。这里，我们接触到了企业QQ的Web技术团队，与他们团队的王帅、甘德建、赵凯、陈胜强、唐朝等几位核心人员进行了深入沟通，了解了基于LNMP，超过4万付费企业办公平台的架构及优化经验。由王帅代表团队回答。

企业QQ平台状况

 腾讯企业QQ SaaS团队

CSDN：请首先介绍一下你个人、团队，及贵团队从事的工作和关注的重点。

王帅：在腾讯工作近5年，一直负责企业产品的Web架构。作为SNG乃至整个腾讯使用PHP最广泛的团队之一，我们为企业内部、企业之间提供了高效的通信。企业QQ依托QQ的账号、通信体系，具备内部组织架构管理、对内沟通、无缝与8.6亿活跃QQ用户沟通（文字/表情/音视频/远程协助等）、对外形象统一、开放API等能力。在平时办公中，企业QQ的Rich沟通形式更是座机电话、手机的很好补充。试想在电话中解释很久的问题，可能在企业QQ上一个截屏就可以解决。我们关注企业的信息沟通及管理，帮助企业掌握运营情况，我们坚信能帮助企业实现其目标与价值。我们的口号是随时随地，随心办公。

CSDN：能否谈一下腾讯企业QQ当下的用户规模？都包括了哪些重量级客户？以及这套平台在腾讯内部的使用情况？

王帅：经过几年的积累，企业QQ拥有4W家的付费企业，超过100W的用户数，在整个企业级SaaS市场属于领先的地位。我们设计定位是对座机电话、手机的补充，企业QQ提供的SaaS通信服务，适合所有开通宽带的企业和几乎所有行业。我们的客户行业分布十分广泛，除了快递物流领域的天天快递、圆通，餐饮领域的西贝，同时还包括*机关、教育单位（比如，上海交通大学）、跨国企业（比如，IT巨头Intel）等。

腾讯SNG的即通综合部平时用企业QQ进行沟通办公，但是由于全公司范围代替RTX的实施成本比较高，所以在腾讯内部只推广到了企业产品部门，不过随着产品影响力的日益增强，我们相信企业QQ必然有机会在全公司范围推广。

CSDN：就腾讯企业QQ这个SaaS来说，客户的担心都在什么地方？有什么问题是大家共同关注的？贵团队使用什么方法攻克了这些难关？

王帅：在使用任何一家的SaaS时，企业CIO/IT经理最担心的就是这套系统的稳定性和安全性。我们从多个维度，保证系统稳定性：

• 服务器方面，我们采用腾讯自建机房，在保证不间断供电的同时，还具备火灾/洪水预警、硬件/软件双重防火墙防护、百G级DDoS攻击防护等能力；除此之外，我们还配备了7*24小时响应的安全管理团队。系统安全方面，采取了分布式数据采样与集中告警机制，不间断的渗透性测试，提前发现系统潜在问题。
• 数据安全方面，我们使用了异地备份机制以保证数据的完整。
• 服务稳定方面，除了优秀的负载均衡技术，我们还使用了N+1的冗余机制以保证系统的平稳运行。
• 软件安全方面，我们更采取了多个措施：客户端防注入、登录加密等方式自保护，消息传输过程采用私有加密协议，客户端与服务端相互不信任的通信设计保证传输安全，即使在网关上监听也无法破解。良好的代码review机制保证核心代码的稳定性，快速下发patch能力保证一旦问题发生能快速修复。

在SaaS的安全方面，我们与Intel共同打造了一套基于SaaS服务，由厂商自己或第三方提供加密方式的解决方案，并已为之申请专利。保证了客户采用自己希望的加密方式，在企业QQ的安全通道中传输。

CSDN：可否谈下QQ企业平台系统的规模/状态，比如RPS，QPS，TPS等？峰值又会有多少？使用什么样的硬件资源支撑了这个平台？

王帅：作为一款企业级产品，用户量不能和个人产品相比，比如QQ空间。腾讯大部分业务是免费+增值方式，大部分服务器只有不到10%承载的是付费用户。企业QQ的服务器规模较小，但几乎100%承载的都是付费用户。目前的RPS在3000左右，峰值可以达到4000至5000，整个团队所维护的服务器大概是几十台。

几十台已经是算了全部支持系统，主逻辑服务器较少。我们会不断压榨现有服务器性能，从最开始开发企业QQ到现在，基本没有新增过服务器。我们会有阶段性的做架构优化，服务器负载一直保持较低水平。后面会介绍一些优化的方法。

走进腾讯企业QQ

CSDN：能不能详细介绍一下这个平台架构的构建过程？都使用了一些什么技术，分别做了什么？

王帅：目前的SaaS平台架构根据产品和量级的需求经历过多次演变，最终演化成了现在的结构。

由最初的快慢分离和简单容灾，增强容灾和提供灰度发布能力，逐渐抽取统一数据层/减少无用请求，强化多set模型和立体监控，到最后统一数据存储。最终演变为：DNS+GSLB+LVS/TGW+业务逻辑机（Nginx+php-fpm+APC）+中间层和异步系统（PHPServer）+cache层+UDS、Redis、CKV等存储层。

LNMP经验分享

1. 基于PHPServer的中间层：采用PHP作为UDP/TCP Server提供中间层数据服务，每秒可以处理请求2万次以上。中间层封装大部分缓存和数据逻辑，因为由PHP扩展和纯PHP开发，开发人员无需关心内存泄露和core的问题，极大的提高了开发效率。同时我们实现了CPU亲和性绑定，PHP的Epoll支持，消息队列，Unix Socket等Linux底层特性提高Server的吞吐能力。

2. 基于C++的PHP扩展：部分逻辑用C++封装成扩展，提高运行效率。公司级业务对接大部分使用C++为PHP编写扩展，是PHP与公司级C/C++ API的产品无缝对接。

3. PHPServer旁路系统：使PHP的pctnl，主进程管理和监控所有的业务进程，所有后台服务器天然支持自动拉起，接入便利，极大提高了后台服务器的可服务范围。

4. Xhprof：可以在运营环境部署的性能调优插件。为提高QPS，降低服务器CPU，提高机器利用率在业务层级提供了可靠的仰仗。

5. 数据上报和监控：基于PHPServer及公司成熟组件的UDP上报和展示以及RTX、微信通知机制进行全面系统的监控，及时发现服务器异常

6. Cache技术：采用APC进行PHP的OPCode缓存。利用共享内存进行第一层cache，缓存高频数据，采用业界常见的memcache、redis进行分布式cache，按照数据单元组合分为多级cache。采用公司级别的CKV作为落地Cache方案。

7. 数据库技术：采用基于MySQL的数据库UDS系统托管。部分数据使用腾讯提供的CDB托管，保证写热备。

8. Yii框架：利用Yii框架的WebApp和ConsoleApp构建所有的PHP工程。

9. 前端技术：我们产品非常重视前端体验。随着RIA富因特网应用程序类型产品的盛行，我们在前端技术方面采用了分模块按需加载（自研的LBF框架）、前端MVC模式的使用（BackBone）、Single Page Application单页开发模式（SPA）等等。同时在移动端页面的开发上，借助html5的各种便利新特性，大大提高了用户体验（LBF Mobile）。未来，随着在多平台多终端上的发展，在前端方面我们也会采用响应式布局等的新理念，来优化多终端之间的智能适配。

10. 前端系统：自建NodeJS+ULS（海量log系统）上报JS的错误，使我们对用户浏览器可能出现错误了如指掌。前端代码发布前对模板文件预编译（ArtTemplate），同时多个静态资源文件合并和压缩（Combo机制），推送到CDN，加速用户侧的加载。使用公司级OZ测速系统，能够了解全国的接入速度，针对性的优化服务器拓扑。

CSDN：如此规模下，平台打造的主要挑战在什么地方？贵团队在这些技术上都做了哪些方面的调优？能达到一个什么样的级别？

王帅：作为一款企业级服务，稳定、安全性是我们最重要的挑战。在稳定性方面，我们坚持进行灰度发布，在正式发布前已经经过多轮灰度用户验证。服务的多Set隔离，在极端情况下一个set出问题，其他set依然能够提供服务。服务器提供各个维度的监控（CPU、内存、流量、磁盘、程序错误等等），同时也有各种触达运维人员的告警（手机、短信、微信、RTX等等），此外，在平行扩展方面也下了很多功夫，服务器负载过大的时候可以通过增加机器轻松扩展。安全性方面，我们的功能在上线前均接受公司的XSS、CSRF等各种漏洞扫描，并且时刻关注所使用的开源软件的漏洞发布情况，及时防堵。

另外，很多查询和操作需要以企业为单位进行操作，在Cache设计上我们支持了多级的Cache模型。

大部分公司的上班时间是一致的，因此很多请求会在早高峰上班时撞车，我们也一直致力与削峰和减少高峰期CPU占用率。

性能调优经验分享

• 所有数据Cache化，多级Cache
• 使用Linux的运维命令查找高峰期耗时较高的CGI和进程，运用Xhprof定位业务性能问题
• 同步网络请求异步化
• 使用Epoll提到Select提高网络IO效率，为使用PHP做后台server提供基础架构能力
• 快慢请求业务分离，互不影响。
• 有效的利用Nginx反向代理能力，将部分（如灰度逻辑）做在nginx层以提高处理性能。

采用上述调优后，我们团队在流量增大2倍的前提下未加一台机器，CPU保持不变。

前端方面，在大型企业人员规模巨大，依然要展现整个公司组织的情况下，我们进行前端json文件本地缓存，对部门和成员数据查找检索算法方面做了算法优化，能够基于拼音首字母、多音字、ID、中文等进行检索，该检索算法已经申请专利。在CGI方面也做了按场景和权限分离，分批拉取，在一个页面上用户量达到3万级别，也能保证用户体验和加载速度。

CSDN：作为web的分布式架构大师，你认为重点在什么地方？架构时应该使用一个什么样的理念？架构师应该具备哪些知识？需要避免哪些坑？

王帅：Web架构选型，最重要的一点是选择最合适的架构，而不是最好的。我们设计架构最根本的理念是：任何时候架构都是为业务服务的，在选型阶段要避免过度设计。任何时候都要符合敏捷迭代的思想，最快速的支持业务开发。在规划一个分布式架构系统的时候，可以从架构的可用性、可靠性、高性能、可管理性、可伸缩性、成本等方面重点关注，这几个方面环环相扣缺一不可，一个成熟架构师会灵活运用各种计算机基础知识，在上述几个方面进行妥协。

架构尽量不要设计得过于复杂化，越简单的模型对于今后的维护成本越有利；同时也不必过度设计，满足现有需求同时为将来扩展预留适当的空间即可，因为产品方向、业务需求的变化可能改变甚至推翻现有的架构，过度设计将造成资源的不必要浪费。在设计一个分布式架构的时候，要对网络、服务器、IDC、带宽、均衡设施、系统容量等等方面都要有较为深入的认识，这些都是较为基础的准备，同时，也要对公司内、外相关的成熟组件有所了解，比如外界开源LVS可以很好的实现负载均衡，自研的TGW/L5/CMLB等系统也可以实现类似需求，可以避免重复造*，享受开源技术红利，集中资源去快速满足业务需求。至于如何避免哪些坑，这个就多到无法穷举了。服务压力上涨属于幸福的烦恼，服务器没故障过几次，很多经验也积累不起来。。

除了自身要具备上述提到的各种前提下，还要多多关注业界主流设计方案，同时将方案请同行指点指点不失为一个很好的方法。推荐一本书《软件架构师应该知道的97件事》，每隔一段时间的重新阅读都会有新的收获。

CSDN：LNMP是个非常普及的web架构，但是很少能将他们用到你们的规模，是否可以给大家分享一些大流量开发过程中总结的一些秘诀，以及一些需要特殊注意的地方。

王帅：LNMP作为最为普及的web架构之一，在当今互联网架构方案中起举足轻重作用。在上述所提到做好架构设计的前提下，在应对大流量时，数据缓存机制重要性显得尤为重要，举例子来说，业务代码中获取数据源的时候，要充分考虑对数据源的访问保护，同时也要防止因缓存失效或者预热过程中大流量直接穿透导致数据源被压垮，尤其是数据库；代码层面上，抽象出一些公共类库，为前端业务、中间层等系统服务。

另外Nginx可以做很多事情，包括但不限于染色、错误处理、反向代理、容灾等。

而PHP本身作为使用C语言开发的脚本语言，在纯后台Server（WebServer）的实现上有极高的开发效率，且效率不会比纯C的Server低太多，在互联网快速变化中，能够快速的帮助产品进行试错。

CSDN：在容灾和资源调度上，这个平台能达到什么样的水准？可否详细谈谈，比如各个层面的副本数量，可用性可以达到几个9？

王帅：我们在容灾和负载均衡上都做了较大努力，从最靠近用户的LVS/TGW接入层开始，到Nginx反向代理层，再到业务逻辑层，最后到中间层、Cache层、数据源等各层系统，每层都可以自容灾，同时向下负载均衡，服务器是跨机房热备，即使一个机房故障，也可以给用户提供稳定服务。同时，任何一台机器主要性能指标达到波动阈值，我们的全体开发成员均会及时收到微信、短信、RTX等全方位的告警，及时采取应对措施，可以保守的说，我们的总体系统可用性达到5个9以上。

CSDN：在企业级产品SaaS的打造上，你有什么可以补充给大家的？比如说如何才能获得一个更好的用户体验？

王帅：在企业产品SaaS的打造上，我们团队多年来在产品体验上积累了相当丰富的经验。首先，我们的部分产品需求基本都来自用户真实的诉求，也就是我们产品始终秉持着为企业用户解决企业痛点而触发的。其次，一个产品需求被认可需要开发前，首先产品方案会经过产品同学内部的沟通，然后会拿到整个项目组一起讨论需求的可行性、合理性等，这样在开发之出就可以暴露出产品设计的种种缺陷，减少后期产品方案反复变更带来的资源浪费。再后来，产品开发、测试完毕后，我们会先根据调查给希望尝鲜的用户灰度试用，在灰度的这段时间内（一般为1~2周），积极收集用户的反馈意见、建议，产品组同学、项目经理全程参与其中，决策是否要调整产品。当然灰度期间，我们整个产品中心也是灰度用户，大家可以就新产品畅所欲言自己的观点。最终，产品经过道道工序后终于推向全体企业，这个时候推出的版本由于已经经过部分用户持续试用、反馈、修正，无论从稳定性还是交互体验上都经过真实用户的验证，更加容易得到广大用户的认可。