大型网站架构演变历程.docx

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训, 两天 12 个小时信息量非常大, 知识的广度和难度也非常大, 培训完后我很难完整理出全部听到的知识, 今天我换了个思路是回味这次培训, 这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。大型网站定义首先我们要思考一个问题, 什么样的网站才是大型网站, 从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标, 懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标, 如果按这些标准那么像 hao123 这样的网站就是大型网站了,如下图所示: 其实这种网站访问量非常大, 并发数也非常高, 但是它却能用最为简单的 Web 技术来实现: 我们只要保持网站的充分的静态化,多部署几台服务器,那么就算地球上所有人都用它,网站也能正常运行。大型网站是技术和业务的结合,一个满足某些用户需求的网站只要技术和业务二者有一方难度很大,必然会让企业投入更多的、更优秀的人力成本实现它,那么这样的网站就是所谓的大型网站了。服务器部署一个初建的网站往往用户群都是很小的, 最简单的网站架构就能解决实际的用户需求, 当然为了保证网站的稳定性和安全性, 我们会把网站的应用部署到至少两台机器上, 后台的存储使用数据库,如果经济实力允许,数据库使用单台服务器部署,由于数据是网站的生命线, 因此我们常常会把部署数据库的服务器使用的好点,这个网站结构如下所示: 这个结构非常简单,其实大部分初建网站开发里往往业务逻辑没有企业级系统那么复杂,所以只要有个好的 idea ,建设一个新网站的成本是非常低的,所使用的技术手段也是非常的基本和简单。我们要准备三台服务器, 而且还要租个机房放置我们的服务器, 这些成本对于草根和屌丝还是非常高的, 幸运的是当下很多大公司和机构提供了云平台, 我们可以花费很少的钱将自己的应用部署到云平台上,这种做法我们甚至不用去考虑把应用、数据库分开部署的问题,更加进一步的降低了网站开发和运维的成本, 但是这种做法也有一个问题, 就是网站的小命被这个云平台捏住了,如果云平台挂了,俺们的网站服务也就跟着挂了。这里我先讲讲自己独立使用服务器部署网站的问题, 如果我们要把网站服务应用使用多台服务器部署,这么做的目的一般有两个: 不过要做到以上两点, 并不是我们简单将网站分开部署就可以满足的, 因为大多数网站在用户使用时候都是要保持用户的状态,具体点就是网站要记住请求是归属到那一个客户端,而这个状态在网站开发里就是通过会话 session 来体现的。 Session 机制分开部署的 Web 应用服务要解决的一个首要问题就是要保持不同物理部署服务器之间的 session 同步问题, 从而达到当用户第一次请求访问到服务器 A, 第二个请求访问到服务器 B, 网站任然知道这两个请求是同一个人, 解决方案很直接: 服务器A 和服务器B上的 sessio n 信息要时刻保持同步,那么如何保证两台服务器之间 session 信息的同步呢? 为了回答上面的问题,我们首先要理解下 session 的机制, session 信息在 Web 容器里都是存储在内存里的, Web 容器会给每个连接它的客户端生成一个 sessionid 值,这个 sessionid 值会被 Web 容器置于 http 协议里的 cookie 域下,当响应被客户端处理后,客户端本地会存储这个 sessionid 值, 用户以后的每个请求都会让这个 sessionid 值随 cookie 一起传递到服务器, 服务器通过 sessionid 找到内存中存储的该用户的 session 内容, sessio n 在内存的数据结构是一个 map 的格式。那么为了保证不同服务器之间的 session 共享,那么最直接的方案就是让服务器之间 session 不断的传递和复制,例如 java 开发里常用的 tomcat 容器就采用这种方案,以前我测试过 tomcat 这种 session 同步的性能,我发现当需要同步的 Web 容器越多, Web 应用所能承载的并发数并没有因为服务器的增加而线性提升,当服务器数量达到一个临界值后, 整个 Web 应用的并发数甚至还会下降,为什么会这样了? 原因很简单, 不同服务器之间 session 的传递和复制会消耗服务器本身的系统资源, 当服务器数量越大, 消耗的资源越多, 当用户请求越频繁, 系统消耗资源也会越来越大。如果我们多部署服务器的目的只是想保证系统的稳定性,采用这种方案还是不错的,不过 web 应用最好部署少点,这样才不会影响到 web 应用的性能问题,如果我们还想提升网站的并发量那么就得采取其他的方案了。 Session 案例解析时下使用的比