大型分布式网站架构

2018-02-11 14:10:53来源:oschina作者:srdlhz人点击

分享

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




最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台