大型网站系统架构核心技术

大型分布式网站的核心思想是采用大量廉价的PC，构建一个低成本、高可用、高可扩展、高吞吐的集群系统，以支撑海量的用户访问和数据存储，理论上具备无限的扩展能力。分布式系统的设计是一门复杂的学习，它涉及通信协议，远程调用，服务治理，系统安全，存储，搜索，监控，稳定性保障，性能优化，数据分析，数据挖掘等各个领域。

                                          分布式服务化大型网站架构

    
1，架构模式：

    分层：企业应用中最常见的一种架构模式，将系统在横向维度上切分成几个部分，第个部分负责一部分相对单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。可将大型网站分为应用层，服务层，数据层。分层架构的挑战是必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次的调用及逆向调用。在实践中，大的分层结构内部还可以继续分层。分层架构是逻辑上的，在物理部署上，三层结构可以部署在同一个物理机器上，但随着网站的业务的发展，分层的模块分离部署。

    分割：分割就是在纵向方面对系统切分，将不同的功能和服务分割开来，有助于开发、维护、分布式部署，提高网站的并发处理能力和功能扩展。

    分布式：分层和分割的一个主要目的就是为了切分后的模块便于分布式部署，即将不同的模块部署在不同的机器上，通过远程调用协作。分布工意味着可以使用更多机器完成同样的功能，CPU，内存，存储，带宽资源越多，能处理的并发访问量就越大。分布式的问题：网络时延，数据一致性，依赖复杂。分布式的方案有以下几种：

• 分布式应用和服务：将分层和分割后的应用和服务分布式部署
• 分布式静态资源：网站的静态资源如Js，CSS，图片等资源独立分布式部署，并采用独立的域名，即动静分离。
• 分布式数据和存储：海量数据需要分布式的关系数据库，NoSQL产品，分布式文件系统。
• 分布式计算：利用Hadoop分布试计算框架，移动计算，实现后台业务处理，数据仓库的数据分析统计。
• 其他分布式方案：开源的disconf分布式配置，基于Zookeeper的分布式并发与协同的分布式锁

    集群：分层和分割后的模块独立部署，对于用户访问集中的模块，还需要服务器集群化，通过负载均衡设备，采用多台服务器部署相同应用，对外提供服务，提高了系统的扩展性，高可用性。

    缓存：将数据放在距离使用最近的位置，以加快处理速度。

• CDN：即内容分发网络，部署在距离终端用户最近的网络服务商。
• 反向代理：部署在网站的前端
• 本地缓存
• 分布式缓存

    异步：利用异步降低耦合性，在分布式系统中，通过分布式消息队列实现异步。利用消息队列，还有如下特点：

• 可以提高系统的可用性：在消息者故障时，数据在消息服务器存储堆积，生产者可继续处理业务，整体表现无故障，消费者恢复后，继续处理消息队列的数据。
• 加快网店响应速度：生产者将数据写入消息队列，不需要等待返回，减少时延。
• 消除并发访问高峰：将访问高峰的请求数据放入消息队列，等待消费者依次处理。

2，网站的高可用架构

    高可用的应用：通过负载均衡进行无状态的应用服务器集群的失效转移；独立部署Session集群服务器统一管理Session

    高可用的服务：无状态，通过负载均衡实现高可用的服务，在具体实践中，有如下高可的服务策略：

• 分级管理：高优先级的服务部署在更好的硬件，更好的物理机上，低优先级的部署在虚拟机上。
• 超时设置：由于服务宕机，线程死锁，调用方失去响应，导致用户请求长时间得不到响应，设置超时时间，一旦超时，通信框架抛出异常，应用程序根据服务调用策略，继续重试或将请求转移到相同的其他机器上。
• 异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败。查询类，必须确认服务调用成功才能继续下一步操作的应用不合适异步调用。
• 服务降级：降级有两种手段：拒绝服务、关闭服务。拒绝服务：拒绝低优先级的应用的调用，减少服务调用次数，确保核心应用正常使用，或拒绝部分请求调用，节约资源，让另一部分请求成功。关闭服务：关闭部分不重要的服务，或服务内部关闭部分不重要的功能，以节约系统开销，为重要服务和功能让出资源。
• 幂等性设计：应用层不关系服务是否真的失败，只要没有收到调用成功的响应，就认为调用失败，并重试服务调用。服务层保证服务重复调用和调用一次产生的结果相同。

    高可用的数据：保证数据高可用的手段主要是数据备份及失效转移。

• 数据持久性：保证数据持久存储，在各种情况下都不会出现丢失的问题，数据需要备份一个或多个副本
• 数据可访问性：多份副本在不同的存储设备上，一个设备损坏，数据访问切换到另一个设备的过程不能很快完成，这段时间数据是不可访问的。
• 数据一致性：在网络，服务器或软件故障时，导致部分数据写入成功，部分写入失败，造成数据不一致；或者数据更新返回失败，事实存储服务器已经更新成功。

    CAP理论：一个提供数据服务的存储系统无法同时满足数据一致性，数据可用性，分区耐受性。分布式系统通常选择系统的可用性（A），伸缩性（P），在某种程序上放弃一致性。

    数据一致性又可如下几点：

    数据强一致：各个副本的数据在物理存储中总是一致的，数据更新操作和操作响应总是一致的，即操作响应通知更新失败，那数据一定没有更新，不是处于不确定状态。

    数据用户一致：各个副本数据可能不一致，但终端用户访问时，通过纠错和校验机制，可以确定一个一致且正确的数据返回给用户。

    数据最终一致：这是数据一致中较弱的一种，存储的数据可能不一致，终端用户访问到的数据也可能不一致，但系统经过一段时间的自我恢复和修正，数据最终会达到一致。

3，网站的伸缩性

    应用服务器的伸缩性：负载均衡不但可以实现网站的伸缩性，还改善可用性。

    实现负载均衡的基础技术：HTTP重定向负载均衡、DNS域名解析负载均衡、反向代理负载均衡，IP负载均衡，数据链路层负载均衡。负载均衡算法：轮询，加权轮询，随机，最少连接，源地HASH。

    分布式缓存集群的伸缩性：

    分布式缓存的一致性Hash算法：先构造一个长度为0到2的32次幂的整数环，将每台物理缓存服务虚拟为150虚拟缓存服务器，将虚拟缓存服务器的Hash值放置在Hash环上，根据缓存的数据的Key值计算得到其Hash值，然后在Hash环上顺时针查找距离这个Key的Hash值最近的缓存服务器节点，Key在环上先找到虚拟服务器节点，再得到物理服务器的信息。
    数据存储服务器集群的伸缩：在大型网站的实际应用中，需要分库，主从复制，分片。

    基于支持数据分片的分布式关系数据产品Cobar的部署模型：

    Cobar服务器可以看作是无状态的应用服务器，因此其伸缩可以简单使用负载均衡的手段。
    MySQL集群扩容，数据迁移不是以数据为单位，而是以Schema为单位，从每个服务器迁移部分Schema到新机器中，由于迁移以Schema为单位，迁移过程可使用MySQL的同步机制，同步完成，修改Cobar服务器的路由配置，将迁移的Schema的IP修改为新机器的IP，然后删除原机器的相关Schema。