这边文章通俗易懂：分布式Web服务器架构
1，举例了解
用自己的话来说，就像工厂有多个分厂，每个分厂负责不同产品的生产，用于解决高性能高并发；集群也是，只不过每个工厂的都可以生产所有产品，解决高可用的。
以工厂为例，假设起初只有一个工厂，但随着业务订单的增多公司发展，当增加工厂的配置产能并不能解决问题时，增设分厂称为一个解决方案。
1.1，分布式
这种方案是，将工厂负责的几个业务分开，使不同地方的工厂生产不同业务的产品。
增设服务器，将不同的业务分布到不同的服务器上。
将业务分开后，在进行管理和生产上更方便了。
但各个工厂生产时尽量要和其他工厂的合作，生产任务在分配的工厂上完成，这样能减少运输成本。
分布式系统尽可能减少节点间通讯开销。
一个工厂负责一种业务，如果这个工厂出现停电，机器故障，工人离职等问题时，这个部分业务的暂停将导致整个公司业务暂停。假设公司生产的物品必须在某中工具内保存，统一存放在某一仓库，一旦停电，产品就都没了。
分布式系统不允许单点失效（No Single Point Failure）
为了预防这种情况，也为了增加单个业务的生产能力，这时就该集群进行横向扩展了。
1.2，集群
与分布式的各地增加工厂不同，集群增加的工厂必须有一个统一的管理部门进行业务分拨，且要建在一起。把工业区扩大，加几个工厂，但管理部门还是一个。当订单发送过来，由管理部门进行接收，根据管辖的工厂繁忙程度来分配由哪个工厂进行生产，生产后统一交给管理部门再交付用户。
分布式服务器可以部署在网络各处，但集群必须放在一起统一管理，请求过来后负载均衡处理，交给空暇的服务器处理。
如果其中一个工厂出了什么问题，管理处也可以交给其他工厂处理，这样就不会因为某个工厂处理问题导致整个公司停工了。
集群容错，但一个服务器出错，请求也不会失败，而是交给其他服务器处理，这样稳定性就强了不少。
对于上面分布式中，一个业务交给一处的工厂处理，为了容错和增加产量，可以将这处工厂进行集群处理。扩建工业区，增加工厂来处理这个业务。
2，介绍
上面举例解释了下分布式和集群的区别和特点，下面来介绍下它们。
2.1 集群
集群主要分成三大类。
2.1.1高可用集群(High Availability Cluster)
高可用集群，英文原文为High Availability Cluster，简称HA Cluster，简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。高可用性集群（HA cluster）是指如单系统一样地运行并支持（计算机）持续正常运行的一个主机群。
简单来说，它用来实现故障检查和业务切换的自动化，提供业务处理的服务器还是一台，其他服务器用来保障业务。
只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的 情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能， 更能满足用户不断出现的需求变化。
keepalived组件，可以实现web服务器的高可用(HA high availably)。实现主备服务器发生故障时ip瞬时无缝交接。
2.1.2负载均衡集群(Load Balance Cluster)
集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。
ngnix，lvs（Linux Virtual Server），HAProxy都是负载均衡组件。3种LVS/Nginx/HAProxy负载均衡器的对比分析。
- lvs性能最强，工作稳定，但不能做动静分离，网站庞大的话实施LVS/DR+Keepalived起来就比较复杂了；
- ngnix可以针对http应用做一些分流的策略，正则规则比HAProxy更为强大和灵活，安装和配置比较简单。但Nginx仅能支持http和Email，这样就在适用范围上面小很多，负载度和稳定度差LVS还有几个等级；
- HAProxy能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作，效率和并发处理上也是优于Nginx的；可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，所以向大家推荐LVS+Keepalived。
在使用上，一般最前端所采取的策略应是LVS，也就是DNS的指向应为LVS均衡器；Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利 用Nginx的性能；如果是比较小的网站（日PV<1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较 多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS
重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。
浅谈web应用的负载均衡、集群、高可用(HA)解决方案。这篇文章有兴趣的可以一读，介绍了几种方案。这篇文中写道：一般在WEB端使用的负载均衡比较多的是HAProxy+keepalived+nginx；数据库mysql集群使用Lvs+keepalived+mysql实现。一般用lvs+keepalived或heatbeat做数据库层的负载均衡。
2.1.2科学计算集群(High Performance Computing Cluster)
高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。
- 高吞吐计算(High-throughput Computing)：有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。
- 分布计算(Distributed Computing)：另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。
2.2分布式
分布式架构的一个重要特点是把计算、存储分布在网络中的多个节点上，通过软件来控制任务的分发和执行调度，这样任务能同时在多个节点并行执行，同时给上层的应用提供一个访问远程节点如访问本地系统一样的接口环境。
众所周知，分布式系统要比集中式系统更复杂，因为分布式系统要解决的问题是一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。一致性指的是在同一时刻，在每个节点都能读到最新写入的数据；可用性指的是一个运行的节点在合理的时间内总能响应请求，不会发生错误或超时；分区容错性指的是当网络分裂发生时，系统仍能继续工作。这些问题在集中式系统中都不是问题，但在分布式系统中则成为最大的挑战。
计算和存储分离是分布式系统的重要特征。而通常在集中式或单机系统中，这两者是可能结合在一起，比如通过一个SQL语句实现查询后排序，查询是从存储中获得数据，排序是属于计算，因此这个SQL语句实际是将计算和存储耦合在一起。在应对大数据或大并发的情况下，这种方便的捆绑带来性能问题，而分布式计算和分布式存储虽然带来复杂性，但是也为系统的处理能力打开了上升拓展的空间。
分布式系统特点：
- 并发性：共享资源，采取ACID或Base原则，见：CAP定理。分布式系统设计遵循CAP定理， CAP是：Consistency(一致性), Availability(可用性), 和 Partition tolerance(分区容错性) 可靠性 简称，CAP定理认为，CAP三种之中，只能同时满足其中两种。
相比ACID 应用， BASE的应用更具良好的扩展性，更适合在互联网上运行的分布式系统。 互联网+的架构，将会是以支持BASE应用为主，同时也要能够支持传统的ACID应用。
- 可扩展性Scalable是重要特点，通过扩展能够获得高性能 高吞吐量 低延迟Latency。
-
可靠性/可用性:故障发现和处理以及恢复 容错处理。在一个正常运作系统中存在一个时间比例的条件。 如果一个用户不能访问系统比例增大，它被认为是不可用。可用性公式：
Availability = uptime / (uptime + downtime)
容错failover是指一个系统在错误发生的情况下，仍然一切运行正常。表示这个系统是宽容错误的。 - 消息处理: 具体产品有：RabbitMQ ZeroMQ Netty等等
- 异构性： 不同操作系统 硬件 程序语言 开发者，中间件是一种解决方案。
- 安全性：授权认证 SSO单点登录 Oauth等等。
- 定位命令：
标识资源 URLs
命名服务Naming services
定位寻找Lookup
主要见SOA中的服务查找。如Zookeeper实现服务查找。 - 透明性：
访问透明度： 使用相同的操作本地和远程资源
位置透明：访问资源无需知道其物理或网络位置
并发透明度：多个进程可以同时运行访问使用共享资源，当不能干扰堵塞 它们的处理进程
复制透明性： 资源的多个实例可以被用来复制以提高可靠性和性能，但无需由用户编制专门的应用程序来实现。
故障透明度：出现软件硬件故障时，使用户和应用方案能继续完成他们的任务不受影响。
移动透明度：允许在 系统存在移动的资源和客户。
性能透明度：允许系统重新配置以 提高性能负荷变化
缩放透明度：在应用程序结构没有变化的情况下能够在规模上扩展或伸缩系统，以提高吞吐量处理能力。
如何架构分布式系统
适用于分布式系统架构的最常见的一个术语是SOA(面向服务架构)。
构建面向服务架构的第一步是确定每个函数功能如何构成整体业务目标，将这些业务映射到离散的服务，且具有独立的断层边界、扩展性和数据负载量。
分布式系统的模型抽象
分布式系统遵循CAP定律，在高一致性，高可用性和分区容错性之间三选二：
- CA (consistency高一致性 + availability高可用性). 使用2pc 两阶段事务提交来保证。其缺点无法实现分区容错性，一旦某个操作失败，整个系统就出错，无法容忍(水至清则无鱼)。
- CP (consistency高一致性 + partition tolerance分区容错性). 使用Paxos来保证，可用性降低。
- AP (availability高可用性 + partition tolerance分区容错性). 使用Gossip等实现最终一致性，如Dynamo.
BASE的含义正好是指“NoSQL数据库设计可以通过牺牲一定的数据一致性和容错性来换取高性能的保持甚至提高”，即NoSQL数据库都应该是牺牲C来换取P，而不是牺牲A。可用性A正好是所有NoSQL数据库都普遍追求的特性。
分布式系统的设计技巧：分区和复制
- 分区：它可以被分割在多个节点，以允许更多的并行处理。有更好的性能，但是容错能力低。
- 复制：它也可以被复制或缓存在不同的节点上，以减少在客户端和服务器之间的距离，更强的容错能力，但是复制消耗性能。关键是复制数据之间的一致性。弱一致性提供更低的延迟和更高的可用性。
资料参考：分布式系统，漫谈“互联网+”架构 （6）- 分布式系统架构回顾
高性能、高可用的分布式架构体系
对于网站产品的的架构体系，可以选择开源或自主研发；如果拥抱开源，则首个开发周期可能会缩短1/3左右，但付出的代价是要深入吃透这些开源方案为我所用，必要时还得修改源代码，这后面的代价很难估计，另外还存在一项风险就是万一选用的开源方案在将来才发现某一些特性不满足，就得推倒重来；如果自主研发，则项目的开发周期会相应延长，而且似乎有重复造轮子的嫌疑。对于开源工具来说，重要开源工具主要包括有Zookeeper，Solr，Openfire，Redis(在它基础上研发分布式NOSQL数据库集群)，Nginx，Haproxy，Keepalived，MySQL(在它基础上研发的ShardDB)；而自主研发的分布式中间件则包括分布式文件系统(Cloudfs)，分布式即时通讯(CloudIm)，分布式消息队列(CloudMQ)，分布式任务调度(CloudJob)，分布式检索平台（CloudIndex），分布式NOSQL数据库集群(CloudRedis)。
