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

@基于TCP协议的RPC

分布式应用架构的演变
单一应用架构》垂直应用架构》分布式应用架构

分布式应用架构所面临的首要问题是如何实现应用之间的远程调用RPC

RPC(Remote Process Call)，远程过程访问，应用广泛，实现方式很多，拥有RMI,WebService等诸多成熟的方案，在业界得到了广泛的应用。
RPC将原来的本地调用转变为调用远程的服务器上的方法，给系统的处理能力和吞吐量带来了近乎无限制的可能，这是系统发展到一定阶段必然性的变革，也是实现分布式计算的基础。

RPC的实现包括客户端和服务端，即服务的调用方和服务的提供方。
Consumer–>RPC–>Provider

随着业务的发展，服务调用的规模发展到一定阶段，对服务提供方的压力也日益增加，因此，服务需要进行扩容。而随着服务提供者的增加和业务的发展，不同的服务之间还需要进行分组，已隔离不同的业务，避免相互影响，在这种情况下，服务的路由和负载均衡则成为必须要考虑的问题。

无论是何种类型的数据，最终都要转化成二进制流在网络上进行传输
将对象转换成二进制流的过程为“对象的序列化”
将二进制流转换成对象的过程为“对象的反序列化”

对象的序列化和反序列化有很多成熟的解决方案，较为常用的有Google的Protocal Buffers，Java本身内置的序列化方式，Hessian，以及后面要介绍的JSON和XML等，它们各自有自己的优缺点。

@基于HTTP协议的RPC

HTTP（Hypertext Transfer Protocal）超文本传输协议，它是由W3C(World Wide Web Consortium,万维网协会)和IETF(Internet Engineering Task Force,因特网工程部)合作的成果，并逐渐发展成为整个互联网信息交换的标准，当今普遍采用的版本是HTTP1.1。

使用HTTP协议的优势和劣势
随着请求规模的扩展，基于TCP协议RPC的实现，程序需要考虑多线程并发，锁，I/O等复杂的底层细节的实现，实现起来较为复杂。在大流量高并发压力下，任意一个细小的错误，都会被无限放大，最终导致宕机。而对于基于HTTP协议的实现来说，很多成熟的开元WEB容器已经帮其处理好了这些事情，如Tomcat，Jboss，Apache，Nginx等，开发人员可以将更多的经理集中在业务的实现上，而非处理底层的细节。

当然，基于HTTP协议的实现也有处于劣势的一面。由于是上层协议，发送包含同等内容的信息，使用HTTP协议传输所占用的字节数肯定要比使用TCP协议传输所占用的字节数更多。因此，在同等网络环境下，通过HTTP协议传输相同内容，效率会比基于TCP协议的数据传输要低，信息传输所占用的时间要更长。
不过，通过优化代码和使用gzip数据压缩，能够缩小这一差距。通过权衡利弊，结合实际环境中其性能对于用户体验的影响来看，基于HTTP协议的RPC还是有很大优势的。

JSON(JavaScript Object Notation)数据对象标记语言，XML(Extensible Markup Language)可扩展标记语言。

两种主流的URL风格，RPC和RESTful风格
RPC风格很好理解，直接在HTTP请求参数中表明需要远程调用的服务端口名称，服务需要的参数等，如：
http://hostname/provider.php?service=sayhello&format=json&arg1=arg1&arg2=arg2
RESTful(Representational State Transfer，表现层状态转换)风格，在表现层状态转换中个，表现层其实指的是资源的表现层，资源是网络上的一个实体，可以是一张图片，一段文字等。RESTful风格其中的一个思想是，通过HTTP请求对应的POST,GET,PUT,DELETE方法，来完成对应的CRUD操作。

@服务的路由和负载均衡

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

SOA架构中，服务的消费者通过服务名称，在众多的服务中找到调用的服务的地址列表，称为服务的路由。如：
consumer->服务列表(service1，service2，service3…)->地址列表(service_address1，service_address2，service_address3…)

而对于负载较高的服务来说，往往对应着由多台服务器组成的集群。在请求到来时，为了将请求均衡地分配到后端服务器，负载均衡程序将从服务对应的地址列表中，通过相应的负载均衡算法和规则，选取一台服务器进行访问，这个过程成为服务的负载均衡，如：
consumer(remote_ip)->负载均衡算法(round_robin，random，weight_random)->地址列表(service_address1，service_address2，service_address3…)
consumer->服务列表(service1，service2，service3…)->地址列表(service_address1，service_address2，service_address3…)

当服务的规模较小时，可以采用硬编码的方式将服务地址和配置写在代码中，通过编码的方式解决服务的路由和负载均衡问题，也可以通过传统的硬件负载均衡设备如F5等，或者采用LVS或者Nginx等软件解决方案，通过相关配置，来解决服务的路由和负载均衡问题，由于服务的机器数量在可控制范围内，因此维护成本能够接受，单个服务的负载均衡架构：
consumer request->service(负载均衡）->service1,service2,service3…

当服务越来越多，规模越来越大时，对应的机器数量也越来越庞大，单靠人工来管理和维护服务及地址的配置信息，已经越来越困难。并且，依靠单一的硬件负载均衡设备或者使用LVS，Nginx等软件方案进行路由和负载均衡调度，单点故障的问题也开始凸显，一旦服务器或者负载均衡服务器宕机，依赖它的所有服务将失效。多服务器路由与负载均衡架构：
consumer request->服务路由->service1（负载均衡->service1,service2,service3…）,service2（负载均衡->service1,service2,service3…）,service3（负载均衡->service1,service2,service3…）…

此时需要一个能够动态注册和获取服务器信息的地方，来统一管理服务名称和其对应的服务器列表信息，称之为服务配置中心(ZooKeeper)。如下图是基于ZooKeeper的路由和负载均衡架构：

负载均衡算法，常见的有轮询法，随机法，源地址哈希法，加权轮询法，加权随机法，最小连接法等，应根据具体的使用场景选取对应的算法。

1，轮询法（Round Robin）
使用轮询法策略的目的在于，希望做到请求转移的绝对均衡，但付出的性能代价也是相当大的。为了pos保证变量修改的互斥性，需要引入重量级的悲观锁synchronized，将会导致该段轮询代码的并发吞吐量发生明显的下降。

2，随机法（Random）
基于概率的理论，吞吐量越大，随即算法的效果越接近轮询法效果。

3，源地址哈希（Hash）法
通过参数传入客户端的remote_ip参数，取得它的哈希值，对服务器列表的大小取模，结果便是选用的服务器在服务器列表中的索引值，该算法保证了相同的客户端IP地址将会被“哈希”到同一台后端服务器，知道后端服务器列表变更。根据此特性可以在服务消费者与服务提供者之间建立有状态的session会话。

4，加权轮询法（Weight Round Robin）
5，加权随机法（Weight Random）
不同的后端服务器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高，负载低的机器配置更高的权重，让其处理更多的请求，而低配置，负载高的机器，则给分配较低的权重，降低其系统负载，这就是加权的意思。

6，最小连接数算法（Least Connections）
最小连接数算法比较灵活和只能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它正是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前请求，尽可能提高后端服务器的利用效率，将负载均衡合理地分流到每一台服务器。

ZooKeeper介绍与环境搭建
ZooKeeper是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠的协调系统，提供的功能包括配置维护，名字服务，分布式同步，组服务等，ZooKeeper是可以集群复制的，集群间通过Zab（ZooKeeper Atomic Broadcast）协议来保持数据的一致性。

@HTTP服务网关（gateway）

如下图，基于网关的安全架构：

由图可知，服务提供者是不直接对外提供服务的，因此，对于外部的APP来说，它依赖gateway进行服务的路由以及请求的转发。
gateway是整个网络的核心节点，一段gateway失效，所有依赖它的外部APP都将无法使用。并且，由于所有的请求均经过gateway进行安全校验和请求转发，其流量是整个后端集群流量之和，可想而知，其流量会有多大。
因此，在设计之初，就需要考虑到系统流量的监控和容量规划，以及gateway集群的可扩展性，以便在流量达到极限之前，能够快速方便地进行系统扩容。

下图是一种网关集群的架构方案，一组对等的服务器组成网关集群，接受外部APP的HTTP请求，当流量“水位”达到警戒值时，能够较为方便地增加机器进行扩容。网关的前面有两台负载均衡设备，负载对网关集群进行负载均衡。负载均衡设备之间进行心跳检测，一旦其中一台宕机，另一台则变更自己的地址，接管宕机的这台设备的流量。平时两台机器均对外提供服务。