《大型网站技术架构:核心原理与案例分析》读书笔记（二）
5. 万无一失：网站的高可用架构
5.1 网站可用性的度量和考核
网站可用性度量
网站不可用事件（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%
故障分=故障时间(分钟)*故障权重、
5.2 高可用的网站架构
网站的高可用架构设计的主要目的：保证服务器硬件故障时服务依然可用，数据依然保存并能被访问。主要手段：数据和服务的冗余备份及失效转移。
分层模型三层：应用层，服务层，数据层。各层之间具有相对独立性，应用层主要负责具体业务逻辑处理，服务层负责提供可复用的服务，数据层负责数据存储与访问。
中小型网站在具体部署时，通常将应用层和服务层部署在一起，而数据层则另外部署。在复杂的大型网站架构中，划分的粒度会更小，更详细，结构更加复杂，服务器规模更加庞大，但通常还是能够把这些服务器划分到这三层中。
位于应用层的服务器：通常时为了应对高并发的访问请求，通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上，使整个集群保持可用，从而实现应用高可用。
位于服务层的服务器：通过集群方式实现高可用，这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，发现有服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用的服务器。
位于数据层的服务器：数据服务器上存储着数据，为了保证服务器宕机时数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到备份的服务器上。
5.3 高可用的应用
无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次每次请求提交数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完成对等，请求提交到任意服务器，处理结果都是完全一样的。
通过负载均衡进行无状态服务器的失效转移
5.4 高可用的服务
可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务都独立分布部署，被具体应用远程调用，是无状态的服务。
高可用的服务策略：
（1）分级管理
运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。同时在服务部署上进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务器则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同区域的数据中心。
（2）超时设置
在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。
（3）异步调用
应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
（4）服务降级
在网站访问高峰期，为保证核心应用和功能的正常运行，需对服务进行降级：
拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用。随机拒绝访问请求调用，节约资源，让另一部分请求得以成功，避免全部无法响应服务。
关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。
（5）幂等性设计
在服务层保证服务重复调用和调用一次产生的结果相同即服务具有幂等性，避免虚假失败。
5.5 高可用的数据
保证数据存储高可用的手段主要是数据备份和失效转移机制。
数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。
失效转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。
5.6 高可用网站的软件质量保证
网站发布
通常使用发布脚本完成发布：
（1）关闭负载均衡服务器上一台或一小批服务路由
（2）关闭这台（些）服务器应用
（3）同步（复制）软件代码包到这台（些）服务器
（4）启动这台（些）服务器
（5）打开负载均衡服务器上这台（些）服务器的路由
（6）集群所有辑器发布完成？若没有则重复1操作。
发布过程中，每次关闭服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。
5.7 网站运行监控
监控数据采集
（1）用户行为日志收集：服务器端日志收集，客户浏览器日志收
（2）服务器性能监控
（3）运行数据报告
监控管理
（1）系统报警
（2）失效转移
（3）自动优雅降级
6.永无止境：网站的伸缩性架构
6.1 网站架构的伸缩性设计
网站的伸缩性设计可分成两类：
（1）根据功能进行物理分离实现伸缩，不同的服务器部署不同服务，提供不同功能
（2）单一功能通过集群实现伸缩，集群内多台服务器部署相同的服务，提供相同的功能
不同功能进行物理分离实现伸缩
（1）单一服务器处理所有服务
（2）数据库从应用服务器分离
（3）缓存从应用服务器分离
（4）静态资源从应用服务器分离
纵向分离（分层后分离）：将业务处理流程上的不同部分分离部署，实现系统伸缩性。
（1）网站具体产品
（2）可复用业务服务
（3）基础技术服务
（4）数据库
6.2 应用服务器集群的伸缩性设计
HTTP重定向负载均衡
HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览器。
负载均衡方案优点比较简单，缺点是浏览器需要两次请求服务器才能完成一次访问性能较差，重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多。
DNS域名解析负载均衡
在DNS服务器中配置多个A记录，每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。
DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可以加快用户访问速度，改善性能。
DNS域名解析负载均衡缺点：目前的DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改DNS的A记录，要使其生效也需要较长时间，这段时间，DNS依然会将域名解析到已经下线的服务器，导致用户访问失败；而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
6.3 分布式缓存集群的伸缩性设计
新上线的的缓存服务器对整个分布式缓存集群的影响最少，即新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能被访问到，这是分布式缓冲集群伸缩性设计的最主要目标。
Memcached分布式缓存集群的访问模型
应用程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端主要由一组API、Memcached服务器集群路由算法，Memcached服务器集群列表及通信模块构成。
其中路由算法负责根据应用程序输入的缓存数据KEY计算得到应该讲数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器数据（读缓存）。
Memcached分布式缓存集群的伸缩性挑战
余数Hash路由算法可以保证缓存数据在整个Memcached服务器集群中比较均衡地分布。可以稍微改进，实现和负载均衡算法中加权负载均衡一样的加权路由。
当分布式缓存集群需要扩容时，如2台服务器扩容至四台服务器，大约75%（3/4）被缓存了的数据不能正确命中，而随着服务器集群规模的增大，这个比例线性上升。当100台服务器集群中加入一台新服务器，不能命中率时99（N/N+1）.
6.4数据存储服务器集群的伸缩性
关系数据库集群的伸缩性设计
市场上主要的关系数据都支持数据复制功能，使用这个功能可以对数据库进行简单伸缩。
多台服务器部署MySQL实例，但是他们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。
除了数据库主从读写分离，业务分割模式可用数据库，不同业务数据表部署在不同的数据库集群上，即俗称的数据分库。这种方式的约束条件是跨库的表不能进行Join操作。
Cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间（Cobar也支持独立部署，以lib的方式和应用程序部署在一起）应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行（每个MySQL实例都部署为主、从结构，保证数据高可用）。
（1）前端通信模块负责和应用程序通信，接收到SQL请求后转交给SQL解析模块，SQL解析模块解析获得SQL路由规则查询条件再转交给SQL路由模块
（2）SQL路由模块根据路有规则配置将应用程序提交SQL解析成两条SQL转交给SQL执行代理模块，发送给数据库A和B分布执行。
（3）数据库A和数据库B的执行结果返回至SQL执行模块，通过结果合并将两个返回结果集合并成一个结果集，最终返回给应用程序，完成在分布式数据库中的一次访问请求。
7.1 构建可扩展的网站架构
设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提高模块的复用性。
在大型网站中，这些模块通过分布式部署的方式，独立的模块部署在独立的服务器（集群）上，从物理上分离模块之间的耦合关系，进一步降低耦合性提高复用性。
模块分布式式部署以后具体聚合方式主要有分布式消息队列和分布式服务。
7.2 利用分布式消息降低系统耦合性
事件驱动架构
通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型EDA架构就是操作系统中常见的生产者消费者模式。在大型网站架构中，最常用的是分布式消息队列。
消息队列利用发布-订阅模式工作，消息发送者发布消息，一个或者多个消息接受者订阅消息。消息发送者是消息源，在对消息进行处理后将消息发送至分布式消息队列，消息接受者从分布式消息队列获取该消息后继续进行处理。
消息接受者在对消息进行过滤、处理、包装后，构造成一个新的消息类型，将消息继续发送出去，等待其他消息接受者订阅处理该消息。
由于消息发送者不需要等待消息接受者处理数据就可以返回，系统具有更好的系统延迟，同时，在网站访问高峰，消息可以暂时存储在消息队列中等待消息接受者根据自身负载处理能力控制消息处理速度，减轻数据库等后端存储的负载压力。
7.3 利用分布式服务打造可复用的业务平台
巨无霸应用系统带来的问题：
（1）变异、部署困难
（2）代码分支管理困难
（3）数据库连接耗尽
（4）新增业务困难
解决方案就是拆分，将模块独立部署，降低系统耦合性。拆分可以分为纵向拆分和横向拆分两种。
纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块代码，即可快速搭建一个应用系统，而模块内业务逻辑变化的时候，只要接口保持一致就不会影响业务程序和其他模块。
纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离，使其成为独立的Web应用。横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务依赖关系，还需要一个完善的分布式服务管理框架。
Web Service与企业级分布式服务
服务提供者通过WSDL（Web Service Description Language，Web服务描述语言）想注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用UDDI（Universal Description，Discovery，and Integration，统一描述、发现和集成）发布服务提供者提供的服务，服务请求这从注册中心检索到服务信息后，通过SOAP（Simple Object Access Protocol，简单对象访问协议）和服务提供者通信，使用相关服务。
Web Service固有的缺点：
（1）臃肿的注册与发现机制
（2）低效的XML序列化手段
（3）开销相对较高的HTTP远程通信
（4）复杂的部署与维护手段
大型网站分布式服务的需求与特点
负载均衡，失效转移，高效的远程通信，整合异构系统，对应用最少侵入，版本管理，实时监控
分布式服务框架设计
SOA（ServiceOriented Architecture面向服务的体系架构）分布式服务架构
Dubbo的远程服务通信模块支持多种通信协议和数据序列化协议，使用NIO通信框架，具有较高的网络通信性能。
7.4 可扩展的数据结构
许多NoSQL数据库使用的ColumnFamily（列族）设计就是一个可扩展的数据库架构设计（无需修改表结构就可以新增字段）的解决方案。ColumnFamily最早在Google的Bigtable中使用，这是一种面向列族的稀疏矩阵存储格式。
支持ColumnFamily结构的NoSQL数据库，创建表的时候，只需要指定ColumnFamily的名字，无需指定字段（Column），可以在数据写入时再指定，通过这种方式，数据表可以包含数百万的字段，使得应用程序的数据结构可以随意扩展，在查询时，可以通过指定任意字段名称和值进行查询。
7.5 利用开放平台建设网站生态圈
开放平台时网站内部和外部交互的接口，外部需要面对众多的第三方开发者，内部需要面对网站内部诸多的业务服务。
API接口：是开发平台暴露给开发者使用的一组API，其形式可以是RESTful、WebService、RPC等各种形式。
协议转换：将各种API输入转换成内部服务可以识别的形式，并将内部服务的返回封装给API的格式。
安全：除了一般应用需要的身份识别、权限控制的安全手段，开放平台还需要分级的访问宽度限制，保证平台资源被第三方应用公平合理使用，也保护网站内部服务不会被外部应用拖垮。
审计：记录第三方应用的访问情况，并进行监控、计费等。
路由：将开放平台的各种访问路由映射到具体的内部服务
流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。
翻译 朗读 复制 正在查询，请稍候…… 重试 朗读 复制 复制 朗读 复制 via 谷歌翻译（国内） 译
浙公网安备 33010602011771号