论JAVA分布式服务架构(三)

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

2.2.1  SOA概述

SOA是面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

1、SOA的目标

使IT系统变得更有弹性，以便更灵活、更快地响应不断改变的企业业务需求，解决软件领域一直以来存在的“如何重用软件功能”问题。采用SOA来构建信息平台，无疑是未来的发展方向。

2、SOA基本特征

可重用的服务：一个服务创建后能用于多个应用和业务流程

松散耦合：服务请求者到服务提供者的绑定与服务之间应该是松耦合的，服务请求者不需要知道服务提供者实现的技术细节。

标准化的服务接口：服务交互必须是明确定义的。Web服务描述语言（Web Services Description Language，WSDL）是用于描述服务请求者所要求的绑定到服务提供者的细节。WSDL不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由哪种程序设计语言编写的。

无状态的服务设计：服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当产生依赖时，它们可以定义成通用业务流程、函数和 数据模型

基于开放标准：当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准．采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。

支持各种消息模式 ：无状态的消息、有状态的消息、等幂消息

可从企业外部访问

随时可用

粗粒度的服务接口分级

2.2.2  基于TCP和HTTP协议的RPC

RPC全称Remote Process Call，即远程过程调用，其服务的调用方与服务的提供方大致如下图所示，左右分别为一对一和多对多关系。RPC的主要目的是获取由远程机器上的程序所执行的结果。

在Java中，可以利用Socket API实现基于TCP协议的RPC调用。由服务的调用方与服务的提供方建立Socket连接，并由服务的调用方通过Socket将需要调用的接口名称、方法名称和参数序列化后传递给服务的提供方，服务的提供方反序列化后再利用反射调用相关的方法，最后将结果返回给服务的调用方。整个基于TCP协议的PRC调用大致如此，但是在实例应用中则会进行一系列的封装，譬如RMI便是在TCP协议上传递可序列化的java对象。由于TCP协议处于协议栈的下层，能够更加灵活地对协议字段进行定制，减少网络开销，提高性能，实现更大的吞吐量和并发数。但是需要更多地关注底层复杂的细节，实现的代价更高。同时对于不同平台（如安卓、iOS等），需要重新开发出不同的工具包来进行请求发送和响应解析，工作量大，难以快速响应和满足 用户需求。

而基于HTTP协议的RPC调用则更像是我们访问网页一样，只是它的返回结果更加单一简单。由服务的调用者向服务的提供者发送请求，这种请求的方式可能是GET、POST、PUT、DELETE等中的一种，而调用的具体方法则根据URL进行方法调用，而方法所需参数则可能是对服务调用方传输过去的XML数据或JSON数据解析后的结果，最后返回JOSN或XML的数据结果。如果使用HTTP协议实现的RPC则可以使用JSON和XML格式的请求或响应数据，而JSON和XML作为通用的格式标准，开源的解析工具已经相当成熟，在其上进行二次开发会非常便捷和简单。但是由于HTTP协议是上层协议，发送包含同等内容的信息，使用HTTP协议传输所占用的字节数会比使用TCP协议传输所占用的字节数更高。因此，同等网络环境下，通过HTTP协议传输相同内容，效率会比基于TCP协议的数据效率要低，信息传输所占的时间也会更长，当然使用gzip压缩数据，能够缩小这一差距。

2.2.3  服务的路由和负载均衡

SOA架构中，服务消费者是通过服务名称，在众多服务中寻找要调用的服务的地址列表，称为服务的路由，如下图所示：

而对于负载较高的服务来说，往往对应着由多台服务器组成的集群。在请求到来时，为了将请求均衡地分配到后端服务器，负载均衡程序将从服务对应的地址列表中，通过相应的负载均衡算法和规则，选取一台服务器进行访问，这个过程称为服务的负载均衡，如下图所示：

当服务的规模较小时，可以采用硬编码的方式将服务地址和配置写在代码中，通过编码的方式来解决服务的路由和负载均衡问题，也可以通过传统的硬件负载均衡设备或者采用LVS或Nginx等软件解决方案，通过相关配置，来解决服务的路由和负载均衡问题，如下图所示，由于服务的机器数量在可控范围内，因此维护成本能够接受。

当服务越来越多，规模越来越大时，对应的机器数量也越来越庞大，如下图所示，单靠人工来管理和维护服务及地址的配置信息，已经越来越难。并且，依赖单一的硬件负载均衡设备或者使用LVS、Nginx等软件方案进行路由和负载均衡调度，单点故障的问题也开始显现出来，一旦服务路由或者负载均衡服务器宕机，依赖它的所有服务均将失效。

此时，需要一个能够动态注册和获取服务信息的地方，来统一管理服务名称和其对应的服务器列表信息，称之为服务配置中心。如下图所示，服务提供者在启动时，将其提供的服务名称、服务器地址注册到配置中心，服务消费者通过服务配置中心来获取需要调用的服务的机器列表，通过相应的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面移除，并能和相应的服务消费者，否则服务消费者就有可能因为调用到已经失效的服务而发生错误。在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询的信息缓存在本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求到服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更（机器上线或者下线）。 这种无中心化的结构解决了之前负载均衡设备所导致的单点故障问题，并且大减轻了服务配置中心的压力。