人人网网站架构-- 服务化的演进

刘源

内容概要

一、人人网网站业务介绍

二、为什么要服务化

三、服务化：开启潘多拉的魔盒

四、问题与解决方案

人人网网站业务

1. 每月数千万活跃用户

2. 每周数 T 照片上传到相册

3. 每天数千万新鲜事儿发布

4. 排名靠前的实时通讯软件（人人桌面）

人人网网站业务

很异构，很分散，很易变动

内容概要

一、人人网网站业务介绍

二、为什么要服务化

三、服务化：开启潘多拉的魔盒

四、问题与解决方案

一张依赖图（局部）

“ 发状态”服务

1. 依赖多2. 沟通烦3. 上线难

为什么服务化

“ 解耦，分而治之，应对变化”

1. 名词太多，简单来说：1. 将高内聚模块实现为服务，服务接口形式化2. 让服务和数据易于访问

2. 应对复杂性和易变性：1. 复杂度增加 VS 人对复杂性控制的界限2. 可预期的变化 VS 不可预期的变化

那我们就开始服务化吧

1. 自实现 REST 框架1. 使用 Java ，基于 Spring MVC2. 开发便捷，应用在 UGC 等业务逻辑中

2. 使用开源 ICE ，1. 完整 RPC 架构2. 实现缓存等中间层、新鲜事儿等系统

内容概要

一、人人网网站业务介绍

二、为什么要服务化

三、服务化：开启潘多拉的魔盒

四、问题与解决方案

异构服务总线

1. 自实现 REST 框架1. 纯 Java 架构，跨语言服务无法调用

2. 使用开源 ICE1. 大而全，整体解决方案2. 想要修改或者扩展？

3. 重造轮子还是使用开源方案？

一次线上事故

3G

状态服务

SocialWIKI

相册服务

SocialWIKI

相册服务3G

状态服务

3G

状态服务

3G

SocialWIKI

相册服务3G3G3G3G3G3G

状态服务

3G3G

SocialWIKI

失控

1. 是不是太无政府主义了？1. 步子迈的太大，容易扯着蛋2. 服务化的太乱，容易挂全站

2. 服务化过度面临问题1. 单边失效的容错2. 局部过载、级联反应，超时放大3. 服务之间的约定伴随调用链增长而失效

从事故深挖出一些共性问题

1. “ 为什么不使用非阻塞方式？”2. “ 为什么没有配额限制？没有权限隔离？”3. “ 为什么不能自动识别依赖、动态增加资

源？”4. “ 能否让 log 汇总和分析实时一点儿？”

内容概要

一、人人网网站业务介绍

二、为什么要服务化

三、服务化：开启潘多拉的魔盒

四、问题与解决方案

问题回顾

1. 异构总线：自建还是开源

2. “ 为什么不使用非阻塞方式？”3. “ 为什么没有配额限制？没有权限隔离？”4. “ 为什么不能自动识别依赖、动态增加资

源？”5. “ 能否让 log 汇总和分析实时一点儿？”

问题抽象

“ 独立的组件”

1. 基础总线2. 调用语义3. 服务寻址和权限控制4. 服务调度5. 服务在线 / 离线 Log/Profiling 收集分析

XOA （ Xiaonei Oriented Architecture ）

基础总线

1. 自建与开源的折中1. 自建：没有精力2. 开源：被绑架

2. 对待开源系统的态度1. 作为组件而不是框架

3. 选择 Thrift

Thrift/ThriftEX

1.定制传输层 / 协议层1.性能优化2.路由、存储、调试3.定制序列化方式，总线 adaptor ，列压缩

2.服务层1.线程模型、进程模型2.服务统一后门： FB303 ，民兵服务

调用语义：“为什么不使用非阻塞方式？”

1. 常用调用语义（状态服务为例）：1.双向阻塞： DB, 数据库2.单向非阻塞：发状态

调用语义

1. 支持其他语义？1. 阻塞 / 非阻塞、同步 / 异步、 Event/回调2. 不为奢饰品付钱

2. 为什么不直接用 MQ ？1. 统一行为、统一总线2. 使用者要的是非阻塞，不是 MQ

中转单向 RPC 调用的消息队列

Thrift / ThriftEX + ZeroMQ

寻址和隔离：“配额限制、权限隔离？”

1. 需要规则1. 服务定位 2. 权限隔离 / 配额限制

2. 借鉴 Linux文件系统标准1. 静态、动态（易变）划分： /proc /etc2. ACL 完成权限划分： rwx

3. 基于 Zookeeper 建立规则（已申请专利）

服务的寻址、权限控制

1. 服务的定位

/<root>/<service>/<version>/<stat>/<node>

root: online, sandbox, testservice: 服务的逻辑名称version: 服务的版本stat: 服务的某个状态，例如 sharding

number 等node: 具体的服务物理节点信息，例如

ip+port+pid

服务的寻址、权限控制

1. 权限控制 ( 基于 zookeeper 的 ACL)/<root>

/<service>/<version>

/<stat>/<node>

super ： 超级用户op ： 运维用户server ： 服务提供者client ： 服务访问者

服务的寻址、权限控制

1. 配额约束

/<root>/…/<stat>/Quota

放置 Quota 配置文件，对于 Client角色的不同 User ，指定相关的访问配额信息

调度：“自动识别依赖、动态增加资源？”

1. 服务化调度：将流程自动化1. 服务太多，依赖太多，易犯错2. 除夕晚高峰、高考结束高峰、登陆攻击

离线服务调度

1. 运维调度：使用 OP角色，离线调度（ Hadoop ）

1. 确认环境、权限2. 检查服务依赖链和配额3. 管理服务生命期4. 环境回收

在线服务调度

1. 异常调度：在线调度1. 扫描服务后门等方式获取异常2. 寻找民兵服务3. 切换民兵服务

服务在线 / 离线 Log/Profiling 收集分析

1. 已有收集系统：1. 延迟数十分钟

2. 待收集数据假设1. 重要的量小（在线），不重要的量大（离线挖掘）2. 又重要量又大，大概率是方向错了

3. 被动收集和主动收集1. 数据分流（ Error ， Warn ， Info ）2. 通过服务后门获取已定义状态等信息

服务在线 / 离线 Log/Profiling 收集分析

添加分流、实时通道， MQ 或后门扫描服务

小结

1. 系统的控制力最终还是人对其控制力1. 业务到底在干啥2. 调用链不能太长3. 充分预估、充分灾备

2. 系统的控制力建立在非置信关系上1. 没有不会挂的系统：隔离错误，拒绝大框架2. 没有充分沟通的交流：规则先行

XOA （ Xiaonei Oriented Architecture ）