人人网服务化与架构变迁V3
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

人人网服务化与架构变迁V3

on

  • 978 views

 

Statistics

Views

Total Views
978
Views on SlideShare
978
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

人人网服务化与架构变迁V3 Presentation Transcript

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