人人网服务化与架构变迁v3 1.pptxVIP

内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案人人网网站业务每月数千万活跃用户每周数T照片上传到相册每天数千万新鲜事儿发布排名靠前的实时通讯软件（人人桌面）人人网网站业务很异构，很分散，很易变动内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案一张依赖图（局部）“发状态”服务依赖多沟通烦上线难为什么服务化“解耦，分而治之，应对变化” 名词太多，简单来说：将高内聚模块实现为服务，服务接口形式化让服务和数据易于访问 应对复杂性和易变性：复杂度增加 VS 人对复杂性控制的界限可预期的变化 VS 不可预期的变化那我们就开始服务化吧自实现REST框架使用Java，基于Spring MVC开发便捷，应用在UGC等业务逻辑中使用开源ICE，完整RPC架构实现缓存等中间层、新鲜事儿等系统内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案异构服务总线自实现REST框架纯Java架构，跨语言服务无法调用使用开源ICE大而全，整体解决方案想要修改或者扩展？重造轮子还是使用开源方案？一次线上事故相册服务相册服务相册服务3G3G3G3G3G3G3G3G3G3G3G3G状态服务状态服务状态服务状态服务SocialWIKISocialWIKISocialWIKISocialWIKI失控是不是太无政府主义了？步子迈的太大，容易扯着蛋服务化的太乱，容易挂全站服务化过度面临问题单边失效的容错局部过载、级联反应，超时放大服务之间的约定伴随调用链增长而失效从事故深挖出一些共性问题“为什么不使用非阻塞方式？”“为什么没有配额限制？没有权限隔离？”“为什么不能自动识别依赖、动态增加资源？”“能否让log汇总和分析实时一点儿？”内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案问题回顾异构总线：自建还是开源“为什么不使用非阻塞方式？”“为什么没有配额限制？没有权限隔离？”“为什么不能自动识别依赖、动态增加资源？”“能否让log汇总和分析实时一点儿？”问题抽象“独立的组件” 基础总线 调用语义 服务寻址和权限控制 服务调度 服务在线/离线 Log/Profiling 收集分析XOA（Xiaonei Oriented Architecture）基础总线自建与开源的折中自建：没有精力开源：被绑架对待开源系统的态度作为组件而不是框架选择ThriftThrift/ThriftEX定制传输层/协议层性能优化路由、存储、调试定制序列化方式，总线adaptor，列压缩服务层线程模型、进程模型服务统一后门：FB303，民兵服务调用语义：“为什么不使用非阻塞方式？”常用调用语义（状态服务为例）：双向阻塞：DB,数据库单向非阻塞：发状态调用语义支持其他语义？阻塞/非阻塞、同步/异步、Event/回调不为奢饰品付钱为什么不直接用MQ？统一行为、统一总线使用者要的是非阻塞，不是MQ中转单向RPC调用的消息队列Thrift / ThriftEX + ZeroMQ寻址和隔离：“配额限制、权限隔离？”需要规则服务定位 权限隔离 / 配额限制借鉴Linux文件系统标准静态、动态（易变）划分：/proc /etcACL完成权限划分： rwx基于Zookeeper建立规则（已申请专利）服务的寻址、权限控制服务的定位 /root/service/version/stat/noderoot: online, sandbox, testservice: 服务的逻辑名称version: 服务的版本stat: 服务的某个状态，例如sharding number等node: 具体的服务物理节点信息，例如ip+port+pid服务的寻址、权限控制权限控制(基于zookeeper的ACL) /root /service/version /stat/nodesuper： 超级用户op： 运维用户server： 服务提供者client： 服务访问者服务的寻址、权限控制配额约束 /root/…/stat/Quota放置Quota配置文件，对于Client角色的不同User，指定相关的访问配额信息调度：“自动识别依赖、动态增加资源？”服务化调度：将流程自动化服务太多，依赖太多，易犯错除夕晚高峰、高考结束高峰、登陆攻击离线服务调度运维调度：使用OP角色，离线调度（Hadoop）确认环境、权限检查服务依赖链和配额管理服务生命期环境回收在线服务调度异常调度：在线调度扫描服务后门等方式获取异常寻找民兵服务切换民兵服务服务在线/离线 Log/Profiling 收集分析已有收集系统：延迟数十分钟待收集数据假设重要的量小（在线），不重要的量大（离线挖掘）