拍拍后台架构介绍.ppt

2019/11/12,广州斗鱼网络科技有限公司,拍拍后台架构介绍,陈志军 2015-9-18,1,拍拍后台架构介绍 - 大纲,纵向 - 技术架构 AppPlatform中间件 模型 负载均衡/容灾方案 MsgQ 监控体系 发布流程 横向 - SOA 案例 - 多客服系统介绍 对斗鱼服务器模型的思考,纵向 - 技术架构,nginx（+前端页面缓存）,DB,apache/Tws,AO可复用的业务、聚合服务,AO+DAO 数据服务,同步/异步,同步/异步,DAL,DB,分布式数据缓存,读/写,写,分布式文件系统,索引服务,DB,App Platform 中间件,表现层： cgi webservice：基于web platform的cgi，运行于多进程模式的tws平台上 template：符合 google template 的页面模板，供cgi或webservice 用来渲染页面 PO: 业务逻辑层和cgi或webservice之间进行数据传递的类，该类由AO组织，由cgi或webservice渲染页面时使用 应用层： AO：业务逻辑实现，运行于进程模式的App platform上（异步能力） IDL：业务对外提供的接口描述文件，可以通过autogen生成C+, java 以及 PHP 的代码 领域层、持久层 BO：领域对象 DAO：数据访问层实现，处理和事务相关的相关逻辑; ，运行于进程模式的App platform上 数据层： 索引：基于sphinx构建的通用索引系统，提供高性能的复杂查询服务 TTC, TMEM, TDB：公司级的云设施,多进程的运行模式,App Platform 中间件,Netio,AO 0x?,AO 0x?,AO 0x?,DAO 0x?,DAO 0x?,Back Netio,Container,FrontKey,BackKey,pth 用户级线程，调度,配置中心,请求,回应,App Platform 中间件,职责单一、明晰 快慢分离 代码、模块、组件复用 平行扩展 集中监控 使用接口描述语言，方便系统间集成 重复代码使用工具自动生成 业务代码与平台代码分离，简化业务逻辑 使用协程方式，简化业务逻辑和代码编写,App Platform 中间件,IDL文件,系统间的集成,IDL提供了充足的元数据信息 autogen，业务协议的自动生成 C+ php java C# delphi python 通过tcp/udp进行通讯,负载均衡与容灾,服务请求路由方式 /usr/local/c2csvc/global_conf/ServiceConfig.xml配置： Route=Mod（按路由key取模） Route=Mod+L5（按路由key取模+L5负载均衡）,负载均衡与容灾 - L5,负载均衡与容灾 - L5,负载均衡与容灾 - L5,MsgQ,应用程序或组件之间的一种通讯方式 分布式的 是“可靠”的,MsgQ - 系统拓扑架构,Agents和Servers集群构成了MsgQ的消息服务总线.,接入,CGI,AO,DAO,idmaker,DAL,频率限制,分布式cache,Web Platform,nginx插件,配置中心,统计Server,权限系统,敏感词,Log Server/模调proxy,App Platform,错误码,MsgQ,其他组件,监控体系,监控一切可监控的,发布流程,EOS发布系统：cgi, html, js, pic rpm打包系统：ao, dao 配置中心：路由切换，配置变更、DB管理等 由系统来保证：（保证环境一致性） dev -beta - gamma -idc 灰度发布,横向 - SOA,面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。 可从外部访问 随时可用 粗粒度的服务接口分级 松散耦合 可重用的服务 服务接口设计管理 标准化的服务接口 支持各种消息模式 精确定义的服务契约,案例 - 多客服后台架构,智能的、 复杂的、 大QQ,案例 - 多客服后台架构,案例 - 多客服后台架构,统计数据 总开通卖家数：3W+ 总开通工号数：12W+ 活跃卖家数：2W+ 活跃工号数：10W+ 聊天客户数：60W+ /日 接收消息数：400W+ /日 发送消息数：450W+ /日,不同类型的服务部署在不同类型的机器上，以节省硬件成本。,服务器类型介绍,对斗鱼服务器模型的思考,性能、扩展、容灾等方面的思考 代码维护方面的思考,现有模型,其它服务器,MsgServer,其它服务器,netmsg,netmsg,rpc,rpc,性能、扩展、容灾等方面的思考,服务间通信链条长，影响性能；且MsgServer容易成为瓶颈 数据都缓存在本地，无法做到平行扩展、无法容灾 服务无法做快慢分离，慢速服务会拖累整体系统 无法按业务逻辑划分模块，导致ChatRoom过于庞大，引起诸多问题 消息队列（RPC请求）放在内存中，服务重启时，必然导致信息丢失 服务器信息同步没有确认机制，不能保证一致性,代码维护方面的思考,存在的问题（引自拍拍） 每个AppServer都有大量的重复代码，增加了应用开发人员的负担； 开发人员不可避免地需要编写调试协议打解包代码，花费大量的时间和精力； 底层代码一旦有调整，需要重编各个AppServer； 每个AppServer都由不同的开发人员负责，可能会存在代码风