聊聊Dubbo（一）：为何选择Dubbo

最新推荐文章于 2022-07-31 08:42:07 发布

ITFLY8

最新推荐文章于 2022-07-31 08:42:07 发布

阅读量188

点赞数

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

服务

为什么要做服务？

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

640?wx_fmt=png

单一应用架构，当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。
垂直应用架构，当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架（MVC）是关键。
分布式服务架构，当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
流动计算架构当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。

服务带来的挑战

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

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

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

640?wx_fmt=png

服务未来的趋势

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

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

640?wx_fmt=jpeg

微服务并不是一种新思想的方法。它更像是一种思想的精炼，一种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的插件。

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

640?wx_fmt=png

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

整个jar很小，轻量；
配置简单；
功能强大，抛开了SOAP（Simple Object Access Protocol简单对象访问协议）、EJB，采用二进制来传递对象；

640?wx_fmt=jpeg

实际场景中的选择：

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

RPC vs REST(JAX-RS)

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