搜索
2021/4/19广州斗鱼网络科技有限公司拍拍后台架构介绍•陈志军•2015-9-181拍拍后台架构介绍-大纲•纵向-技术架构•AppPlatform中间件•模型•负载均衡/容灾方案•MsgQ•监控体系•发布流程•横向-SOA•案例-多客服系统介绍•对斗鱼服务器模型的思考纵向-技术架构nginx（+前端页面缓存）DBapache/TwsAO可复用的业务、聚合服务AO+DAO数据服务同步/异步同步/异步DALDB分布式数据缓存读/写写分布式文件系统配置中心索引服务DBAppPlatform中间件•表现层：•cgi•webservice：基于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中间件NetioMSGQTCPAO_MSGAO_MSGAO_MSGMSGQMSGQMSGQDBMS一台物理机器ControllorMSGQDAO_ITEM_MSGMSGQDBMSDAO_SHOP_MSG1620026301DAO_ITEM_MSGDAO_SHOP_MSGDAO_SHOP_MSGDAO_ITEM_MSG26200262010x16200x26300x2620•职责单一、明晰•快慢分离•代码、模块、组件复用•平行扩展•集中监控•使用接口描述语言，方便系统间集成•重复代码使用工具自动生成•业务代码与平台代码分离，简化业务逻辑•使用协程方式，简化业务逻辑和代码编写AppPlatform中间件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负载均衡与容灾-L5MsgQ•应用程序或组件之间的一种通讯方式•分布式的•是“可靠”的MsgQ-系统拓扑架构•Agents和Servers集群构成了MsgQ的消息服务总线.发布主题消息(ID=1)发布主题消息(ID=1)发布主题消息(ID=2)Server集群MQServer主机MQServer主机MQServer主机MQServer主机订阅主题消息(ID=1)订阅主题消息(ID=1)订阅主题消息(ID=2)消费者主机AgentC2消费者主机AgentC1消费者主机AgentC3生产者主机AgentP1生产者主机AgentP2生产者主机AgentP1生产者主机AgentP3发布主题消息(ID=5)消费者主机AgentC4订阅主题消息(ID=5)接入CGIAODAOidmakerDAL频率限制分布式cacheWebPlatformnginx插件配置中心统计Server权限系统敏感词LogServer/模调proxyAppPlatform错误码MsgQ其他组件监控体系监控一切可监控的发布流程•EOS发布系统：cgi,html,js,pic•rpm打包系统：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其它服务器netmsgnetmsgrpcrpcMainWorker01Worker02Worker03队列队列队列投递Task性能、扩展、容灾等方面的思考1.服务间通信链条长，影响性能；且MsgServer容易成为瓶颈2.数据都缓存在本地，无法做到平行扩展、无法容灾3.服务无法做快慢分离，慢速服务会拖累整体系统4.无法按业务逻辑划分模块，导致ChatRoom过于庞大，引起诸多问题5.消息队列（RPC请求）放在内存中，服务重启时，必然导致信息丢失6.服务器信息同步没有确认机制，不能保证一致性代码维护方面的思考存在的问题（引自拍拍）•每个AppServer都有大量的重复代码，增加了应用开发人员的负担；•开发人员不可避免地需要编写调试协议打解包代码，花费大量的时间和精力；•底层代码一旦有调整，需要重编各个AppServer；•每个AppServer都由不同的开发人员负责，可能会存在代码风格和日志格式的不统一，增加了运营统计的难度。存在的其他问题•业务层面需过多关注底层模型，如线程模型•异步调用使用回调的方式，增加代码复杂度和可阅读性•接口不遵循互不信任原则，如：很少有参数校验•日志记录不完备，日志未分级别谢谢大家！问题？