新浪微博服务治理框架
微博客信息服务管理规定
【发布单位】国家互联网信息办公室【发布文号】【发布日期】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级微博故障报告单（要点）故障标题故障描述所属产品线影响功能故障级别影响时长开始时间发现时间恢复时间发现途径故障原因根本原因触发原因影响用户影响用户数计算方法投诉情况责任部门责任人故障分类处理过程改进措施服务影响时长=服务恢复时间-故障开始时间故障定级规则故障故障报告单。
微博社区管理规章制度
微博社区管理规章制度规章制度【篇一】第十七条危害信息处理流程： (一) 站方通过主动发现和接受用户举报两种方式发现危害信息。
完成真实身份验证的用户可通过微博页面上的“举报”功能，对涉嫌违规的行为进行举报。
(二) 危害信息由站方根据本规定直接处理。
第十八条不实信息处理流程 (一) 追溯期：自违规发生的3个月内。
(二) 发现方式：站方通过主动发现和接受用户举报两种方式发现不实信息。
完成真实身份验证的用户可通过微博页面上的“举报”功能，对涉嫌违规的行为进行举报。
(三) 受理条件： 1. 被举报内容直接转发数超过100，即受理; 2. 被超过10位用户举报，即受理; 3. 恶意举报不予受理。
(四) 受理之后， 1. 若涉及信息明显不实，由站方根据本规定直接处理，并建立卷宗公示结果。
如有必要，将在直接处理前通知双方进行3小时的陈述，陈述信息将作为辅助判定的重要依据。
2. 若涉及信息已有判例，循例处理，并建立卷宗公示结果。
3. 若涉及信息既非明显不实，又无判例可循，进入专家委员会判定阶段。
(五) 专家委员会判定阶段： 1. 站方就事件建立网页卷宗，并以微博通知的方式，请当事人进入网页卷宗举证或自辩。
陈述时间为：自通知发出后3小时内。
2. 对涉及的微博予以标注，提醒他人此微博涉嫌违规已被举报。
3. 陈述结束， (1) 由系统从专家委员会全体成员中随机选出9位成员构成判定具体案例的专家委员会。
(2) 以微博私信的方式邀请委员会成员进入网页卷宗投票判定。
(3) 判定时间为：自陈述结束后24小时内。
(4) 判定时间结束，若一方票数大于5(含)，完成判定。
(5) 每3小时发起一轮投票，总票数不足或双方票数相同时发起下一轮，直到24小时判定总时间结束。
(6) 若24小时后未能完成判定，按被举报方不违规处理。
(六) 站方根据判定结果，完成对违规内容、帐号的处置和公示，并以微博通知的方式告知。
第十九条用户纠纷处理流程 (一) 追溯期：自违规发生的3个月内。
新浪微博商业运营模式的分析-毕业论文
---文档均为word文档，下载后可直接编辑使用亦可打印---摘要互联网的竞争已经不再局限于技术竞争的局面，更重要的是商业模式的竞争。
大部分的互联网企业都是通过融资的手段来获得启动资金，但是并不是说谁的资金量越多越好，每一个企业都应将可持续盈利为最终目标，因此谁拥有好的商业模式谁就会抢先一步发展。
如今，微博在社会产生的巨大影响力大家有目共睹，但是发展到现在微博还没有一个比较清晰的商业模式，使得许多投资者对其失去耐心，这种状况对微博的发展很不利，因此对微博的商业模式的研究具有重要的意义。
新浪微博是新浪推出的门户类微博服务，其也是国内最早推出该服务的门户类网站。
自2009年8月推出以来其凭着成熟的推广策略迅速成为国内最大的社交媒体平台，2011年初，新浪微博初步完成其用户的积累，开始其商业模式的第二个阶段—商业布局，并开始盈利模式的探索。
本文通过对新浪商业模式的研究，意在对新浪微博的发展提供建议，为媒体社会化尽一份微薄之力。
以新浪微博为研究对象，首先分析了微博的概念、特点、新浪微博的商业模式的体系构成。
其次从纵向和横向两个维度对新浪微博的商业模式进行分析，最后指出新浪微博的不足点并提出改善的意见。
关键词：微博；商业模式；社会化媒体；对策ABSTRACTThe competition of the Internet is no longer confined to the technology competition,more important is the business model competition.Most of the Internet companies are starting to get capital by means of financing,but not to say that the more amount of money who is better,every enterprise should be sustainable profit as the ultimate goal,so who has a good business model who will be the first step.Now,the huge influence of the micro-blog produce in society all obvious to people but to now,micro-blog has not been a clear business model,making many investors lose patience on this situation,the development of micro-blog is very unfavorable,so the research on the business model of micro-blog has important.Sina micro-blog is micro-blog service portal launched by Sina,which is also the first to launch the service portal site.Since its launch in August 2009 the Relying on mature promotion strategy quickly became the largest social media platform,at the beginning of 2011,Sina Weibo initially completed the user accumulation,started its business model in the second stage,commercial layout,and begin to make a profit mode of exploration.In this paper,through the Sina business model research,intended to Sina Weibo development provides suggestions for social media as a modest force.To Sina Weibo as the research object,the first analysis of the micro Boconcept,characteristics,Sina microblog business model constitute the system.Secondly,from the vertical and horizontal two dimension on Sina Weibo business model analysis,finally,it is pointed out that sina Weibo and puts forward improved opinions.Keyword：Micro-blog；business model；social media；countermeasure目录新浪微博商业运营模式的分析一、新浪微博发展现状（一）新浪微博发展产生的背景1.微博的定义2.国外微博的发展状况3.国内微博发展状况（二）新浪微博发展的历程二、新浪微博的商业运营模式分析（一）新浪微博商业模式纵向分析1.新浪微博初创期2.圈地时期3.商业布局时期（二）新浪微博商业模式横向分析1.用户维度（1）目标群体定位（2）使用渠道2.产品维度（1）用户价值产张（2）核心能力3.盈利维度（1）合作伙伴网络（2）收入模型（三）新浪微博商业模式运作步骤1.新浪微博商业运营步骤2.新浪微博商业运作模式（四）新浪微博的作用、价值分析1.新浪微博在传播新闻的、信息的作用2.新浪微博在个人、企业、机构宣传中的作用3.新浪微博在时事、突发事件中的作用4.新浪微博在政府机关的作用三、新浪微博在中国未来发展的对策与建议1.提高意见领袖的参与度2.提高用户的媒介素养3.提高运营商的“信息”把关能力4.完善微博管理的法律法规绪论（一）选题背景2006年博客技术先驱埃文·威廉姆斯创办了Obovious公司并推出了Twitter 服务，它的出现标志着微博的诞生。
《人民日报》官方微博的媒体框架研究
《人民日报》官方微博的媒体框架研究摘要：本文以框架理论为基础，结合当下微博的发展现状，对@人民日报进行媒体框架研究，考察其内容特点和传播策略，揭示出其媒体框架，并指出其在微博运营方面存在的问题。
关键词：媒体框架《人民日报》官方微博微博运营美国著名社会学家戈夫曼（Goffman）认为，框架是人们用来阐释外在客观世界的心理模式;框架能使我们确定、理解、归纳、指称事件和信息。
媒体框架起作用的过程，就是媒体通过选择新闻事实形成媒介议题，使某些事实凸显出来，进而影响人们对现实问题重要性的认识。
媒体微博可以看作是媒体在微博平台上的延伸，微博生产者在媒体的特定框架下选择、强调或重组新闻事件和其他信息，利用微博的方式对材料进行组合，使之在微博上体现媒体赋予的意义，并影响微博“粉丝”对该事件或信息的诠释。
因此，对媒体微博的框架分析有助于解读其运营策略和传播效果。
笔者选取《人民日报》官方微博在2014年1月1日至3月31日期间发布的4954条微博作为分析样本（所有数据选取时间截至2014年5月9日15：00），对微博的主题、类型、发布时段和发布形式等13个方面进行量化研究，并对微博的语言表达进行文本分析，以期揭示其媒体框架。
一、《人民日报》官方微博的传播策略1.多样化主题呈现主流媒体风格，温情类内容塑造亲民形象。
@人民日报发布的微博呈现出主题多样化的特征（见表1）。
同时，在主题分布上又有所侧重，社会民生、国际新闻和时事政治主题微博占据了其发布总数的一半以上，符合主流大报的角色定位。
为了转变严肃、刻板的形象，@人民日报还增加了百科知识和人生哲理主题的比重，关注了微博年轻“粉丝”的生活和情感需求。
2.通过设置微栏目整合信息，依据受众习惯平衡发布节奏。
微博平台海量、即时的信息传播带来了便捷性，同时也引起了信息泛滥和传播低效的问题。
为此，@人民日报设置微栏目来有效地整合信息。
统计发现，新闻报道类的数量占样本总数的一半以上（58.0%），其次为观点评论类（25.2%）、生活服务类（13.0%）、网友互动类（3.6%）以及其他（0.2%）。
大V平台的商业化模式与治理——以新浪微博为例
“大V”平台的商业化模式与治理——以新浪微博为例摘要：随着近几年互联网技术的发展，微博、微信的发展如日中天，移动互联网时代已经到来。
“大V”是身份获得认证的微博意见领袖，在网络上具有极强的影响力，这无疑成为企业在社交媒体上进行商业宣传推广的强大平台。
但是一个新兴的平台，需要有效的监管与治理，才能更好地长远发展。
通过介绍新浪微博“大V”平台的商业化模式运作机制，分析平台存在的一些问题，并提出相应的治理对策。
关键词：新浪微博“大V”平台商业化模式治理21世纪，中国已经进入移动互联新时代。
自2009年8月新浪推出“新浪微博”以来，微博以一种不可阻挡的趋势在网民中火热蔓延，截止2013年上半年，新浪微博注册用户数就达到5.36亿，这一数字至今还在扩大。
新浪微博是一个集信息传递、即时新闻、娱乐、反腐、社交等为一体的服务平台，它不仅是普通网民发表自己意见的平台，更是网络“大V”名人与大众沟通交流、信息共享、传达意见的纽带，“大V”也逐渐开始担当起舆论领袖的作用。
微博“大V”平台到底是怎么样的呢？一、微博“大V”平台“大V”是指在新浪、腾讯、网易等微博平台上获得个人认证，拥有众多粉丝的微博用户。
由于经过认证的微博用户，在微博昵称后都会附有类似于大写的英语字母“V”的图标，因此，网民将这种经过个人认证并拥有众多粉丝的微博用户称为“大V”，通常把粉丝数量在50万以上的微博用户称为“网络大V”。
这些网络“大V”主要是由各界名人、明星、学者等组成，如成龙、潘石屹、李开复等微博用户都是新浪微博“大V”的一员。
中国的“大V”是一个构成非常繁杂的群体，有不同的类型，他们覆盖的人群其实也是很不同的。
每个“大V”都有自己的主攻话题点，不同的粉丝根据自己的兴趣爱好就会关注不同的“大V”。
“大V”的粉丝数量多，自然就成为了普通网民追捧的对象，甚至许多“大V”的粉丝都是数以百万或者数以千万计，他们在微博传播中具有重要的影响力。
比如“大V”的每一条更新的微博都会引来无数的转发或评论，而他们的每一次转发又或者是一次评论，都会使得一条微博迅速变火或者走红。
微博管理方案
微博管理方案随着互联网的快速发展，微博逐渐成为人们交流、分享信息的重要平台。
然而，微博的管理成为一个迫切需要解决的问题。
本文将提出一种有效的微博管理方案，以解决微博中存在的问题。
第一部分：用户认证为了确保微博上发布的内容真实可信，我们建议引入用户认证机制。
用户可以通过提供身份证明或其他相关证明来申请认证，并获得一个认证标识。
认证用户可以享受更多的权限和特权，例如发布广告、参与有奖活动等。
这不仅能够保护用户的利益，还能提高微博平台的整体品质。
第二部分：内容审核微博平台应设立专门的内容审核团队，对用户发布的内容进行审核。
审核团队应具备丰富的经验和专业知识，能够准确判断微博内容是否违规。
对于有违规行为的内容，应及时删除或进行相应的处理。
同时，应建立举报机制，鼓励用户积极举报违规行为，以便快速处理问题。
第三部分：社区管理为了保证微博社区的健康发展，我们建议加强社区管理。
首先，建立完善的用户举报机制，鼓励用户积极参与社区管理并举报违规行为。
其次，增加人力投入，加强对高风险区域或热门话题的监控，及时发现并处理问题。
此外，还可以设立评审团队，定期或不定期对用户发布的内容进行审核，保障社区的秩序和安全。
第四部分：用户教育与引导为了提高用户的素质和意识，我们应加强用户教育与引导。
微博平台应定期发布关于网络安全和法律法规的宣传资料，提醒用户遵守相关规定。
同时，针对常见的违规行为，如谣言传播、恶意攻击等，可以发布相关案例并加以解析，引导用户正确使用微博，培养良好的网络行为习惯。
第五部分：技术手段和功能优化除了人力管理，微博平台还可以采用一些技术手段和功能优化来加强管理。
例如，可以引入自动过滤系统，对敏感词汇或违规信息进行自动识别和封禁处理。
此外，可以对用户行为进行分析和统计，根据用户信用度和活跃度，对不同用户实施不同的管理策略。
结语：微博作为一个重要的社交平台，管理方案的完善至关重要。
通过用户认证、内容审核、社区管理、用户教育与引导以及技术手段和功能优化的综合应用，我们可以有效解决微博管理中存在的问题，提升微博平台的整体品质和用户体验。
新浪微博社区管理规定
新浪微博社区管理规定（试行）第一章总则第一条为维护新浪微博社区秩序，更好的保障用户合法权益，新浪微博社区管理中心（以下统称“站方”)根据现行法律法规及《新浪微博社区公约(试行)》，制定本规定。
第二条新浪微博用户在本平台的活动不得违反现行法律法规。
本平台将按照相关法律法规及用户注册协议，配合司法机关维护被侵权人合法权益。
第三条站方负责本规定的解释及执行。
第二章基本原则本规定通过以下基本原则，保障执行过程中的公正与透明：第四条本规定适用于新浪微博所有用户。
第五条完成真实身份验证的用户，可通过新浪微博提供的“举报”功能对违规行为进行举报。
完成真实身份验证的用户包括：个人认证用户、机构认证用户、微博达人、绑定手机或其他完成身份验证的用户。
第六条站方对用户举报的受理条件公开透明。
第七条对于可明显识别的违规行为，由站方直接处理；其他违规行为，由社区委员会判定后处理。
站方服从社区委员会的判定结果。
第八条违规的判定、处理公开透明。
用户可查阅除危害信息外任何违规的处理过程(自受理之后到完成处理)。
查询范围包括已完成处理的和正在处理的。
第三章社区委员会第九条社区委员会由公开招募的微博用户构成。
第十条社区委员会分为两类：判定用户纠纷的普通委员会，判定不实信息的专家委员会。
第十一条普通委员会成员总数量为5000名至10000名，专家委员会成员总数量为1000名至1500名。
第十二条在涉嫌违规行为的判定中，社区委员会在时限内以多数决的方式，形成判定结果，站方据此完成处理。
第十三条普通委员会报名及审核条件：(一) 完成真实身份验证的个人用户。
包括：个人认证用户、微博达人、绑定手机或其他完成身份验证的用户。
(二) 年满18周岁。
(三) 注册时间大于180天，发布微博数量大于100条。
(四) 粉丝数大于50。
(五) 最近一个自然月里15天有登录行为。
(六) 按报名顺序选取。
第十四条专家委员会报名及审核条件：(一) 具有公开身份和一定权威性的个人认证用户和机构认证用户。
政府机构官方微博管理与考核办法
政府机构官方微博管理与考核办法(针对独立官博)政务微博是政府部门和公务人员进行政府信息公开、应对网络舆情、开展政民互动以及网络问政的重要手段和平台，在促进政府与民众沟通、改善政府形象和推进社会管理创新等方面具有重要的作用。
为加强新浪政务微博的规范管理，促进政务微博健康发展，新浪微博现推出《政府机构官方微博的管理与考核办法》，“办法”分“针对独立官博”与“针对微博群”两个版本，此版本将详细解析独立的政务微博官博的管理与考核办法。
第一部分：政府机构官方微博管理办法一、明确组织机构1. 明确政务微博主管领导。
2. 成立政务微博工作小组，明确组长、小组成员。
3. 各部门（单位）分别确定一位微博事务主管领导和一名联络员，具体负责本部门（单位）的微博工作。
4. 建立网评员队伍，网评员为各区县乡镇、各相关部门（单位）的工作人员。
5. 建立专家队伍，专家队伍由行业相关专业人员组成。
6. 建立第三方服务团队。
二、明确各部门（单位）基本职责1. 政务微博主管领导：应当坚持每日阅读本单位政务微博博文，为微博工作总体规划把关，制定改进工作意见，审核涉及重大事件的微博。
2. 政务微博各管理（单位）主管领导：应负责策划针对本部门（单位）的微博话题、内容审核、审查敏感话题回应等。
3. 政务微博小组：负责搜集内容、撰写编排、策划活动、实时审查、发现舆情、掌握动向、问题督办、记录日志、存档备案、参与学习等。
并应同时设置专人专岗，安排内容编辑、形象设计、数据评估、活动策划专职人员。
4. 下属各处室、分局、委属单位联络员：需围绕本部门（单位）工作职责编写微博，协助监测舆情，根据政务微博小组的督办需求开展工作，与相关专家沟通等。
5. 网评员：对本单位已发布的微博进行点评、转发，积极参与各类讨论，并协助监测本单位相关舆情，及时回复。
6. 专家：需经常配合单位的微博及相关工作，参与微访谈，协助处理突发事件等。
7. 第三方服务团队：提供技术支撑，做好图片视频编辑、活动执行、后台技术维护等。
新浪微博政府版介绍及使用说明
“粉丝数、发博量、 回复数、影响力”等
数据统计及排行
微博考核 指标设定
一键建群 群发通知
调用私密群 各种功能
【后台| 管理平台| 多账号管理功能说明及使用方法】
新浪微博政府版，允许您邀请最多6个管理员，帮您共同管理您的微博；同时，您可以自行设定单一管理员 的权限（代发微博、代发评论、代处理@提到我的），方便丌同的管理员去做账号的与向维护。
2弹出的新窗口将带您去到自定义设置页面，点击“使
用背景图”后，“浏览”两个字亮起，点击“浏览”，从 您的电脑中选择图片（建议图片尺寸为1280*900，大小 丌超过5M的图片） 选择图片后打开，背景图上传成功，点击保存如下图Leabharlann 1如下图所示选择自定义背景图
3保存后自劢跳转到您的主页，即其他用户看到您页面
此外，在任意位置，点击账号头像、昵 称等相关信息，即可进入到新浪微博政 府版主页页面。
【入口| 管理后台入口】
当您升级成为政府与业版微博，并丏登陆新浪微博网页版后，您会发现，在您的个人首页页面上，出现 一个“与业版用户访问管理后台”窗口，点击即可进入管理后台页面。
点击
【前台| 模块总体介绍 】
展示模块
关联微博聚合，多账号整合传播：
您可以将丌同的关联微博集中添加到一个模块中，并丏设置 在主页显示，当用户到达您的微博主页时，能同时看到不政 府相关的横/纵向机构、官员和公务人员的微博头像，并选 择关注，展开更深入地沟通。
【前台| 展示模块| 地图使用说明】
新浪微博政府版，允许您在“我的主页”中，随心调整您的模块设置，您可以编辑戒者隐藏相关展示模 块。（以下我们就地图模块丼例说明，视频、图片等操作方法可参考地图模块）
【前台| 互劢模块| 活劢使用说明】
新浪微博单独上路 业务架构调整
新浪微博单独上路业务架构调整来源: 一财网发布时间：2013-01-11 名噪一时的新浪MBO，现在看来只是一场财务游戏。
要想微博获得更大成功，曹国伟要做的事太多了。
留给曹国伟的时间已经越来越紧迫了。
2012年快结束时，所有新浪员工都收到了一封这位CEO发出的邮件。
除了新年祝福，他还确认了新浪组织架构的又一次调整。
新浪的业务架构被分为了门户和微博两大部分，曹国伟本人继续担任CEO，但会把更多的精力放在微博业务上—新任新浪微博负责人王高飞将直接向曹国伟汇报；COO杜红则负责新浪门户业务。
王高飞原为新浪无线事业部负责人，在这次调整中，新浪无线事业部被并入了新浪微博事业部。
原新浪微博事业部负责人彭少彬则负责新的产品创新部门。
在这封邮件发出之前，新浪刚刚经历了一次“被换帅”风波，杜红将接替曹国伟的说法一度被传得有板有眼：过去一年，令人眼花缭乱的微博“商业化”的探索没有获得多大起色，新浪的股价已经再次回到了低点，而曹国伟应该对此负责。
这次风波反映出，新浪正错过一次历史上最好的时机。
它是在2009年由曹国伟、杜红等管理层完成MBO（管理层持股 Management buy out）所带来的。
当时，曹国伟等6位高管以1.8亿美元购买了新浪10%的股权，成为第一大股东。
由于新浪在历史上一直处于股权分散的状态，曹国伟的这一举动被人们认为是将新浪带入了一个新的时期。
现在看起来，这个新时期仅仅维持了两年多的时间。
当6位管理人员完成了持股、新浪股价冲上历史最高点时，它也开始了缓慢的回落。
成功MBO之后的管理层，一直在持续抛售自己所拥有的股份。
最近一次的SEC文件显示，由曹国伟本人持有，以及其它5位高管通过曹国伟代持的新浪股份，已经降到了4.8%。
从资本游戏的层面看，这是一次几近完美的行动。
MBO所需资金，多为中信资本、美林证券等机构提供的借款，曹国伟等人借助新浪股价高企的时机让“债主”们套现离场，自己也获得部分好处，或许也无可厚非。
浅议社交网络的分析工具——以新浪微博、微信为例.pdf
·160·经营者浅议社交网络的分析工具——以新浪微博、微信为例艾 婧首先，我们应该建立一个系统的分析框架，明确这个框架很重要，我们要有意识地形成社交网络关系与信息的布局，其中，关系是根本，它对信息发展有直接或间接的作用。
只有通过系统的视角才能更清晰地掌握社交网络的整体脉络，了解在不同的关系框架下，不同的信息是如何传播与反馈的，并且通过关系与信息工具来分析社交网络的整体布局构造。
其次，从关系的角度来看，在社交网络中，人们对关系的需求，主要表现在建立和维护这两个方面，通过划分关系强度来了解不同网站之间的关系；从信息的角度来看，信息传播方式通过关系框架的建立而确定，在某些方面，关系框架不仅决定信息的流向，还在某些方面决定信息的开放度以及内容分类等。
一、三个关系分析工具“三个关系分析工具”指的是社交网络“关系强度”“关系需求”“关系模式”的比较分析工具。
（一）“关系强度”分析工具关系强度，简单来说被划分为强、中、弱，强度是不断变化的。
这是一个非常重要的概念，因为作为社交网站的基础，关系强度往往影响各大社交网络的建立与发展。
一般来说，关系强度较弱指偏虚拟化，关系强度较强指偏现实化。
以信息流为主体的社交网络，关系强度较弱。
第一，以新浪微博为例，在使用期间，用户可以彼此互相关注，因此这种关系是偏弱的，但与此同时，也有一定比例的强关系存在，在发展初期，关系强度较强的关系不会超过较弱的关系。
第二，以Facebook 为例，Facebook 使用期间，以同学、朋友等现实关系为主，因此是强关系为主的关系强度。
第三，以微信、腾讯QQ 为例，主要是以“朋友圈”来区分关系，譬如腾讯QQ 系统会向客户推荐适合客户圈子的群或公众号，由此可见这是强关系与弱关系并存的，用户把不同类别的关系放在不同的朋友圈中去管理。
第四，不同的社交网络，其内部的关系强度，是有所差别且具有自己的偏重摘 要 社交网络源自英文SNS 的翻译，中文直译为社会性网络服务或社会化网络服务。
- 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