解析微博的信息呈现结构
解剖微博：解析微博的信息呈现格式
摘要: 都云人言可微，哪怕微言耸听！大小门户齐上阵，且看沙场秋点兵。–定场诗一首前言：回到七嘴八舌的原始社会所谓沟通，就是人们忙着做两件简单事：听别人说什么；自己该说什么。有一种沟通，主席台上某个发言人拿着扩音器讲话，身为听众只能在台下窃窃私语，这个...
都云人言可微，哪怕微言耸听！大小门户齐上阵，且看沙场秋点兵。–定场诗一首
前言：回到七嘴八舌的原始社会
所谓沟通，就是人们忙着做两件简单事：听别人说什么；自己该说什么。
有一种沟通，主席台上某个发言人拿着扩音器讲话，身为听众只能在台下窃窃私语，这个叫门户；有一种沟通，大家都可以轮流上讲台上拿着扩音器说话，并且邀请台下的观众评论，这个叫论坛；有一种沟通，大家都回到自己家说话，张贴标语，然后可以任意的去别人家拜访和聆听，这个叫日志，也叫Blog；还有一种沟通，大家围坐在一起，你可以选择收听那些你感兴趣的人，物以类聚，七嘴八舌，这个外国叫Twitter，到了中国叫“微博”。
一个人说话大家听，是信息的专制；大家轮流说话，似乎是信息的民主；有组织无纪律的七嘴八舌，也许可以算作信息的原始社会。平等，是微博的可怕之处，每个人都有话语权，也有选择聆听的权利。
微博的任务
核心任务、扩展任务、外延任务，这三者组成了微博要实现的沟通目的。反射系统由收听和发送两个部分组成，参与者通常扮演倾听者和发言人两个角色。其实这个世界很奇怪，从很小的时候，我们莫名其妙的学会七嘴八舌，聋哑人通常有两个原因产生：一是无法收听，所以不知道所谓发音，虽然发声系统是完好的，也说不出话，很痛苦；二是无法发声，虽然能听得到，但是无法产生反馈，很痛苦。最幸福的莫过既不能收听也不能发声，因为他们完全与声音绝缘。
微博信息格式的核心任务、扩展任务、外延任务
核心任务包括：
大家说了什么；其中哪些是“我说的话”，哪些是“别人的话”；在别人的话里面，某个人又说了些什么，谁对我说过什么。
扩展任务包括：
我是谁；哪些是我喜欢的人；谁在和我悄悄对话；某人对他说了什么；大家在讨论何种话题。
外延任务包括：
哪些话题是我感兴趣的，哪些人喜欢我；他是谁。
为了完成这些基本任务，由Twitter首创了一种最简单巧妙的方法：每人一条时间轴。时间轴记录了某个用户所说过的全部的话，你有你的时间轴，我跟随了你，那么你的时间轴也将进入我的视野。
就这么简单！解决了微博的核心任务，从Twitter风靡到其模式渗透到国内，大家可以发现一个问题，此微博与比微博的交互模式发生不同，是由其解决核心任务的方式决定的，具体表现为呈现格式，也就是英文中的Format，而在解决扩展任务和外延任务的问题上，各家都是大同小异的。
微博除了Format其他的一些都是显而易见的
分析呈现格式的过程中，会映射出很多不同的思路和问题，不仅仅在于交互、用户体验，也包括运营思路和内容定位。Format的不同，也就是微博的差异。
一条Tweets的格式：叙述、@用户、#标签、Url短地址
140个字符能解决什么问题？也许真解决不了什么问题，但是的确是通用格式。从概念上，微博只有两种实体：用户和内容。用户与内容之间的联系，内容与内容之间的联系，用户与用户之间的联系，这些实体行为会有N多，如果要为每一种行为定义一个Format，貌似有了章法，但剥夺了用户乐趣。Twitter采用了高度灵活的方法，给用户自定义Format的权力。
Twitter的信息格式的与应用
@用户
直接指向一个用户的页面，同时轻松的提取出与用户自己有关的话#标签
用一些关键字将所有有关的内容归纳在一起
Url短地址
一个超级链接，可能是站外的
Twitter的这种格式，是一种仿生学应用，在人类现实语言当中，基本也采用这类格式，用户的学习成本很低。我们总是在追求那些用户易于接受的方式，这就是体验改善。
RT开始的转发噩梦
转发，是Twitter的功能之一，即“将别人的发言张贴到自己的时间轴”，这种转发是原封不动的，且无法增加新内容的。开放精神让Twitter具有高度灵活，用户自发的突破了“原文转发”的形式，RT产生了。
RT最早来自一些客户端应用，后来也成为饭否这样的Twitter追随者的标准功能。所谓RT 就是在140个字的范围内，采用“我对某人发言的评论 RT @某人：他的发言内容”的形式，在自己的时间轴上建立包含他人内容的分支，同时增加新的内容和自己的评论。RT是人工的复制别人时间轴的片段，以接龙的形式产生言论序列，共同讨论。
RT是一种爱好者自创的微博关联形式
Twitter为什么要坚持原文转发呢？实际上无数爱好者强烈要求Twitter将RT 作为官方标准功能，但Twitter坚持“发言的可追溯原则”，所以RT一直作为非官方的格式存在着。RT内容是发言者可以任意更改的，容易产生混淆和篡改；
依然有无数的爱好者在140个字的范围内乐此不疲的RT，因为他们不喜欢“原封不动的转发”，更期望说一些什么。于是，国内开发的微博通常包含两个新功能：援引和评论。
国内微博的“援引”功能
方块字比拉丁字母更节省字节，若不信，请你将中文版的《红楼梦》和英文版的《The Dream of Red Mansion》一起拿出来放在桌面上，看看那一本更厚实。140个字对有着悠久话痨历史的民族来说，反而略显局促了，特别是在版聊流行的时代，RT捉襟见肘。
援引功能是要付出代价的，必须给每一条微博记录增加句柄，因为每一条言论都可能要引用别人时间轴上的片段。通过句柄突破140个字的RT局限，让一条一条的言论延续起来，万幸的是，这种引用仅限在原文基础上进行一次，否则，他们也知道会搞出满屏糖葫芦出来。
援引微博的信息呈现格式
援引微博的传播示意
援引的出现让280字的大块文章成为可能，140个字的空间留给原创者，另外140个字的空间留给后面的跟进用户。新浪、腾讯、网易，几乎所有中文门户的微薄都在如法炮制，原创发言后面的产生的多个RT分支，布朗运动一样的乱窜。
援引微博的拓扑过程
援引让一条原创发言可以有N个方向的拓扑，也的确让时间轴丰富多彩起来，但也存在如下的问题：
1.一旦原创发言被删除，那么后面的多条RT分支就没有了头绪，微博又不
允许“关联删除”，会在某些用户的时间轴上留下很多“窟窿”。
2.因为有“援引”，那么每条微博可能有了身份，要么是“原创”要么是
“转载+RT”，这是数据结构上的划分，并非是用户自发的。
3.RT中的内容还是可以供后续用户任意修改的，从某种意义上说，如果用
户想针对某人的发言说点什么，又怕这个人删除原始发言，那么用户就必须采取“在原创的状态下RT”，又回到了Twitter爱好者级的RT应用。
可以预料，援引功能最初有两个目的：第一，保护原创；第二，给RT以合法地位。但是创建援引功能的朋友忽略了两个问题：第一，所有在用户时间轴上的言论都是原创的，原创是与生俱来的，不需要保护的；第二，即便给了RT单独的存储空间，你仍无法避免用户在RT中修改前文。Twitter是完全看透了这些问题，所以一直没有也没打算增加“援引”功能。
还有一种可能，国内门户开发的围脖期望更长的篇幅，140个字对他们的话痨用户真的不够用，于是搞出“援引”这样的东西。这一点也被Google直接看透，Buzz貌似是没有字符限制的。
从“没有援引”的数据转移到“包含援引”的状态，很容易，加一个句柄；但这已经是一个不可逆的操作了……实际上，这么做已经完全放弃了未来使用更灵活的模式解决问题的可能：因为用户已经产生了带有句柄的数据，你不可能把句柄象盲肠那样割下来。Twitter也很有可能在考虑未来如何研发新的应用，但是不会选择那些没有退路的方法。
“评论”是根搅屎棍
人的平等就是言语的平等，“援引”将微博分为两种：原创和RT，这是一个很糟糕的开始，因为一旦有了不平等就会出现更危险的状况：“评论”让用户可以在别人的时间轴上插入内容！
“评论”的产生是运营思路的结果，新浪微博按照其博客的形式引入名人效应，搞出V用户，既然是“粉丝”，就要学会倾听，当粉儿们@一下自己的偶像，V 们就可以完全不在自己的时间轴里加任何东西，而直接在某粉的时间轴加入一条评论。要承认“评论”是一种创造，可以让V们堵住耳朵自言自语的表演。
某微博的评论功能允许其他人在我的时间轴上插入内容
“评论”是一种不公平的功能，结果就是某些用户可以自说自话的不关注其他人而拥有成千上万的粉丝，这是有违“七嘴八舌”的原则的。由于可以不在自己的时间轴说话，用户可以完全的扮演不同的角色和态度，给予不同的人不同的嘴脸，这是现实。
无法看到某人说过的所有话，那么就是不对称和不完整。
某条微博现在可能有三种身份：原创的，援引+RT，不在自己的时间轴的评论。感谢国内同业的朋友改善了Twitter带来的那种平等交流的气息，而把国内的微博搞的像歌迷会一样的东西，让少部分用户先V起来，貌似走下神坛，却又登上圣殿。
富格式的微博时代
Twitter看字，微博看图。Twitter是无法直接张贴多媒体的，在有图才可能有真相的时代，用户无法接受那种把任何东西都作为一个短地址包含在140个字方式，这是可以理解的。有一种方式是非常不错的，即自动解析内容中的短地址，如果包含视频或图片就显示他们。基于流量上的考虑，直接显示图片是不妥的。
微博到了中国有了新的变化，开发者和用户发现，短地址无论多么短都会占用字节，让他们无法忍受，于是乎将多媒体外挂的微博格式产生了。用户可以单独的提供多媒体的资源和地址，某一条微博将和它们产生关联，当然其代价是不断的在微博格式上增加句柄。目前新浪已经加挂了微博投票功能，或许某一点类似养猪种菜这样的单元也会被加上去，无论用户是否允许。
富微博信息呈现格式
姑且可以将外挂多媒体和各种地址的微博称呼为富微博，微博实在承载了太多门户网站的厚望，微博不微了。那种简单的，无华的，质朴的交互为什么一到中国就改变了味道呢？
在某些网站，至今还能找到N年前发布的信息，而在某些比较大门户，已经找不到了08年发表的东西。如果你们是急功近利的，那么请给未来的开发多留一些
退路，而不要因为现在的错误去彻底清除用户的数据。博客、web2.0、SNS大家都曾经追逐过，现在又如何呢？中国式微博的未来在哪？
https://www.wendangku.net/doc/ce14235484.html,授权发表
原文：https://www.wendangku.net/doc/ce14235484.html,/Point/201011/The-Heart-Of-Sparrow.html
淘宝平台架构师谈海量互联网服务技术架构
林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi 在中国的推广起到了很大的作用。 王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？ 林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对应用的影响程度，因此通常会需要一个强大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构并存、数据冗余和同步等问题。 王速瑜：数据备份问题：对于大容量的数据备份，技术上如何做到不影响正常的服务？如何合理制定冷备、热备的实施策略、方式、时间段？在数据损坏、主服务器硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？ 林昊：对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据库的特性（例如Oracle的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务功能，因此可选的时段只能是系统访问量较低的时段。方式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。 王速瑜：开放平台设计问题：开放平台API设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计，倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的? 林昊：对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http，接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供；开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电信行业。: 王速瑜：跨IDC部署程序模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？ 林昊：跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要借助自动化的部署系统。 王速瑜：Web2.0网站的海量小文件的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体解决方案的？
新浪微博技术
中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。图为微博平台首席架构师杨卫华演讲。 以下为演讲实录： 大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。 首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一版本的技术细节，典型的LAMP(Linux-Apache-MySQL-PHP)架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。 我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。 第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。
新浪微博技术架构
首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。 我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。 第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。 我们再看数据的拆分，数据拆分有很多方式，很多互联网产品最常用的方法，比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的服务器，所以我们考虑微博的数据我们按照时间拆分，比如说一个月发一张表，这样就解决了我们不同时间的惟度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的地址是索引数据，内容是内容数据。假如说我们分开的话，内容就简单的变成了一种key-value的方式，key-value是最容易扩展的一种数据。比如说一个用户发表了一千条微博，这一千条微博我们接口前端要分页放，比如说用户需要访问第五页，那我们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表，我们记录上很难判断第五页在哪张表里，我们需要索引所有的表。如果这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是说索引上做了一个二次索引，改变我们还是按照时间拆分，但是我们把每个月记录的偏移记下来，就是一个月这个用户发表了多少条，ID是哪里，就是按照这些数据迅速把记录找出来。 异步处理，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果我们要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后我们在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，我们去年做了一个对大规模部署非常有利的指令，就是stats queue，适合大规模运维。 第二版我们做了这些改进之后，微博的用户和访问量并没有停止，还有很多新的问题出现。比如说系统问题，单点故障导致的雪崩，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比如说世界杯，可能会导致用户每秒发表的内容达到几百条。我们考虑如何改进，首先系统方面循序任意模块失败。另外静态内容，第一步我们用CDN来加速，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分，然后提前进行容量规划。 另一方面我们还有平台化的需求，去年11月我们就说要做开放平台，开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。 系统规模在持续的增大，另外也有平台化的需求，我们新架构应该怎么做才能满足这些需要？我们看一下同行，比如说Google怎么样考虑这个问题的？Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务。比如说我们在https://www.wendangku.net/doc/ce14235484.html,执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因此，我们第三版的考虑就是先有服务才有接口最后才有应用，我们才能把这个系统做大。
新浪微博电子商务分析
电子商务案例分析学院：外国语学院 班级：日语10级3班 姓名：吴巧曼 学号：201001080923
社交网络的电子商务 ——新浪微博 一、电子商务与社交网络的介绍 1.社交网络的定义 社交网络即社交网络服务，源自英文SNS（Social Network Service）的翻译，中文直译为社会性网络服务或社会化网络服务，意译为社交网络服务。社交网络含义包括硬件、软件、服务及应用，由于四字构成的词组更符合中国人的构词习惯，因此人们习惯上用社交网络来代指SNS（Social Network Service）。 2.电子商务的定义 电子商务通常是指是在全球各地广泛的商业贸易活动中，在因特网开放的网络环境下，基于浏览器/服务器应用方式，买卖双方不谋面地进行各种商贸活动，实现消费者的网上购物、商户之间的网上交易和在线电子支付以及各种商务活动、交易活动、金融活动和相关的综合服务活动的一种新型的商业运营模式。电子商务是利用微电脑技术和网络通讯技术进行的商务活动。各国政府、学者、企业界人士根据自己所处的地位和对电子商务参与的角度和程度的不同，给出了许多不同的定义。 二、新浪微博对电子商务的应用 1.新浪微博简介 新浪微博是一个由新浪网推出，提供微型博客服务的类Twitter网站。用户可以通过网页、WAP页面、手机短信/彩信发布消息或上传图片。新浪可以把微博理解为“微型博客”或者“一句话博客”。它全中国当前最主流，最火爆，最具人气的微博产品。用一句话随时随地记录生活，随时随地分享新鲜事。用最迅猛的速度发现最热、最火、最酷、最新的资讯。随时随地关注明星动态。 2.新浪微博的发展 新浪微博于2009年8月14日开始内测。9月25日，新浪微博正式添加了@功能以及私信功能，此外还提供“评论”和“转发”功能，供用户交流。目前优秀的微博桌面客户端有微波炉、AIR微博（官方）、Wing微博。
新浪微博框架
大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。 首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就
会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。 我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。 第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。
新浪微博API
微博开放平台是一个基于新浪微博客系统的开放的信息订阅、分享与交流平台。微博开放平台为您提供了海量的微博信息、粉丝关系、以及随时随地发生的信息裂变式传播渠道。 广大开发者或网站只要登录平台网站并创建应用，即可通过平台开放接口(Open API)对微博系统进行读写，挖掘微博系统的新功能与新玩法。 平台概述 出自新浪微博API 跳转到：导航, 搜索 微博开放平台是一个基于新浪微博客系统的开放的信息订阅、分享与交流平台。微博开放平台为您提供了海量的微博信息、粉丝关系、以及随时随地发生的信息裂变式传播渠道。 您可以登录平台并创建应用，使用微博平台提供的接口，创建有趣的应用或者让您的网站具有更强的社交特性。 用微博账号登录 经过简单的代码整合，并在您的网站上放置微博登录按钮，您的网站用户就能够使用微博账号进行登录。网站可以获取当前用户的用户名、头像图片、当前用户的粉丝和关注对象列表。您可以整合现有的用户账户系统或者直接替换成微博的账户系统，帮助您提升网站的用户注册量和提升网站访问数据。 使用OAuth的授权机制进行开发，在网站的显著位置添加“与新浪微博连接”的功能，让用户与能够直接点击并登录。 参考开发介绍：连接微博 分享与动态 新浪微博现有的用户传播体系非常完整，好友之间通过大量的信息分享带来病毒式的传播。平台提供了分享按钮和动态展现插件，让你仅仅通过几行HTML 代码就能够在你的网站上加入社交特性。分享的内容也会在微博网站上展现，用户点击链接后可直接进入相关内容。我们也提供了大量的 API接口帮你实现更多的特性。 内容分享： 添加分享到微博的按钮： 点击后弹出分享窗口分享内容：
新浪架构师谈微博架构
微博(Micro-Blog)顾名思义是微型博客，是一种基于用户关系的信息分享和传播平台,用户可通过浏览器、手机、及时通讯软件(MSN、QQ、Skype等)及外部API接口等多种渠道发布140字以内信息[1]。支持跨平台交流、与移动设备无缝连接的技术优势,饱含Web2.0特质。 有这么一道题- 微博数据库设计：有A,B,C3个用户，A关注C，C关注A和B；A,B更新后C会收到信息提示,比如： 2010-11-16 22：40 用户A 发表a1; 2010-11-16 22：41 用户A 发表a2; 2010-11-16 22：42 用户A 发表a3 2010-11-16 23：40 用户B 发表b1; 2010-11-16 22：40 用户B 发表b2; 问题1：如何设计数据表和查询？ 问题2：如果C关注了10000个用户，A被10万个人关注，系统又该如何设计？ 问题1，我的解答是：设计两张表，一张用于表示用户user，有ID,用户名(username)，发布内容（message），发布时间(time)等字段；另一张表用于表示用户之间关注，有ID，用户名(username)，关注的用户名，开始关注时间等字段。回去想了想，发现如果数据表照我这样设计的话，问题2的情况就会产生大量的数据，但如果把关注的用户都写在一个记录里那样字符串可能会更大。所以想听听诸位达人的意见，如果是你们会怎样设计数据表呢？ 问题1简单而且随意，直接跳过，估计面试的人都不会看。问题2的困难在于： 第一点.C关注的用户太多，设计上必须在显示C的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。 第二点.第二点.A被关注的人太多，设计上必须在A更新的时候，避免去通知所有关注…… 为避免不必要的复杂连接关系，最好还是设计符合第三范式的关系数据。 我想至少应该设计三张表，分别是： 用户表user：ID，username...； 关注关系表attention: ID->ID； 发布信息表in fo：ID->message； 三张表的设计是比较规范的，至于用户和关注之间的关联要看需求，做join也可以，做DataMap也可以。 个人觉得，需要的逻辑关系在哪儿，而且要进数据库，想不数据量大都不行。当然关注可以不做在一张表中也是一个选择，按关系类型分开走，可以减少特定需求的查询量。 这玩意得丢内存里头吧memcached 发新的话题的话丢队列里头写数据库去 user { befollow[0...n]; post[0...n]; topics[0..n]; } 然后，user[befollow[k]].topics=current_user.topics[j]; 用户只要检查topics就好了要不每次上来来个join什么的，估计数据库就挂了
新浪微博及其盈利模式分析
新浪微博及其盈利模式分析 09新闻刘婧璐2009311295
目录 目录 (2) 摘要 (3) 一、新浪微博概述 (3) （一）概念 (3) （二）历史 (3) （三）功能 (4) （四）特点 (4) 二、微博与SNS关系 (5) （一）SNS概念 (6) （二）微博与SNS关系 (6) （三）微博与SNS区别 (6) （四）SNS现有盈利模式 (7) 三、类twitter基础上的改进 (8) （一）多媒体功能让内容更丰富 (8) （二）用户年龄段偏低，与手机结合紧密 (9) （三）转发评论认证等数据更满足虚荣心 (9) （四）非独立网站，依托强大门户网站另辟蹊径 (9) （五）名人效应 (10) 四、新浪在国内微博行业中的地位 (10) （一）人气分析 (11) （二）媒体影响力分析 (11) （三）基于微博开放平台应用软件分析 (12) 五、新浪微博盈利模式 (13) （一）现有盈利模式 (13) （二）计划中的盈利模式 (15) （三）潜在盈利模式 (15) 六、新浪微博商业前景 (18) (一)新浪企业价值飙升 (18) （二）长期应注意与监管层关系 (19) (三)盈利模式尚未验证 (19) （四）盈利模式创新 (19) 参考文献 (20)
摘要 本文在介绍新浪微博的基础上，重点分析新浪微博的盈利模式。 在分析其盈利模式之前，本文先分析了新浪微博与SNS、Twitter的关系和区别以及目前新浪在国内微博行业的地位，新浪在这三次比较中显现出的特性，使得新浪既可以沿袭SNS和Twitter已有的商业模式，又可以凭借自身特色加以创新。本文在此基础上讨论了新浪微博现有的盈利模式，计划中的盈利模式和潜在盈利模式。 一、新浪微博概述 （一）概念 根据百度百科上的概念，微博是一种通过简短文本更新用户信息，融合多种发布方式(如及时消息，短信息，电子邮件，音频，视频)和不同平台技术(WEB，WAP)为一体的博客形式。 新浪微博是由新浪网推出，提供微型博客服务的类Twitter网站，用户可以通过网页、WAP页面和手机短信、彩信发布140字以内的消息或上传图片，此外还可通过API用第三方软件或插件发布信息。 （二）历史 2009年5月在新浪例行战略会议上新浪高层提出了作为微博的想法，并于2009年8月14日开始内测。 高层起初并没有想把微博往Twitter这条路上走。决定做微博的时候，新浪当时已经做了应用比较丰富的SNS——新浪“朋友”。这个应用到现在都很少有人知道。新浪“朋友”一开始是Facebook路线，后来一改再改，最后已经有点接近微博的形态，类似于把Facebook的mini-feed功能单独拿出来做，传递名人的动态消息，但由于不具备内容的承载性最终被停掉。 新浪高层经过反复思考，他们认为微博虽然不同于SNS，但 Twitter本身具
新浪云开发平台开发指南
新浪 SAE 分布式 Web 服务应用平台
——云计算技术在网络推广中的应用 https://www.wendangku.net/doc/ce14235484.html,
1）什么是 Sina App Engine
Sina App Engine（以下简称 SAE）是新浪研发中心于 2009 年 8 月开始内部开发，并 在 2009 年 11 月 3 日正式推出第一个 Alpha 版本的国内首个公有云计算平台，SAE 是 新浪云计算战略的核心组成部分。
SAE 作为国内的公有云计算， 从开发伊始借鉴吸纳 Google、 Amazon 等国外公司的公有 云计算的成功技术经验，并很快推出不同于他们的具有自身特色的云计算平台。SAE 选择在国内流行最广的 Web 开发语言 PHP 作为首选的支持语言，Web 开发者可以在 Linux/Mac/Windows 上通过 SVN、SDK 或者 Web 版在线代码编辑器进行开发、部署、调 试，团队开发时还可以进行成员协作，不同的角色将对代码、项目拥有不同的权限； SAE 提供了一系列分布式计算、存储服务供开发者使用，包括分布式文件存储、分布 式数据库集群、分布式缓存、分布式定时服务等，这些服务将大大降低开发者的开发 成本。同时又由于 SAE 整体架构的高可靠性和新浪的品牌保证，大大降低了开发者的 运营风险。另外，作为典型的云计算，SAE 采用“所付即所用，所付仅所用”的计费 理念，通过日志和统计中心精确的计算每个应用的资源消耗（包括 CPU、内存、磁盘 等） 。
第 1 页
总之，SAE 就是简单高效的分布式 Web 服务开发、运行平台。
2）SAE 整体架构 SAE 从架构上采用分层设计，从上往下分别为反向代理层、路由逻辑层、Web 计算服 务池。 而从 Web 计算服务层延伸出 SAE 附属的分布式计算型服务和分布式存储型服务， 具体又分成同步计算型服务、 异步计算型服务、 持久化存储服务、 非持久化存储服务。 各种服务统一向日志和统计中心汇报，参考下图：
7 层反向代理层：HTTP 反向代理，在最外层，负责响应用户的 HTTP 请求，分析请求， 并转发到后端的 Web 服务池上，并提供负载均衡、健康检查等功能。 服务路由层：逻辑层，负责根据请求的唯一标识，快速的映射（O(1)时间复杂度）到 相应的 Web 服务池，并映射到相应的硬件路径。如果发现映射关系不存在或者错误， 则给出相应的错误提示。该层对用户隐藏了很多具体地址信息，使开发者无需关心服 务的内部实际分配情况。 Web 服务池：由一些不同特性的 Web 服务池组成。每个 Web 服务池实际是由一组
第 2 页
新浪微博开放平台api
用java开发新浪微博的API 首先先注册新浪微博（如果有了的可以直接登录） 在进入新浪微博的开放平台下载SDK 下载最新的SDK https://www.wendangku.net/doc/ce14235484.html,/wiki/SDK 然后把SDK 导入到MyEclipse 里 接着在进入新浪微博的开放平台点击我要成为开发者 注册 1.填写开发者资料 2.验证邮箱 3.创建应用/添加网站 点击创建应用 有5种应用 选择站内应用然后把信息填完点击创建 成功后在应用基本信息里就会显示App Key 和App Secret
再接着往下看会看到 站内应用地址和应用实际地址记住填写的内容 回到MyEclipse在src下面找到config.properties 填写 client_ID =App Key client_SERCRET =App Secret redirect_URI =应用实际地址（也可以不写我就没有写） 保存 接着就是写一条获取微博的前20条信息 在examples 下的weibo4j.examples.oauth2下的OAuth4Code下直接运行（如果报错把 改成 ） ，就会出现授权页面,登录，登录成功后，点击授权查看网址后面有个code=XXXX 把code=后面的XXXX复制到MyEclipse 的控制台中的https://https://www.wendangku.net/doc/ce14235484.html,/oauth2/authorize?client_id=1682103644&redir ect_uri=https://www.wendangku.net/doc/ce14235484.html,/boyaboya&response_type=code&state=& scope= Hit enter when it's done.[Enter]:后面 然后按回车就会输出一大堆消息直接跳到最后会看到 记住"access_token" 后面的值就是是我们要用到的值了记录下来 下面开始获取微博最新的前20条信息喽 weibo4j.examples.timeline 下的 GetPublicTimeline 类中 代码如下 package weibo4j.examples.timeline;
Java系统架构师【面试题】
Java系统分析/架构师面试题 【专业知识相关】 1、谈谈对OOP、IOC、AOP的设计理念的理解； 2、谈谈对主流的J2EE框架（Spring、Struts、Ibatis、Hibernate等）；这 些框架的局限性在哪儿？在何种情况下会不适合用这些框架？ 3、关于J2EE方面开发方面，说出前、后端的设计模型； （提示：比如前端的MVC框架，Axis，Ext，JQuery，Flex等，后端的Ejb，Spring，IOC，AOP，JMS，JNDI，RMI，以及负载均衡等） 4、什么是SOA，ROA？谈谈两种技术的原理及适用场景； 5、说说JVM原理，内存泄露与溢出的区别，何时产生内存泄露？ 6、谈谈JAVA通信方面相关知识，以及大项目之间通信方案； 【软件架构、服务器、中间件相关】 7、谈谈架构师的职责有哪些？ 8、软件设计领域，有哪些设计模式，你常用的几种设计模式；各个设计模式 有哪些优缺点，适应哪些场景； 9、谈谈你日常用的几种WEB服务器、中间件的相关特性及优缺点； 10、如果要设计一个搜索引擎，像Google那样只有两个页面，要求性能最大 化，Web方面应该如何设计？（不需要考虑搜索的逻辑） 11、企业级应用有哪些特殊要求？在何种情况下我们不需要考虑这些要求？ 12、谈谈你现在做技术最大的困惑是什么？ 13、描述一个你感觉最成功的一次架构案例? 14、怎么做到系统整合? （提示：A、通过代码的整合方式，使用相同的数据库。B、通过SSO方式，可以是异构数据库.） 15、浅谈一下负载均衡的原理? 16、怎么处理权限分配?有几种权限分配模型?（提示：目前流行的三种： A、自主型访问控制； B、强制型访问控制； C、基于角色的访问控制RBAC）【数据库方面】
亿级用户下的新浪微博平台架构
亿级用户下的新浪微博平台架构 架构之路（系列三）卫向军新浪微博 引言 新浪微博在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服务。 水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。
能力开放平台
能力开放平台 目录 1、能力开放平台简介 (2) 1.1什么是能力： (2) 1.2能力平台是什么： (2) 1.3 为什么要能力开放 (2) 1.4 能力开放后对我们有哪些好处： (3) 2、现今业界主流开放平台概述 (3) 2.1电信能力开放平台 (3) 2.2互联网应用开放平台 (3) 2.3 云计算开放平台 (3) 3、电信能力开放平台综合概述 (4) 3.1 电信开放平台总体发展演进 (4) 3.2 电信开放平台能够开放哪些能力 (4) 3.3 电信能力开放模式分析比较 (4) 3.3.1 销售开放模式 (4) 3.3.2 分成开放模式 (5) 3.3.3 免费型开放模式 (5) 3.4 电信开放平台发展思路 (5) 3.5 电信能力开放平台具体应用发展思路 (5) 3.6 电信能力开放平台应用举例 (6)
1、能力开放平台简介 1.1什么是能力： 总的来说，能力是对底层复杂的实现进行了抽象，对外提供一个开发和执行环境。通过对快速引入新的应用和服务提供支持，以更低的平均运作成本来高效、可靠地创建和管理丰富多样的融合业务。 在以往开发者开发出来的能力往往具有较大的范围限制，基本上属于一个封闭模式。随着能力开发者对自身业务思路的拓展耗尽，这些独立的孤能力便再也没有其它的新应用能够引进。 基于电信通讯能力，以更开放、更灵活的，自行开发配置的方式向用户提供通信服务的设想，让用户、开发者，运营商实现真正意义上的共赢，就是能力开放平台的宗旨。它将是实现以上梦想的一个重要的基础技术平台，为AP和SI提供统一的能力调用接口。 在用户需求中，能力开发者利用自身能力实现的用户需求只占一小部分(如：单纯的通话、短信之类)。更多业务方面的需求，对于用户来说是综合性的，并非某个独立的能力就可满足，实现这些业务需求需要将多种能力进行结合才能实现。 1.2能力平台是什么： 能力开放平台在整合和利用现有电信IMS、ISAG核心网资源的基础上，采用统一的多层级的开放接口来开放电信能力，聚集互联网上有潜力、有创造力的开发者，让开发者能利用这些能力不断地创造出更好的商业应用和服务，实现开发者的无限的创造能力，形成一大批新的移动互联网应用及服务。 1.3 为什么要能力开放 1）在一个产业中，想做一个全能型的企业已经不现实，在满足客户需求的时候，由自身全盘控制，面临着巨大的服务质量和业务创新的挑战 2）在移动互联网时代，构建一个良好的生态链是竞争优势的关键。运营商与互联网合作、与企业合作。与个人用户合作，形成真正的合作伙伴关系，关键就在于这些合作伙伴能够与运营商的自身生态系统形成紧密的联系。开放能力当然是选择之一。 3）用户消费在运营商业务上的时间长度和注意力资源份额越来越少。运营商需要把自己的能力嵌入到那些用户花费更多时间和精力的业务内。 这几个理由对于运营商来说，都是长期的趋势和长期的目的。
关于对新浪微博新版的一些个人看法和分析
关于对新浪微博新版的一些个人看法和分析 一．前言 2011年10月17日，新版新浪微博正式面向全体用户开放升级。新版的新浪微博，将页面的布局从传统的两栏版更改成了三栏版。同时，对基础功能进行了全线升级，在人机操作、人际互动方面加强了功能优化，并增加了即时通信，微相册等重磅新应用。相信使用过新版的用户可以感觉得出来，新版的新浪微博，已经在逐渐向着社交网站转变。为什么会进行这样的转变？下面笔者将就此谈谈自己的一些粗浅的看法和分析。 二．正文 首先从页面布局的改变来看，之所以要将沿用了两年的两栏版改成三栏版，一方面是因为这样的设计，拓宽了界面视野，使之可以显示更多的内容和应用，更便于用户进行操作；另一方面，个人认为是由于新浪微博的发展转型，使其考虑向成熟的社交产品如QQ空间等进行借鉴，因而采用了这种当前热门SNS社区网站典型特征的三栏布局。当然，并不是每一个用户都会喜欢这种布局，因此新浪微博保留了传统的两栏版，升级后微博用户可以在两栏和三栏版本间进行切换使用。 接着来看看新浪微博这次升级所带来的一些变化以及新增加的功能和应用。
从导航上看，新版新浪微博将此前的两层导航变成了单层统一导航，将模块和搜索框的位置进行了合理调整和整合，同时也进行了全线升级，例如用户在搜索框内输入信息，能自动联想到含有关键字的微博、用户、微群以及应用；而“消息”模块则聚合了评论、粉丝、私信、@提醒、通知和邀请等各类信息，还有整合相册功能，并和对图片进行在线编辑、美化和圈人；其他模块基本上或多或少都有不同的改变，这里就不再一一进行说明。 升级前的版本
升级后的版本 由此可见，新版新浪微博对个人资料、互动消息、功能模块进行了整合管理，位置上进行了合理调整，更加地从用户习惯考虑，注重用户的社交互动体验。 此次升级，还针对老版本的私信进行了改动，在支持原来的文字和表情传输基础上，增加了图片和附件传输功能，能支持50M以内的图片和文件发送，这个功能有点像微博“邮箱” 了，用户的一对一互动变得更加便捷。 在笔者看来，微博这个产品，从用户交流来看，其特性是专门用来满足用户一对多需求的，不仅仅是像QQ群那样只针对一小部分人，而是更加开放，更加易互动性的。然而微博在这一方面也并非完美，它也存在缺陷：对于普通用户而言，你可以关注名人，关注自己想关注的其他用户，看他们的言论，给他们留言，但如果对方粉丝数目庞大，这种留言，往往是石沉大海，不会受到重视，得不到回应；而普通用户即便持之以恒的坚持每天发微博，却未必 会获得多少粉丝的关注，这种单向的注意力倾向必定会让普通大众产生挫败感，最后渐行渐
新浪微博API开发简介之PHP基础篇-用户授权
现在玩微博的人越来越多了，而关于微博的第三方应用开发也越来越多，自己在偶然间开始接触了新浪微博API开发，新浪微博API开发的资源比较多，新浪微博提供了一个开发者的平台，网址是： https://www.wendangku.net/doc/ce14235484.html,，它里面有很全面的新浪微博开发的资料，包括开发者的使用和介绍，各种语言的API函数介绍文档，SDK等多种资料。 自己在开发和学习的过程中，感觉虽然没有太大难度，但还是有一些问题是需要我们注意的，今天就我在开发和学习的过程中，简单的对利用PHP进行新浪微博API开发的内容进行一个整理和说明， 新浪微博API开发前的准备工作 首先到新浪微博开放平台下载基于PHP的SDK开发包，下载地址是： https://www.wendangku.net/doc/ce14235484.html,/p/libweibo/downloads/detail?name=weibo-oauth-class-with-image-avatar-06-29 .zip 下载完成后放到自己的开发环境中并解压，在其中也包含了demo演示程序，我们可以参考其样例程序进行编写。 新浪微博API开发最重要的用户授权过程 其实在开发过程中很多的问题都是集中在用户授权这个阶段，我开发的第三方应用，使用的是OAuth授权，关于OAuth授权的流程在新浪微博开放平台里有很清晰完整的介绍，我们可以到 https://www.wendangku.net/doc/ce14235484.html,/wiki/Oauth去查看，我这里从实例开发的角度进行介绍和说明。 1.首先获取未授权的Request Token $o = new WeiboOAuth( WB_AKEY , WB_SKEY ); $keys = $o->getRequestToken(); //echo($keys['oauth_token'].' : '.$keys['oauth_token_secret']); 我们需要在新浪微博开放平台中注册一个帐号，或直接使用我们的新浪微博帐号登录，进入我的应用，然后按照提示创建属于我们自己的第三方应用，创建完成之后我们可以得到两个授权的App Key和App Secret值，这两个值就是我们开发应用的关键。 得到授权值后，我们就可以利用上面的代码获得未授权的Request Token值了，它们会保存在$key数组变量中。 2.然后请求用户授权Token $_SESSION['keys'] = $keys; $aurl = $o->getAuthorizeURL( $keys['oauth_token'] ,false , 'http://localhost/callback.php'); 得到未授权的Request Token值后，我们就利用上面的代码可以开始准备去新浪微博授权页面进行授权，$aurl就是授权链接页面，我们得到$aurl后就可以利用header()直接跳转到该授权页面，然后用户输入新浪微博帐号和密码进行授权，授权完成后，自动跳回你在最后一个参数里面设置的回调页面： http://localhost/callback.php，该链接你可以设置为上一个页面，这样授权完成之后就会自动又跳转回去了。