文件的同步镜像在很多地方都需要用到，因此rsync这款免费软件得到了广泛的应用，包括在Windows平台上，都已经有了支持rsync的“cwRsyncServer”。 但是，我们一般都是通过结合crontab计划任务来实现文件同步的，这样做的缺点是效率低，不能做到实时同步。当然可以同编写一个脚本，时时监控！ 现在，在Linux平台下我们可以利用3.0内核的inotify监控文件系统机制，通过inotify-tools来实现实时同步了。 介绍inotify： Inotify 是一个 Linux特性，它监控文件系统操作，比如读取、写入和创建。Inotify 反应灵敏，用法非常简单，并且比 cron 任务的繁忙轮询高效得多。学习如何将 inotify 集成到您的应用程序中，并发现一组可用来进一步自动化系统治理的命令行工具。 具体操作如下： 1.安装所需软件 目前各大Linux发行版本都已经具有了rsync与inotify-tools的软件包，推荐通过apt-get等方式进行安装。 Ubuntu: [root@server1 ~]# apt-get install rsync inotify-tools 2.配置ssh key信任 建议通过普通用户进行操作，理由是通过root操作本身就危险，免密码登陆的root就更危险了。 在两台服务器上创建rsync用户 [root@server1 ~]# useradd -m rsync [root@server1 ~]# passwd rsync [root@server2 ~]# useradd -m rsync [root@server2 ~]# passwd rsync [root@server1 ~]# su – rsync [rsync@server1 ~]$ ssh-keygen -t rsa 在提示保存私钥（key）和公钥（public [...]
目前为止市面上常用的VPS架构包括：XEN、OpenVZ、KVM、Hyper-V、HVM等。 太详细的资料，网上一搜一大堆。在此不进行太多介绍了，只用最简单的语言来让你更快了解它： OpenVZ架构 基于linux操作系统，所以只能支持linux操作系统，无法安装windows；支持超售技术，母鸡2G内存，可以分成10个512内存小鸡，硬盘等也可以。 XEN架构 完全硬件分割，可以支持linux和windows操作系统；不支持超售，如果想分割出小鸡，必须要有足够的硬件资源。相对而讲，XEN的小鸡，用起来稳定性更好一些。 KVM架构 需要VNC连接，然后，自动上传或加载ISO文件，操作系统需要自行安装。相对讲，自由度和可订制度更高一些，例如：小夜购买的3刀KVM，就装的最简单版本debian，连ssh都木有。 Hyper-V架构 基于微软的系统，国内很大一部分采用这个架构，例如景安等，目前用过几家，centos模板都不太给力。 目前常用的架构，就是这些。
一、目前网站架构一般分成负载均衡层、 web层和数据库层，我其实一般还会多加一层，即文件服务器层，因为现在随着网站的PV越来越多，文件服务器的压力也越来越大；不过随着moosefs、 DRDB+Heartbeat+NFS的日趋成熟，这问题也不大了.网站最前端的负载均衡层称之为Director，它起的是分摊请求的作用，最常见的就是轮询。 二、F5是通过硬件的方式来实现负载均衡，它较多应用于CDN系统，用于squid反向加速集群的负载均衡，是专业的硬件负载均衡设备，尤其适用于每秒新建连接数和并发连接数要求高的场景；LVS和Nginx是通过软件的方式来实现的，但稳定性也相当强悍，在处理高并发的情况也有相当不俗的表现。 三、Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用 direct方式分流，效果较能得到保证。 四、目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived，以前 Nginx没有成熟的双机备份方案，但通过shell脚本监控是可以实现的，有兴趣的可具体参考我在51cto上的项目实施方案；另外，如果考虑 Nginx的负载均衡高可用，也可以通过DNS轮询的方式来实现，有兴趣的可以参考张宴的相关文章。 五、集群是指负载均衡后面的web集群或tomcat集群等，但现在的集群意义泛指了整个系统架构，它包括了负载均衡器以及后端的应用服务器集群等，现在许多人都喜欢把Linux集群指为LVS，但我觉得严格意义上应该区分开。 六、负载均衡高可用中的高可用指的是实现负载均衡器的HA，即一台负载均衡器坏掉后另一台可以在<1s秒内切换，最常用的软件就是Keepalived和Heatbeat，成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、 Nginx+Keepalived。 七、LVS的优势非常多：①抗负载能力强；②工作稳定(因为有成熟的HA方案)；③无流量；④基本上能支持所有的应用，基于以上的优点，LVS拥有不少的粉丝；但世事无绝对，LVS对网络的依赖性太大了，在网络环境相对复杂的应用场景中，我不得不放弃它而选用Nginx。 八、Nginx对网络的依赖性小，而且它的正则强大而灵活，强悍的特点吸引了不少人，而且配置也是相当的方便和简约，小中型项目实施中我基本是考虑它的；当然，如果资金充足，F5是不二的选择。 九、大型网站架构中其实可以结合使用F5、LVS或Nginx，选择它们中的二种或三种全部选择；如果因为预算的原因不选择F5，那么网站最前端的指向应该是LVS，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的。 十、VIP地址是Keepalived虚拟的一个IP，它是一个对外的公开IP，也是DNS指向的IP；所以在设计网站架构时，你必须向你的IDC多申请一个对外IP 十一、在实际项目实施过程中发现，Lvs和Nginx对https的支持都非常好，尤其是LVS，相对而言处理起来更为简便。 十二、在LVS+Keepalived及Nginx+Keepalived的故障处理中，这二者都是很方便的；如果发生了系统故障或服务器相关故障，即可将DNS指向由它们后端的某台真实web，达到短期处理故障的效果，毕竟广告网站和电子商务网站的PV就是金钱，这也是为什么要将负载均衡高可用设计于此的原因；大型的广告网站我就建议直接上CDN系统了。 十三、现在Linux集群都被大家神话了，其实这个也没多少复杂；关键看你的应用场景，哪种适用就选用哪种，Nginx和LVS、F5都不是神话，哪种方便哪种适用就选用哪种。 十四、另外关于session共享的问题，这也是一个老生长谈的问题了；Nginx可以用ip_hash机制来解决session的问题，而F5和LVS都有会话保持机制来解决这个问题，此外，还可以将session写进数据库，这也是一个解决session共享的好办法，当然这个也会加重数据库的负担，这个看系统架构师的取舍了。 十五、我现在目前维护的电子商务网站并发大约是1000左右，以前的证券资讯类网站是100左右，大型网上广告大约是3000，我感觉web层的并发越来越不是一个问题；现在由于服务器的强悍，再加上Nginx作web的高抗并发性，web层的并发并不是什么大问题；相反而言，文件服务器层和数据库层的压力是越来越大了，单NFS不可能胜任目前的工作，现在好的方案是moosefs和 DRDB+Heartbeat+NFS；而我喜欢的Mysql服务器，成熟的应用方案还是主从，如果压力过大，我不得不选择oracle的RAC双机方案。 十六、现在受张宴的影响，大家都去玩Nginx了(尤其是作web)，其实在服务器性能优异，内存足够的情况下，Apache的抗并发能力并不弱，整个网站的瓶颈应该还是在数据库方面；我建议可以双方面了解Apache和Nginx，前端用Nginx作负载均衡，后端用Apache作web，效果也是相当的好。 十七、Heartbeat的脑裂问题没有想象中那么严重，在线上环境可以考虑使用；DRDB+Heartbeat算是成熟的应用了，建议掌握。我在相当多的场合用此组合来替代EMC共享存储，毕竟30万的价格并不是每个客户都愿意接受的。 十八、无论设计的方案是多么的成熟，还是建议要配置Nagios监控机来实时监控我们的服务器情况；邮件和短信报警都可以开启，毕竟手机可以随身携带嘛;有条件的还可以购买专门的商业扫描网站服务，它会每隔一分钟扫描你的网站，如果发现没有alive会向你的邮件发警告信息或直接电话联系。 十九、至少网站的安全性问题，我建议用硬件防火墙，比较推荐的是华赛三层防火墙+天泰web防火墙，DDOS的安全防护一定要到位；Linux服务器本身的iptables和SElinux均可关闭，当然，端口开放越少越好。
动态应用，是相对于网站静态内容而言，是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件，比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。 大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。 大型动态应用系统又可分为几个子系统： 1）Web前端系统 2）负载均衡系统 3）数据库集群系统 4）缓存系统 5）分布式存储系统 6）分布式服务器管理系统 7）代码分发系统 Web前端系统 结构图： 为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。该Web前端系统基于 Apache/Lighttpd/Eginx等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理 负载均衡系统 负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs, nginx。大多数网站都是硬件、软件负载均衡系统并用。 数据库集群系统 结构图： 由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的，才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系？ 我们可以采用如上图所示的方案： 1) 使用 MySQL 数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。 2) 使用 MySQL Replication 机制实现快速将主库（写库）的数据库复制到从库（读库）。一个主库对应多个从库，主库数据实时同步到从库。 3) 写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。 4) 读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。 5) 数据库服务器和应用服务器分离。 6) 从数据库使用BigIP做负载均衡。 缓存系统 缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcached。使用正确的缓存系统可以达到实现以下目标： 1、使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。 2、减轻对数据库及存储集服务器的访问压力。 3、Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。 分布式存储系统 结构图： Web系统平台中的存储需求有下面两个特点： 1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。 2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。 因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。（这个地方需要加入对某个分布式存储系统的简单介绍。） 分布式服务器管理系统 结构图： 随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。 在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。它是基于C/S [...]
如果仓促而为，设计一个专题或者网站一定会成为恶梦。Web设计需要遵循一些准则并有计划地去做。 规则 #1 : 先出设计图 这是必须的。不要假设设计图在你的头脑中就开始设计web，必须要放到纸上。可以这样做： 1， 拿尺子、笔和纸，按照具体的尺寸一行一行地画下来； 2， 记得考虑分界线的长度等，这样才能符合CSS的像素； 3， 记下设计的每一个细节免得忘记，如果把所有细节都累积到最后将是巨大的麻烦。 规则 #2 :配色 这是设计的核心部分，只有颜色搭配合适才能使你的网页看起来不错。首先要决定的是主色，也即你在网页中多数使用的颜色；然后选择跟主色调搭配的第二颜色；不要选择超过三种颜色不然你的设计看起来会很乱。如果你想要更多的颜色，可以使用浅色或者深色的阴影来搭配主色调。 1， 浏览十个跟你网页有同样主色调的网页； 2， 给几个人看你的配色方案并取得反馈； 3， 从浏览的网页和反馈你将更好地完善你的颜色搭配。 规则 #3 : 从基本的版块开始构建 定下配色和设计图之后，从最基本的框架开始构建——我的意思是说不添加任何文本。因为在版面中加入文本会使得架构混乱。方法如下： 1， 每一个版块设定边界线，这样能够看到具体的尺寸和位置； 2， 对不同的版块使用不同的颜色，在完成版块后再改成你想要的颜色。 规则 #4 : 理清CSS 不要在你的HTML文件中将styling元素搞得太复杂，不然等到你修改的时候你就不得不到处搜索。所以将所有styling元素归置在一个单独的CSS文档中。 在styling之前理清你的CSS免得太过杂乱导致你多次重复同一件事。CSS支持继承，也即parent block的style可以用于child block.，充分利用这条特性。命名CSS分类名也要易懂易记。比如使用“main_content”而不是“div_1”。 规则 #5 : 制订多重 CSS 文档 我们都知道，使用浏览器可以轻易地看到网页的输出，但使用另一浏览器的时候则可能发现输出不正常。这不是什么稀奇事儿，因为每个浏览器对HTML和CSS的处理方式都不一样。 为避免这种情况，每个浏览器准备一个CSS文档，这样所有浏览器都可以正常浏览。虽然这有一定的难度，但是记着指望一个CSS文档来满足所有浏览器是不可能的。
相信互联网已经越来越成为人们生活中不可或缺的一部分。ajax，flex等等富客户端的应用使得人们越加“幸福”地体验着许多原先只能在C/S实现的功能。比如Google机会已经把最基本的office应用都搬到了互联网上。当然便利的同时毫无疑问的也使页面的速度越来越慢。自己是做前端开发的，在性能方面，根据yahoo的调查，后台只占5%，而前端高达95%之多，其中有88%的东西是可以优化的。 以上是一张web2.0页面的生命周期图。工程师很形象地讲它分成了“怀孕，出生，毕业，结婚”四个阶段。如果在我们点击网页链接的时候能够意识到这个过程而不是简单的请求-响应的话，我们便可以挖掘出很多细节上可以提升性能的东西。今天听了淘宝小马哥的一个对yahoo开发团队对web性能研究的一个讲座，感觉收获很大，想在blog上做个分享。 相信很多人都听过优化网站性能的14条规则。更多的信息可见developer.yahoo.com 1. 尽可能的减少 HTTP 的请求数 [content] 2. 使用 CDN（Content Delivery Network） [server] 3. 添加 Expires 头(或者 Cache-control ) [server] 4. Gzip 组件 [server] 5. 将 CSS 样式放在页面的上方 [css][/css] 6. 将脚本移动到底部（包括内联的） [javascript][/javascript] 7. 避免使用 CSS 中的 Expressions [css][/css] 8. 将 JavaScript 和 [...]
注意：这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。 文入正题： 首先讨论一下大型网站需要注意和考虑的问题 A. 海量数据的处理 众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。 B. 数据并发的处理 在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。 另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。 C. 文件存贮的问题 对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。 也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 所以我们不得不承认，文件存贮是个很不容易的问题 D. 数据关系的处理 我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。 E. 数据索引的问题 众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。 索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题， F. 分布式处理 对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。 G. Ajax的利弊分析 成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。 H. 数据安全性的分析 对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和qq空间的群发了。大家愿意试试，实际上并不是很难。 I. 数据同步和集群的处理的问题 当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题 K.数据共享的渠道以及OPENAPI趋势 Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。
到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。 如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。 拥抱熟知的技术 动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。 架构层次清晰化 起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。 Web Server <–> (AppServer)<–>Cache(eg. Memcached)<–>DB 层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。 数据冗余? 有必要 很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。 前端优化很重要 因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。 功能增加要谨慎 不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。 有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。 从开始考虑性能 [...]
本人作为一位web工程师，着眼最多之处莫过于性能与架构，本次幸得参与sd2.0大会，得以与同行广泛交流,于此二方面，有些架构设计的心得，不敢独享，与众友分享，本文是这次参会与众同撩交流的心得. 架构设计的几个心得： 一，不要过设计：never over design 这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。 ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构 web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的 二，web架构生命周期：web architecture‘s life cycle 既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你 所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长 google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的 三，缓存：Cache 空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快速为好。。 缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定 老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具 链接:钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢? 我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存 四，核心模块一定要自己开发：DIY your core module 这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其代码是非常可怕的 五，合理选择数据存储方式：reasonable data storage 我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？ 首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了) select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and [...]
Amoeba(变形虫)项目，专注 分布式数据库 proxy 开发。座落与Client、DB Server(s)之间。对客户 端透明。具有负载均衡、高可用性、sql过滤、读写分离、可路由相关的query到目标数据库、可并发请 求多台数据库合并结果。 主要解决： * 降低 数据切分带来的复杂多数据库结构 * 提供切分规则并降低 数据切分规则 给应用带来的影响 * 降低db 与客户端的连接数 * 读写分离 * 制定一种规则可支持DB线性扩容 目前在amoeba 框架上面已经实现了 amoeba for mysql. amoeba 中文文档下载地址： http://amoeba.meidusa.com/amoeba.pdf amoeba 未来发展方向： http://amoeba.meidusa.com/amoeba-big-picture.pdf
