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

刘源

内容概要

一、人人网网站业务介绍

二、为什么要服务化

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

四、问题与解决方案

人人网网站业务

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）