作为一个大型Web系统，那得有大型系统所具备的能力，能够在业务逻辑上更有优势处理各种“大”（数据量大，并发量大，系统逻辑复杂，需求开发迭代快速）的问题。那么一个这样一个系统应该具有哪些能力呢？
所说的处理能力，也就是从一个非技术层面体现一个系统性能的问题。就像老板告诉你，这个系统要快，要好，要稳定，要实时监控数据等等！而对于一个技术人员来讲，你该怎么实现老板对这个系统的标准呢？
这篇文章，我将把一个系统架构比作一个河流，更准切的来讲应该是是由河流，河塘，大坝等组成的河流网络。
关于系统的处理能力我归纳了下面几点：
并发处理能力是一个系统评判的重要因素。一般的场景，要求10万/秒的请求，特殊场景要求60万/秒的请求。那河流那处理能力应该就是河流能够流通水量的能力了。
1.首先基于系统处理能力的问题，我们第一步做的就是对系统进行上限值设定。如果把系统比作一条河流，那里河流中能流动的水，无论多少都需要有一个上限的限定，在源头限定水量的大小。是河流不会造成河水溢出的重要保障。
集群Web服务器请求上限值设定，现在主流的Web服务器（Apache,Nginx,IIS）都可以根据集群服务器的处理能力对设计处理请求的上线值。
集群缓存组件连接数上限值设定。
主从数据库连接数上线值设定。
2.对系统的处理能力上限的设定其实本质上来讲，只是对系统并发能力的保障。没有实质性的去解决处理高并发的问题。还是拿河流说事，老板说你这条河流要处理每小时五百万立方的水量。你该怎么做？以控制变量的思维来想，假如河流宽度和深度都已经是一个固定值了（我们单台服务器的处理能力已经是一个固定值了），它只能处理每小时一百万的水量。那我们想到的就是增加河流数量了，单挑河流处理不过来我多条河流处理。在系统架构上，我们还可以根据我们具体系统的业务领域对请求进行分类，不同领域请求交给专门应对服务器去处理，也就是领域分而治之的思想了。对系统请求进行分发和请求结果进行代理返回给请求的客户端，也就是我们说的负载均衡及反向代理了。实现负载均衡一种是硬件负载均衡，另外就是代理服务器做负载均衡。看系统大小，适度就行。并非一味的追求高可用，系统越大，引发的成本及问题也会越多。一般的大型系统，用代理服务器做负载均衡和反向代理就完全够用了。如果满足不了要求，系统的量级也会出现其他的问题（请求链路长短问题，我们可能需要根据请求用户区域问题分区域部署）。无论是来自系统外部的请求，还是内部SOA服务请求，我所要想讲的就是，请求的负载均衡及领域分而治之。
对于单个请求，我们怎么去提高它的处理速度。以一个商品交易的逻辑为例，你发起一个支付的请求，最基本的条件你是可以支付的。但什么样的条件是可以支付的呢？合法用户，合法商户，有订单号，有货，你还得有钱，然后还得把你买的行为记录下来指不定你还要退货等。这里所的条件还是一些很笼统的条件。需要满足这些条件可能需要更多的逻辑验证。分析这个逻辑，我们不需要每次用户去购买商品的时候去重新判断一遍他是合法用户，我们也不需要用户去购买商品的时候，又一遍的去结算他的金额。这里我想说的是：
1.尽量精简主流程，能够异步的尽量异步去处理，能预处理的预处理。
2.一些能够异步处理的，比如日志信息记录，小心推送等功能，尽量使用异步方式处理，不阻塞主流程。
3.能够预处理的信息，尽量预处理。
4.尽量使用缓存，代替不必要的重复计算。其实代码逻辑也需要考虑这一点。这一点其实很多情况需要和预处理关联起来。
5.考虑是否可以并发处理多个不相关的且验证复杂的逻辑，当这些逻辑是必要验证以及不好做预处理的情况下。
所谓的功能模块具有优秀的快速开发能力，不会有牵一发而动全身的情况。在架构使底层服务上，架构师对领域的定义和划分，对各层的抽象的定义是否合理。这能力很大程度上取决于架构师个人开发素质及对业务场景认知。
通过硬件解决系统性能问题，是一个系统性能优秀的主要表现，也是最划算的方式。这里涉及到的技术主要就是集群了。系统要是简单的访问量巨大，我们可以通过添加应用服务器结算请求量大的问题。如果系统底层逻辑复杂，应用服务器可以承受一定的请求量，而底层服务无法满足处理这个数据量请求的运算的时候。我们可以通过两种方式去解决这个问题。当这种业务场景是持续的且是需要及时处理，我们可以增加处理不过来的底层服务机器满足处理能力。如果场景是一些不需要实时处理的且情况是间歇性的。我们可以考虑将数据队列起来，有条不紊的处理。在河流的实例中，就相当于。所有的水量我都让他进入河塘，我通过河塘获取水量。按照我的处理能力处理数据。不关心上流谁要是我能处理还是超出我处理能力的。
原文地址：http://www.cnblogs.com/Lyunwen/p/6510734.html
