文章目录

1. 前言2. 服务2.1 为什么要做服务2.2 服务带来的挑战2.3 服务未来的趋势3. 框架3.1 服务框架对比3.1.1 Dubbo3.1.2 Dubbox3.1.3 Spring Cloud3.1.4 Motan3.1.5 Hessian3.1.6 rpcx3.1.7 gRPC3.1.8 thrift3.1.9 总结3.2 通信协议3.2.1 效率问题3.2.2 http和rpc是什么关系3.2.2.1 基于HTTP的远程调用方案。3.2.2.2 RPC3.2.3 什么情况下适用dubbo协议，什么时候适用rmi协议？

1. 前言

随着现在互联网行业的发展，越来越多的框架、中间件、容器等开源技术不断地涌现，更好地来服务于业务，解决实现业务的问题。然而面对众多的技术选择，我们要如何甄别出适合自己团队业务的技术呢？对于人来说，鞋子过大，可能影响奔跑的速度，鞋子过小，可能影响身体的成长。技术对于业务也是如此的关系。

所以，相对于技术的学习、搭建、使用、运维等技能，我们对技术的甄别选择更是重中之重。那么本文要讲的Dubbox框架，又是如何在众多的服务框架中脱颖而出，被团队选中践行服务之路？

2. 服务

2.1 为什么要做服务

技术为业务而生，架构也为业务而出现。随着业务的发展、用户量的增长，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。

系统架构演进

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

平台随着业务的发展从 All in One 环境就可以满足业务需求（以Java来说，可能只是一两个war包就解决了）；发展到需要拆分多个应用，并且采用MVC的方式分离前后端，加快开发效率；在发展到服务越来越多，不得不将一些核心或共用的服务拆分出来，提供实时流动监控计算等，其实发展到此阶段，如果服务拆分的足够精细，并且独立运行，这个时候至少可以理解为SOA架构了。

2.2 服务带来的挑战

当迎来服务SOA时代，我们面临要解决的问题会很多，比如：系统的复杂度上升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等。那么面对这些问题为什么还要做分布式服务呢？因为在未来只有砥砺前行，才能走的更高更远。不过看到这些问题不要气馁，先不管这些问题，让我们一步步来梳理下现存有什么问题，我们要完成什么目标。

根据现在团队的业务系统情况，首先我们要梳理出现存的问题是什么：

多种调用传输方式：HTTP方式、WebService方式；服务调用依赖关系：人工记录，查看代码分析；服务调用性能监控：日志记录，人工查看时间；服务与应用紧耦合：服务挂掉，应用无法可用；服务集群负载配置：Nginx配置，存在单点问题；

在去选择技术框架时，技术框架最基本要解决上面现存问题，同时我们也要确认出我们的期望，要达到的目标是什么：

支持当前业务需求，这是最最基本的条件；服务避免单点问题，去中心化；服务高可用、高并发，解耦服务依赖；服务通用化，支持异构系统调用服务；解耦系统服务间依赖，去重复；服务依赖关系自维护，可视化；服务性能监控自统计，可视化；服务需自带注册、发现、健康检查、负载均衡等特性；开发人员关注度高，上手快；

还有，最重要一点，这也是往往很多技术人员进入的误区，“对于技术，不要为了使用而使用，用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的，能快速方便的满足业务需求的架构才是好的架构。没有最好的，只有适合自己的。

2.3 服务未来的趋势

一谈到服务，可能大家很多听说过SOA、MSA等服务的概念名词，近几年MSA炒的比较火，其实每一个概念的背后都在解决不同的问题。此类名词的最大特点就是 一解释就懂，一问就不知，一讨论就打架 。

两者说到底都是对外提供接口的一种架构设计方式。我倒觉得微服务其实就是随着互联网的发展，复杂的平台、业务的出现，导致SOA架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。以这种说法做为根据，我觉得SOA与微服务的区别在于如下几个方面：

微服务相比于SOA更加精细 ，微服务更多的以独立的进程的方式存在，互相之间并无影响；微服务提供的接口方式更加通用化 ，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；微服务更倾向于分布式去中心化的部署方式 ，在互联网业务场景下更适合；

微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与 敏捷软件开发 思想是高度一致的，而它与SOA原则的演化的目标也是相同的，则减少传统的 企业服务总线 开发的高复杂性。两者之间最关键的区别在于， 微服务专注于以自治的方式产生价值。 但是两种架构背后的意图是不同的： SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

微服务并不是一种新思想的方法。它更像是一种思想的精炼，一种SOA的演进，并且更好地利用了先进的技术以解决问题，例如容器与自动化等。所以对于我们去选择服务技术框架时，并不是非黑即白，而是针对SOA、MSA两种架构设计同时要考虑到兼容性， 对于现有平台情况架构设计，退则守SOA，进则攻MSA，阶段性选择适合的。

3. 框架

现在业界比较成熟的服务框架有很多，比如：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技术实现，都可以进行远程调用，具体技术实现优劣参考以下分析，这也是具体在技术方案选择过程中的重要依据。

3.1 服务框架对比

3.1.1 Dubbo

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系，导致dubbo团队已经解散，反到是当当网的扩展版本 Dubbox 仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、国美维护了自己的分支或者在dubbo的基础开发，但是官方的库缺乏维护，相关的依赖类比如Spring，Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级Spring和Netty的插件。

Dubbo 于 年开始又重启维护，发布了更新后的 2.5.7 版本，而 Spring Cloud 更新的非常快。

3.1.2 Dubbox

Dubbox 和Dubbo本质上没有区别，名字的含义扩展了Dubbo而已，以下扩展出来的功能，也是选择Dubbox很重要的考察点。

支持REST风格远程调用（HTTP + JSON/XML)；支持基于Kryo和FST的Java高效序列化实现；支持基于Jackson的JSON序列化；支持基于嵌入式Tomcat的HTTP remoting体系；升级Spring至3.x；升级ZooKeeper客户端；支持完全基于Java代码的Dubbo配置；

3.1.3 Spring Cloud

Spring Cloud 完全基于 Spring Boot ，是一个非常新的项目，推出1.0的release版本，目前Github上更新速度很快. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全局琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用．它们将在任何分布式环境中工作，包括开发人员自己的笔记本电脑，裸物理机的数据中心，和像Cloud Foundry云管理平台。在未来引领这微服务架构的发展，提供业界标准的一套微服务架构解决方案。

缺点是项目很年轻，很少见到国内业界有人在生产上成套使用，一般都是只有其中一两个组件。相关的技术文档大部分是英文的，案例也相对较少，使用的话需要摸索的时间会长一些。

下图是Spring Cloud和Dubbo对比：

注意：这个图可能是早期的图，在Dubbo 2.7版本已经实现好多功能

虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。

3.1.4 Motan

Motan 是新浪微博开源的一个Java 框架。它诞生的比较晚，起于，5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。与Dubbo相比，Motan在功能方面并没有那么全面，也没有实现特别多的扩展。用的人比较少，功能和稳定性有待观望。对跨语言调用支持较差，主要支持java。

3.1.5 Hessian

Hessian 采用的是二进制RPC协议，适用于发送二进制数据。但本身也是一个Web Service框架对RPC调用提供支持，功能简单，使用起来也方便。基于Http协议进行传输。通过Servlet提供远程服务。通过Hessain本身提供的API来发起请求。响应端根据Hessian提供的API来接受请求。

Hessian优点：

整个jar很小，轻量；配置简单；功能强大 ，抛开了soap(simple object access protocal 简单对象访问协议)、ejb，采用二进制来传递对象；

3.1.6 rpcx

rpcx 是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

3.1.7 gRPC

gRPC 是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

3.1.8 thrift

thrift 是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。

3.1.9 总结

以上RPC框架功能比较：

实际场景中的选择：

Spring Cloud ： Spring全家桶，用起来很舒服，只有你想不到，没有它做不到。可惜因为发布的比较晚，国内还没出现比较成功的案例，大部分都是试水，不过毕竟有Spring作背书，还是比较看好。Dubbox： 相对于Dubbo支持了REST，估计是很多公司选择Dubbox的一个重要原因之一，但如果使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖，各有利弊，懂的取舍吧。Thrift： 如果你比较高冷，完全可以基于Thrift自己搞一套抽象的自定义框架吧。Montan： 可能因为出来的比较晚，目前除了新浪微博初发布的，Hessian： 如果是初创公司或系统数量还没有超过5个，推荐选择这个，毕竟在开发速度、运维成本、上手难度等都是比较轻量、简单的，即使在以后迁移至SOA，也是无缝迁移。rpcx/gRPC： 在服务没有出现严重性能的问题下，或技术栈没有变更的情况下，可能一直不会引入，即使引入也只是小部分模块优化使用。

3.2 通信协议

请回答一个问题，http和rpc是什么关系？

3.2.1 效率问题

pc是远端过程调用，其调用协议通常包含传输协议和序列化协议。

上面我们列举的Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技术框架，底层需要使用具体的协议来传输数据。

传输协议包含: 如著名的 [gRPC](grpc / grpc.io) 使用的 http2 协议，也有如dubbo一类的自定义报文的tcp协议，称之为dubbo协议。序列化协议包含: 如基于文本编码的 xml json，也有二进制编码的 protobuf hessian等。

为什么要使用自定义 tcp 协议的 rpc 做后端进程通信，而不是直接用http协议？要解决这个问题就应该搞清楚 http 使用的 tcp 协议，和我们自定义的 tcp 协议在报文上的区别。

首先要否认一点 http 协议相较于自定义tcp报文协议，增加的开销在于连接的建立与断开。http协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接。http也可以使用protobuf这种二进制编码协议对内容进行编码因此二者最大的区别还是在传输协议上。

通用定义的http1.1协议的tcp报文包含太多废信息，一个POST协议的格式大致如下：

HTTP/1.0 200 OK Content-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84<html><body>Hello World</body></html>

即使编码协议也就是body是使用二进制编码协议，报文元数据也就是header头的键值对却用了文本编码，非常占字节数。如上图所使用的报文中有效字节数仅仅占约 30%，也就是70%的时间用于传输元数据废编码。当然实际情况下报文内容可能会比这个长，但是报头所占的比例也是非常可观的。那么假如我们使用自定义tcp协议的报文如下：

报头占用的字节数也就只有16个byte，极大地精简了传输内容。

这也就是为什么后端进程间通常会采用自定义tcp协议的rpc来进行通信的原因。

所谓的效率优势是针对http1.1协议来讲的，http2.0协议已经优化编码效率问题，像grpc这种rpc库使用的就是http2.0协议。这么来说吧http容器的性能测试单位通常是kqps，自定义tpc协议则通常是以10kqps到100kqps为基准

3.2.2 http和rpc是什么关系

HTTP和RPC不是对等的概念。

RPC是一个完整的远程调用方案，它包括了：接口规范+序列化反序列化规范+通信协议等。

而HTTP只是一个通信协议，工作在OSI的第七层，不是一个完整的远程调用方案。

3.2.2.1 基于HTTP的远程调用方案。

HTTP+Restful，其优势很大。它可读性好，且可以得到防火墙的支持、跨语言的支持。而且，在近几年的报告中，Restful大有超过RPC的趋势。

但是使用该方案也有其缺点，这是与其优点相对应的：

首先是有用信息占比少，毕竟HTTP工作在第七层，包含了大量的HTTP头等信息。其次是效率低，还是因为第七层的缘故，必须按照HTTP协议进行层层封装。还有，其可读性似乎没有必要，因为我们可以引入网关增加可读性。此外，使用HTTP协议调用远程方法比较复杂，要封装各种参数名和参数值。

而RPC则与HTTP互补，我们详细介绍下。

3.2.2.2 RPC

RPC可以使用http协议或其他协议完成数据传输，但是额外多了要序列化、异常处理等内容。

下面是客户端的代码，看着类有点多，其实代码不长。其中的RPC代码完成完成动态代理、远程调用参数序列化、远程调用发起、远程调用结果反序列化的工作：

下面是服务端的代码，代码更少，完成远程调用接收、调用参数反序列化、调用实际触发、调用结果序列化的工作：

3.2.3 什么情况下适用dubbo协议，什么时候适用rmi协议？

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是dubbo协议是官网推荐使用的，dubbo 缺省协议是dubbo协议，采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

RMI协议采用阻塞式(同步)短连接和 JDK 标准序列化方式。适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。后面会对其他几种协议详细介绍，这里就不赘述了。