大型分布式网站架构设计与实践 第一章

第一章：面向服务的体系架构（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的重要组件。

它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper的基本运转流程：

1、选举Leader。

2、同步数据。

3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。

4、Leader要具有最高的执行ID，类似root权限。

5、集群中大多数的机器得到响应并接受选出的Leader

B. 负载均衡的算法

1.轮询（round robin）法：按照顺序轮流分配到后端服务器上，不关心服务器实际的连接数以及当前的系统负载

2.随机法：根据服务器列表的大小来随机选取其中的一台来进行访问。

3.源地址哈希（Hash）法：获取用户ip地址，通过hash函数来计算一个数值，然后和服务器列表大小来取模运算

4。加权轮询法：配置高的权重，让其处理更多的请求

5.加权随机法：按照权重来选择服务器

6.最小连接数（least connection）法：根据服务器当前的连接数，动态的选取其中当前积压连接数最少的一台服务器来处理当前请求，尽可能提高后端服务器的利用率，将负载合理地分流到每一台机器

B.1通过Groovy动态脚本语言来实现负载均衡规则的动态配置

C。zkClient（zookeeper的第三方客户端工具）的使用：解决watcher的一次性注册问题。

D。HTTP服务网关