浅谈为何选择Dubbo

本文摘录至搜狐，个人觉得很值得已读，仅用于学习交流。

1. 为什么要做服务？

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

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

服务 为什么要做服务？

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

1. 1>单一应用架构，当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架（ORM）是关键。

2. 什么是ORM
   即Object-Relationl Mapping，它的作用是在关系型数据库和对象之间作一个映射，这样，我们在具体的操作数据库的时候，就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作它就可以了 。
   个人理解：就是将通用的增删改查抽取成业务层或者持久层的公共方法，方便系统中重复调用。

3. 2>垂直应用架构，当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架（MVC）是关键。

4. 什么是MVC
   MVC是一个架构，或者说是一个设计模式，它就是强制性使应用程序的输入，处理和输出分开。将一个应用程序分为三个部分：Model，View，Controller。
   MVC的优点：分工明确（分层）、松耦合（视图层和业务层分离）、复用性高（多个视图能够共享一个模型、提高代码复用性）。
   MVC的缺点：1、有时会导致级联的修改（变现层修改导致各层都要修改）。2、降低了系统的性能（不能直接调用数据库）。
   个人理解：MVC主要实现的就是前后端分离，视图层和业务层分离。

5. 3>分布式服务架构，当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架（RPC）是关键。

6. 

7. 4>流动计算架构当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心（SOA）是关键。
   
   分布式服务框架相关文章：https://www.cnblogs.com/jiyukai/p/9459983.html

2. 服务带来的挑战
服务带来的挑战

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

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

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

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

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

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

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

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

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

服务框架对比

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

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

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

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对比：

实际场景中的选择：
1.Spring Cloud：Spring全家桶，用起来很舒服，只有你想不到，没有它做不到。

2.Dubbox：相对于Dubbo支持了REST，估计是很多公司选择Dubbox的一个重要原因之一，但如果使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖，各有利弊，懂的取舍吧。

RPC 和 REST API
由于Dubbo是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如Dubbo的服务调用是通过RPC实现的，但是如果仔细拜读过Martin Fowler的Microservices一文，其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢？

1.服务提供方与调用方接口依赖方式太强 我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。

2.服务对平台敏感，难以简单复用 通常我们在提供对外服务时，都会 以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。
相信这些痛点也是为什么当当网在Dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。

Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。

而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

Dubbox带来什么 Dubbo服务治理


Dubbox扩展特性

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

1.《分布式RPC框架性能大比拼》
2.《实施微服务，我们需要哪些基础框架？》
3.《微服务（Microservice）那点事》
4.《Spring Cloud微服务框架主要子项目和RPC框架的对比》
5.《微服务、SOA 和 API：是敌是友？》
6.《微服务与SOA的实践应用对比》
7.《微服务架构的基础框架选择：Spring Cloud还是Dubbo？》
8.《微服务与SOA架构》
9.《Web Service实践之REST vs RPC》
10.《RPC好，还是RESTful好？》
11.《Rpc和Rest接口，微服务之Rpc》
12.《WEB开发中，使用JSON-RPC好，还是RESTful API好？》
原文链接：http://m.sohu.com/a/222328540_756465