1、微博平台服务化框架,卫向军,Agenda,服务化框架服务标准化日志标准化数据聚合平台服务治理平台监控平台,微博平台架构,业务架构,内容/关系/通讯,技术架构,接口层,Jersey框架,监控,服务治理,私信,短链,资源层,组合服务 原子,用户关系,Config,Dubbo,MCQ,MessageQueue,MC,Redis,MySQL,HBase,Cache Service,SSD Service,Key-List Service,Trace,接口,RPC,异常,Error,调用链,SLA,服务状态,服务依赖,发布和灰度,服务扩容与缩容,流量切换,核心内容,服务化框架,监控平台,监控指标UI呈现
2、,报警子系统,服务治理平台,流量切换,服务扩容,数据聚合平台,接口日志,RPC日志,资源日志,Motan Client,Motan Registry,上报,上报,上报,服务发布,RPC,Push,Client,Config Server,Push,Cache Service,服务标准化,服务模型,服务注册,ServiceType(atomic/composite)DependentServices,+,Service Provider在注册时增加ServiceType，标识该服务是Atomic还是Composite， atomic服务不依赖于任何其他服务。Service Provider在注册
3、时增加DependentService，标识该服务直接依赖的所有服务。上面两项用于服务治理平台中服务依赖的静态分析。能否将Web 接口注册为服务？（个人觉得短期不需要）。,服务标准化,日志标准化,日志采集点,调用链模型(1),调用链模型(2),一次服务调用由4个采集点组成，分别是：CS（客户端发送）、SR（服务端接收）、SS（服务端发送）、CR（客户端接收）。CS和CR共同组成Client的一个Span，在当前RequestContext下生成该SpanID，同时从RequestContext下获取Parent Span。在SR和SS处理之前，RequestContext暂存的Span将被替换
4、成上一步生成的SpanID, SR和SS将生成另外一个Span。,调用链标准化日志,Exception/Error标准化日志,备注：仅当Exception和Error发生在调用链上时，才生成ReqID，SID，PSID，Type,服务状态标准化日志,备注：所有的分布式服务都可以使用这个标准化日志,数据聚合平台,分布式服务状态流式处理流程,RPC Server Cluster,Node 1,Node 2,Node 3,status,status,status,Motan Registry,N1 Status,数据聚合平台,N2 Status,N3 Status,Service运行状态,服务静态状
5、态,+,RPC调用链,接口调用链,资源调用链,调用链信息,+,Service统计信息,HBase,分布式服务依赖,Motan Registry,数据聚合平台,服务静态依赖,+,RPC调用链,接口调用链,资源调用链,调用链状态,服务一致性校验,HBase,服务动态依赖,服务动态依赖,服务动态依赖,服务治理平台,服务依赖,流量切换,流量切换,Motan Client,流量切换,Motan Registry,IDC1:10.5.2.110.5.2.2,IDC2:10.6.2.110.6.2.2,10.5.2.1,10.5.2.1,10.6.2.1,10.6.2.1,控制流,切换前数据流,切换后数据流,IDC1+IDC2 IDC1,问题：基于IDC的流量切换策略是否够用？是否需要增加按20/80比例的流量分发策略？,Push,服务扩容与缩容,发布和灰度,预览,灰度放量,全量放量,通过标识服务节点状态，达到灰度发布目的,服务更新后，选择1个节点预览服务客户端，调度策略可以给不同的节点分配不同的权重,1,2,3,选择部分节点做灰度发布服务客户端，调度策略可以给不同的节点分配不同的权重,放量到全部服务节点服务客户端，调度策略可以给不同的节点分配不同的权重,谢谢!,
