所在的位置：数据结构 >> 课程介绍 >> 大型网站技术架构第2篇&nb

大型网站技术架构第2篇&nb

扩展性：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则(对扩展开放，对修改关闭)，架构设计考虑未来功能扩晨，当系统增加新功能时，小需要对现有系统的结构和代码进行修改。

伸缩性：指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。

7.1构建可扩展的网站架构

设计网站可扩展架构的核心思想是模块化，并在此基础之上，降低模块间的耦合性，提高模块的复用性。

第6章讨论过网站通过分层和分割的方式进行架构伸缩，分层和分割也是模块化设计的重要手段，利用分层和分割的方式将软件分割为若干个低耦合的独立的组件模块．这些组件模块以消息传递及依赖调用的方式聚合成一个完整的系统。

在大型网站中，这些模块通过分布式部署的方式，独立的模块部署在独立的服务器：集群)上．从物理上分离模块之间的耦合关系，进一步降低耦合性提高复用性。

模块分布式部署以后具体聚合方式主要有分布式消息队列和分布式服务。

7.2利用分布式消息队列降低系统耦合性

7.2.1事件驱动架构

事件驱动架构：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦台，并借助事件消息的通信完成模块间合作，典型的EDA架构就是操作系统中常见的生产者消费者模式。在大型剐站架构中，具体实现手段有很多，最常用的是分布式消息队列。

消息队列利用发布——订阅模式工作。消息发送者发布消皂，一个或者多个消息接收者订阅消包。消息发送者是消息源，在对消息进行处理后将消息发送至分布式汽包队列，消息接受者从分布式消息队列获取该消息后继续进行处理。

可以看到．消息发送者和消息接受者之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，而消息接受者只需要从分布式消包队列获取消息后进行处理，不需要知道该消息从何而来。对新增业务，只要对陵类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展设计。

消息接受者在对消息进行过滤、处理，包装后，构造成一个新的消息类型，将消息继续发送出去，等待其他消息接受者订阅处理该消息。因此基于事件(消息对象)驱动的业务架构可以是一系列的流程。

由于消息发送者不需要等待消息接受者处理数据就可以返回，系统具有更好的响应延迟；同时，在网站访问高峰，消息可以暂时存储在消息队列中等待消息接受者根据自身负载处理能力控制消息处理速度，减轻数据库等后端存储的负载压力。

7.2.2分布式消息队列

消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，消包队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据消自订阅列表查找订阅该消息的消息消费者应用程序，将消包队列中的消息按照先进先出(FIFO)的原则将消包通过远程通信接口发送给消息消费者程序。

目前开源的和商业的分布式消包队列产品有很多，比较著名的如ApacheActiveMQ等，这些产品除了实现分布式消启队列的一般功能．在可用性、伸缩性、数据一致性、性能和可管理性方面也做了很多改善。

为了避免消包队列服务器宕机造成消皂丢失，会将消息成功发送到消自队列的消自、存储在消息生产者服务器．等消息真正被消包消费者服务器处理后才删除消自。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中其他的服务器发布消息。

7.3利用分布式服务打造可复用的业务平台

使用分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理一个消息，那么分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接门描述进行服务调用。

巨无霸网站给开发、维护、部署都带来了巨大的麻烦，如编译、部署的困难，代码分支管理困难，数据库连接耗尽，新增业务困难等。解决方案就是拆分，将模块独立部署，降低系统耦台性。拆分可以分为纵向拆分和横向拆分两种。

纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，就直接将其设计部署为一个独立WEB应用系统。

横向拆分：将复用的业务拆分出来．独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块代码，即可快速搭建一个应用系统，而模块内业务逻辑变化的时候，只要接口保持一致就不会影响业务程序和其他模块。

7.3.1WebService与企业级分布式服务

WebService曾经是企业应用系统开发领域最时髦的词汇之一，用以整合异构系统及构建分布式系统。虽然有成熟的技术规范和产品实现，但也有固有的缺点：臃肿的注册与发现机制、低效的XML序列化手段、开销相对较高的HTTP远程通信、复杂的部署与维护手段。这些问题导致webservice难以满足大型网站对系统高性能、高可用，易部署、易维护的要求。

7.3.2大型网站分布式服务的需求与特点

负载均衡

失效转移

高效的远程通信

整合异构系统

对应用最少侵入

版本管理

实时监控

7.3.3分布式服务框架设计

服务消费者程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块．也可以是远程的服务，因此对应用较少侵入：应用程序只需要调用服务接口，服务框架根据配置自动调用本地或远程实现。

服务框架客户端模块通过服务注册中心加载服务提供者列表(服务提供者启动后自动向服务注册中心注册自己可提供的服务接口列表)，查找需要的服务接口，并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败，客户端模块会自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务，实现服务的自动失效转移，保证服务高可用。

远程服务通信模块支持多种通信协议和数据序列化协议，使用NIO通信框架，具有较高的网络通信性能。

7.4可扩展的数据结构

有没有办法能够做到可扩展的数据结构设计呢?无需修改表结构就可以新增字段呢?许多NoS()L数据库使用的columnFamily(列族)设计就是一个解决方案。

使用支持columnFamily结构的NoS(强数据库，创建表的时候，只需要指定columnFamily的名字，无需指定字段(colunm)，可以在数据写入时再指定，通过这种方式，数据表可以包含数百万的字段，使得应用程序的数据结构可以随意扩展。而在查询时，可以通过指定任意字段名称和值进行查询。

7.5利用开放平台建设网站生态圈

开放平台是网站内部和外部交互的接口，外部需要面对众多的第三方开发者，内部需要面对网站内诸多的业务服务。一般包括如下：

API接口：是开放平台暴露给开发者使用的一组API，其形式可以是RESTml、WebService、RPC等各种形式。

协议转换：将各种API输入转换成内部服务可以识别的形式，并将内部服务的返回封装成API的格式。

安全：除了一般应用需要的身份识别、权限控制等安全手段，开放平台还需要分级的访问带宽限制．保证平台资源被第三方应用公平合理使用，也保护网站内部服务不会被外部应用拖垮。

审计：记录第三方应用的访问情况，并进行监控、计费等。

路由：将开放平台的各种访问路由映射到具体的内部服务。

流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。