《拍拍后台架构介绍.ppt》由会员分享，可在线阅读，更多相关《拍拍后台架构介绍.ppt（30页珍藏版）》请在三一办公上搜索。
1、8/15/2023,广州斗鱼网络科技有限公司,拍拍后台架构介绍,陈志军2015-9-18,拍拍后台架构介绍-大纲,纵向-技术架构AppPlatform中间件模型负载均衡/容灾方案MsgQ监控体系发布流程横向-SOA案例-多客服系统介绍对斗鱼服务器模型的思考,纵向-技术架构,nginx（+前端页面缓存）,DB,apache/Tws,AO可复用的业务、聚合服务,AO+DAO 数据服务,同步/异步,同步/异步,DAL,DB,分布式数据缓存,云平台,页面片缓存,读/写,写,分布式文件系统,索引服务,DB,App Platform 中间件,表现层：cgiwebservice：基于web platform
2、的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上数据层：索引：基于
3、sphinx构建的通用索引系统，提供高性能的复杂查询服务TTC,TMEM,TDB：公司级的云设施,多进程的运行模式,App Platform 中间件,Netio,AO0 x?,AO0 x?,AO0 x?,DAO0 x?,DAO0 x?,BackNetio,Container,FrontKey,BackKey,pth 用户级线程，调度,配置中心,请求,回应,App Platform 中间件,职责单一、明晰快慢分离代码、模块、组件复用平行扩展集中监控使用接口描述语言，方便系统间集成重复代码使用工具自动生成业务代码与平台代码分离，简化业务逻辑使用协程方式，简化业务逻辑和代码编写,App Platfo
4、rm 中间件,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,负载均衡与容灾-L5,MsgQ,应用程序或组件之间的一种通讯方式分布式的 是“可靠”的,MsgQ-系统拓扑架构,Agents和Servers集群构成了
5、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,面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称为服
6、务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。可从外部访问 随时可用 粗粒度的服务接口分级 松散耦合 可重用的服务 服务接口设计管理 标准化的服务接口 支持各种消息模式 精确定义的服务契约,案例-多客服后台架构,智能的、复杂的、大QQ,案例-多客服后台架构,案例-多客服后台架构,统计数据总开通卖家数：3W+总开通工号数：12W+活跃卖家数：2W+活跃工号数：10W+聊天客户数：60W+/日接收消息数：400W+/日 发送消息数：450W
7、+/日,不同类型的服务部署在不同类型的机器上，以节省硬件成本。,服务器类型介绍,对斗鱼服务器模型的思考,性能、扩展、容灾等方面的思考代码维护方面的思考,现有模型,其它服务器,MsgServer,其它服务器,netmsg,netmsg,rpc,rpc,性能、扩展、容灾等方面的思考,服务间通信链条长，影响性能；且MsgServer容易成为瓶颈数据都缓存在本地，无法做到平行扩展、无法容灾服务无法做快慢分离，慢速服务会拖累整体系统无法按业务逻辑划分模块，导致ChatRoom过于庞大，引起诸多问题消息队列（RPC请求）放在内存中，服务重启时，必然导致信息丢失服务器信息同步没有确认机制，不能保证一致性,代码维护方面的思考,存在的问题（引自拍拍）每个AppServer都有大量的重复代码，增加了应用开发人员的负担；开发人员不可避免地需要编写调试协议打解包代码，花费大量的时间和精力；底层代码一旦有调整，需要重编各个AppServer；每个AppServer都由不同的开发人员负责，可能会存在代码风格和日志格式的不统一，增加了运营统计的难度。存在的其他问题业务层面需过多关注底层模型，如线程模型异步调用使用回调的方式，增加代码复杂度和可阅读性接口不遵循互不信任原则，如：很少有参数校验日志记录不完备，日志未分级别,谢谢大家！,问题？,
