第一章:面向服务的体系架构(SOA)
分布式首要面临的问题:如何实现应用之间的远程调用(RPC:Remote Process Call 即远程过程调用,实现的方式如:RMI,WebService等方案)
a。基于HTTP协议的RPC:实现便捷、使用灵活、开放且天生支持异构平台之间的调用优点。
b。基于TCP协议的RPC:效率高,实现起来比较复杂,且由于协议和标准不同,很难实现跨平台和企业间的便捷通信。
RPC的实现包括客户端和服务端,即服务的调用方和服务的提供方。
c。对象的序列化:无论何种类型的数据,最终是以二进制流的方式在网络上进行传输。
在OOP中:对象的序列化、对象的反序列化。
较为常用的有Google的Protocal Buffers、JAVA本身内置的序列化方式、Hessian、JSON、XML等。
优缺点:Protocal Buffers:性能优异、支持跨平台,但是其编程代码入侵性比较强,需要编写proto文件,无法使用java的编程语言。
Hessian:相对protocal buffers来说,性能稍微低,对各种编程语言支持,性能稳定,需要引入hessian.jar包
java内置的序列化:性能低,但是不需要引入jar包。
现在比较流行的json与xml
http://blog.csdn.net/jaryle/article/details/52195276
java学习之Hessian通信基础
一:基于TCP协议的RPC
当服务调用者的规模达到一定的程度,对服务提供者的压力也不断的增加,so,服务需要进行扩容。而当服务提供方的增加和业务的发展,不同的服务之间
还需要进行分组,以隔离不同的业务,避免相互影响,在这种情况下,服务的路由和负载均衡则成为必要考虑的问题。服务调用方根据服务提供方的分组信息和
地址信息进行路由。
使用底层的传输协议Socket来远程调用,客户端使用socket,服务端使用socketsever来接受客户端的请求,在通过java反射机制来执行客户端所请求的方法,以及
返回执行后的结果
二:基于HTTP协议的RPC:
1.http请求与响应。
2.通过HttpClient发送HTTP请求:对htp协议的通信进行了封装。
String url=“http://www.baidu.com”;
//组装请求
HttpClient httpclient = new DefaultHttpClient();
HttpGet get = new HttpGet(url);
//接收响应
HttpRepose repose = httpclient.execute(get);
HttpEntity entity = repose.getEntity();
byte [] bytes = EntityUntils.toByteArray(entity);
String result = new String(bytes,"UTF-8")
三:TCP与HTTP协议的RPC的对比
TCP:优点:能够灵活对协议字段进行定制、减少网络传输字节、降低网络开销、提高性能、实现更大的吞吐量和并发数。
缺点:需要更多的关注底层复杂的细节(考虑并发、锁、I/O等),实现的代价更高,难以得到平台厂商和开源的支持,很难实现跨平台。
HTTP:优点:可以使用json、xml格式来响应数据,非常便捷。
缺点:其协议所传输的字节数远远超过tcp所传输的字节数,效率相比之下低。可以使用代码优化以及gzip的方式来压缩数据。
四:restful风格
其中的一个思想就是通过http请求对应的POST(增加)、GET(获取)、PUT(更新)、DELET(删除)方法,来完成对应的增删改查CRUD操作。
五:服务的路由和负载均衡
当服务的规模很小,可以采用硬编码的方式将服务地址和配置写在代码,可以采用LVS(是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统)或Nginx等软件解决方案,通过相关的配置,即可解决服务的路由及负载均衡问题。
当服务的规模很大,对应的服务器越来越多,单靠人工来管理和维护服务器地址和配置信息,很困难,单点故障的问题也开始凸显,一旦服务器路由或者负载均衡服务器的宕机,依赖它的所有服务均失效。
因此,需要一个能够动态的注册和获取服务信息的地方,来统一管理服务名称和服务器列表信息,称之为服务配置中心,服务提供者在启动时,将其提供的服务名称和服务地址注册到服务配置中心,服务消费者通过服务配置中心来获取需要调用的服务的机器列表,通过响应的负载均衡算法,选取一台服务器进行调用。当服务器宕机或者下线时,相应的机器能够动态的从服务配置中心里面移除,并通知相应的服务消费者,在此过程中,服务消费者只有在第一次调用服务时需要查询服务配置中心,然后将查询到的信息缓存到本地,后面的调用直接从本地的缓存读取即可,除非服务配置中心中发生服务器地址列表变更(上线或者下线)
A。基于ZooKeeper的路由和负载均衡架构
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。
它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
B. 负载均衡的算法
1.轮询(round robin)法:按照顺序轮流分配到后端服务器上,不关心服务器实际的连接数以及当前的系统负载
2.随机法:根据服务器列表的大小来随机选取其中的一台来进行访问。
3.源地址哈希(Hash)法:获取用户ip地址,通过hash函数来计算一个数值,然后和服务器列表大小来取模运算
4。加权轮询法:配置高的权重,让其处理更多的请求
5.加权随机法:按照权重来选择服务器
6.最小连接数(least connection)法:根据服务器当前的连接数,动态的选取其中当前积压连接数最少的一台服务器来处理当前请求,尽可能提高后端服务器的利用率,将负载合理地分流到每一台机器
B.1 通过Groovy动态脚本语言来实现负载均衡规则的动态配置
C。zkClient(zookeeper的第三方客户端工具)的使用:解决watcher的一次性注册问题。
D。HTTP服务网关