大型网站技术架构-7 随需应变：网站的可扩展架构

读书笔记 摘自：《大型网站技术架构：核心原理与案例分析-李智慧》

---

7 随需应变：网站的可扩展架构

有赖于网站的扩展性架构设计，就是在对现有系统影响最小的情况下，系统功能可持续扩展及提升的能力。

扩展性（Extensibility）
指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。

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

7.1 构建可扩展的网站架构

开发低耦合系统是软件设计的终极目标之一

度量一个开发框架、设计模式、编程语言优劣的重要尺度就是衡量它是不是让软件开发过程和软件产品更加低耦合。

低耦合的系统更容易扩展，低耦合的模块更容易复用，一个低耦合的系统设计也会让开发过程和维护变得更加轻松和容易管理。

完全没有耦合就是没有关系，也就无法组合出一个强大的系统。

软件架构师最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自架构师对业务场景的理解、对人性的把握、甚至对世界的认知。

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

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

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

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

如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响最小，这样系统的可扩展性无疑更好一些。

7.2.1 事件驱动架构

事件驱动架构（Event Driven Architecture）：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型的EDA架构就是操作系统中常见的生产者消费者模式。

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

7.2.2 分布式消息队列

目前开源的和商业的分布式消息队列产品有很多，比较著名的如Apache ActiveMQ等

分布式消息队列可以很复杂，比如可以支持ESB（企业服务总线）、支持SOA（面向服务的架构）等；也可以很简单，比如用MySQL也可以当作分布式消息队列

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

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

巨无霸应用系统带来如下几点问题：

1. 编译、部署困难

2. 代码分支管理困难

3. 数据库连接耗尽

4. 新增业务困难

解决方案就是拆分，将模块独立部署，降低系统耦合性。拆分可以分为纵向拆分和横向拆分两种。

对于横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务依赖关系，还需要一个完善的分布式服务管理框架。

7.3.1 Web Service与企业级分布式服务

Web Service曾经是企业应用系统开发领域最时髦的词汇之一，用以整合异构系统及构建分布式系统。

Web Service虽然有成熟的技术规范和产品实现，并在企业应用领域有许多成功的案例，但也有如下固有的缺点。
1. 臃肿的注册与发现机制。2. 低效的XML序列化手段。
3. 开销相对较高的HTTP远程通信。4. 复杂的部署与维护手段。

这些问题导致Web Service难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。

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

负载均衡

失效转移
因此对于大型网站的分布式服务而言，即使是很少访问的简单服务，也需要集群部署，分布式服务框架支持服务提供者的失效转移机制，当某个服务实例不可用，就将访问切换到其他服务实例上，以实现服务整体高可用。

高效的远程通信

整合异构系统

对应用最少侵入

版本管理
但是网站服务不可能中断，因此分布式服务框架需要支持服务多版本发布，服务提供者先升级接口发布新版本的服务，并同时提供旧版本的服务供请求者调用，当请求者调用接口升级后才可以关闭旧版本服务。

实时监控

7.3.3 分布式服务框架设计

大型网站需要更简单更高效的分布式服务框架构建其SOA（Service Oriented Architecture面向服务的体系架构）。

目前国内有较多成功实施案例的开源分布式服务框架是阿里巴巴的Dubbo（http://code.alibabatech.com/wiki/display/dubbo/Home/）。

应用程序只需要调用服务接口，服务框架根据配置自动调用本地或远程实现。

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

7.4 可扩展的数据结构

传统的关系数据库为了保证关系运算（通过SQL语句）的正确性，在设计数据库表结构的时候，就需要指定表的schema——字段名称，数据类型等，并要遵循特定的设计范式。这些规范带来的一个问题就是僵硬的数据结构难以面对需求变更带来的挑战，有些应用系统设计者通过预先设计一些冗余字段来应对，不过显然这是一种糟糕的数据库设计。

许多NoSQL数据库使用的ColumnFamily（列族）设计就是一个解决方案。

提前预设多少冗余字段都会捉襟见肘，疲于应付。
而使用支持ColumnFamily结构的NoSQL数据库，创建表的时候，只需要指定ColumnFamily的名字，无需指定字段（Column），可以在数据写入时再指定，通过这种方式，数据表可以包含数百万的字段，使得应用程序的数据结构可以随意扩展。

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

根据长尾效应，这些增值服务的数量越是庞大，种类越是繁多，盈利也就越多。同样，一个网站自己能够开发出的增值服务也是有限的。

大型网站为了更好地服务自己的用户，开发更多的增值服务，会把网站内部的服务封装成一些调用接口开放出去，供外部的第三方开发者使用，这个提供开放接口的平台被称作开放平台。

虽然每个网站的业务场景和需求都各不相同，但是开放平台的架构设计却大同小异

开放平台还需要分级的访问带宽限制，保证平台资源被第三方应用公平合理使用，也保护网站内部服务不会被外部应用拖垮。

7.6 小结

网站通过不断试错，在残酷的市场中寻找自己的竞争优势，持续地推出新功能，发现达不到预期，就立马下线。

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls