新浪微博服务治理框架
微博客信息服务管理规定
【发布单位】国家互联网信息办公室【发布文号】【发布日期】2018-02-02【生效日期】2018-03-20【失效日期】【所属类别】国家法律法规【文件来源】中国网信网微博客信息服务管理规定第一条为促进微博客信息服务健康有序发展，保护公民、法人和其他组织的合法权益，维护国家安全和公共利益，根据《中华人民共和国网络安全法》《国务院关于授权国家互联网信息办公室负责互联网信息内容管理工作的通知》，制定本规定。
第二条在中华人民共和国境内从事微博客信息服务，应当遵守本规定。
本规定所称微博客，是指基于使用者关注机制，主要以简短文字、图片、视频等形式实现信息传播、获取的社交网络服务。
微博客服务提供者是指提供微博客平台服务的主体。
微博客服务使用者是指使用微博客平台从事信息发布、互动交流等的行为主体。
微博客信息服务是指提供微博客平台服务及使用微博客平台从事信息发布、传播等行为。
第三条国家互联网信息办公室负责全国微博客信息服务的监督管理执法工作。
地方互联网信息办公室依据职责负责本行政区域内的微博客信息服务的监督管理执法工作。
第四条微博客服务提供者应当依法取得法律法规规定的相关资质。
向社会公众提供互联网新闻信息服务的，应当依法取得互联网新闻信息服务许可，并在许可范围内开展服务，禁止未经许可或超越许可范围开展互联网新闻信息服务活动。
第五条微博客服务提供者应当发挥促进经济发展、服务社会大众的积极作用，弘扬社会主义核心价值观，传播先进文化，坚持正确舆论导向，倡导依法上网、文明上网、安全上网。
第六条微博客服务提供者应当落实信息内容安全管理主体责任，建立健全用户注册、信息发布审核、跟帖评论管理、应急处置、从业人员教育培训等制度及总编辑制度，具有安全可控的技术保障和防范措施，配备与服务规模相适应的管理人员。
微博客服务提供者应当制定平台服务规则，与微博客服务使用者签订服务协议，明确双方权利、义务，要求微博客服务使用者遵守相关法律法规。
新浪微博框架
大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。
最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。
很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。
另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。
今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。
首先给大家介绍一下微博架构发展的历程。
新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。
第一版就是是非常快的，我们可以非常快的实现我们的模块。
我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。
我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。
第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。
另外一个是MPSS，就是多个端口可以布置在服务器上。
为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。
我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。
这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。
如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。
我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。
我们技术上碰到几个问题。
第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。
另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。
四大门户微博集体“检修”内容监管成头痛大事
四大门户微博集体“检修”内容监管成头痛大事随着四大门户新闻座次基本排定，微博又?为它们争夺的新阵地，然而，微博之路走起来并不容易。
7月上旬，门户网站的微博服务集体发生重大“事变”：先是搜狐网的微博服务于7月10日、11日无法进入；第二天，新浪微博的标志旁边就打上了“测试版”的符号，随后，网易和腾讯两家的微博上也跟着出现了同样的标符。
可即便如此，网易微博还是重演了和搜狐一样短暂“停运”的现象。
呈竞争关系的门户微博们在同一时间相继出现同样的现象，绝非巧合。
《IT时代周刊》从知情人士处获悉，门户网站此举是受到了监管部门的压力，“搜狐微博暂停服务是由于审查合规问题，它们的服务中存在非法内容”，该人士透露，新浪微博页面增添的“测试版”字样正是体现出对监管压力的某种妥协姿态。
微博服务自从在门户网站上推出以来，短时间内在覆盖人数、用户访问次数、用户浏览页面及浏览时间等方面，均保持了高速增长。
有相关数据显示，截止到2010年5月，微博服务的月度覆盖人数已达8065万，环比增长16.6％。
然而，微博遭停事件的发生，使得微博这一当前“红得发紫”的互联网应用暗生危机。
也使业界对微博的前景有了重新审视。
微博之危事情发生后，各门户对此事三缄其口。
不过，搜狐网的客服代表向本刊记者证实搜狐微博于7月9日23时至7月12日期间关闭，但只表示是为了“维护”，对业界的“出于监管压力”之说并没有发表言论。
其他网站的说法和搜狐如出一辙。
新浪网营销中心副总经理刘奇也否认网站打出“测试版”符号与政府命令或其他竞争者有关，并说用户不必担心微博服务会被关闭。
然而，其打上“测试版”符号，是为了新浪微博“一周年纪念日策划再次启用仪式”的解释却令人觉得好笑。
新浪微博于去年8月正式推出，至今却仍然处于试用阶段。
但对于新浪微博正式上线的时间，相关发言人自始至终都没有给出准确答复。
尽管门户公司的相关发言人对此事的回应极为官样，甚至避而不谈，但公司内部人士却对此毫不避讳。
新浪微博架构与平台安全演讲稿
• 重新思考 Rest API
• 大部分调用都是空返回 • 大部分时间在处理不必要的询问 • 无法实时投递 • 存在请求数限制（ limit） （rate
如何解决
• 新一代推送接口(Stream API) (Stream • 采用推送的方式
• 有新数据服务器立即推送给调用方 • 无数据则不消耗流量 • 客户端实现更简单
•
数据压力及峰值
• •
将数据、功能、部署尽可能拆分 部署尽可能拆分 提前容量规划
平台化需求
• Web 系统
• 有用户行为才有请求
• API 系统
• 轮询请求 • 峰值不明显 • 用户行为很难预测
• 系统规模持续增大 • 平台化需求 • 新的架构如何设计 新的架构如何设计？
• “Break large complex systems
• 类似 mysql seconds behind master
• “Many services are written to alert
operations on failure and to depend upon human intervention for recovery, about 20% of the time they will make mistakes.
• 2. YMB is designed for wide wide-area
replication. This isolates individual PNUTS clusters from dealing with update between regions”
新推送架构
现状
• API 大部分请求都是为了获取最新
微博方案
新浪拆为门户板块与微博板块,门户板块由杜红负责
前段时间关于杜红将接任曹国伟新浪CEO之职的传言四起。
随着今天曹国伟一封CEO来信发出，该传言被证明至少在相当一段时期内不会为真了。
而这封信也表明，新浪前段时间，的确是在进行紧密集中的高层分工与架构调整。
曹国伟表明，这是“新浪多年来第一次根据战略发展的需要进行的架构重建”。
调整的总体思路是，新浪拆为门户板块与微博板块，门户板块由杜红负责（这可能就是杜红将任新浪CEO传言的由来），微博板块由曹国伟负责，王高飞任总经理。
For personal use only in study and research; not for commercial use可以说，杜红接管了老新浪。
这个动作，可以被看作是新浪加大微博与门户、移动与传统互联网的切分力度，也可以看作是对微博商业化更决绝的尝试。
此前，微博商业化的一个难题就是微博广告客户很大程度是由门户客户迁移过来，这实际上不利于微博广告产品与客户系统的独立进化，对新浪来说，也像是左手倒右手的无谓游戏。
可以想见，经此切分后，明年新浪营销体系会经受不小的调整与重新磨合。
另外一个亮点是，重建后，新浪新设了独立的产品创新部门，负责创新产品项目的孵化，由公司副总裁彭少彬负责。
另外新浪现在才提出明年将“移动优先”的战略，似乎真心晚了点？以下为曹国伟信的全文：各位同事，2012年即将结束，新的财年马上就要开始，感谢大家在过去一年里的辛勤工作，也借此机会跟大家分享一下公司2013年的战略思考和相关业务和组织架构的调整。
在2012年，我们取得了不少成绩，但也有不小的遗憾。
无论是门户还是微博，无论在移动端还是PC端，我们的用户和流量都在进一步增长，而移动端的增长尤为显著。
微博商业化也有了一个良好的开端。
回顾2012年，移动互联网的发展势头异常迅猛，而围绕移动互联网的产品和模式的创新与迭代正在迅速地改变互联网的竞争格局。
我们原来从PC向移动延伸的业务架构以及按职能线划分的组织架构无论在战略布局还是在执行效率上已经很难适应移动时代的市场竞争。
微博架构方案
-提供微博内容全文搜索，优化用户体验；
-实现实时搜索，提高搜索效率。
四、网络安全与数据保护
1.网络安全
-部署防火墙、入侵检测系统，防止恶意攻击；
-使用安全协议，如HTTPS，保障数据传输安全；
-实施严格的权限管理，防止内部数据泄露。
2.数据保护
-对用户敏感数据进行加密存储和传输；
-分析监控数据，优化系统性能。
六、实施与验收
1.实施计划
-制定详细的项目实施计划，明确时间节点、责任人和验收标准；
-按照实施计划，分阶段推进项目实施；
-组织技术培训，确保项目团队具备实施能力。
2.验收标准
-系统稳定性：确保99.99%的在线时间；
-性能指标：满足业务需求，响应时间不超过500ms；
-数据安全：无数据泄露事件发生；
微博架构方案
第1篇
微博架构方案
一、项目背景
随着互联网的快速发展，社交媒体已经成为人们日常生活中不可或缺的部分。微博作为国内领先的社交媒体平台，为广大用户提供了一个实时信息分享、互动交流的场所。为了满足日益增长的用户需求，保障平台稳定、高效运行，现需对微博平台架构进行优化升级。
二、方案目标
1.提高系统稳定性：确保平台在高并发、高负载情况下，仍能稳定运行，降低故障率。
（2）采用分布式设计，提高系统性能，确保高并发场景下的稳定运行。
（3）引入负载均衡技术，合理分配请求，提高资源利用率。
2.数据库设计
（1）采用关系型数据库存储用户数据，如MySQL、Oracle等。
（2）采用NoSQL数据库存储非结构化数据，如MongoDB、Redis等。
（3）建立合理的索引策略，提高数据查询速度。
微博的运营方式有哪些
微博的运营方式有哪些中国互联网从博客时代正式进入了微博时代，传统门户网站一股脑儿投奔微博怀抱。
就连已经关闭的饭否也获得了“重生”。
微博已不仅仅是一种新兴媒体，它可以做成一个网游、邮箱、音乐、搜索、相册等产品线的整合平台，那么微博的运营方式有哪些?微博的运营方式新浪微博：媒体效应用户超5000万分成三七开从微博上线之日起，新浪就成立了专门的团队负责微博运营，如今，这一团队已经发展成为微博产品事业部，全面负责微博产品的开发、运营及规划。
虽然四大门户均已开发了微博产品，但其中作为独立事业部运作的仅新浪一家。
新浪副总裁、微博事业部总经理彭少彬表示，以微博平台为核心，新浪微博可以提供应用、连接、分享三个层面的合作模式。
与苹果的AppStore、优酷等合作，极大地提升了用户黏性和品牌曝光度。
与新浪博客共享计划相比，新浪微博将会提供更加多元化的广告模式。
在这个广告服务平台上，广告主和开发者可以进行双向选择，并实现自主竞价。
在应用增值服务方面，随着用户数的爆发式增长，无论是企业用户还是个人用户，都会产生对收费服务的需求，这就为开发者通过应用增值服务获得收入创造了更广阔的空间。
此前，在互联网市场，一旦牵涉到平台应用增值服务的分成，平台基本都会占据主导地位。
但彭少彬透露，目前新浪微博用户已超5000万，开发者在新浪微博平台上开发的应用增值服务，新浪微博平台与开发者将采用3：7的分成比例，把应用增值服务的大部分收入给开发者，更大限度地保护开发者利益。
搜狐微博：明星效应名人战略投入不封顶搜狐相关媒介负责人林涛表示，“作为Web2.0的最新产品，微博的战略地位已被搜狐提升到最高级别”。
张朝阳更是表示，将亲自来抓微博的发展，对其“进行不封顶的投入，名人战略必须得走”。
此前，张朝阳在不同场合多次阐述对微博发展趋势的看法，“目前微博还仅仅在特定圈子中比较风靡，而未来微博肯定是面向大众的。
比如明星名人不一定只发一个微博，两个都可以发。
新浪技术保障部运维架构师 王关胜 《构建高效的防御体系》
微博平台护城河构建高效的防御体系@王关胜大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.微博平台业务介绍用户8亿注册用户8000万+DAU 1.75亿MAU系统200+集群3000+设备日均6百亿Hits运维99.99%Docker：53%变更：15次/周2.面临的挑战●产品功能迭代快，系统变更及代码上线次数多●突发的热点事件#周一见##且行切珍惜##马航370##刘翔摔倒#●每日不定时段的Push内容●业务上复杂的依赖关系●基于微博的大型运营活动：让红包飞，随手拍…●每年一度的三节保障&春晚大考3.突发流量峰值●热门事件：最大30倍瞬间峰值◆微博，转发，评论，赞◆长微博◆话题●典型案例：日常Push◆落地页：业务模块，如话题，热门微博◆下发速度：快，中，慢◆用户模型：全量，高中低频，地区，灰度模型（如尾号）◆用户互动时间：<1h◆分类：应用内Push，应用外Push，运营及活动Push大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.什么是防御体系架构容量监控干预实时性&报警快误报少&报警准无遗漏&覆盖全防御体系四要素性能好&冗余够快速动态扩容压测&容量预警极简的架构稳健的架构美丽的架构预案全&手段多操作快&方案细干预行之有效.快.全.准.简.美.稳.多.效.细.够.警.动2.防御体系框架四层七层Web RPCProcessor 规范业务日志Http MC(Q)资源层MySQL Redis Hbase 平台架构运维四化建设全链路SLA 运维数据接口分工&职责&KPI 标准流程规范监控容量架构干预定期巡检&演练7x24小时轮班定期培训知识管理防御标准化防御制度服务隔离快速失败大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.防御架构设计之防单点●防单点◆调用链路上避免单点无状态：前端，队列处理，RPC 支持503机制◆线性扩容，平滑上下线，在线调整业务代码层支持，运维只需改配置◆核心资源设计为分层访问缓存分级10G 10G 10G 10G Maste r 10G10G10G10GSlaveWebL1L1L1L1DB(1)select one of L1 cache （include master ）,get from it(2) if L1 exist,return;if not exist,get from master.(3) if master exist, return, and set L1; else if not exist, get from slave(4) if slave exist, return,set master and L1;else if not exist,get from db(5) if db exist,return,set master,slave and L1;else throw exception(6)if has new data (mcq process),update all of L1,master, slave访问逻辑防御架构设计之隔离●隔离：80-20原则◆业务层：基于SLA的快速失败代码分层与服务化异步解耦合◆部署层：核心链路独立部署多机房容灾◆基础架构层：核心服务设备网络层隔离交换机上联容灾微博平台部署架构多机房部署核心服务独立域名，上下行分开七层独立部署核心服务独立服务池Tomcat线程保护快速失败服务化及独立部署核心资源独立部署外部依赖异步解耦隔离方法防御架构设计之多机房实践多机房组件●核心问题◆机房间延时：用户的请求应该在本机房内完成◆专线质量◆部署范围：核心业务路径本地部署依赖业务数据同步◆数据异地多写：部署业务消息化多机房同步组件（MytriggerQ，WMB）◆七层规则：非核心路径穿透北京◆数据一致性◆配置基础设施◆技术改造对线上业务的影响2.主动防御-监控体系新浪综合运维平台SinaWatchJpool_agentLogtailer SinaScri pt基础资源应用程序业务监控运维数据load cpu memswapNet disk inodepingIo proc threadtcp_c Message cs pgmf端口监控线程Jvm & GC Nginx 状态资源线程池&分布耗时接口稳定性（99.95%）Profile &WatchMan 集群单机健康状态部署层数据业务层数据资源层数据核心模块数据Diy Dashboard移动APP 联系人分组合并报警配额WEB警铃邮件短信私信同比&环比面积图趋势函数节点监控数据API平台业务监控实践●业务日志标准化：profile.log◆监控分类:7大类◆指标项：API 举例C-计数T-时间单位：ms指标total_countslowThresholdslow_countavg-timeival1ival2ival3ival4ival5说明调用量SLA 慢请求平台耗时<500<500-1s><1s-2s><2s-4s>>4s类型CTCTC C C C C资源层APIMC&MCQ MySQL 依赖SERVICEHTTP 依赖Hbase 依赖Redis 依赖API 日志样例：{"type":"API ","name":"/statuses/friends_timeline","slowThreshold":0,"total_count":0,"slow_count":0,"avg_time":"00.00","interval1":0,"interval2":0,"interval3":0,"interval4":0,"interval5":0}业务监控方案●监控选型：Logtailer+Statsd+Graphite●Logtailer封装◆Python实现的agent◆分布式1存储（一致性Hash）◆打包发送（UDP协议）◆本地Cache（10s）●Graphite优化◆高可用部署◆接入Memcached◆Whisper I/O优化（合并写）●监控数据量◆Metrics:Statshd:90k/s Carbon:1800k/s◆指标项：1000+◆报警：<300LogtailerStatsdNginxHAproxycarbon-relaywhispercarbon-cachewhispercarbon-cachewhispercarbon-cachecarbon-relay graphite-webweb app基于Graphite的方案业务监控Dashboard●Graphite Dashboard◆丰富的函数操作及聚合规则◆定制用户自己的Dashboard◆移动端APP◆强大的接口业务模块DashboardAPP端Dashboard APP端报警通知业务监控-完善方案改进版业务监控集群App logJvm loglogstashKibanaElasticSearchStatsDMfiter Graphite资源依赖Http 依赖服务依赖RPC依赖层4/7层Sina WatchSina ScriptsSina Atp用户日志查询报警平台DashboardSpark HbaseWatchManTrace UI部署线日志查询报警平台业务Dashboard Trace单机健康状态监控●集群单机健康状态监控◆指标定义◆实现方案◆数据通道：agent(Python)->SinaWatch ->API ->Dashboard ◆健康状态判断：算法（区间权重+优先级+硬性指标）◆数据展示：异常的节点可获取异常数据分类影响因素好-正常坏-亚健康糟糕-异常系统Load <1212<X<24>24Cpu_idle <30%10%<X<30%<10%Iowait <20%20%<X<35%>50%Swap<500M 1G<X<2G >2G 业务5xx 错误比率<1%1%<x<5%>5%接口平均耗时<100ms100-500ms>1s产品展示图3.主动防御-容量评估●平台容量评估实践◆压力测试方式：集群容量数据一览图 单接口压测：模拟请求（http_load）单机压测：✓线上引流：Tcpcopy(放大/多台引至一台)✓调整Nginx权重：平台自动化化压测系统服务池压测：全链路压测✓机房间流量切换（核心服务）✓Nginx upstream自动变更ps:粒度：1/单IDC Nginx集群数量资源容灾与压测：Touchstone（基于tc）◆容量评估产出：基于Python的自动化压测工具水位预警工具容量报表4.主动防御-干预手段 有效的干预手段是快速解决问题&故障的基石异常处理预案重启/回滚/紧急上线服务降级/封禁流量切换干预手段限流Docker 机动池数据修复快慢定期循检故障演练7x24小时轮班重大事件响应流程&制度操作方案扩容应急预案-服务降级降级Web UI●预案：100+◆日常&应急预案◆重大活动，三节等预案手册●服务降级：5000+◆原则：覆盖全，开关避免手输◆方案：业务代码框架层实现，动态修改运行时环境Tomcat监听端口，支持check/on/off/status集成运维工具系统◆范围：大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.新浪故障管理制度●组织形式◆实体故障管理组--跟进故障业务方及运维核心人员--解决故障◆虚拟：TDO-各部门专家支持故障Review，深入挖掘故障本因◆沟通方式：在线：电话，QQ及群，其他IM通知：短信，邮件●管理制度◆拥抱故障◆KPI--故障记分运营KPI与产品良好的用户体验挂钩处理故障能力与KPI挂钩◆奖惩制度：设立运维季度奖，涵盖面广人为故障，责任到人，通告及罚钱2.新浪故障处理流程•接收报障•判断是否为故障•启动故障通报流程•跟进处理进展•判断及启动升级策略•确认解决•发出恢复通报•故障讨论会•发送报告•跟进改进措施故障管理组流程•与报障来源部门确认具体现象确认故障现象故障通知•与TDO协调相关部门处理•每30分钟通报一次进展协调跟进•技术方向升级•故障管理方向升级•客服方向升级级别预判升级•第一时间通知主要工程师及TDO•10分钟内发出短信及邮件•确认故障恢复•5分钟内发出短信•召开故障讨论会故障解决•第一版报告故障4小时后发•故障报告最终版2个工作日内发出故障报告故障管理组主要工作运维&开发故障处理流程数据修复流程•周知相关领导及服务台•初步判断问题并定解决方案•如有上线及变更优先回滚•多方方案并行推进•以停止故障影响为目的•提交数据修复变更申请•主管审批并确定负责人•数据修复方案review•周知各相关方关注服务•实施数据修复3.新浪故障报告●故障定级◆级别：5级，E级为重要问题◆指标：6类，每类细化指标每个产品线指标不同，每类多级重要产品按功能模块划分多级，赋分◆公式：故障级别计算公式●故障原因◆原则：每一个故障及问题追查本因◆分类：研发类和产品线◆分级：一级分类和二级分类一级分类：✧网络类✧局方故障✧应用软件✧硬件设备✧系统类✧人为因素微博故障定级规则A级：85分以上B级：71-84分C级：61-70分D级：41-60分E级：41及分以下（备案不发）权重值衡量指标衡量指标级别30%1、影响微博功能220%2、影响服务时长315%3、影响用户范围415%4、用户投诉级别110%5、影响服务程度210%6、影响用户时段1故障评分64.5故障级别：C级微博故障报告单（要点）故障标题故障描述所属产品线影响功能故障级别影响时长开始时间发现时间恢复时间发现途径故障原因根本原因触发原因影响用户影响用户数计算方法投诉情况责任部门责任人故障分类处理过程改进措施服务影响时长=服务恢复时间-故障开始时间故障定级规则故障故障报告单。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SID
PSID Annotation
span ID，调用链中的一个节点，从请求开始到请求结束，生成方式同ReqID。
Caller spanID 该调用节点的类别，有API client/API server/RPC Client/RPC Server/其他中间件定 义 接口名称 开始时间和请求时间
Service Name Start/Process Time
服务化框架
监控平台
监控指标UI呈现 报警子系统 流量切换 服务治理平台 服务扩容 服务发布
RPC 数据聚合平台 Motan Registry 上报 资源日志 Push Motan Client
Cache Service … Config Server
上报
接口日志
上报 RPC日志
Push
Client
调用链标准化日志
ReqID SID PSID Annotation Service Name InterfaceNa me Start Time Process time Node IP 16位UUID RPC Node IP
Field ReqID
Description 请求序列号，在调用链入口生成，考虑使用节点IP地址+IDC机房编码+序列号生 成
10.5.2.1 IDC1: Motan Registry IDC2: 10.6.2.1 10.6.2.2 10.6.2.1 10.5.2.1 10.5.2.2 Push Motan Client 切换后数据流 10.5.2.1
10.6.2.1
问题：基于IDC的流量切换策略是否够用？是否需要增加按20/80比例的流量分发策略？
微博平台服务化框架
卫向军
Agenda
• • • • • • 服务化框架 服务标准化 日志标准化 数据聚合平台 服务治理平台 监控平台
微博平台架构
业务架构
接口层 内容/关系/通讯 技术架构 Jersey框架 监控 接口 RPC Tr a c e 服务依赖 服务治理
Dubbo 组合 服务 原子 短链 用户 关系 Config 私信 … MCQ MessageQu eue
Field Annotation Service Name Avg QPS Min QPS Max QPS Sample Period Extension
备注：所有的分布式服务都可以使用这个标准化日志
数据聚合平台
分布式服务状态流式处理流程
RPC Server Cluster Node 1 status Node 2 status Node 3 status
数据聚合平台
调用链状态
服务动态依赖
+
服务静态依赖
服务动态依赖
服务一致性校验
服务动态依赖
HBase
服务治理平台
服务依赖
功能：
• 静态依赖表(Motan Registry) • 动态依赖表(调用链分析) • 动态+静态依赖表一致性检查
作用
• 指导如何拆分现有的业务或者复杂的RPC服务。 • 依赖某一RPC服务的所有接口和服务，下线服务时使用 • 当某一服务异常时，通知受影响的服务负责人 • 服务升级时，通知受影响的服务负责人
服务标准化
服务模型
服务注册
+
ServiceType(atomic/ composite) DependentServices
1. Service Provider在注册时增加ServiceType，标识该服务是Atomic还是Composite， atomic服务不依赖于任何其他服务。 2. Service Provider在注册时增加DependentService，标识该服务直接依赖的所有 服务。 3. 上面两项用于服务治理平台中服务依赖的静态分析。 4. 能否将Web 接口注册为服务？（个人觉得短期不需要）。
流量切换
功能：
• 将流量从一个Ine级别流量切换
作用
• 机房发生故障或者维修时，快速切换 • 某一机房的RPC服务故障时，快速切换能力 • 方便服务的扩容与升级，为服务的灰度发布提供基 础能力
流量切换
流量切换 控制流
切换前数据流 IDC1+IDC2 IDC1
服务扩容与缩容
扩容
• 准备扩容服务机器，验证ready后。 • 通过服务治理平台，增加扩容服务节点，调整状 态为预览。
缩容
• 按照IDC/rack/machine规则将需要下掉的服务流量 分流到其他机器上，然后对服务缩容。
发布和灰度
通过标识服务节点状态，达到灰度发布目的
服务更新后，选 择1个节点预览 服务客户端，调 度策略可以给不 同的节点分配不 同的权重 选择部分节点做 灰度发布 服务客户端，调 度策略可以给不 同的节点分配不 同的权重 放量到全部服务 节点 服务客户端，调 度策略可以给不 同的节点分配不 同的权重
API 接口(A)
RPC(B)
RPC(C)
CS SR CS SR
RPC(D)
CR
SS
CS CR SS
SR
RPC(E)
CR CR SS SS
调用链模型(2)
CS
SR
CR
SS
• 一次服务调用由4个采集点组成，分别是：CS（客户端发送）、SR（服 务端接收）、SS（服务端发送）、CR（客户端接收）。 • CS和CR共同组成Client的一个Span，在当前RequestContext下生成该 SpanID，同时从RequestContext下获取Parent Span。 • 在SR和SS处理之前，RequestContext暂存的Span将被替换成上一步生成 的SpanID, SR和SS将生成另外一个Span。
异常
Error 调用链 SLA 服务状态
发布和灰 度 服务扩容 与缩容 流量切换
资源层
MC
Redis
MyS QL
HBa se
Cache Service SSD Service
Key-List Service
核心内容
业务架构 • 服务拆分为原 子服务与组合 服务 • 平台服务标准 化定义 技术架构 • Trace系统与基 础技术组件改 造 • Dubbo/Config Service与服务 治理改造 • 定义标准化日 志格式 • 定义标准化分 布式服务状态 日志 监控 • 接口状态：分 析日志 • 服务状态：分 析服务日志 • Error/Exception： 分析日志 • 调用链：分析 日志 服务治理 • 服务依赖：动 态分析法+静态 分析法 • 服务扩容：服 务报警+手动/ 自动扩容 • 流量切换：不 同的流量切换 策略 • 服务发布与灰 度：TBD
Node IP
处理该Span请求的机器IP地址
Exception/Error标准化日志
ReqID 16位UUID SID PSID Type Exception/Error Content
Field ReqID SID
Description 请求序列号，在调用链入口生成，考虑使用节点IP地址+IDC机房编码+序列 号生成 span ID，调用链中的一个节点，从请求开始到请求结束，生成方式同 ReqID。
数据聚合平台
接口调用链 RPC调用链 资源调用链 调 用 链 信 息 N1 Status N2 Status N3 Status 服 务 静 态 状 态
+
Service运行状态
+
Motan Registry
Service统计信息
HBase
分布式服务依赖
资源调用链 RPC调用链 接口调用链 Motan Registry
服务标准化
定义服务级别 1为核心服务 定义服务XXX
2为非核心服 务
日志标准化
日志采集点
采集点 用于何种统计项
调用链出入口 Exception
调用链 Exception、调用链
Error
服务节点日志 TBD
Error、调用链
服务健康状态
调用链模型(1)
User
CS SR CS CR SR SS
预览 1
灰度放量 2
全量放量 3
谢谢!
PSID
Type Content
Caller spanID
Exception or Error Exception/Error 内容
备注：仅当Exception和Error发生在调用链上时，才生成ReqID，SID，PSID，Type
服务状态标准化日志
Annotation RPC Service Name InterfaceN ame Description 该调用节点的类别，有API client/API server/RPC Client/RPC Server/其他中间件定义 接口名称 平均的QPS 最小的QPS 最大的QPS 采样间隔 扩展用字段 Avg QPS Min QPS Max QPS Node IP Sample Period Extension