普通微博系统结构.docVIP

普通微博系统结构 wudi1975@163.com 2012.2.1 1.系统概述 （此处删除数百字）Balabala讲了一通项目背景，删之毫无鸭梨。 2.系统压力分析和估算 微博这种系统特点非常鲜明，那就是非常多的人，非常频繁地使用非常少量的核心功能：发微博、查微博、评论微博、被通知有新微博（被@或者关注引导）。微博的事务性要求非常低，但并发量和数据量极大。 2.1写并发 （此处删除数百字）简要估算了一下微博系统的承受压力的目标，结果为：系统长期支持一千的并发，短时间可以支持一万的并发，那么平均每秒产生的数据就是几兆。 2.2读并发 参考新浪微博等需要支持大并发、大压力问题的系统解决方案，一开始就采取了把读、写分开的方式来处理数据压力问题，写的压力从业务角度而言比较纯粹，读的压力则比较复杂，涉及的数据量也更大，但是解决的手段也多，下文再详细分析。 3.基本结构 新浪微博压力比本系统大，而且其架构已经证明了事实可行，所以，本系统尽可能参考新浪微博的架构。 3.1基本B/S系统三层架构 图2.1 3.1.1简述 如上图2.1所示，这是一个最基本的三层架构的B/S系统。 用户通过浏览器访问web站点来进行业务操作，浏览器可以是：IE、google chrome、fireFox等。被访问的web站点可以是任何形式：php、java、.net等等。 客户浏览器与web站点之间的通信是采用http协议(有安全性要求则采用https协议)来实现，这个通信是在广域网进行。 Web站点往往会采用一个MVC框架来组织业务实现，在此，MVC不是重点不再赘述。 Web站点的数据持久化功能会采用一个数据库管理系统来辅助实现，web站点的各种业务模块会通过socket（TCPIP协议的一个实现）工具来实现与数据库的通信。这个通信是在局域网进行。 3.1.2系统瓶颈 B/S系统的瓶颈会出现在以下几个方面： 用户并发请求太大，导致web服务器无法及时处理完所有请求 用户请求的数据量太大，导致web服务器的上行带宽被耗尽 业务计算量太大，web服务器cpu被耗尽 业务计算产生的中间数据太多，web服务器内存耗尽，cpu时间被消耗在处理缺页中断上 用户并发请求太大，需要的数据库链接数超过连接池的性能指标，导致无法获取数据库链接 数据库压力过大，IO量超过硬件性能指标。 以上6种问题，本系统会碰到A、B、E、F。 3.1.3针对大运算量和大量中间数据的扩展方法 图3.1.3 如上图3.1.3所示，上部灰色方框部分是对图2.1中web服务器层的细化，web服务器的作用是响应http请求，根据请求的url返回对应的文件数据（html、图片、音频、视频等静态内容）， web服务器本身是不支持动态内容的处理的，web服务器会检测接收到的请求是否动态内容请求，如果是，则在配置文件中查询是否有动态处理扩展，如果有，则将请求转交给动态处理扩展的模块，例如，apache就是单纯的web服务器，tomcat就是提供动态内容处理的模块。Tomcat接收apache转发的请求，处理完成后，将数据返回给apache，由apache返回给http请求方。 Apache是基本web服务器，apache + tomcat是广义上的web服务器。在计算压力不大的情况下，web服务器自己提供动态内容处理也行，在计算压力大的情况下一般会把动态内容处理的业务交给第三方专用模块应用服务器来处理。这种应用服务有很多技术实现，如：EJB、SOAP、CICS等。 使用专门的应用服务器来解决计算压力，可以解决瓶颈C和D。而微博这种系统，从业务上来说，已经是极度简化的功能，没有什么计算压力，不必使用专门的应用服务器。 3.1.4针对大并发量和大数据量的扩展技术 大并发量和大数据量一直就是B/S系统要面对的主要问题，有非常多的解决手段，有些是技术层次的、有些是设计层次的、有些是硬件层次的、有些是第三方提供的，需要根据情况从中选择最合适的组合来使用。 尽可能让用户访问静态资源 对应极端的压力需要采用极端的措施，各大门户网站和购物网站是典型的大并发量的例子，他们采取的措施是实现CMS（内容管理系统）的功能，并且，尽量让用户访问静态内容，减少实时计算处理，例如：记者发布一则新闻或者商家发布一批新商品，系统并不是等用户查询时从数据库中查找新闻或商品，然后生成显示页面的内容，而是在发布的时候就生成了静态内容，并且将链接加入到一系列需要这个内容的页面中，或者直接将静态内容嵌入到需要的页面中。这种逻辑的实现，比动态查询要复杂得多，得到的好处有两点： 第一，用户查询信息时不再需要实时查询数据库、生成html标记，减轻了大并发量时的服务器压力； 第二，静态的内容可以简单使用web服务器集群来线性扩展性能，只要增加硬件设备就能提供