人人网服务化与架构变迁v3 (1)课件

人人网网站架构

--服务化的演进内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案人人网网站业务每月数千万活跃用户每周数T照片上传到相册每天数千万新鲜事儿发布排名靠前的实时通讯软件（人人桌面）内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案一张依赖图（局部）“发状态”服务依赖多沟通烦上线难为什么服务化“解耦，分而治之，应对变化”名词太多，简单来说：将高内聚模块实现为服务，服务接口形式化让服务和数据易于访问

应对复杂性和易变性：复杂度增加VS人对复杂性控制的界限可预期的变化VS不可预期的变化内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案异构服务总线自实现REST框架纯Java架构，跨语言服务无法调用使用开源ICE大而全，整体解决方案想要修改或者扩展？重造轮子还是使用开源方案？一次线上事故3G状态服务SocialWIKI相册服务SocialWIKI相册服务3G状态服务3G状态服务3GSocialWIKI相册服务3G3G3G3G3G3G状态服务3G3GSocialWIKI从事故深挖出一些共性问题“为什么不使用非阻塞方式？”“为什么没有配额限制？没有权限隔离？”“为什么不能自动识别依赖、动态增加资源？”“能否让log汇总和分析实时一点儿？”内容概要一、人人网网站业务介绍二、为什么要服务化三、服务化：开启潘多拉的魔盒四、问题与解决方案问题回顾异构总线：自建还是开源“为什么不使用非阻塞方式？”“为什么没有配额限制？没有权限隔离？”“为什么不能自动识别依赖、动态增加资源？”“能否让log汇总和分析实时一点儿？”XOA（XiaoneiOrientedArchitecture）基础总线自建与开源的折中自建：没有精力开源：被绑架对待开源系统的态度作为组件而不是框架选择ThriftThrift/ThriftEX定制传输层/协议层性能优化路由、存储、调试定制序列化方式，总线adaptor，列压缩服务层线程模型、进程模型服务统一后门：FB303，民兵服务调用语义支持其他语义？阻塞/非阻塞、同步/异步、Event/回调不为奢饰品付钱为什么不直接用MQ？统一行为、统一总线使用者要的是非阻塞，不是MQ中转单向RPC调用的消息队列Thrift/ThriftEX+ZeroMQ寻址和隔离：“配额限制、权限隔离？”需要规则服务定位权限隔离/配额限制借鉴Linux文件系统标准静态、动态（易变）划分：/proc/etcACL完成权限划分：rwx基于Zookeeper建立规则（已申请专利）服务的寻址、权限控制权限控制(基于zookeeper的ACL)

/<root>

/<service>/<version> /<stat>/<node>super： 超级用户op： 运维用户server： 服务提供者client： 服务访问者服务的寻址、权限控制配额约束

/<root>/…/<stat>/Quota放置Quota配置文件，对于Client角色的不同User，指定相关的访问配额信息在线服务调度异常调度：在线调度扫描服务后门等方式获取异常寻找民兵服务切换民兵服务服务在线/离线Log/Profiling收集分析已有收集系统：延迟数十分钟待收集数据假设重要的量小（在线），不重要的量大（离线挖掘）又重要量又大，大概率是方向错了被动收集和主动收集数据分流（Error，Warn，Info）通过服务后门获取已定义状态等信息服务在线/离线Log/Profiling收集分析添加分流、实时通道，MQ或后门扫描服务小结系统的控制力最终还是人对其控制力业务到底在干啥调用链不能太长充分预