大型分布式网站技术架构笔记(一)

本文参考了两位阿里人写的书：《大型分布式网站架构设计与实践》（https://book.douban.com/subject/25972633/）《大型网站技术架构：核心原理与案例分析》（https://book.douban.com/subject/25723064/）

以下是本人的一些总结与思考。

大型分布式网站架构核心要素：
- 性能
- 可用性
- 伸缩性
- 扩展性
- 安全性

这里只做一个概述，具体目录如下：
大型分布式网站技术架构笔记(二) 性能优化
大型分布式网站技术架构笔记(三) 高可用架构

1 性能
性能是一个网站的重要指标，任何架构设计都必须考虑性能的问题。
性能涉及到前端优化，服务器端优化，数据库查询优化等多个方面。因此，只在此介绍一些常用的调优方式。

• 前端优化
  在浏览器端，可以使用浏览器缓存，页面压缩，页面合理布局，减少http请求等手段改善性能。
  还可以使用CDN，将静态内容分发至离用户最近的网络服务机房，使用户可以以最短的路径获取数据。

• 服务器端优化
  可以使用缓存，通过缓存的数据处理用户请求，加快请求过程，减轻数据库负载压力。
  也可以异步操作将用户请求发送至消息队列，等待后续处理，当前请求直接返回响应给用户。
  在网站有高并发的情况下，可以使用集群，提高整体处理能力，改善性能。
  在代码，可以使用多线程加快处理速度等手段优化性能。

• 数据库优化
  索引，缓存，SQL优化等手段都比较成熟。

性能优化最重要的一步，寻找性能瓶颈，也就是木桶原理中最短的那块木板。
这里介绍一些常用的测试性能的工具

• 前端优化工具–YSlow
  YSlow可以对网站的页面进行分析，并告诉你为了提高网站性能，如何基于某些规则而进行优化。 YSlow可以分析任何网站，并为每一个规则产生一个整体报告，如果页面可以进行优化，则YSlow会列出具体的修改意见

• 页面响应时间
  服务端单个请求的响应时间跟页面的响应时间以及页面的加载速度密切相关，借助；另外一个工具–firebug，可以清晰的看到整个页面的加载时间以及具体每一个请求响应的时间。这样就能快速找到响应慢得请求，并进行优化。

• 方法响应时间
  定位到响应慢的请求后，接下来就要深入发掘导致请求响应慢的原因，并且定位到具体的代码。通过对代码的检查，能定位到具体的方法和代码行，但是比较费时，又容易遗漏。
  java环境下有一种十分有效的追踪工具–btrace
  btrace可以用来帮我们做运行时的java程序分析，监控等等操作。

• 数据库查询
  很多方法响应慢，是由于查询数据库耗时比较多，查询语句比较糟糕。
  Mysql提供了慢SQL日志的功能，能够记录查询超过一定阈值的SQL查询。
  查看是否启用慢日志：
  show variables like ‘%log_slow_queriesd%’;
  查看慢于多少秒的SQL会记录到慢日志中：
  show variables like ‘%long_query_time%’;
  通过Mysql的配置文件，可以修改慢日志的相关配置；

以上工具的具体的安装及使用就不在这里一一展开了。

2 可用性
页面显示在用户面前需要经过很多的环节，任何一个环节出现问题，都会导致服务不可用，用户无法正常使用页面。这里不讨论硬件故障造成的不可用。
一个典型的网站设计通常分三层：

应用层负责业务逻辑处理，服务层提供可复用的服务，数据层负责数据的存储与访问。
在复杂的大型网站中，一般会划分的粒度更细，结构更复杂，旦通常都可以划分到这三层,以百度为例：

• 应用层
  为了应对高并发的访问请求，通常会使用负载均衡设备把一组的服务器组合为一个集群，共同对外提供服务。当负载均衡设备监控到某台服务器不可用时，就将其从集群中剔除，并把请求转发到集群中的其他可用的服务器。

• 服务层
  应用层通过分布式服务框架来调用这一层提供的服务。分布式服务框架会在应用层的客户端程序中实现软件级的负载均衡，并通过注册中心监控这些提供服务的服务器。一旦发现某个服务器不可用，会立即通知客户端程序修改服务访问列表，剔除不可用的服务器。

• 数据层
  写入数据的同时同步复制数据，把数据写入多台服务器，实现数据的冗余备份。当数据服务器宕机时，会把针对数据的访问切换到拥有备份数据的服务器上。

3 伸缩性

网站架构发展史其实就是一部不断向网站添加服务器的历史。
伸缩性架构分为两种：

• 根据功能进行物理分离 –不同服务器部署不同的服务。
• 单一功能通过集群实现 –集群内的多台服务器部署相同的服务，提供相同的功能。

3.1 根据功能进行物理分离

网站发展早期，总是从现有的服务器中分离出部分功能与服务的：

每次分离都会有更多的服务器加入，这些新增的服务器被用于处理某种特定的服务。这种伸缩性手段可以用于网站发展的任何阶段，它可以分为两种情况：纵向分离与横向分离。

• 纵向分离（分层后分离）：是将业务流程上的不同层进行分离部署。

• 横向分离（业务分割后的分离）：把不同的业务模块分离部署。

横向分离的粒度可以很小，比如一个关键网页可以独立部署为一个服务，专门部署。

3.2 单一功能集群部署
在 “根据功能进行物理分离” 的模式下，随着网站访问量的增长，即使是分离到最小粒度的独立部署也可能无法满足业务规模的需要。这时就必须使用集群，即把相同的服务部署在多台服务器构成的集群上，实现整体对外服务。
一个服务的集群规模，需要同时考虑可用性、性能以及关联服务集群的影响。
集群伸缩性又分为应用服务器集群伸缩和数据服务器集群伸缩。后面会一一探讨。

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

在此，对容易混为一谈的 “扩展性” 和 “伸缩性” 的概念进行详细说明：

• 扩展性

表现为：基础设施不需要经常变更，应用之间较少依赖或耦合，可以对需求变更快速响应。它对扩展开放，对修改关闭。架构设计会考虑到未来功能的可扩展性，所以当系统增加新功能时，不需要对现有系统的结构和代码进行修改。

• 伸缩性

是指系统通过增加（或减少）自身资源规模的方式增强（或减少）处理业务的能力。如果这种增减是成比例的，就可以称之为线性伸缩性。通常是利用集群的方式增加服务器的数量，以提高系统整体业务吞吐能力。

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

可以利用分层与分割的方式，把软件分割为若干个低耦合、独立的组件模块，然后在这些组件模块之间以消息传递或依赖调用的方式聚合成一个完整的系统。

这些模块可以通过分布式部署的方式，部署在独立的服务器上。这种从物理上分离模块之间的耦合关系，可以进一步降低耦合性。

模块的分布式部署后的聚合方式有：

• 分布式消息队列
• 分布式服务