腾讯大讲堂24 QQShow重构历程.pptVIP

QQShow2.0重构历程 QQ秀开发组 QQ秀1.0的技术架构 各层细化的结构图及数据流 QQ秀1.0技术架构的一些困惑 只能提供GIF图片服务, 限制了应用的进一步发展 QQ秀服务抛开商城应用, 简单而言其实就是给应用提供一套图片下载展示的系统, 在互联网应用初期, 由于带宽以及用户机器性能原因, 我们只能提供GIF图片展示用户个性化的形象, 而且也能吸引用户来玩, 但是随着QQ秀业务的发展, 用户也不再满足于简单的图形化形象的展示. 商城应用性能存在一定的瓶颈 作为公司最早最成熟产品, 原有的商城设计承受了大于设计容量很多倍的考验, 存在重新规划的需求以满足后续业务的新生. 服务可运营性不足 我们提供的服务在运行期缺少跟踪的手段, 来了投诉也没有个清晰的渠道来获取相应的信息, 在容灾建设方面也缺少快速恢复的手段. 整个服务缺少必要的实时化监控. IDC分布等. 运营的一些数据缺少数据支撑 不能满足业务精细化运行的需要 前台用户交互部分和用户数据逻辑部分耦合度过高 QQ秀2.0要解决的困惑 在提供一套图形形象的基础上, 提供基于flash的形象展示, 并且把flash形象作为QQ秀形象的主要应用, 为业务后续的发展提供更丰富的展示平台 在用户数快速增长的环境下解决商城性能问题 提高服务的可运营性, 提高服务的质量 支撑业务发展所必需了解的运营数据 商城前后台逻辑实现用户交互以及数据逻辑的分离, 方便后续业务的扩展以及简化开发 QQ秀2.0商城子系统 QQ秀2.0商城子系统 面向QQ秀用户访问后台DB全部通过DBC/TTC层代理，DBC屏蔽TTC的分布，TTC屏蔽DB的分布，既有cache能力，又能有效的屏蔽后台DB物理分布信息，给后台数据的扩容以及迁移带来很大的便利。另外DBC按业务DB细分成10种类型（当前实际部署5种类型），部署在一台服务器上为一组，一共3组提供中转服务。 面向管理端/daemon，考虑到TTC对部分SQL功能的支持不能满足业务的需求，这部分时直连DB解决。后续持续对管理端/daemon部分功能直连DB部分做进一步改造，达到IP的全部配置化，进一步完善TTC等等。 对公司/部门的公共接口服务采用无状态逻辑server进行中转/避免用户接入层的频繁变更，采用N+1的方式进行热备 对文件存储的服务做到接口服务IP/PORT的可配置，可以方便的迁移这类服务部署到其他位置（类似TTC对DB的物理分布配置功能） 前台模块 采用Flash引擎，Flash负责交互，封装了独立的换装js库负责和Flash通讯 采用AJAX技术，用XML作为前后台的通讯媒介，方便调试和自动化测试 前台采用了统一的出错处理机制以及页面填充函数，简化了页面的开发 前台相关交互部分尽量都模块化，形成互补干扰的子模块， 比如换装系统、菜单模块、专区模块、一些业务线经常变更的特性做成可以管理的模块方便更新 前台模块的基本思路和Qzone的前台优化思路一致, 降低流量, 提高用户体验速度以及提高交互的感受 逻辑模块 数据储存模块 QQShow2.0商城现在全部采用DBC+TTC的方式实现数据存储。 定义了5类DBC分别中转不同级别的TTC请求，避免非核心功能的频繁更改影响核心业务 每类DBC分别部署到5台不同机器，实现了负载均衡和容灾 数据储存模块 对于核心数据，例如用户信息和用户物品分布了在100个库10000表，这样可以减少DB写操作时的锁表情况，提高DB写效率 尽量将核心数据的TTC部署在其DB的同台服务器上，可以大大提高TTC的读写速度。 数据储存模块 数据存储模块定义了统一的接口基类，用模板的方式实现了分别针对Db、TTC、C4A的三个派生类，使得底层存储和上层逻辑独立。 容灾建设 Configserver/Agent服务, 保证服务故障的时候能快速切换到正常提供服务的备用服务上（主要应用在逻辑层无状态服务上） 数据层容灾主要靠BU公共组件提供支持 业务侧暂时保证对核心数据层服务提供N+M热备, 结合Configserver/Agent服务能快速恢复服务 对非核心数据层服务提供冷备服务, 结合冷备数据以及LOG恢复数据, 再借助Agent能快速恢复服务 日常运营监控模块 利用返回码系统实现了关键调用的情况以及调用时间的上报，而开发人员只需维护关键调用映射表。（模块间调用监控） 返回码系统记录关键调用路径，并将错误和调用时间超过1s的调用集中以UDP的方式发送到logserver集中管理 CGI服务的自动化测试监控 页面级测速监控 运营数据统计接入 QQ秀2.0后台子系统 QQ秀2.0后台item系统 商城子系统中的展示84图, 换装flash文件的拉取都是通过来拉取