拍拍后台架构介绍

2024/4/8广州斗鱼网络科技有限公司拍拍后台架构介绍陈志军2015-9-181拍拍后台架构介绍-大纲纵向-技术架构AppPlatform中间件模型负载均衡/容灾方案MsgQ监控体系发布流程横向-SOA案例-多客服系统介绍对斗鱼服务器模型的思考纵向-技术架构nginx（+前端页面缓存）DBapache/TwsAO可复用的业务、聚合服务AO+DAO数据服务同步/异步同步/异步DALDB分布式数据缓存读/写写分布式文件系统配置中心索引服务DBAppPlatform中间件表现层：cgiwebservice：基于webplatform的cgi，运行于多进程模式的tws平台上template：符合googletemplate的页面模板，供cgi或webservice用来渲染页面PO:业务逻辑层和cgi或webservice之间进行数据传递的类，该类由AO组织，由cgi或webservice渲染页面时使用应用层：AO：业务逻辑实现，运行于进程模式的Appplatform上（异步能力）IDL：业务对外提供的接口描述文件，可以通过autogen生成C++,java以及PHP的代码领域层、持久层BO：领域对象DAO：数据访问层实现，处理和事务相关的相关逻辑;，运行于进程模式的Appplatform上数据层：索引：基于sphinx构建的通用索引系统，提供高性能的复杂查询服务TTC,TMEM,TDB：公司级的云设施DAOCAO数据库索引AOBOBOcgiIDLwebservicePOPOwebplatformappplatformTMEMtemplateMVC展现层应用层领域层持久层数据层多进程的运行模式AppPlatform中间件NetioAO0x????AO0x????AO0x????DAO0x????DAO0x????BackNetioContainerFrontKeyBackKeypth用户级线程，调度配置中心请求回应AppPlatform中间件职责单一、明晰快慢分离代码、模块、组件复用平行扩展集中监控使用接口描述语言，方便系统间集成重复代码使用工具自动生成业务代码与平台代码分离，简化业务逻辑使用协程方式，简化业务逻辑和代码编写AppPlatform中间件

IDL文件系统间的集成IDL提供了充足的元数据信息autogen，业务协议的自动生成C++phpjavaC#delphipython…通过tcp/udp进行通讯负载均衡与容灾服务请求路由方式/usr/local/c2csvc/global_conf/ServiceConfig.xml配置：Route=Mod（按路由key取模）Route=Mod+L5（按路由key取模+L5负载均衡）负载均衡与容灾-L5负载均衡与容灾-L5负载均衡与容灾-L5MsgQ应用程序或组件之间的一种通讯方式分布式的

是“可靠”的MsgQ-系统拓扑架构Agents和Servers集群构成了MsgQ的消息服务总线.接入CGIAODAOidmakerDAL频率限制分布式cacheWebPlatformnginx插件配置中心统计Server权限系统敏感词LogServer/模调proxyAppPlatform错误码MsgQ其他组件监控体系监控一切可监控的发布流程EOS发布系统：cgi,html,js,picrpm打包系统：ao,dao配置中心：路由切换，配置变更、DB管理等由系统来保证：（保证环境一致性） dev->beta->gamma->idc灰度发布横向-SOA 面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。可从外部访问随时可用粗粒度的服务接口分级松散耦合可重用的服务服务接口设计管理标准化的服务接口支持各种消息模式精确定义的服务契约案例-多客服后台架构智能的、复杂的、大QQ案例-多客服后台架构案例-多客服后台架构模块功能服务器数量Proxy实现Sconn、Oidb、Paipai代理>=2，B2跨机房容灾多机负载均衡，可平衡扩展Web接入实现客户端请求接入代理>=4，C1网通和电信环境跨机房容灾Nginx负载均衡Ao/DaoC2CPlatform平台架构>=4，B1跨机房容灾多机负载均衡，可平衡扩展L5技术应用，自动摘除僵死机器，进行过载保护DB数据存储>=6，A1数据跨机房双备份统计数据总开通卖家数：3W+

总开通工号数：12W+活跃卖家数：2W+

活跃工号数：10W+聊天客户数：60W+/日接收消息数：400W+/日 发送消息数：450W+/日

不同类型的服务部署在不同类型的机器上，以节省硬件成本。服务器类型介绍对斗鱼服务器模型的思考性能、扩展、容灾等方面的思考代码维护方面的思考现有模型其它服务器MsgServer其它服务器netmsgnetmsgrpcrpc性能、扩展、容灾等方面的思考服务间通信链条长，影响性能；且MsgServer容易成为瓶颈数据都缓存在本地，无法做到平行扩展、无法容灾服务无法做快慢分离，慢速服务会拖累整体系统无法按业务逻辑划分模块，导致ChatRoom过于庞大，引起诸多问题消息队列（RPC请求）放在内存中，服务重启时，必然导致信息丢失服务器信息同步没有确认机制，不能保证一致性代码维护方面的思考存在的问题（引自拍拍）每个AppServer都有大量的重复代码，增加了应用开发人员的负担；开发人员不可避免地需要编写调试协议打解包代码，花费大量的时间和精力；底层代码一旦有调整，需要重编各个AppServer；每个AppSe