大型分布式网站架构-CSDN博客

2019独角兽企业重金招聘Python工程师标准>>>

SOA（Service-Oriented Architecture 面向服务的体系结构）

服务化的体系，即SOA，SOA系统之间以服务的方式来进行交互，这样就保证了交互的标准性，这对一个多人开发的大型网站至关重要；

实现SOA的重点： 1. 实现基本的服务方式的请求/响应 2. 对于访问量巨大的网站，主要都是采用可水平伸缩的集群方式来支撑巨大的访问量，这涉及到在服务交互时需要做负载均衡的处理；硬件负载均衡成本大，还会导致单点的巨大风险，目前各大网站多数采取软件负载的方式实现服务的交互；

第一章面向服务的体系架构（SOA）

单一应用架构拆分成垂直应用架构，解决了单一应用架构所面临的扩容问题，流量能分散到各个子系统中，且系统的体积可控，一定程度上降低了维护成本，提高开发效率；但当垂直应用越来越多，达到一定规模时，应用之间相互交互、调用不可避免；否则不同系统之间存在着重叠的业务，容易形成信息孤岛，重复造轮子；此时，相对核心的业务将被抽取出来，作为单独的系统对外提供服务，打成业务之间的相互复用，系统也因此演变成分布式应用架构体系；

分布式应用架构所面临的首要问题，便是如何实现应用之间的远程调用(RPC)。基于HTTP协议的系统间的RPC，具有使用灵活、实现便捷(多种开源的Web服务器支持)、开放(国际标准)且天生支持异构平台之间的调用等多个优点，得到了广泛的使用；而基于TCP协议的RPC实现版本，它效率更高，但实现起来更加复杂，且由于协议和标准不同，难以进行扩平台和企业间的便捷通信。当服务越来越多。原本基于F5、LVS等负载均衡策略、服务地址管理和配置变得相当复杂繁琐，单点压力也越来越大。服务的动态注册和路由、更加高效的负载均衡的实现，成为了期待解决的问题；

RPC (Remote Process Call)，单台服务器的处理能力受硬件成本的限制，不可能无限制提升。RPC将原来的本地调用转变为调用远端的服务器上的方法，给系统的处理能力和吞吐量带来了近似于无限制提升的可能，这是系统发展到一定阶段的必然性变革，也是实现分布式计算的基础；

附：网络七层协议模型

基于 TCP 协议实现 RPC：

RPC 的实现包括客户端和服务端；服务调用方发送RPC请求到服务提供方，服务提供方根据调用方提供的参数执行请求方法，将执行结果返回给调用方，一次RPC调用完成；这里涉及到调用参数及响应结果的序列化和反序列化操作，以及非阻塞 I/O （常用 Netty 框架）等；

对象的序列化：无论是何种类型的数据，最终都需要转换成二进制流在网络上进行传输；数据的发送方需要将对象转换成二进制流(对象的序列化)，而数据的接收方则需要把二进制流再恢复为对象(对象的反序列化)；序列化框架重点(1. 序列化性能 2. 序列化之后的码流大小 3. 是否跨平台 4.使用的难易程度)；Google的ProtoBuf性能优异、支持跨平台，但需要编写proto文件，代码侵入性较强；Hessian效率相对ProtoBuf较低、跨平台，性能比Java自带序列化方式高很多；

所有的网络协议都是采用Big Endian 字节序来进行传输的；附：大端序和小端序

基于 HTTP 协议实现 RPC

HTTP 协议属于应用层协议，它构建在TCP(传输层)和IP(网络层)协议之上，处于TCP/IP体系架构中的顶端，它不需要处理下层协议间诸如丢包补发、握手及数据的分段和重新组装等繁琐的细节，使开发人员可以专注于上层应用的设计；

基于TCP协议实现的RPC：由于处于协议栈的下层(传输层)，能够更灵活地对协议字段进行定制，减少网络传输的字节数，降低网络开销，提高性能，实现更大的吞吐量和并发数，但是需要更多地关注底层复杂的细节，实现的代价更高，且由于协议自身的局限性，难以得到平台厂商和开源社区的支持，较难实现跨平台的调用。如果是基于HTTP协议来实现RPC，不同平台的移动端应用程序，像Android、HTML5、IOS等都需要重新开发不同的工具包来进行请求发送和响应解析，工作量很大，难以快速响应和满足用户需求；随着请求规模的扩展，基于TCP协议的RPC实现，程序需要考虑多线程并发、锁、I/O等复杂的底层细节实现，实现较为复杂。在大流量高并发压力下，任意一个细小的错误都会被无限放大，最终导致程序宕机。

基于HTTP协议实现的RPC：基于HTTP协议的RPC可以使用JSON或XML格式的响应数据，解析简单便捷；对基于HTTP协议的实现来说，有很多成熟的开源Web容器(Tomcat、Jboss、Apache等)，开发人员可以更多集中精力在业务上，而不是底层细节；劣势：由于是上层协议，发送包含同等内容的信息，使用HTTP协议传输所占字节数比使用TCP协议传输所占字节数更多，同等网络环境下，传输耗时会更长；

RESTful 和 RPC

RPC 风格的 URL：

RESTful 风格的一个思想是，通过HTTP请求对应的 POST、GET、PUT、DELETE方法，来完成对应的 CRUD 操作；

服务的路由和负载均衡

分布式应用架构体系对于业务逻辑复用的需求十分强烈，上层业务都想借用已有的底层服务，来快速搭建更多、更丰富的应用，降低新业务开展的人力和时间成本，快速满足瞬息万变的市场需求。公共业务被拆分出来，形成可共用的服务，最大程度地保障代码和逻辑的复用，避免重复建设，这种设计也称为 SOA；

服务的路由： SOA架构中，服务消费者通过服务名称，在众多服务中找到要调用的服务的地址列表；

负载均衡：通过相应的负载均衡算法阿和规则，将请求均衡地分配到后端服务器集群中；（负载均衡算法：(加权)轮询法、随机法、源地址Hash法、最小连接数法等）

服务配置中心：一个能动态注册和获取服务信息的地方，来统一管理服务名称和其对应的服务器列表信息；（如：基于Zookeeper的路由和负载均衡架构）；另外也可以基于Groovy脚本语言动态配置负载均衡的路由规则；

HTTP服务网关

近年来所流行的开放平台；HTTP请求报文、参数等为明文，公共环境下必须建立一个强大的安全体系，来保障相关数据和接口的安全；网关(gateway): 接受HTTP请求，完成权限和安全校验，根据传入的服务名称，到服务配置中心找到相应的服务名称节点，加载对应的服务提供者的地址列表，通过负载均衡算法，选取机器发起远程调用，将客户端参数传递到后端服务器；服务提供方根据所传入的参数，进行处理给出响应；当gateway接收到响应后，再将响应输出给客户端APP；

一种网关集群的架构方案：一组对等的服务器组成网关集群，接收外部APP的HTTP请求；为了方便增加服务器进行扩容，网关集群前有两台负载均衡设备；

第二章分布式系统的基础设施

分布式协作及配置管理系统Zookeeper、分布式缓存系统、持久化存储、分布式消息系统、搜索引擎，以及CDN系统、负载均衡系统、运维自动化系统，实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等；

分布式缓存：主要用于在高并发环境下，减轻数据库压力，提高系统的响应速度和并发吞吐；磁盘处理速度和内存不是一个级别的，无法处理大量的读、写请求；本地缓存、分布式缓存；

Memcache 和 Redis： Redis 和 Memcached 对比： http://www.importnew.com/26921.html

Consistent Hash 分布式Session

持久化存储： MySQL、HBase、Redis；

MySQL扩展 (1.业务拆分，进行分库 2.读写分离，主从复制 3.分库分表)

通常情况下我们只开启一台Master的写入，另一台Master仅仅stand by或者作为读库开放，这样可以避免数据写入的冲突，防止数据不一致的发生；

HBase：列存储数据库；伸缩能力好，更适合海量数据的存储和处理；但能支持的查询维度有限；可以使用搜索引擎来构建索引，在一定程度上解决HBase复杂条件组合查询问题；

HBase 的二级索引表

Redis： STRING、HASH、LIST、SET、ZSET

消息系统：同步转异步，降低系统耦合，提高健壮性，更快响应，提供更高吞吐量，削峰填谷，缓解集群压力； P2P(点对点)、Pub/Sub(发布订阅)

垂直化搜索引擎：主要针对企业内部的自有数据的检索；全文检索、模糊匹配，解决分布式环境下分库分表或使用NoSQL，导致无法进行多表关联或进行复杂查询的问题；

搜索引擎的几个概念: 倒排(反向)索引(inverted index)：将文档中的词作为关键字，建立词和文档的映射关系; 分词：将句子或段落进行切割，从中提取出包含固定语义的词；排序: 将相关度更高的文档排在前面；

Lucene的几个概念: 文档(Document)是一系列域(Field)的组合; 域(Field)代表一系列与文档相关的内容; 词(Term)是搜索的基本单元，与Field对应，它包括了搜索的域的名称以及搜索的关键词，可以用它来查询指定域中包含特定内容的文档；查询(Query)，最基本的查询可能是一系列Term的条件组合，成为TermQuery,也可能是短语查询(PhraseQuery)、前缀查询(PrefixQuery)、范围查询等; 分词器(Analyzer)；