亿级用户下的新浪微博平台架构
产品需求-新浪微博用户等级体系分析
新浪微博用户等级体系分析，用户可以通过访问这个页面，查看自己的等级，并了解等级升级规则。
笔者拿自己的一个帐号观察发现当前等级已经是LV6，而不是LV0/1。
说明这个前两年等级计算可能之前就已经存在，一直在后台计算数据，只是从未向用户演示过而已。
通过上面截图，我们可以得到，微博等级包含以下几个表现形式：1.当前等级2.活跃天数3.等级计算规则4.升级剩余天数，可以在页面中看到每个等级level对应的基本逐渐活跃天数需要，还可以看到非常活跃天数的累积规则：可以看到活跃平均值的看到获得有三种方式：1.登录后在线时长2.发表微博奖励3.连续登录奖励好吧，这里暂且成长是否参考了其他公司或产品的用户等级激励不谈体系，但是从这里的计算规则来看，这里还是费了一番心思的——在提高用户活跃度上有很多思考和动作。
那么现在新浪微博上是否只有这一种用户激励成长体系呢?下面就确知的几种激励，做一个简单的梳理。
1.V认证用户：新浪微博在最早推出的时候，就拥有了V认证用户，一度，那个黄色的小V让无数人竟折腰。
在某种场合，加V用户自夸俨然是一种炫耀的资本，尤其是一些小有名气又不太知名权威人士的社会人士，一度将微博作为提升自身形象和知名度的一个重要途径。
因为加V代表着身份，代表着话语权，代表着是少数的人则，代表着“精英”身份……但最近和老朋友聊天，已经有很多朋友陆续说加V已经不值钱了，甚至有的想去V。
记得最早听说加V的条件是——500总和人以上公司总监级别人士才可以凭借身份证明重要信息加V认证。
但是目前仍然经常看到以下某某公司销售、某某公司运维字样的认证某时描述，此时笔者当更愿意相信加V认证已经变成一种很贴近草根的注重用户激励方式。
2.微博达人：这应该是最早面向草根的用户激励草根体系吧，根据官方显示的能够帮助资料，达人只需顾及一定条件如：绑定手机、真实头像、粉丝数达到100等即可申请。
而且具有完整的系数和升级规则——但貌似这一规则没有在网站上公示，我们只找到以下一段手写：“达人积分是根据作为微博达人在微博上的活跃度(登陆、发原创微博、评论)和社区产品活跃度(微群、活动)的使用情况和积分规则，系统自动统计计算出来的，可以在对个人微博首页(我的微博)页面查询，达为也可以在微博达人首页查询“。
6大科技公司组织架构
封面作者：PanHongliang仅供个人学习6月，Web设计师Manu Cornet在自己的博客上，画了一组美国科技公司的组织结构图。
在他笔下，亚马逊等级森严且有序。
谷歌结构清晰，产品和部门之间却相互交错且混乱。
Facebook架构分散，就像一张散开的网络。
微软内部各自占山为王，军阀作风深入骨髓。
苹果一个人说了算，而那个人路人皆知。
庞大的甲骨文，臃肿的法务部显然要比工程部门更加重要。
真是一组有趣的图，它很快风靡网络。
6月29日，它传入中国，在新浪微博上被转发了一万多次。
据此，《第一财经周刊》也尝试着炮制了一份中国主要的科技公司的结构图—百度、腾讯、华为、联想、阿里巴巴、新浪。
结果发现，它们也是彼此风格迥异。
不同的公司成长历史、不同的业务架构和不同的管理风格，让它们的架构图也呈现出明显的不同。
华为：华为与很多强调组织结构稳定的企业不同，华为建立的是一种可以有所变化的矩阵结构。
换句话说，华为每次的产品创新都肯定伴随组织架构的变化，而在华为每3个月就会发生一次大的技术创新。
这更类似于某种进退自如的创业管理机制。
一旦出现机遇，相应的部门便迅速出击、抓住机遇。
在这个部门的牵动下，公司的组织结构发生一定的变形—流程没有变化，只是部门与部门之间联系的次数和内容发生了变化。
但这种变形是暂时的，当阶段性的任务完成后，整个组织结构又会恢复到常态。
阿里巴巴：你能想象没有马云的阿里巴巴吗?尽管2007年阿里巴巴B2B业务上市后，马云开始练太极、习道学、悟阴阳，但是，在阿里巴巴马云的影子似乎无时无处不在。
现在，他又向公众展示了一条完美的产业链。
万网提供域名，并量身定制出两套网站—B2B和B2C，再通过阿里巴巴网站和淘宝商城、淘宝集市三大平台，精确对接细分用户。
散在全国的7个百万平方M以上的阿里大仓、若干个小仓，由物流宝打通的从供应商到阿里大小仓直至用户之间的物流数据流，囊括大阿里战略中所有的业务。
而马云，正如他自己所说，“已经融化在这家公司里。
亿级用户下的新浪微博平台架构
团队职责
• 业务模块化、 • 提供标准化 服务化 的技术框架 • 业务流程优 • 解决系统高 化 并发、高可 • 业务容量评 用、高可扩 估 展问题
1. 平台组织架构（物理）与技术体系（逻辑）从无缝结合，提 高了团队协作的效率，降低了沟通成本。 2. 12个区间分别聚焦于各自的侧重点，指明长期的发展方向。
Web（JS、CSS、HTML） Android iPhone
接入层
Web（php）
MAPI
Push 网关
后台
搜索
微博平台（Java）
大数据
平台架构演变
2009 - 2010
2011 - 2014
2014 – 将来
节点B rpc1
SR SS
CS
SR
节点D rpc3
4节点模型： CS = Client Send SR = Server Receive SS = Server Send CR = Client Receive
亿级用户下的新浪微博平台架构
@卫向军_微博
Agenda
1. 微博的技术架构 2. 微博平台的技术挑战 3. 微博平台架构演变与第三代技术架构体系 4. Watchman-分布式服务追踪系统 5. Feed多级双机房缓存系统 6. 致谢
微博技术架构
客户端
流量切换
5
RPC MCQ 短链 用户 发号器 Config
8
服务状态
11
服务依赖
服务层
调用链
发布和灰度
3 资源层
MC HBase
6
Cache组件
9
Error
12
扩容与缩容
新浪微博架构与平台安全演讲稿
• 重新思考 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、政府信息化总体情况随着信息技术的迅猛发展，特别是互联网技术的普及与应用，推进政府部门办公自动化、网络化、电子化以及全面信息共享已是大势所趋。
2011年2月19日，某某在某党校省部级主要领导干部社会管理及其创新专题研讨班开班式上提出“进一步加强和完善信息网络管理，提高对虚拟社会的管理水平，健全网上舆论引导机制。
”2011年5月30日中共某政治局召开会议，某再次强调，要“完善信息网络服务管理，营造良好社会环境”。
党的“十七大”报告中提出，要“全面认识工业化、信息化、城镇化、市场化、国际化深入发展的新形势新任务，深刻把握我国面临的新课题、新矛盾”，说明某对信息化给予了高度的重视。
2013年10月15日，《国务院办公厅关于进一步加强政府信息公开回应社会关切提升政府公信力的意见》发布，意见从平台建设、机制建设和保障措施方面提出要求。
其中要求，各地区各部门应积极探索利用政务微博、微信等新媒体，及时发布各类权威政务信息，尤其是涉及公众重大关切的公共事件和政策法规方面的信息，并充分利用新媒体的互动功能，以及时、便捷的方式与公众进行互动交流。
同时中还明确要求，加强政府信息上网发布工作，以数字化、图表、音频、视频等方式予以展现，使政府信息传播更加可视、可读、可感，进一步增强政府网站的吸引力、亲和力。
由上可见，中国政务信息化在信息化时代中是取得了一定成就的，但也存在着不少需要改进之处。
目前，政府信息系统大多建立在独立封闭的体系中，从而造成了信息服务落后、办公业务事务处理迟缓、信息和技术屏障等问题，这就需要一个无缝的、协同的技术形态，从而建立能够沟通、联动、兼容的移动政务平台。
2、微信公众平台微信是腾讯公司推出的一款通过网络快速发送语音短信、视频、图片和文字，支持多人群聊的手机软件，具有零资费、跨平台沟通、显示实时输入状态等功能，也更灵活、智能，且节省资费。
微信公众平台是腾讯公司在微信的基础上新增的功能模块，这一平台的一大特点在手机订阅账号，用户在使用过程中仅需通过自主“关注”“订阅”，信息就可直达用户的手机桌面，更适合“一对一”的精准传递消息。
微博架构方案
-提供微博内容全文搜索，优化用户体验；
-实现实时搜索，提高搜索效率。
四、网络安全与数据保护
1.网络安全
-部署防火墙、入侵检测系统，防止恶意攻击；
-使用安全协议，如HTTPS，保障数据传输安全；
-实施严格的权限管理，防止内部数据泄露。
2.数据保护
-对用户敏感数据进行加密存储和传输；
-分析监控数据，优化系统性能。
六、实施与验收
1.实施计划
-制定详细的项目实施计划，明确时间节点、责任人和验收标准；
-按照实施计划，分阶段推进项目实施；
-组织技术培训，确保项目团队具备实施能力。
2.验收标准
-系统稳定性：确保99.99%的在线时间；
-性能指标：满足业务需求，响应时间不超过500ms；
-数据安全：无数据泄露事件发生；
微博架构方案
第1篇
微博架构方案
一、项目背景
随着互联网的快速发展，社交媒体已经成为人们日常生活中不可或缺的部分。微博作为国内领先的社交媒体平台，为广大用户提供了一个实时信息分享、互动交流的场所。为了满足日益增长的用户需求，保障平台稳定、高效运行，现需对微博平台架构进行优化升级。
二、方案目标
1.提高系统稳定性：确保平台在高并发、高负载情况下，仍能稳定运行，降低故障率。
（2）采用分布式设计，提高系统性能，确保高并发场景下的稳定运行。
（3）引入负载均衡技术，合理分配请求，提高资源利用率。
2.数据库设计
（1）采用关系型数据库存储用户数据，如MySQL、Oracle等。
（2）采用NoSQL数据库存储非结构化数据，如MongoDB、Redis等。
（3）建立合理的索引策略，提高数据查询速度。
大型互联网公司新浪微博技术架构分析与设计
大型互联网公司新浪微博技术架构分析与设计新浪微博，作为当今国内最大的基于社交媒体之一，我们就不用在这赘述了。
今天我站在架构的角度上，从技术跟设计方面给大家通俗的讲一下，如果不对，请指出，我本是事实的角度，一定回承认，改正，谢谢。
12月31日跨年夜，网友再次刷新微博发送峰值。
根据微博方面的数据，2016年第一分钟,微博用户共发出883536条微博，超过去年同期。
跨年期间，相关微博互动量达1.38亿，2947万用户发布4414万条微博，整体阅读量达到106亿。
微博推出的#哈喽2016#新年许愿活动，两天里收集了166万多条网友的新年愿望，阅读量超过3亿。
如此巨大的用户规模和业务量，需要高可用（HA）、高并发访问、低延时的强大后台系统支撑。
微博平台第一代架构为LAMP架构，数据库使用的MyIsam，后台用的php，缓存为Memcache。
随着应用规模的增长，衍生出的第二代架构对业务功能模块化、服务化、组件化，后台系统从php替换为Java，逐渐形成面向服务的SOA架构（面向服务的架构），在很长一段时间支撑微博平台业务发展。
SOA架构在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
我们先看一张微博的核心业务图（如下），是不是非常复杂，但这已经是一个简化的不能再简化的业务图啦，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠的发布新产品新功能。
新浪微博心业务图第三代技术体系微博平台的第三代技术体系，使用正交分解法建立模型，在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层，在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台，接着看一下平台的整体架构图。
第三代技术体系正交分解法将整个图分解为3*4=12个区域，每一个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构，下面详细介绍水平方向与垂直方向的设计原则，尤其重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。
新媒介概论 名词解释
长尾理论（The Long Tail）是网络时代兴起的一种新理论，由美国人 克里斯·安德森提出。长尾理论认为，由于成本和效率的因素，当商品 储存流通展示的场地和渠道足够宽广，商品生产成本急剧下降以至于个 人都可以进行生产，并且商品的销售成本急剧降低时，几乎任何以前看 似需求极低的产品，只要有卖，都会有人买。这些需求和销量不高的产 品所占据的共同市场份额，可以和主流产品的市场份额 相比，甚至更 大。
5 新媒体的边界不断变化呈现出媒介融合的趋势
媒介融合
媒介融合概念的提出始于20世纪80年代的美国。其最简单的定义是将原 先属于不同类型的媒介结合在一起。美国马塞诸塞州理工大学教授I· 浦尔认为，媒介融合就是指各种媒介呈现出多功能一体化的发展趋势。 美国新闻学会媒介研究中心主任Andrew Nachison 将“融合媒介”定义 为“印刷的、音频的、视频的、互动性数字媒体组织之间的战略的、操 作的、文化的联盟”，他强调的“媒介融合”更多是指各个媒介之间的 合作和联盟。 喻国明教授在《传媒经济学》中认为，媒介融合是指报刊、广播电视、 互联网所依赖的技术越来越趋同，以信息技术为中介，以卫星、电缆、计 算机技术等为传输手段，数字技术改变了获得数据、现像和语言三种基 本信息的时间、空间及成本，各种信息在同一个平台上得到了整合，不 同形式的媒介彼此之间的互换性与互联性得到了加强，媒介一体化的趋 势日趋明显。
新媒体
新媒体是新的技术支撑体系下出现的媒体形态，如数字杂志、数字报 纸、数字广播、手机短信、网络、桌面视窗、数字电视、数字电影、触 摸媒体等。相对于报纸、广播、电视、杂志四大传统意义上的媒体，新 媒体被形象地称为“第五媒体”。较之于传统媒体，新媒体自然有它自 己的特点。对此，吴征认为：“相对于旧媒体，新媒体的第一个特点是 它的消解力量——消解传统媒体(电视、广播、报纸、通信)之间的边 界，消解国家与国家之间、社群之间、产业之间边界，消解信息发送者 与接收者之间的边界，等等”。 新媒体必须有革新的一面，技术上革新，形式上革新，理念上革新。同 时，“新媒体”必须具备价值、原创性、效应和生命力。
用户贡献模式案例分析新浪微博
用户贡献模式之新浪微博
微博的基本情况
新浪微博是一款为大众提供娱乐休闲生活服务的信息分享和交流平台 。新浪微博于2009年8月14日开始内测，9月25日，新浪微博正式 添加了@功能以及私信功能，此外还提供“评论”和“转发”功能， 供用户交流。 新浪微博采用了与新浪博客一样的推广策略，即邀请明星和名人加入 开设微型博客，并对他们进行实名认证，认证后的用户在用户名后会 加上一个字母“V”（认证个人字母V为金黄色，认证企业字母V为深 蓝色），以示与普通用户的区别，同时也可避免冒充名人微博的行为 ，但微博功能和普通用户是相同的。 于2009年8月14日开始内测，2009年11月3日，Sina App Engine Alpha版上线，可通过API用第三方软件或插件发布信息。截至2014 年3月，微博月活跃用户1.438亿，日活跃用户6660万，其中包括大 量政府机构、官员、企业、个人认证账号，开放的传播机制使新浪微 博成为中国的“公共议事厅”。
收入和利润ቤተ መጻሕፍቲ ባይዱ源
5）同第三方网站分享流量
根据我们的统计，新浪微博已为第三方网站提供了大量有价值的访问 流量，尤其是对于在线电子商务和在线视频。至少有三种可以是新浪 微博分享流量的方案： 1）第三方网站的官方微博，例如淘宝商城。 2）鉴于新浪微博所采用了开发系统，我们预计使用“分享到新浪”的人 将会增多，而“点击返回”的价值将会带来潜在的盈利机会。 3）与Facebook的购物商城类似，允许第三方合作伙伴开设购物商城。
新浪微博的资本模式
2010年10月11日，新浪为微博注册成立独立公司 ，名为微梦创科网络技术(中国)有限公司，注册资本
2000万美元，法人代表为曹国伟，此前，新浪微博一直
靠总公司新浪的资金支持，成为独立公司之后，新浪微博 将依靠自身的营收来支撑公司运转，当然，新浪也会出资 支。
微博系统架构的可信性研究
■ ｄ ｉ１ ．９ ９ ． ｓ ６ １ １２ ０ １０ ０ ｏ ： ０３ ６ ￣ｉ ｎ１ ７ ． １ ２２ １ ８０ ７ ｓ
的可信性研究
庆 轩
（ 清华大学 ，北 京 １ ０ ８ ０ ０ ４）
摘 要 ：文章 对微博 系统 架构进行 了介绍 ，提 出了新 产生的 问题 及改善 方案。 关 键 词 ：微 博 系统；改善 方案 ；可信性
第一版微博服务一经推出，受到了中国广大网民的充分 认可，最早 的人人 网、开心网、博客和播客等各种社会 网络与交互方
式都没有受 到国内大众 的广泛参与，而微博这个 新事物 ，以它小巧灵便 、快捷 时尚的身姿挤入了继 Ｑ Ｑ、飞信后，国人参与人数
最多的网络服务。随着用户迅速攀升，原先 的 Ｌ ＭＰ架构已经不堪重负，最初的微 博发放 的推拉模式也受到了挑 战。 Ａ
‘ ＼ ＼
旺三圊 Ｅ三 五 回 臣三
据 ，更 新的策略是 Ｌ Ｕ（ 近最少使用 ） Ｒ 最 ，以及每 个 Ｋ Ｖ对的 有效时限。Ｋ Ｖ对存储有效 时限是在 ｍｅ 由 Ａ ｐ 置并作为 端 ｐ设
参数传给 ｍｓ 的。同时 ｍ 采用是 偷懒替代法，ＨＳ ｓ Ｉ 不会 开额外 的进程 来实时监测过时的 Ｋ Ｖ对并删除 ，而是 当且仅 当，新来
一
图１ ｍｅ ａ ｈ 的 应 用 ｍｃ ｃ ｅ
需要注 意的是，Ｍｅ ａ ｈ ｄ使用内存管理数 据，所 以它 ｍｃ ｃ ｅ
是易失 的，当服务 器重 启，或者 Ｍｅ ａ ｈ ｄ进程 中止 时，数 ｍｃ ｃ ｅ 据便会 丢失，所以 Ｍｅ ａ ｈ ｄ不能用来保存持久数据。有很 ｍｃ ｃ ｅ 多人都 有错 误理解 ，认为 Ｍｅ ａ ｈ ｄ的性 能非常好 ，相 对于 ｍｃ ｃ ｅ
新浪微博框架
大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。
最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。
很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。
另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。
今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。
首先给大家介绍一下微博架构发展的历程。
新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。
第一版就是是非常快的，我们可以非常快的实现我们的模块。
我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。
我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。
第一颁的技术细节，典型的LAMP架构，是使用Myisam存储引擎，它的优点就是速度非常快。
另外一个是MPSS，就是多个端口可以布置在服务器上。
为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。
我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。
这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。
如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。
我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。
我们技术上碰到几个问题。
第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。
另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。
电视媒体官方微博的框架比较分析_以新浪微博影响力榜排名前三的.
120现代传播2012年第5期（总第190期电视媒体官方微博的框架比较分析---- 以新浪微博影响力榜排名前三的卫视微博为例■高一然【内容摘要】本文对新浪微博电视媒体影响力榜排名前三的卫视微博进行基于框架理论的内容分析，从微博发布数量、议题、发布方式、发布时间等角度得出三家微博的不同特点和传播状态，以期为更多的电视媒体在微博平台上的发展提供借鉴。
【关键词】微博；电视媒体；框架分析现今，移动互联网、交互媒体成为媒介发展的向好趋势，拥有这些特质的微博已成为当下最热门的新的媒介形式。
电视媒体如今也抓住微博的新媒体传播平台，将自身在电视媒体中的影响力发挥到微博平台，并通过微博用户这一广大的网络平台推动电视媒体的发展。
因此，针对电视媒体发布微博的内容分析，将有助于更深一步了解电视媒体微博的传播状态。
本研究采用基于框架理论的内容分析方法，使用了新浪微博影响力榜2011年12月12日至12月18日的周榜排名数据，将这一周内凤凰卫视”湖南卫视”浙江卫视中国蓝”三个微博账号发布的全部442条微博作为样本。
三家卫视微博基本情况表影响力排名影响力数值人气榜排名粉丝量凤凰卫视1103132341607湖南卫视290342218095浙江卫视中国蓝379181978728截至新浪微博风云人气榜” 201年12月19日11时的数据一、微博发布数量分析1.微博发布总量在12月12日至18日一周内，凤凰卫视、湖南卫视、浙江卫视中国蓝共发布微博442条，数量依次是浙江卫视中国蓝195条、凤凰卫视162条、湖南卫视85 条。
微博发布数量影响着影响力”的活跃度，浙江卫视中国蓝在数量上占优，湖南卫视的微博总量低于其他两卫视微博数量各自的50%。
2.微博被评论、被转发次数与发布总量的关系总量的多少不是影响力的决定性因素，被转发次数与被评论次数关系着影响力”的传播力，即被粉丝追捧的情况，是微博是否能够有效影响受众态度的检验标准，微博被粉丝转发和评论表明受众态度”的认可。
新的微博来了!把数据搭建成货柜,从广场变为超市
新的微博来了！把数据搭建成货柜，从广场变为超市2009年，新浪微博上线，微博在发展初期的主体是一个人与人之间的网络结构，一年之后，许多企业、媒体和机构都看到了微博作为信息传播和沟通平台的价值，纷纷进驻，而到了现在，新浪微博上已拥有470亿条关系链。
如果我们说腾讯的关系链是以人和人为基础建立的、豆瓣的关系链是以人和兴趣为基础建立的、大众点评的关系链是以人和餐厅为基础建立的，那么微博的关系链则十分复杂——个人用户之间、个人用户与大V用户、个人用户与企业/商户……还有这4年间用户行为中积累的的大量人与地点、物件之间的关系链条，使得新浪微博成为了一张错综复杂的关系网。
混乱不堪的数据是没有价值的，于是，在2013年年初，新浪微博内部决定开始从后端到前端对微博进行调整——从后端上，将这些关系型数据结构化，将用户关系、用户行为、企业、物品之间的关系梳理，搭建清晰的链接脉络；从前端上，不仅要让移动终端和Web页面都有统一的功能和架构，而且让人、企业、物品页面都有统一的框架，将关系和数据统一拼装在一个相似的页面体系类，减少以往页面结构的差异化。
在这次调整中，首先与用户见面的是新浪微博在7月31日对“个人主页”的调整。
新浪微博的产品经理刘彬告诉PingWest，这次个人主页升级的核心是突出“个人兴趣”——在如今的个人主页下方，会显示用户的签到地点、赞过的图书和音乐。
而用户也可以在主页的“赞”功能中集中查看这些内容。
刘彬说，这次的改版只是一次初期尝试，接下来他们会让个人页面在形态上产生更多的差异化，来进行个人兴趣展示。
例如，为用户提各类应用库和功能模块，如果我是一个摄影爱好者，那么我可以在自己的主页面上添加图片展示模块，来突出展示我拍摄的照片，如果我是一个音乐爱好者，那么我可以优先展示自己演唱或推荐的歌曲。
在个人页面之外，新浪微博会在10月前完成对不同类型微博账户的分类和调整，其中主要分为媒体微博、本地服务微博、在线商户微博、艺人微博和物品微博。
千万级规模高性能、高并发的网络架构
千万级规模高性能、高并发的网络架构经验分享本文通过介绍新浪微博的平台架构以及核心技术难点，对于大型网站的发展历程提出一系列理论和实际相结合的经验总结。
主要介绍：1.架构以及我理解中架构的本质；2.新浪微博整体架构是什么样的；3.在大型网站的系统架构是如何演变的；4.微博的技术挑战和正交分解法解析架构；5.微博多级双机房缓存架构；6.分布式服务追踪系统；7.总结。
在开始谈我对架构本质的理解之前，先谈谈个人对千万级规模的网站的理解，对这个数量级我们战略上要藐视视，战术上要重视。
先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(Uber)，从媒体公布的信息看，它每天接单量平均在百万左右， 假如每天有10个小时的服务时间，平均QPS只有30左右。
对于一个后台服务器，单机的平均QPS可以到达800-1000，单独看写的业务量很简单 。
为什么我们又不能说轻视它？第一，我们看它的数据存储，每天一百万的话，一年数据量的规模是多少？其次，刚才说的订单量，每一个订单要推送给附近的司机、司机要并发抢单，后面业务场景的访问量往往是前者的上百倍，轻松就超过上亿级别了。
我想从架构的本质谈起，希望大家理解在做架构设计的时候，从什么出发点开始，解决的什么样的问题。
架构，刚开始的解释是我从知乎上看到的。
什么是架构？有人讲，说架构并不是一个很悬乎的东西，实际上就是一个架子，放一些业务和算法，跟我们的生活中的晾衣架很像。
更抽象一点，说架构其实是对我们重复性业务的抽象和我们未来业务拓展的前瞻，强调过去的经验和你对整个行业的预见。
我们要想做一个架构的话需要哪些能力？我觉得架构师一个最重要的能力就是你要有战略分解能力。
这个怎么来看呢，第一，你必须要有抽象的能力，抽象的能力最基本就是去重，去重在整个架构中体现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重提高可复用率。
第二，分类能力。
做软件需要做对象的解耦，要定义对象的属性和方法，做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范。
新浪微博单独上路 业务架构调整
新浪微博单独上路业务架构调整来源: 一财网发布时间：2013-01-11 名噪一时的新浪MBO，现在看来只是一场财务游戏。
要想微博获得更大成功，曹国伟要做的事太多了。
留给曹国伟的时间已经越来越紧迫了。
2012年快结束时，所有新浪员工都收到了一封这位CEO发出的邮件。
除了新年祝福，他还确认了新浪组织架构的又一次调整。
新浪的业务架构被分为了门户和微博两大部分，曹国伟本人继续担任CEO，但会把更多的精力放在微博业务上—新任新浪微博负责人王高飞将直接向曹国伟汇报；COO杜红则负责新浪门户业务。
王高飞原为新浪无线事业部负责人，在这次调整中，新浪无线事业部被并入了新浪微博事业部。
原新浪微博事业部负责人彭少彬则负责新的产品创新部门。
在这封邮件发出之前，新浪刚刚经历了一次“被换帅”风波，杜红将接替曹国伟的说法一度被传得有板有眼：过去一年，令人眼花缭乱的微博“商业化”的探索没有获得多大起色，新浪的股价已经再次回到了低点，而曹国伟应该对此负责。
这次风波反映出，新浪正错过一次历史上最好的时机。
它是在2009年由曹国伟、杜红等管理层完成MBO（管理层持股 Management buy out）所带来的。
当时，曹国伟等6位高管以1.8亿美元购买了新浪10%的股权，成为第一大股东。
由于新浪在历史上一直处于股权分散的状态，曹国伟的这一举动被人们认为是将新浪带入了一个新的时期。
现在看起来，这个新时期仅仅维持了两年多的时间。
当6位管理人员完成了持股、新浪股价冲上历史最高点时，它也开始了缓慢的回落。
成功MBO之后的管理层，一直在持续抛售自己所拥有的股份。
最近一次的SEC文件显示，由曹国伟本人持有，以及其它5位高管通过曹国伟代持的新浪股份，已经降到了4.8%。
从资本游戏的层面看，这是一次几近完美的行动。
MBO所需资金，多为中信资本、美林证券等机构提供的借款，曹国伟等人借助新浪股价高企的时机让“债主”们套现离场，自己也获得部分好处，或许也无可厚非。
新浪微博架构猜想
新浪微博架构猜想定时轮询服务端，获得几分钟之后：采用Jsonp的方式STK_*****这些js中的callback的方法是动态生成的进入页面：直接获得html代码，应该是采用了全页面缓存这里面缓存的是页面的feed，不缓存好友数，头像这些，这些还是通过XHR来获得的动态页面部分静态化点击微博：出现的也是通过content cache过的这里面没有显示粉丝数，关注数，以及每个feed的评论、转载数，根据新浪微博架构的描述，这些是动态变化的，如果这个也缓存，用户体验以及准确度都达不到要求，老是变动会失去缓存的意义，所以，这些是通过XHR去服务端请求的，如下图：点击粉丝：点击关注采用的技术和点击微博一样，全页面缓存PS：为什么新浪微博更新（新发表，评论，好友数等），需要手工去点击？因为新浪微博采用了全页面缓存的方式，点击的动作刚好触发去做整个页面缓存。
评论：直接返回的是评论内容的HTML，避免页面渲染轮询feed轮询回来的结果通过STK这个方法，来判断是否有更新，如果都为0，则不更新，否则提示有新的更新，然后让用户点击。
返回的是是否有新的评论，新的feed数，可见服务端肯定保存了我当前获得的那条最新记录数，应该是放在vector cache（feed id list）中，架构：To Push or to pull It’S a question新浪采用了什么技术来实现这个最核心的问题的呢？Feed架构Push：简单，但是当量打的时候，则分发到所有粉丝那边就变得比较麻烦，如小潘同学这种微博控，粉丝数有250w+，他发一条消息，如果采用push，简直就是自虐嘛Pull：存储量少，但是要在线进行计算，比如我有40个关注的对象，那我每次需要把40个人的feed都拿出来，然后根据时间进行排序，而且翻页也有问题，所以基本上纯pull不太靠谱新浪应该是采用复合型的方式，push+pullRead：首先读inbox，然后在获取关注列表，然后读取关注列表中的outbox，最后信息进行聚合，生成新的inbox的vector cache当第一次的时候，inbox的hot cache为空，则从所有关注列表的outbox的vector cache中获得id，然后进行聚合，最后生成一个新的inbox 的hot cacheWrite：每个在线用户生成一个inbox，然后当关注的人发表一条微博的时候，会向这个人的inbox中插入一个id，格式如：feed{1,2,3,4…100}，这样可以减少所有用户那边插入数据，又可以减少计算的代价Cache前面的Inbox和outBox和索引比较类似，只存储了feed的id列表Social graph这个就是列表和用户的资料最后一个是内容缓存，比如热门的那些内容放到hotCache中，还有就是全页面缓存以及预热生成json和xml给openAPICache 结构第一部分就是inbox：微博我的首页开始的ID列表，完全是内存里面，但是有一个缺点，我们要添加元素需要先GET再SET第二部分outbox发出微博有存储最新ID在于聚合（key为自己）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
亿级用户下的新浪微博平台架构
架构之路（系列三）卫向军新浪微博
引言
新浪微博在2014年3月公布的月活跃用户（MAU）已经达到1.43亿，2014年新年第一分钟发送的微博达808298条，如此巨大的用户规模和业务量，需要高可用（HA）、高并发访问、低延时的强大后台系统支撑。
微博平台第一代架构为LAMP架构，数据库使用的MyIsam，后台用的php，缓存为Memcache。
随着应用规模的增长，衍生出的第二代架构对业务功能模块化、服务化、组件化，后台系统从php替换为Java，逐渐形成面向服务的SOA 架构，在很长一段时间支撑微博平台业务发展。
在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
我们先看一张微博的核心业务图（如下），是不是非常复杂，但这已经是一个简化的不能再简化的业务图啦，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠的发布新产品新功能。
第三代技术体系
微博平台的第三代技术体系，使用正交分解法建立模型，在水平方向，采用典型的三级分层
模型，即接口层、服务层与资源层，在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台，接着看一下平台的整体架构图。
如上图所示，正交分解法将整个图分解为3*4=12个区域，每一个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构，下面详细介绍水平方向与垂直方向的设计原则，尤其重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。
水平分层
水平维度的划分，在大中型互联网后台业务系统的设计中非常基础，在平台的每一代技术体系中都有体现，这里还是简单介绍一下，为后续垂直维度的延伸讲解做铺垫：
接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（Feed）服务、用户关系服务以及通讯服务（单发私信、群发、群聊）。
服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类，图中使用泳道隔离，表示它们的独立性，另外一类为组合服务，通过各种原子服务和业务逻辑的组合，完成的Composite服务，比如Feed服务、通讯服务除了本身的业务逻辑，还依赖于短链、用户、以及发号器服务。
资源层主要数据模型的存储，包含通用的缓存资源Redis和MC，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。
水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。
与分层模型对应的，微博系统中的服务器主要包括三种类型：前端机（提供API 接口服务），队列机（处理上行业务逻辑，主要是数据写入），存储（mc、mysql、mcq、redis 、HBase 等）。
垂直延伸技术架构
随着业务架构的发展和优化，平台研发实现了许多卓越的中间件产品，用来支撑核心业务，这些中间件由业务驱动产生，随着技术组件越来越丰富，形成完备的平台技术框架，大大提升了平台的产品研发效率和业务运行稳定性。
区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台，下面介绍一下其中的核心组件。
接口层WebV4框架
接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用了Spring的面向切面（AOP）设计理念。
接口框架基于jersey 进行二次开发，基于annotation定义接口的URL和参数，并且内置Auth、频次控制、访问日志和降级功能，同时还有自动化的Bean-json/xml序列化接口框架用来支撑接口层平台的监控与服务治理系统。
服务层框架
服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。
MCQ消息队列
消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接的提高了DB操作性能，另外一个应用场景，平台通过消息队列，向搜索、大数据、商业运营部门提供实时数据。
微博平台内部大量使用的MCQ(Simple Queue Service Over Memcache)消息队列服务，基于MemCache协议，消息数据持久化写入Berkeley，只有get/set两个命令，MCQ有丰富的client library，同时也非常容易做监控（stats queue），在微博线上运行多年，性能比通用的MQ高很多倍。
Motan RPC框架
微博的Motan RPC服务，底层通讯引擎采用了Netty网络框架，序列化协议支持Hessian 和Java序列化，通讯协议支持Motan、http、tcp、mc等，Motan框架在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了High Availability与Load Balance策略（支持灵活的FailOver和FailFast HA策略，以及
Round Robin、LRU、Consistent Hash等Load Balance策略），服务治理方面，生成完整的服务
调用链数据，服务请求性能数据，响应时间（Response Time）、QPS以及标准化Error、Exception 日志信息。
资源层框架
资源层的框架非常多，有封装MySQL与HBase的Key-List DAL中间件、有定制化的计数组件，有支持分布式MC与Redis的Proxy，在这些方面业界有较多的经验分享，我在这里分享一下平台架构的对象库与SSD Cache组件。
对象库
对象库支持便捷的序列化与反序列化微博中的对象数据，序列化时，将JVM内存中的对象序列化写入在HBase中并生成唯一的ObjectID，当需要访问该对象时，通过ObjectID读取，对象库支持任意类型的对象，支持PB、JSON、二进制序列化协议，微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象，并抽象出标准的对象元数据Schema，对象的内容上传到对象存储系统（Sina S3）中，对象元数据中保存Sina S3的下载地址。
SSD Cache
随着SSD硬盘的普及，其优越的IO性能被越来越多的替换传统的SATA和SAS磁盘，常见的应用场景有三种：1）替换MySQL数据库的硬盘，目前社区还没有针对SSD优化的MySQL 版本，即使这样，直接升级SSD硬盘也能带来8倍左右的IOPS提升；2）替换Redis的硬盘，提升其性能；3）用在CDN中，加快静态资源加载速度。
微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。
垂直的监控与服务治理
随着服务规模和业务变得越来越复杂，即使业务架构师也很难准确的描述服务之间的依赖关系，服务的管理运维变得越来难，在这个背景下，参考google的dapper和twitter的zipkin，平台实现了自己的大型分布式追踪系统WatchMan。
WatchMan大型分布式追踪系统
如其他大中型互联网应用一样，微博平台由众多的分布式组件构成，用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后，会经过很多个业务系统或系统组件，并留下足迹（footprint）。
但是这些分散的数据对于问题排查，或是流程优化都帮助有限。
对于这样一种典型的跨进程/跨线程的场景，汇总收集并分析这类日志就显得尤为重要。
另一方面，收集每一处足迹（footprint）的性能数据，并根据策略对各子系统做流控或降级也是确保微博平台高可用的重要因素。
要能做到追踪每个请求的完整调用链路；收集调用链路上每个服务的性能数据；能追踪系统中所有的Error和Exception；通过计算性能数据和比对性能指标（SLA）再回馈到控制流程（control flow）中，基于这些目标就诞生了微博的Watchman 系统。
其系统设计一个核心原则就是低侵入性（non-invasivenss）：作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对使用方的透明性，可以大大减少开发人员的负担和接入门槛。
基于此考虑，所有的日志采集点都分布在技术框架中间件中，包括接口框架、RPC框架以及其他资源中间件。
WatchMan由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容，服务降级，流量切换，服务发布与灰度。
现在，技术框架在平台发挥着越来越重要的作用，驱动着平台的技术升级、业务开发、系统运维服务，本文限于篇幅限制，没有展开介绍，后续会不断的介绍核心中间件的设计原则和系统架构。
参考资料
正交分解法
jersey框架
weibo-watchman系统。