第七章 随需应变：网站的可扩展架构
为什么有的网站必须规定系统发布日，一到发布日如临大敌，整个技术部都加班通宵达旦，而有的网站就可以随时发布，新功能就可以随时上线？
这些赖于网站的扩展性架构设计，就是在对现有系统影响最小的情况下，系统功能可持续扩展及提升能力。
扩展是针对代码添加，伸缩是增对资源增加减少。
7.1 构建可扩展的网站架构
开发低耦合系统是软件设计的终极目标之一，从各种软件到工具集再到各种框架，降低软件系统耦合性是终极目标。
那么如何分解系统各个模块、如何定义各个模块的借口、如何复用组合不同模块构造成一个完整的系统，这是软件设计中最有挑战的部分。
分层和分割方式进行架构伸缩，这也是模块化设计（如前端的react、vue等组件的思想，还有模板引擎的继承等特性）的重要手段，利用分层和分割的方式将软件分割为若干个低耦合的独立的组件模块。
模块分布式部署以后，具体聚合方式主要由分布式消息队列和分布式服务。
7.2 利用分布式消息队列降低系统耦合性
7.2.1 事件驱动架构
EDA(EVENT DRIVEN ARCHITECTURE)事件驱动架构：通过在低耦合的模块之间传输消息，以保持模块的松散耦合。最经典的就是生产者消费者模式（操作系统的）以及分布式消息队列。
消息发送者和接受者没有直接耦合，一方对另一方没有直接影响。
7.2.2 分布式消息队列
先进先出的模式，著名的分布式消息队列有很多，比如Apache、activeMq。
伸缩性方面，在加入服务器时，通知生产者服务器更改消息队列服务器列表即可。
可用性，为了避免消息队列服务器宕机造成消息丢失，会将消息成功发送到消息队列存储在消息生产者服务器上，等消息真被消费之后，才删除。
7.3 利用分布式服务打造可复用的业务平台。
随着网站的发展演化，整个网站逐渐发展会成为一个巨无霸，带来编译、部署、维护、开发的巨大麻烦。
1、编译、部署时间长。
2、代码分支管理困难
3、数据库连接耗尽
4、新增业务苦难
解决方案就是拆分，将模块独立部署，降低系统耦合性。
纵向拆分：将一个大应用拆分为多个小应用。
横向拆分：讲可复用的业务拆分处理，独立部署为分布式服务。
7.3.1 Web Service 与企业级分布式服务
web service是企业应用系统开发领域最时髦的词汇之一，服务提供WSDL想注册中兴描述自身提供的服务接口属性，注册中心发布服务。服务请求者通过soap和服务提供者通信。
缺点：
1、臃肿的发现和***制
2、低效xml序列化手段
3、开销大的http远程通信
4、复杂部署和维护手段。
7.3.2 大型网站分布式服务的需求与特点
对于大型网站，除了web service提供的服务注册于发现、服务调用等功能外，还需要分布式框架支持一下特性。
负载均衡：对热门服务比如登录、商品服务，要部署在一个集群上。
失效转移：可复用会被多个应用调用，一旦不可用，要提供失效转移机制。
高效的远程通信
整合异构系统
对应用最少的侵入
版本管理
实时监控
7.3.3 分布式服务框架设计
大型网站需要更简单高效的分布式服务框架构建其SOA（service orientend architecture面向服务的体系架构）。利用Thrift管理器分布式服务，服务的注册、发现以及调用都通过thrift完成。
Dubbo为例分析架构设计。
多种通信协议和序列化协议，使用NIO通信框架，有较高的网络通信性能。
7.4 可扩展的数据结构
7.5 利用开放平台建设网站生态圈
API接口：是开房平台暴露给开发者使用的一组API，其形式可以是RESTFUL\WEBSERVICE\RPC等各种形式。
协议转换：将各种API输入转换成内部服务可以识别的形式，并将内部服务的返回封装成API的格式。
安全：身份识别、权限控制、带宽限制等
审计：访问情况、计费、监控
路由：将开放平台的各种访问路由映射到具体内部服务
流程：将一组离散的服务组成一个上下文相关的新服务，提供统一接口