"新浪科技讯 11月16日下午消息，由 新浪微博( http://t.sina.com.cn)(http://t.sina.com.cn)主办的中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。图为微博平台首席架构师杨卫华演讲。\n以下为演讲实录：\n大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是 怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家 对微博的底层技术有更好的了解。另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面 的一些架构，分析一下架构里面哪些共性大家可以参考。\n首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是 …"

"又拍网是一个照片分享社区，从2005年6月至今积累了260万用户，1.1亿张照片，目前的日访问量为200多万。5年的发展历程里经历过许多起伏，也积累了一些经验，在这篇文章里，我要介绍一些我们在技术上的积累。\n又拍网和大多数Web2.0站点一样，构建于大量开源软件之上，包括MySQL、PHP、nginx、Python、memcached、redis、Solr、Hadoop和RabbitMQ等等。又拍网的服务器端开发语言主要是PHP和Python，其中PHP用于编写Web逻辑（通过HTTP和用户直接打交道）， 而Python则主要用于开发内部服务和后台任务。在客户端则使用了大量的Javascript， 这里要感谢一下MooTools这个JS框架，它使得我们很享受前端开发过程。 另外，我们把图片处理过程从PHP进程里独立出来变成一个服务。这个服务基于nginx，但是是作为nginx的一个模块而开放REST API。\n**图1：**开发语言\n由于\nPHP的单线程模型，我们把耗时较久的运算和I/O操作从HTTP请求周期中分离出来， 交给由Python实现的任务进程来完成，以保证请求响应速度。这些 …"

"内容概要：本文分析了大型程序系统设计中经常需要面对的同步和异步结构问题。列举异步结构模式实现手段，论证异步模式效率远远优越于同步模式，证明在硬件资源理想情况下，对同步模式而言并发量对计算机系统的平均交易处理时间没有影响，对异步模式而言平均交易处理时间会随着并发量的增大而急剧下降，最终也趋向一个恒定值。在实际有限计算机资源情况下，程序设计必须设置最大并发量以控制并发程度，否则过多并发量会形成交易对硬件资源的竞争，造成交易的拥塞。\n关键词：同步，异步，消息队列，效率，并发\n一．基本概念\n同步和异步问题是大型程序设计中需要慎重等待的问题，但目前这方面的讨论很少，本文就试图进行有关方面讨论。\n一个大型的程序系统常常是由很多不能功能模块组成的。程序系统运行时不同功能模块要按一定顺序执行，以协同完成一件任务。功能模块协作运行完成一件任务存在同步和异步两种方式。如果在某一时间段，这个程序系统的所有功能模块都在为完成相同的一件任务而服务，某一个功能模块在完成一件任务的子任务后，需要等待其他功能模块完成子任务，这样只有当全部功能模块按顺序完成一件任务后，程序系统才能接收下一个任务，功能模块是串行运行，这 …"

"章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。 讲解的内容就不具体介绍了，在LVS 官方网站上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^\n组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。\n典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示： [][2] 如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示： [][3] 目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。 在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数 据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩 …"

"统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂，越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说，去年3月在伦敦召开的QCon会议上，Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道，其中一个主要的结论就是eBay不使用事务，用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。\nInfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论，以获得更多信息：\n为什么eBay不使用事务，或者为什么可以决定不采取应用级事务？\n我们并非一概不使用事务。我们只是不使用跨物理资源的事务，因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。（例如在客户端控制 的事务中，）一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务，因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反，我们选择缺少事务的设计，并加入失效模式，失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。\n应用级事务总是有些问题。只 …"

"在前一期 山寨交流会 上： 桂 新 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的 一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。\n以下是我在 博客大巴 开 发中的一些实践小结：\n1 数据库相关\n1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，\n1.2 解决这个问题目前的主要策略就是分片( share nothing)，单个数 …"

"在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。\n架构概况 超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。\n之前曾有一篇 揭 秘 MySpace 架构的文章，也有中文版本《 亿万用户网站 MySpace的成功秘密》！\n运维数据收集 其实这个演讲我感觉主要讲的是这个数据收集模块 🙂 MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。\n每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服 …"

"基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址：好像是在定期启用新的集群，各个时期的域名分布如下：\nhttp://farm1.static.flickr.com 2006年中以前；\nhttp://farm2.static.flickr.com 2006年底；\nhttp://farm3.static.flickr.com 2007年底；\nhttp://farm4.static.flickr.com 2008年底；\n《构建可扩展的Web站点》 上 没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中：记录会包含当时的存储所在的集群：\nuser_foo – farm1.static……/20060124_003.jpg\n\\ farm1.static……/20060324_005.jpg\n\\ farm1.static……/20060824_021.jpg\n\\ …"

"这次beta沙龙请了高春辉的团队来讲他们的经验。本来我是 希望老高讲，不过他说最近的系统主要是许超前在带人开发，所以实际的演讲人是许超前。\n国内最早让大家意识到网站的发展阶段的文档大概就是于敦德翻译的LiveJournal发展历程的ppt。这次许超前的演讲非常类似 LiveJournal的那篇。\n手机之家用了7年时间，发展到1000万以上用户，3000万以上帖子，1.1TB附件，每天780万以上的PV这个规模。这个数字虽然比 不上大型互联网公司，但是对一个只有几个人的技术团队，已经是一个很令人骄傲的数字了。\nLiveJournal在发展中一边用着开源软件，一边造轮子，最后造出来了memcached这个简单而强大的工具，最终成了这一代网站开发离不 开的东西。\n这次演讲有意思的部分就是从memcached相关的事情开始的。\n一 关于memcached的应用和管理。\nmemcached确实是个简单，好用，见效快的东西。不过简单也有简单的问题，程序员各有各的习惯，结果导致key很不规范，用什么方式的都有。 这个问题恐怕用过memcached的人都深有体会。当然，用开发规范来限制程序员的行为是一 …"

"软件架构师是个让人羡慕的职业，在市场经济成熟的国家，其薪酬已经达到医生、律师、注册会计师、建筑设计师的水平。但是薪酬高低与职业成熟度没有直 接的关系。重赏之下必有勇夫，高薪往往造成培养机制不健全的行业出现暂时的良莠不齐。目前我们还没有培养软件架构师的成熟机制，架构师大多是程序员自学成 材。程序员擅长和电脑打交道，却不善于处理工作中的人际关系。然而经验表明，除了技术特长，沟通协作的技巧、领导协调的能力、统筹取舍的经验在指挥开发项 目的过程中起着更重要的作用，而这些内容在计算机学院的课本里压根找不到。刚刚升任软件架构师的人，都有一段时间觉得茫然失措，因为有太多非技术问题困扰 着他们。\n****软件架构师是IT 行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事， 博文视点 即将翻译出版的新书《软件 架构师应该知道的97 件事》（ 97 Things Every Software Architect Should Know ）探讨的就是这个主题。\n本书的编辑Richard Monson-Haefel 是畅销书《 …"

"csdn作为国内最大的程序开发社区，影响了足足一代人。它是国内优秀杂志《程序员》的网站，我从前非常喜欢《程序员》这本杂志，里面的文章都非常优秀， 那时只有5元钱的我每个月花10块钱买本这样的杂志，看个三五年，都舍不得丢下。\n但是今天观察了下csdn站点的架构，发现做的比较简单，看来开发者比较喜欢从程序着手，着重优化代码和数据库，对系统整体架构思考的时间不多。\n我着重看了几个二级域名：www、news、bbs/community和blog，其中www、news这些静态文件都有通过squid缓存，用的 app_squid架构，然后是dns轮询做分流。\n在这里顺便讨论下为什么很多大型网站都喜欢用dns轮询来作首页，而不采用lvs或其它负载均衡策略。这是因为负载均衡都是把所有的访问先集中到一个ip 上，因为只有一个ip，所以无意间这个ip的稳定性就关系重大了。ip稳定性会受很多因素影响：n个交换机、线路、机器等等，颇为复杂。而首页很有可能会 用到异地的负载均衡，这么来不用dns，方案就很难设计了。现在的常用浏览器和下载软件，都有对dns的故障处理机制，所以dns也是可以屏蔽掉一些故障 的，虽然 …"

"这是一个最简洁的架构。在这个架构里，负载均衡器都可以省了，用最为廉价的dns来替代，dns的优点就是廉价，不用维护，也不愁性能和稳定，还可以跨机房多用几条带宽作分流。 另外，在图片服务中，可以选择用另一个域名做dns。优点是主站中的任何cookie等header不会带到图片服务中，省了不少上传流量和服务器可能有 的处理时间；缺点是多花了点域名的钱。目前门户都喜欢用这办法，小站用的话，用另一个域名还附带有一个特别的优点：因为部分域名服务商允许添加的二级域名 有限，所以用别的域名可以节约有限的域名资源。dns这一块也可以用泛域名，不过貌似国内的泛域名支持不是特别的稳定，有些网站的泛域名，在linux下 不能解析windows就正常，比较奇怪，我也没法解释。\n在这个架构里我总共开了36个域名，但是一时没有那么多机器，所以有一些域名指向同一台机器。一般来说，一个刚上线的项目，放一台机也未尝不可，但是链接 （包括域名）一定要固定下来，不然以后调整会非常痛苦。\n域名的事情还是比较简单的，只要照着填写web表单就完成了，配置四台nginx服务器当然也是非常简单的，因为不需要什么特殊的功能，所以四台机 …"

"原文链接：（俊麟 Michael’s blog ） http://www.toplee.com/blog/71.html 注：原文链接后的相关评论也很精彩，建议也参考一下原文链接后的评论。\n我在CERNET做过拨号接入平台的搭建，而后在Yahoo\u0026amp;3721从事过搜索引擎前端开发，又在MOP处理过大型社区猫扑大杂烩的架构升级等工作，同时自己接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，可以和大家一起探讨一下。\n一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。\n大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环 …"