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 于 2017 年开始又重启维护，发布了更新后的 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 ，是一个非常新的项目，2016年推出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 框架。它诞生的比较晚，起于2013年，2016年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： 可能因为出来的比较晚，目前除了新浪微博16年初发布的，
• 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/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: 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 标准序列化方式。适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。后面会对其他几种协议详细介绍，这里就不赘述了。