大型网站的架构和语言 大型网站开发流程和步骤

今天我们就来说说一个网站一般是如何一步一步搭建系统架构的 。虽然我们一开始就希望网站能有一个好的架构,但是马克思告诉我们,事物都是在发展中不断前进的,网站架构也是随着业务的拓展和用户的需求不断完善的 。下面是一个网站架构逐步发展的基本过程 。看完之后,请想一想你现在处于哪个阶段?
架构演进的第一步:web服务器和数据库的物理分离
起初,由于一些想法,在互联网上建立了一个网站 。这时候连主机都可能是租来的 。但是,由于本文只关注架构的演进,所以我们假设此时已经托管了一台主机,并且有一定的带宽 。这时候因为网站有一定的特点,所以吸引了一部分人来访问 。渐渐的,你发现系统的压力越来越高,反应速度越来越慢 。这个时候很明显是数据库和应用交互,应用有问题,数据库也容易出问题 。当数据库出错时,应用程序也容易出现问题 。所以它进入了进化的第一阶段:应用程序和数据库被物理分离,变成了两台机器 。这个时候没有新的技术需求,但是你发现真的管用 。系统恢复到了以前的响应速度,并支持更高的流量,数据库和应用程序之间不再相互影响 。
完成这一步后,请看一下系统图:
架构进化的第二步:增加页面缓存
好景不长 。随着访问的人越来越多,你发现响应速度又开始变慢了 。找出原因,发现访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢 。但是数据库连接不能开太多,否则数据库机的压力会很大 。因此,考虑采用缓存机制来减少数据库连接资源的竞争和数据库读取的压力 。这时候,首先我们可能会选择使用squid等类似的机制来缓存系统中相对静态的页面(比如一两天就要更新的页面)(当然也可以使用让页面静态化的方案),这样就可以很好的减少WebServer的压力和对数据库连接资源的争夺,而不需要对程序做任何修改 。好了,于是我们开始用squid来缓存相对静态的页面 。
完成这一步后,请看一下系统图:
这一步涉及到这些知识体系:
前端页面缓存技术,比如squid,要想用好,就得掌握squid的实现和缓存的失效算法 。
架构进化第三步:增加页面碎片缓存
加了squid作为缓存后,整个系统的速度确实提高了,WebServer的压力也开始减小 。但是随着访问次数的增加,发现系统又开始变得有些慢了 。在尝到了squid等动态缓存的好处后,我开始考虑是否可以缓存当前动态页面中相对静态的部分,于是我考虑采用ESI这样的页面碎片缓存策略 。好了,于是我开始用ESI来缓存动态页面相对静态的片段 。
完成这一步后,请看一下系统图:
这一步涉及到这些知识体系:
页面缓存技术,如ESI等 。要想用好,还需要掌握ESI的实现等 。
架构演进的第四步:数据缓存
再次使用ESI等技术提升系统缓存效果后,系统的压力确实进一步减轻,但同样的,随着访问次数的增加,系统开始变慢 。搜索后可能会发现系统中存在一些重复获取数据信息的地方,比如获取用户信息 。这时,我们开始考虑是否也可以缓存这些数据信息,于是我们将这些数据缓存在本地内存中 。改完之后完全符合预期,系统的响应速度恢复了,数据库的压力又减轻了不少 。
完成这一步后,请看一下系统图:
这一步涉及到这些知识体系:
缓存技术,包括地图数据结构、缓存算法、所选框架本身的实现机制等 。
架构演进的第5步:添加web服务器
好景不长 。结果发现,随着系统访问量的再次增加,webserver机器的压力会在高峰期上升到一个相对较高的水平 。这时我们开始考虑增加一个webserver,也是为了同时解决可用性问题,避免单个webserver down机无法使用 。做出这些考虑后,我们决定添加一个webserver,在添加webserver时,我们会遇到一些问题 。典型的有:
1.如何分配对这两台机器的访问权限?这时候通常要考虑的解决方案是Apache自己的负载均衡方案,或者是LVS之类的软件负载均衡方案;
2.如何保持状态信息的同步,比如用户会话等 。此时,要考虑的解决方案包括写入数据库、写入存储、cookie或同步会话信息等机制 。
3.如何保持数据缓存信息的同步,比如之前缓存的用户数据等 。这时通常考虑的机制是缓存同步或者分布式缓存;
4.如何让上传文件的类似功能继续正常工作?这时,通常考虑的机制是使用共享文件系统或存储等 。;
解决了这些问题之后,webserver的数量终于增加到了两个,系统也终于恢复到了之前的速度 。


推荐阅读