此文的真正目的也就是让各位了解,作为一个网站架构的角色,你至少应当具备哪些知识点。当然,如果你现在已经是架构的角色,看到此文有不同见解,你可以提出来。
有人说过,架构的思想就是分分分。那就以此人的思想作为准则,看看是否真的是这样。
我们知道,网站的结构被模式分为MVC三层,作为架构,你考虑问题也主要是从这几个层面考虑。
1. 我们先看View层,这一层真接面向用户,用户的直接使用体验全在这上面。
这一层思考的方面主要有UI的优化,比方说javascript web2.0 框架的选型, Jquery, prototype, Exjs, Dojo. 比如果严格的DIV+CSS的UI制作,很多人常常会聊到压缩技术,也就是在这一层,适当的使用压缩技术可以减轻网络负担。有的网页的小图片过多,还会带来网站请求数的增加,所以有的网站会将单个网站尽量瘦身。但有些门户网站的首页实在瘦不下来,这时候所考虑的往往是将小图片合并,然后合理使用css 的定位技术。同时,还要合理的利用客户端的cache
刚刚我们提到过网络负担,想像一下,如果全世界都是你网站的粉丝,再好的服务器都会有些为难。 所以几乎所有的大型网站都会有load balance 技术。也就是说,并不是所有的用户请求都在同一个cpu上完成计算。另外,还有相关的技术可以使得南京用户的请求只在南京的服务器上请求资源,北京的用户则用北京的服务器。这也就是我们常说的CDN 内容分发网络. 但是,这些技术带来的难题便是数据同步,数据库同步,基至内存同步。load balance 叫做 负载均衡。它与我们通常讲的集群不太一样。F5是负载均衡的一种实现.
任何一种大型 应用都不可能只架设在一个Web Server上面,所以众多的架构者还会考虑将静态文件与执行文件存储在不同的服务器上。我们经常会遇到的静态文件服务器会有Lighttpd apche, 和 Nginx. 通过它们除了用来存储静态内容之外,还有的会做高速文件缓存如Squid和反向代理。
Java 里面用到的服务器会有Weblogic , Websphere或是 tomcat, 现在的tomcat 6可以很简单的将请求服务中的网络IO模型设置为 NIO, 这种方式也用在架构设计中,如果你需要的话。
2. 再看看Control层,有人讲这一层是程序员的事情,架构在这一层发挥空间不大。但我认为,这里面,架构师仍有它的发挥空间。如果要在这一层做一些performance tuning 的工作,程序员要注意的主要是一些锁机制,利用好工具找到程序哪里耗时最长,哪里耗内存最多,哪里用CPU最历害。
3. 存储层往往是架构师觉得最具挑战性的工作,在这一层,它们要防止过多的DB hits。 甚至有人提出,DB只不过是一个Backup 的工具,逻辑处理产生的临时数据都应存储在内存里面, 间隔一段时间将内存的数据刷到数据库就行了。如果使用文件系统,同样也要防止文件系统的频繁访产问。如果在网上找一下cache这个关键字,它们的名目多的让人一下找不到重点。Memcached, JBossCache, ENCache, OSCache等等。
存储层的IO逻辑也很有讲究,很容易遇到需要经常性的写入很多小文件的问题,这样就会带来小文件随机访问的负担,将众多小文件写入到一个大文件中,可以确保硬盘指针的顺序访问,而不是随机性的满盘去定位。
许多大型的网站,它们在自己的架构实践中常常指到自己的存储系统采用的根本就不是关系型数据库,也就是说现在出现了许多的基于Key, Value存储方式的产品,合理的设计加上可扩展的架构,相信你会在产品架构路上走得更顺。
4. 当然还有很多,我想到一点补一点吧。这次就写到这里。
有人说过,架构的思想就是分分分。那就以此人的思想作为准则,看看是否真的是这样。
我们知道,网站的结构被模式分为MVC三层,作为架构,你考虑问题也主要是从这几个层面考虑。
1. 我们先看View层,这一层真接面向用户,用户的直接使用体验全在这上面。
这一层思考的方面主要有UI的优化,比方说javascript web2.0 框架的选型, Jquery, prototype, Exjs, Dojo. 比如果严格的DIV+CSS的UI制作,很多人常常会聊到压缩技术,也就是在这一层,适当的使用压缩技术可以减轻网络负担。有的网页的小图片过多,还会带来网站请求数的增加,所以有的网站会将单个网站尽量瘦身。但有些门户网站的首页实在瘦不下来,这时候所考虑的往往是将小图片合并,然后合理使用css 的定位技术。同时,还要合理的利用客户端的cache
刚刚我们提到过网络负担,想像一下,如果全世界都是你网站的粉丝,再好的服务器都会有些为难。 所以几乎所有的大型网站都会有load balance 技术。也就是说,并不是所有的用户请求都在同一个cpu上完成计算。另外,还有相关的技术可以使得南京用户的请求只在南京的服务器上请求资源,北京的用户则用北京的服务器。这也就是我们常说的CDN 内容分发网络. 但是,这些技术带来的难题便是数据同步,数据库同步,基至内存同步。load balance 叫做 负载均衡。它与我们通常讲的集群不太一样。F5是负载均衡的一种实现.
任何一种大型 应用都不可能只架设在一个Web Server上面,所以众多的架构者还会考虑将静态文件与执行文件存储在不同的服务器上。我们经常会遇到的静态文件服务器会有Lighttpd apche, 和 Nginx. 通过它们除了用来存储静态内容之外,还有的会做高速文件缓存如Squid和反向代理。
Java 里面用到的服务器会有Weblogic , Websphere或是 tomcat, 现在的tomcat 6可以很简单的将请求服务中的网络IO模型设置为 NIO, 这种方式也用在架构设计中,如果你需要的话。
2. 再看看Control层,有人讲这一层是程序员的事情,架构在这一层发挥空间不大。但我认为,这里面,架构师仍有它的发挥空间。如果要在这一层做一些performance tuning 的工作,程序员要注意的主要是一些锁机制,利用好工具找到程序哪里耗时最长,哪里耗内存最多,哪里用CPU最历害。
3. 存储层往往是架构师觉得最具挑战性的工作,在这一层,它们要防止过多的DB hits。 甚至有人提出,DB只不过是一个Backup 的工具,逻辑处理产生的临时数据都应存储在内存里面, 间隔一段时间将内存的数据刷到数据库就行了。如果使用文件系统,同样也要防止文件系统的频繁访产问。如果在网上找一下cache这个关键字,它们的名目多的让人一下找不到重点。Memcached, JBossCache, ENCache, OSCache等等。
存储层的IO逻辑也很有讲究,很容易遇到需要经常性的写入很多小文件的问题,这样就会带来小文件随机访问的负担,将众多小文件写入到一个大文件中,可以确保硬盘指针的顺序访问,而不是随机性的满盘去定位。
许多大型的网站,它们在自己的架构实践中常常指到自己的存储系统采用的根本就不是关系型数据库,也就是说现在出现了许多的基于Key, Value存储方式的产品,合理的设计加上可扩展的架构,相信你会在产品架构路上走得更顺。
4. 当然还有很多,我想到一点补一点吧。这次就写到这里。