在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局;2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等;3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。
架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。
这三个维度分别为面向对象、面向方面、面向服务。
这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。
面向对象
面向对象提出有三个主要目标:重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。
在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。
面向方面
面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。
面向方面不仅仅是一门编程技术，同样也是一种架构设计的思路。如果说OO是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。
简单地理解，OO与AOP分别从两个不同的角度给我们提供了分析系统的思路。面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。
我们认为OO是接近于人类认识自然的思维方式，但对于东方而言却并不一定是这样的。
当西方人看到一个复杂系统的时候，只会有一种思路，就是“分解”，将系统分解成一块一块，然后每个部分进行研究。
当东方人看到一个复杂系统的时候，更多地会关注系统中存在的关系，将系统作为一个有机的整体进行研究，这也是东方和西方在事物看法上存在的差异。
这两种思维方式都没有问题，如果结合起来分析问题，解决问题会更好。面向对象与面向方面也同样如此，都能对应到人类认识自然的思维方式上。
面向服务
面向服务可以说是最近炒得比较火热的概念。包括现在提到的SaaS（Software as a service），软件即服务。准确而言，面向服务不仅仅是软件行业的概念，这个要从社会的产业结构说起。
社会产业总共分为三个，第一产业农业，第二产业工业，第三产业服务业。最早社会的主要产业是第一产业农业，将近有几万年的历史。
十八世纪下半叶在英国开始的工业革命，对人们的生活产生了根本性的影响，社会的主要产业成了第二产业工业。
现在仍然属于工业时代，或者有人说的“后工业时代”。而在后工业时代，社会的经济体制必定要向第三产业服务业逐渐转型。面向服务其实是社会经济体制重心的一种迁移。
还是说回到软件行业，社会的主要产业将转变成服务业，自然软件行业也会出现对应的变化，那就是这里提到的面向服务。面向服务今后会影响到软件的交付模式，会对整个软件行业的体制产生影响。
而说到架构层面，面向服务是系统发布功能的一种方式。并且基于这种方式下不同的系统之间能有效地通信、协作。常见的实现技术就是Web Service。
软件全局观
软件架构设计的三个维度：面向对象、面向方面、面向服务。
最年长的一个维度就是面向对象，发展了好几十年，也是相对而言比较成熟的一个维度。它解决的问题是系统内部结构的设计。
面向方面思想的提出能够弥补面向对象的缺陷。面向对象的方式不能实现横切关注点的分离，而面向方面正是为了解决这个问题。面向方面与面向对象一样都是解决系统内部结构的设计。
面向服务更多的是涉及到系统的外部，简单地说就是发布功能。它并不关注系统内部结构的实现，所以说面向服务与面向对象或者面向方面并不冲突。
这三个维度并不是绝对孤立的，它们之间会互相影响、制约，相互发展的。我们在分析架构的时候需要同时考虑到这三个维度的问题，这样有助于我们设计出更加优秀的架构。
java高并发解决方案
1、HTML静态化 2、图片服务器分离 3、数据库集群和库表散列 4、缓存 5、镜像 6、负载均衡
一：高并发高负载类网站关注点之数据库
没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用，数据库的响应是首先要解决的。
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。
以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。
需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，
或者干脆自己做，因为php4中mysql的链接池经常出问题。
有几个常用的措施
1、对常用功能建立缓存模块
2、网页尽量静态化
3、使用单独的图片服务器，降低服务器压力，使其不会因为图片加载造成崩溃
4、使用镜像解决不同网络接入商和不同地域用户访问差异
5、数据库集群图表散列
6、加强网络层硬件配置，硬的不行来软的。
7、终极办法：负载均衡
如何分析系统的性能问题：
从以下几个维度进行考虑
当并发压力加大时，往往是吞吐量上不去，肯定是某一个方面出现了瓶颈，（比如CPU，内存（大量的swap），磁盘IO，网络IO，操作系统，应用）
如果CPU比较高（user,sys,wa），user高，可以把系统的线程dump出来，观察系统正在做的逻辑，优化逻辑；sys高，则说明kernel耗费了大量的CPU时间，比如当前的线程的切换比较厉害等等；wa高一般是IO操作比较频繁，CPU频繁调度
查看CPU，还需要观察系统load,一般不要超过系统的物理core数量。
如果出现大量的swap，说明物理内存不足
磁盘IO（文件系统cache）
网络IO（包的数量，以及大小）
应用本身，比如锁，还有连接池的大小设置，并发连接数限制(这种是资源利用率不高，但是tps上不去)
操作系统（文件句柄，socket优化等）
如何设计高并发的系统
a、空间换时间（多级缓存）
1）客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）
2）反向代理缓存
3）应用端的缓存(memcache)
4）内存数据库
5）Buffer机制（数据库，中间件等）
b、伸缩能力
1）拆分
业务拆分,逻辑分段（非阻塞，能异步则异步）
数据拆分（分库分表）
2）无状态
c、优化资源利用
1）基于逻辑的不同，采取不一样的策略，优化资源利用，按照业务进行资源分配（业务分流，线程分配）
2）流控
3）超时控制
首先在整个网络的高度讨论了使用镜像网站，CDN内容分发网络等技术对负载均衡带来的便利及各自的优缺点比较。然后在局域网层次对第四层交换技术，包括硬件解决方案F5和软件解决方案LVS，进行了简单的讨论。接下来在单服务器层次，本文着重讨论了单台服务器的Socket优化，硬盘级缓存技术，内存级缓存技术，CPU与IO平衡技术（即以运算为主的程序与以数据读写为主的程序搭配部署），读写分离技术等。在应用层，本文介绍了一些大型网站常用的技术，以及选择使用该技术的理由。最后，在架构的高度讨论了网站扩容，容错等问题。
Web2.0网站所有典型特征：高并发，高流量，数据量大，逻辑复杂，用户分散等等
2.1 镜像网站技术
镜像网站是指将一个完全相同的站点放到几个服务器上，分别有自己的URL，这些服务器上的网站互相称为镜像网站［13］。镜像网站和主站并没有太大差别，或者可以视为主站的拷贝。镜像网站的好处是：如果不能对主站作正常访问（如服务器故障，网络故障或者网速太慢等），仍能通过镜像服务器获得服务。不便之处是：更新网站内容的时候，需要同时更新多个服务器；需要用户记忆超过一个网址，或需要用户选择访问多个镜像网站中的一个，而用户选择的，不一定是最优的。在用户选择的过程中，缺乏必要的可控性。
2.2 CDN内容分发网络
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的互联网中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，分散服务器的压力，解决互联网拥挤的状况，提高用户访问网站的响应速度。从而解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题［14］。
CDN与镜像网站技术的不同之处在于网站代替用户去选择最优的内容服务器，增强了可控制性。CDN其实是夹在网页浏览者和被访问的服务器中间的一层镜像或者说缓存，浏览者访问时点击的还是服务器原来的URL地址，但是看到的内容其实是对浏览者来说最优的一台镜像服务器上的页面缓存内容。这是通过调整服务器的域名解析来实现的。使用CDN技术的域名解析服务器需要维护一个镜像服务器列表和一份来访IP到镜像服务器的对应表。当一个用户的请求到来的时候，根据用户的IP，查询对应表，得到最优的镜像服务器的IP地址，返回给用户。这里的最优，需要综合考虑服务器的处理能力，带宽，离访问者的距离远近等因素。当某个地方的镜像网站流量过大，带宽消耗过快，或者出现服务器，网络等故障的时候，可以很方便的设置将用户的访问转到另外一个地方（图2）。这样就增强了可控制性。
图2 CDN原理示意图
CDN网络加速技术也有它的局限性。首先，因为内容更新的时候，需要同步更新多台镜像服务器，所以它也只适用于内容更新不太频繁，或者对实时性要求不是很高的网站；其次，DNS解析有缓存，当某一个镜像网站的访问需要转移时，主DNS服务器更改了IP解析结果，但各地的DNS服务器缓存更新会滞后一段时间，这段时间内用户的访问仍然会指向该服务器，可控制性依然有不足。
目前，国内访问量较高的大型网站如新浪、网易等的资讯频道，均使用CDN网络加速技术（图3），虽然网站的访问量巨大，但无论在什么地方访问，速度都会很快。但论坛，邮箱等更新频繁，实时性要求高的频道，则不适合使用这种技术。
2.4 网络层架构小结
从整个互联网络的高度来看网站架构，努力的方向是明确的：让用户就近取得内容，但又要在速度和可控制性之间作一个平衡。对于更新比较频繁内容，由于难以保持镜像网站之间的同步，则需要使用其他的辅助技术。
3 交换层架构
3.1 第四层交换简介
按照OSI［16］七层模型，第四层是传输层。传输层负责端到端通信，在IP协议栈中是TCP和UDP所在的协议层。TCP和UDP数据包中包含端口号（port number），它们可以唯一区分每个数据包所属的协议和应用程序。接收端计算机的操作系统根据端口号确定所收到的IP包类型，并把它交给合适的高层程序。IP地址和端口号的组合通常称作“插口（Socket）”。
第四层交换的一个简单定义是：它是一种传输功能，它决定传输不仅仅依据MAC地址(第二层网桥)或源/目标IP地址(第三层路由)，而且依据IP地址与TCP/UDP (第四层) 应用端口号的组合（Socket）［17］。第四层交换功能就像是虚拟IP，指向实际的服务器。它传输的数据支持多种协议，有HTTP、FTP、NFS、Telnet等。
以HTTP协议为例，在第四层交换中为每个服务器组设立一个虚拟IP（Virtue IP，VIP），每组服务器支持某一个或几个域名。在域名服务器（DNS）中存储服务器组的VIP，而不是某一台服务器的真实地址。
当用户请求页面时，一个带有目标服务器组的VIP连接请求发送给第四层交换机。第四层交换机使用某种选择策略，在组中选取最优的服务器，将数据包中的目标VIP地址用实际服务器的IP地址取代，并将连接请求传给该服务器。第四层交换一般都实现了会话保持功能，即同一会话的所有的包由第四层交换机进行映射后，在用户和同一服务器间进行传输［18］。
第四层交换按实现分类，分为硬件实现和软件实现。
3.2 硬件实现
第四层交换的硬件实现一般都由专业的硬件厂商作为商业解决方案提供。常见的有Alteon［19］，F5［20］等。这些产品非常昂贵，但是能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了［21］。鉴于条件关系，这里不展开讨论。
3.3 软件实现
第四层交换也可以通过软件实现，不过性能比专业硬件稍差，但是满足一定量的压力还是可以达到的，而且软件实现配置起来更灵活。 软件四层交换常用的有Linux上的LVS（Linux Virtual Server），它提供了基于心跳（heart beat）的实时灾难应对解决方案，提高了系统的鲁棒性，同时提供了灵活的VIP配置和管理功能，可以同时满足多种应用需求［22］。
4.3 硬盘级缓存
硬盘级别的缓存是指将需要动态生成的内容暂时缓存在硬盘上，在一个可接受的延迟时间范围内，同样的请求不再动态生成，以达到节约系统资源，提高网站承受能力的目的。Linux环境下硬盘级缓存一般使用Squid［27］。
Squid是一个高性能的代理缓存服务器。和一般的代理缓存软件不同，Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。它接受来自客户端对目标对象的请求并适当地处理这些请求。比如说，用户通过浏览器想下载（即浏览）一个web页面，浏览器请求Squid为它取得这个页面。Squid随之连接到页面所在的原始服务器并向服务器发出取得该页面的请求。取得页面后，Squid再将页面返回给用户端浏览器，并且同时在Squid本地缓存目录里保存一份副本。当下一次有用户需要同一页面时，Squid可以简单地从缓存中读取它的副本，直接返回给用户，而不用再次请求原始服务器。当前的Squid可以处理HTTP， FTP， GOPHER， SSL和WAIS等协议。
Squid默认通过检测HTTP协议头的Expires和 Cache-Control字段来决定缓存的时间。在实际应用中，可以显式的在服务器端脚本中输出HTTP头，也可以通过配置apache的mod_expires模块，让apache自动的给每一个网页加上过期时间。对于静态内容，如图片，视频文件，供下载的软件等，还可以针对文件类型（扩展名），用 Squid 的 refresh_pattern 来指定缓存时间。
Squid 运行的时候，默认会在硬盘上建两层hash目录，用来存储缓存的Object。它还会在内存中建立一个Hash Table，用来记录硬盘中Object分布的情况。如果Squid配置成为一个Squid集群中的一个的话，它还会建立一个 Digest Table(摘要表)，用来存储其它 Squid 上的Object摘要。当用户端想要的资料本地硬盘上没有时，可以很快的知道应该去集群中的哪一台机器获得。在硬盘空间快要达到配置限额的时候，可以配置使用某种策略（默认使用LRU：Least Recently Used-最近最少用）删除一些Object，从而腾出空间［28］［29］。
集群中的Squid Server 之间可以有两种关系：第一种关系是：Child 和 Parent。当 Child Squid Server 没有资料时，会直接向 Parent Squid Server 要资料，然后一直等，直到 Parent 给它资料为止。 第二种关系是：Sibling 和 Sibling。当 Squid Server 没有资料时，会先向 Sibling 的 Squid Server 要资料，如果 Sibling 没资料，就跳过它向 Parent 要或直接上原始网站去拿。
默认配置的Squid，没有经过任何优化的时候，一般可以达到 50% 的命中率［30］（图4）。如果需要，还可以通过参数优化，拆分业务，优化文件系统等办法，使得Squid达到 90% 以上的缓存命中率。 Squid
处理TCP连接消耗的服务器资源比真正的HTTP服务器要小的多，当Squid分担了大部分连接，网站的承压能力就大大增强了。
创造新一代Web 2.0网站的技术越来越精简和简化。程序员从使用复杂的企业级Java堆栈和数据库（e.g.Oracle），切换到更直接的LAMP组合（Linux操 作系统，Apache，MySQL和PHP/ Python/Perl）。新的语言和框架（e.g.Diango和Ruby on Rails）使得网站和数据库之间的层自动化。前端框架（e.g.jQuery）帮助简化了不同浏览器之间错综复杂的关系。云服务（e.g.Amazon Web Services）简化了部署，提供了钥匙网络。
古老的Web前端，现在都演变成CSS4、JSON和JavaScript的MVC框架，比如 Angular.js和Backbone.js。
最近几年，web架构拥抱解耦的理念并且将应用层设施从web服务器中分离。虽然现在仅仅是将原先基于LAMP(Linux, Apache, MySQL, PHP, Python or Perl)所构建的网站，变为基于LEMP（E表示Engine x）的。
几台服务器,就是想问问做没做基本的图片服务器和数据库服务器分离,
那么问题就来了，原因可能是如下几种：
1.上传的文件太多(或者图片太多)。
2.网页的页面压力太大写的不够好。
3.数据库的压力太大。
思路
第一种问题解决方案，上传的文件太多,这个问题最难解决了,同时也是最简单的,因为解决的方案就是一个字钱，君不见优酷土豆此类网站烧钱之甚啊!因为涉及到并发,打个比方,一条高速公路是100M，那么你的并行量级咱们就按照100M计算，(这种说法已经最笨了)假设每个人的上传5M的文件和图片那么这个网站的并发我是不是就可以认为是100/5 = 20呢? 也就是说这个网站只能20个人访问了，多了轻则卡顿丢失文件,总则就是网站崩溃了,这种问题也最难解决,因为文件和图片永远都是网站流量的最大杀手,没什么好办法只能做图片服务器分离.文件服务器分离了,(但是这里又违背了人家只用一台服务器的原则),有的公司看上去很大,但是老板就是对IT部门不重视不投资那么多没什么办法。
从上面的分析我们可以总结出iis读取页面的机理和原因：
第一种:就是对internet请求进行分析和归类,分成静态页面请求和动态页面请求,所谓的静态请求就是html静态页面，动态请求我们暂时理解为aspx，或者cshtml请求。
第二种:就是对动态页面请求进行分析，等到动态请求分析成为静态请求的时候组合再一起返回给浏览器。
所以我得出了两个结论:
第一种，我们把一些流量高但是页面数据不总是变化页面我们可以考虑使其静态化。这也是现在一些流行网站的做法。
第二种，我们可以尽力的减少动态请求分析的时间。
第三种数据库压力大的解决方案,这种问题很多就是程序员自己自身素质的问题了,或者架构没有搭建好。
我猜想原因可能是:
第一种，有的人喜欢把文件或者图片变成二进制保存到数据库里，这样参照第一种崩溃原因。
第二种，就是有的程序员他很擅长数据库方面的技术,所以他把所有的业务和逻辑都封装成了存储过程保存在数据库里，后台代码只有一个事务回滚甚至没有，这样的业务，在后台响应时间内接收不到回应自然会报错了。
其他
1.根据测试报告中所描述的时间，找出瓶颈所在，确定优化方案，这个很重要，是行动的指南。
2.确定优化目标，例如原来100秒，优化到6秒；
3.分析网络连接点，将能够从服务端可以取出的数据，一次取出，在客户端进行逻辑运算。
4.需要考虑在网络不稳定的情况或异常关机的情况下，对于客户端的未保存的数据进行缓存，保证用户输入数据的安全。
5.除了减少中间层的访问次数，对于查询数据较慢的表格也需要加如Index进行优化。
根据上述方法，优化已经基本达到了目标，总结如下：
1.优化无止尽，需要找出瓶颈，确定优化目标；
2.优化不仅仅考虑中间层的连接次数，对于数据库的性能优化也同样重要。遇到过原来一个查询需要8000MS，通过数据库和SQL语句的优化，达到了500MS；
3.优化需要结合具体的程序考虑，需要层层跟踪。例如，需要跟踪哪里进行了中间层连接，这个连接是否有必要。
4.利用缓存时候，需要考虑缓存数据的一致性。
5.保存数据，进行批量中间层保存；
6.独立的事务处理可以在PL/SQL里面实现，这样效率最高。
架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。
这三个维度分别为面向对象、面向方面、面向服务。
这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。
面向对象
面向对象提出有三个主要目标:重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。
在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。
面向方面
面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。
面向方面不仅仅是一门编程技术，同样也是一种架构设计的思路。如果说OO是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。
简单地理解，OO与AOP分别从两个不同的角度给我们提供了分析系统的思路。面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。
我们认为OO是接近于人类认识自然的思维方式，但对于东方而言却并不一定是这样的。
当西方人看到一个复杂系统的时候，只会有一种思路，就是“分解”，将系统分解成一块一块，然后每个部分进行研究。
当东方人看到一个复杂系统的时候，更多地会关注系统中存在的关系，将系统作为一个有机的整体进行研究，这也是东方和西方在事物看法上存在的差异。
这两种思维方式都没有问题，如果结合起来分析问题，解决问题会更好。面向对象与面向方面也同样如此，都能对应到人类认识自然的思维方式上。
面向服务
面向服务可以说是最近炒得比较火热的概念。包括现在提到的SaaS（Software as a service），软件即服务。准确而言，面向服务不仅仅是软件行业的概念，这个要从社会的产业结构说起。
社会产业总共分为三个，第一产业农业，第二产业工业，第三产业服务业。最早社会的主要产业是第一产业农业，将近有几万年的历史。
十八世纪下半叶在英国开始的工业革命，对人们的生活产生了根本性的影响，社会的主要产业成了第二产业工业。
现在仍然属于工业时代，或者有人说的“后工业时代”。而在后工业时代，社会的经济体制必定要向第三产业服务业逐渐转型。面向服务其实是社会经济体制重心的一种迁移。
还是说回到软件行业，社会的主要产业将转变成服务业，自然软件行业也会出现对应的变化，那就是这里提到的面向服务。面向服务今后会影响到软件的交付模式，会对整个软件行业的体制产生影响。
而说到架构层面，面向服务是系统发布功能的一种方式。并且基于这种方式下不同的系统之间能有效地通信、协作。常见的实现技术就是Web Service。
软件全局观
软件架构设计的三个维度：面向对象、面向方面、面向服务。
最年长的一个维度就是面向对象，发展了好几十年，也是相对而言比较成熟的一个维度。它解决的问题是系统内部结构的设计。
面向方面思想的提出能够弥补面向对象的缺陷。面向对象的方式不能实现横切关注点的分离，而面向方面正是为了解决这个问题。面向方面与面向对象一样都是解决系统内部结构的设计。
面向服务更多的是涉及到系统的外部，简单地说就是发布功能。它并不关注系统内部结构的实现，所以说面向服务与面向对象或者面向方面并不冲突。
这三个维度并不是绝对孤立的，它们之间会互相影响、制约，相互发展的。我们在分析架构的时候需要同时考虑到这三个维度的问题，这样有助于我们设计出更加优秀的架构。
java高并发解决方案
1、HTML静态化 2、图片服务器分离 3、数据库集群和库表散列 4、缓存 5、镜像 6、负载均衡
一：高并发高负载类网站关注点之数据库
没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用，数据库的响应是首先要解决的。
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。
以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。
需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，
或者干脆自己做，因为php4中mysql的链接池经常出问题。
有几个常用的措施
1、对常用功能建立缓存模块
2、网页尽量静态化
3、使用单独的图片服务器，降低服务器压力，使其不会因为图片加载造成崩溃
4、使用镜像解决不同网络接入商和不同地域用户访问差异
5、数据库集群图表散列
6、加强网络层硬件配置，硬的不行来软的。
7、终极办法：负载均衡
如何分析系统的性能问题：
从以下几个维度进行考虑
当并发压力加大时，往往是吞吐量上不去，肯定是某一个方面出现了瓶颈，（比如CPU，内存（大量的swap），磁盘IO，网络IO，操作系统，应用）
如果CPU比较高（user,sys,wa），user高，可以把系统的线程dump出来，观察系统正在做的逻辑，优化逻辑；sys高，则说明kernel耗费了大量的CPU时间，比如当前的线程的切换比较厉害等等；wa高一般是IO操作比较频繁，CPU频繁调度
查看CPU，还需要观察系统load,一般不要超过系统的物理core数量。
如果出现大量的swap，说明物理内存不足
磁盘IO（文件系统cache）
网络IO（包的数量，以及大小）
应用本身，比如锁，还有连接池的大小设置，并发连接数限制(这种是资源利用率不高，但是tps上不去)
操作系统（文件句柄，socket优化等）
如何设计高并发的系统
a、空间换时间（多级缓存）
1）客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）
2）反向代理缓存
3）应用端的缓存(memcache)
4）内存数据库
5）Buffer机制（数据库，中间件等）
b、伸缩能力
1）拆分
业务拆分,逻辑分段（非阻塞，能异步则异步）
数据拆分（分库分表）
2）无状态
c、优化资源利用
1）基于逻辑的不同，采取不一样的策略，优化资源利用，按照业务进行资源分配（业务分流，线程分配）
2）流控
3）超时控制
首先在整个网络的高度讨论了使用镜像网站，CDN内容分发网络等技术对负载均衡带来的便利及各自的优缺点比较。然后在局域网层次对第四层交换技术，包括硬件解决方案F5和软件解决方案LVS，进行了简单的讨论。接下来在单服务器层次，本文着重讨论了单台服务器的Socket优化，硬盘级缓存技术，内存级缓存技术，CPU与IO平衡技术（即以运算为主的程序与以数据读写为主的程序搭配部署），读写分离技术等。在应用层，本文介绍了一些大型网站常用的技术，以及选择使用该技术的理由。最后，在架构的高度讨论了网站扩容，容错等问题。
Web2.0网站所有典型特征：高并发，高流量，数据量大，逻辑复杂，用户分散等等
2.1 镜像网站技术
镜像网站是指将一个完全相同的站点放到几个服务器上，分别有自己的URL，这些服务器上的网站互相称为镜像网站［13］。镜像网站和主站并没有太大差别，或者可以视为主站的拷贝。镜像网站的好处是：如果不能对主站作正常访问（如服务器故障，网络故障或者网速太慢等），仍能通过镜像服务器获得服务。不便之处是：更新网站内容的时候，需要同时更新多个服务器；需要用户记忆超过一个网址，或需要用户选择访问多个镜像网站中的一个，而用户选择的，不一定是最优的。在用户选择的过程中，缺乏必要的可控性。
2.2 CDN内容分发网络
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的互联网中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，分散服务器的压力，解决互联网拥挤的状况，提高用户访问网站的响应速度。从而解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题［14］。
CDN与镜像网站技术的不同之处在于网站代替用户去选择最优的内容服务器，增强了可控制性。CDN其实是夹在网页浏览者和被访问的服务器中间的一层镜像或者说缓存，浏览者访问时点击的还是服务器原来的URL地址，但是看到的内容其实是对浏览者来说最优的一台镜像服务器上的页面缓存内容。这是通过调整服务器的域名解析来实现的。使用CDN技术的域名解析服务器需要维护一个镜像服务器列表和一份来访IP到镜像服务器的对应表。当一个用户的请求到来的时候，根据用户的IP，查询对应表，得到最优的镜像服务器的IP地址，返回给用户。这里的最优，需要综合考虑服务器的处理能力，带宽，离访问者的距离远近等因素。当某个地方的镜像网站流量过大，带宽消耗过快，或者出现服务器，网络等故障的时候，可以很方便的设置将用户的访问转到另外一个地方（图2）。这样就增强了可控制性。
图2 CDN原理示意图
CDN网络加速技术也有它的局限性。首先，因为内容更新的时候，需要同步更新多台镜像服务器，所以它也只适用于内容更新不太频繁，或者对实时性要求不是很高的网站；其次，DNS解析有缓存，当某一个镜像网站的访问需要转移时，主DNS服务器更改了IP解析结果，但各地的DNS服务器缓存更新会滞后一段时间，这段时间内用户的访问仍然会指向该服务器，可控制性依然有不足。
目前，国内访问量较高的大型网站如新浪、网易等的资讯频道，均使用CDN网络加速技术（图3），虽然网站的访问量巨大，但无论在什么地方访问，速度都会很快。但论坛，邮箱等更新频繁，实时性要求高的频道，则不适合使用这种技术。
2.4 网络层架构小结
从整个互联网络的高度来看网站架构，努力的方向是明确的：让用户就近取得内容，但又要在速度和可控制性之间作一个平衡。对于更新比较频繁内容，由于难以保持镜像网站之间的同步，则需要使用其他的辅助技术。
3 交换层架构
3.1 第四层交换简介
按照OSI［16］七层模型，第四层是传输层。传输层负责端到端通信，在IP协议栈中是TCP和UDP所在的协议层。TCP和UDP数据包中包含端口号（port number），它们可以唯一区分每个数据包所属的协议和应用程序。接收端计算机的操作系统根据端口号确定所收到的IP包类型，并把它交给合适的高层程序。IP地址和端口号的组合通常称作“插口（Socket）”。
第四层交换的一个简单定义是：它是一种传输功能，它决定传输不仅仅依据MAC地址(第二层网桥)或源/目标IP地址(第三层路由)，而且依据IP地址与TCP/UDP (第四层) 应用端口号的组合（Socket）［17］。第四层交换功能就像是虚拟IP，指向实际的服务器。它传输的数据支持多种协议，有HTTP、FTP、NFS、Telnet等。
以HTTP协议为例，在第四层交换中为每个服务器组设立一个虚拟IP（Virtue IP，VIP），每组服务器支持某一个或几个域名。在域名服务器（DNS）中存储服务器组的VIP，而不是某一台服务器的真实地址。
当用户请求页面时，一个带有目标服务器组的VIP连接请求发送给第四层交换机。第四层交换机使用某种选择策略，在组中选取最优的服务器，将数据包中的目标VIP地址用实际服务器的IP地址取代，并将连接请求传给该服务器。第四层交换一般都实现了会话保持功能，即同一会话的所有的包由第四层交换机进行映射后，在用户和同一服务器间进行传输［18］。
第四层交换按实现分类，分为硬件实现和软件实现。
3.2 硬件实现
第四层交换的硬件实现一般都由专业的硬件厂商作为商业解决方案提供。常见的有Alteon［19］，F5［20］等。这些产品非常昂贵，但是能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了［21］。鉴于条件关系，这里不展开讨论。
3.3 软件实现
第四层交换也可以通过软件实现，不过性能比专业硬件稍差，但是满足一定量的压力还是可以达到的，而且软件实现配置起来更灵活。 软件四层交换常用的有Linux上的LVS（Linux Virtual Server），它提供了基于心跳（heart beat）的实时灾难应对解决方案，提高了系统的鲁棒性，同时提供了灵活的VIP配置和管理功能，可以同时满足多种应用需求［22］。
4.3 硬盘级缓存
硬盘级别的缓存是指将需要动态生成的内容暂时缓存在硬盘上，在一个可接受的延迟时间范围内，同样的请求不再动态生成，以达到节约系统资源，提高网站承受能力的目的。Linux环境下硬盘级缓存一般使用Squid［27］。
Squid是一个高性能的代理缓存服务器。和一般的代理缓存软件不同，Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。它接受来自客户端对目标对象的请求并适当地处理这些请求。比如说，用户通过浏览器想下载（即浏览）一个web页面，浏览器请求Squid为它取得这个页面。Squid随之连接到页面所在的原始服务器并向服务器发出取得该页面的请求。取得页面后，Squid再将页面返回给用户端浏览器，并且同时在Squid本地缓存目录里保存一份副本。当下一次有用户需要同一页面时，Squid可以简单地从缓存中读取它的副本，直接返回给用户，而不用再次请求原始服务器。当前的Squid可以处理HTTP， FTP， GOPHER， SSL和WAIS等协议。
Squid默认通过检测HTTP协议头的Expires和 Cache-Control字段来决定缓存的时间。在实际应用中，可以显式的在服务器端脚本中输出HTTP头，也可以通过配置apache的mod_expires模块，让apache自动的给每一个网页加上过期时间。对于静态内容，如图片，视频文件，供下载的软件等，还可以针对文件类型（扩展名），用 Squid 的 refresh_pattern 来指定缓存时间。
Squid 运行的时候，默认会在硬盘上建两层hash目录，用来存储缓存的Object。它还会在内存中建立一个Hash Table，用来记录硬盘中Object分布的情况。如果Squid配置成为一个Squid集群中的一个的话，它还会建立一个 Digest Table(摘要表)，用来存储其它 Squid 上的Object摘要。当用户端想要的资料本地硬盘上没有时，可以很快的知道应该去集群中的哪一台机器获得。在硬盘空间快要达到配置限额的时候，可以配置使用某种策略（默认使用LRU：Least Recently Used-最近最少用）删除一些Object，从而腾出空间［28］［29］。
集群中的Squid Server 之间可以有两种关系：第一种关系是：Child 和 Parent。当 Child Squid Server 没有资料时，会直接向 Parent Squid Server 要资料，然后一直等，直到 Parent 给它资料为止。 第二种关系是：Sibling 和 Sibling。当 Squid Server 没有资料时，会先向 Sibling 的 Squid Server 要资料，如果 Sibling 没资料，就跳过它向 Parent 要或直接上原始网站去拿。
默认配置的Squid，没有经过任何优化的时候，一般可以达到 50% 的命中率［30］（图4）。如果需要，还可以通过参数优化，拆分业务，优化文件系统等办法，使得Squid达到 90% 以上的缓存命中率。 Squid
处理TCP连接消耗的服务器资源比真正的HTTP服务器要小的多，当Squid分担了大部分连接，网站的承压能力就大大增强了。
创造新一代Web 2.0网站的技术越来越精简和简化。程序员从使用复杂的企业级Java堆栈和数据库（e.g.Oracle），切换到更直接的LAMP组合（Linux操 作系统，Apache，MySQL和PHP/ Python/Perl）。新的语言和框架（e.g.Diango和Ruby on Rails）使得网站和数据库之间的层自动化。前端框架（e.g.jQuery）帮助简化了不同浏览器之间错综复杂的关系。云服务（e.g.Amazon Web Services）简化了部署，提供了钥匙网络。
古老的Web前端，现在都演变成CSS4、JSON和JavaScript的MVC框架，比如 Angular.js和Backbone.js。
最近几年，web架构拥抱解耦的理念并且将应用层设施从web服务器中分离。虽然现在仅仅是将原先基于LAMP(Linux, Apache, MySQL, PHP, Python or Perl)所构建的网站，变为基于LEMP（E表示Engine x）的。
几台服务器,就是想问问做没做基本的图片服务器和数据库服务器分离,
那么问题就来了，原因可能是如下几种：
1.上传的文件太多(或者图片太多)。
2.网页的页面压力太大写的不够好。
3.数据库的压力太大。
思路
第一种问题解决方案，上传的文件太多,这个问题最难解决了,同时也是最简单的,因为解决的方案就是一个字钱，君不见优酷土豆此类网站烧钱之甚啊!因为涉及到并发,打个比方,一条高速公路是100M，那么你的并行量级咱们就按照100M计算，(这种说法已经最笨了)假设每个人的上传5M的文件和图片那么这个网站的并发我是不是就可以认为是100/5 = 20呢? 也就是说这个网站只能20个人访问了，多了轻则卡顿丢失文件,总则就是网站崩溃了,这种问题也最难解决,因为文件和图片永远都是网站流量的最大杀手,没什么好办法只能做图片服务器分离.文件服务器分离了,(但是这里又违背了人家只用一台服务器的原则),有的公司看上去很大,但是老板就是对IT部门不重视不投资那么多没什么办法。
从上面的分析我们可以总结出iis读取页面的机理和原因：
第一种:就是对internet请求进行分析和归类,分成静态页面请求和动态页面请求,所谓的静态请求就是html静态页面，动态请求我们暂时理解为aspx，或者cshtml请求。
第二种:就是对动态页面请求进行分析，等到动态请求分析成为静态请求的时候组合再一起返回给浏览器。
所以我得出了两个结论:
第一种，我们把一些流量高但是页面数据不总是变化页面我们可以考虑使其静态化。这也是现在一些流行网站的做法。
第二种，我们可以尽力的减少动态请求分析的时间。
第三种数据库压力大的解决方案,这种问题很多就是程序员自己自身素质的问题了,或者架构没有搭建好。
我猜想原因可能是:
第一种，有的人喜欢把文件或者图片变成二进制保存到数据库里，这样参照第一种崩溃原因。
第二种，就是有的程序员他很擅长数据库方面的技术,所以他把所有的业务和逻辑都封装成了存储过程保存在数据库里，后台代码只有一个事务回滚甚至没有，这样的业务，在后台响应时间内接收不到回应自然会报错了。
其他
1.根据测试报告中所描述的时间，找出瓶颈所在，确定优化方案，这个很重要，是行动的指南。
2.确定优化目标，例如原来100秒，优化到6秒；
3.分析网络连接点，将能够从服务端可以取出的数据，一次取出，在客户端进行逻辑运算。
4.需要考虑在网络不稳定的情况或异常关机的情况下，对于客户端的未保存的数据进行缓存，保证用户输入数据的安全。
5.除了减少中间层的访问次数，对于查询数据较慢的表格也需要加如Index进行优化。
根据上述方法，优化已经基本达到了目标，总结如下：
1.优化无止尽，需要找出瓶颈，确定优化目标；
2.优化不仅仅考虑中间层的连接次数，对于数据库的性能优化也同样重要。遇到过原来一个查询需要8000MS，通过数据库和SQL语句的优化，达到了500MS；
3.优化需要结合具体的程序考虑，需要层层跟踪。例如，需要跟踪哪里进行了中间层连接，这个连接是否有必要。
4.利用缓存时候，需要考虑缓存数据的一致性。
5.保存数据，进行批量中间层保存；
6.独立的事务处理可以在PL/SQL里面实现，这样效率最高。
扫一扫
8331
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
