SOA框架——Dubbo

1.背景

想象下这么个场景:

有个做生活服务的APP,主要提供一些生活化的咨询信息,比如天气、新闻、个人三金账单、政府办事事项等等,那么把这些功能全部放入一个应用肯定是不现实的。

按照分布式服务的设计理念,可能最终的结果是用户登录、注册相关的作为一个user应用,天气相关的一个weather应用,新闻资讯相关的一个news应用,账单相关的一个bill应用,政府办事相关的一个life应用,这样就被拆分成了若干个功能相对稳定的应用,同时应用之间通过RPC调用,共同构成了一个分布式服务框架。

这种分布式服务架构在流量、服务数量相对小的时候足够满足实际需要,但是在服务数量越来越大、流量增大或者间断性流量出现峰值、服务间调用越来越复杂的情况下,这种架构就就很难再满足需要了。比如上述的APP这周搞推广注册送礼的活动,突然间登录、注册的操作暴增,此时负责处理相关业务的user应用负荷增加,出现响应慢、超时、宕机的情况,怎么办?按分布式服务框架,最简单直接的办法是增加user应用的实例、带宽等硬件资源,再在调用方或者Nginx端改改user应用相关的负载列表,重启over。等推广结束之后再改改负载列表,停掉增加的资源,重启over.......

如此一来,反复地增加、删除、停止、启动,只要中间某一步做错,就会造成难以想象的错误。那么如何弹性、动态地计算所需资源,又如何动态地增加、删除资源,最大程度不影响业务流转,减少犯错误的几率,是一个新的课题。由此流动式的架构理念运用而生,而dubbo框架正是流动式计算架构的一种。

2.Dubbo是什么

Dubbo是阿里旗下的一个弹性的分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。

3.Dubbo能做什么

3.1.透明化的远程方法调用

没有API侵入,就能像调用本地方法一样调用远程方法。

在实际项目中,通常会对Provider和Consumer使用的公共部分,抽象为一个通用的一个jar包,内部定义需要的Service、DTO、POJO、工具类等。此时,Provider端实现Service服务,Consumer引入jar包,申明服务。通过此种方法,实现无API侵入,Service对Consumer透明,但最终实现了Consumer对Provider的调用。

3.2.服务自动注册与发现

服务的注册、发现、更新都是基于注册中心Registry来实现的。

Registry与Provider、Registry与Consumer之间实现了基于Socket长连接的实时心跳检测,每隔几秒钟检测一次,收集Provider、Consumer的服务信息,整理更新服务列表。通过这样的实现,Provider和Consumer均不再需要写死服务提供方地址,只需要配置注册中心地址即可,实现动态化。

3.3.软负载均衡及容错机制

Dubbo提供了一系列的软负载均衡算法供使用,可替代F5等硬件负载均衡器,降低硬件成本,减少单点。

Consumer通过订阅服务,在本地缓存可调用的服务列表,在实际调用某服务时,基于负载均衡算法,选取某一节点调用。当某服务节点宕机、或网络不可用时,Registry基于心跳检测实时更新可调用者列表,并将更新信息推送到Consumer,由Consumer更新本地缓存,实现容错,实现高可用。

4.Dubbo服务架构及调用流程

Dubbo架构图如下所示:

节点角色说明:

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心,可选。

Monitor: 统计服务的调用次调和调用时间的监控中心,可选。

Container: 服务运行容器。

调用流程:

0. 服务容器负责启动、加载,运行Provider。

1. Provider在启动时,向Registry注册自己提供的服务,Registry缓存服务列表,并建立长连接心跳检测。

2. Consumer在启动时,向Registry订阅自己所需的服务,并建立长连接心跳检测。

3. Registry返回服务提供者地址列表给Consumer并缓存,如果服务有变更,Registry将基于长连接推送变更数据给Consumer并更新。

4. Consumer在使用服务时,基于软负载均衡算法,从提供者地址列表中,选一台Provider进行调用,如果调用失败,则切换到另一台调用。

5. Consumer和Provider,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到Monitor。

5.Dubbo应用搭建

Dubbo采用全Spring配置方式,透明化接入应用,只需用Spring加载Dubbo的配置即可。

代码结构

代码project结构非常简单,如图:

其中,

dubbo-api是公共的基础包,主要声明provider和consumer共用的服务接口、工具类、实体等,以jar包形式提供;

dubbo-provider是服务提供者,声明provider需要提供的哪些服务,以war包形式提供;

dubbo-customer是服务消费者,声明需要使用的服务,以war包形式提供;

dubbo-service是dubbo-api中服务的实现者,此包可直接包含在dubbo-provider中,以jar包形式体现。

Dubbo-api

在公共jar包中,定义服务接口,如下:

dubbo-service

在实现jar包中,实现dubbo-api中定义的接口(此实现对消费方式透明的),如下:

dubbo-provider

使用Spring配置声明对外暴露服务,主要包含:

dubbo-application服务提供者的名字:标记唯一提供者;

dubbo-registry注册中心地址及其端口:启动时,向注册中心注册服务,此处使用zookeeper;

dubbo-protocol通信协议及端口:各个终端之间通讯的协议,使用dubbo协议;

dubbo-service暴露服务声明:需要暴露哪些服务,就声明哪些dubbo:service的Bean。

dubbo-customer

使用Spring配置,引用远程暴露的服务,主要包含:

dubbo-application服务消费者名字:标记唯一消费者;

dubbo-registry注册中心地址及其端口:启动时,向注册中心订阅服务,并在本地缓存;

dubbo-reference服务引用:声明需要使用的服务接口名称,和原生spring声明bean的方式类似。

配置如下图:

服务使用时,像spring式注入JavaBean,类似本地化调用Service一样使用,如图:

dubbo工程搭建总结

通过上述代码示例,不难看出dubbo使用其实非常简单,通过Spring配置全部搞定。对于消费者来说,只需要知道服务在哪里、服务名叫什么、有什么方法、入参是哪些即可,不需要知道内部的实现细节。这种特性完全无API侵入,实现各部分之间松散耦合,减少依赖。

6.Dubbo的高级特性

除了上述基本功能之外,dubbo具有诸多高级特性,组成了dubbo整套架构体系。

多元化注册中心

注册中心可以使用zookeeper、redis等作为注册中心,也可以去中心使用广播形式。

zookeeper作为注册中心,内部存储使用了目录式结构,此为推荐;

Redis这样的K/V式数据存储,内部则使用了服务名作为Key,URL地址作为Value,比如:

另广播Multicast形式,启动时广播自身的地址,无注册中心,此为测试使用。

集群容错

上述示例中,只使用了单个zk实例、单provider、单consumer,实际生产中还可以配置多个实例即注册中心集群、provider集群、consumer集群,相同集群之间是等价的,最终为负载均衡提供条件。

软负载均衡

当注册中心其他实例宕机,只要有一个可提供服务则可保证整个应用群可正常发布、订阅服务;即使全部宕机只要之前的服务提供者可正常提供服务,虽不能发布和订阅,但是消费者任然可以调用,因为消费者本地缓存了可调用列表。

Provider集群各实例提供了相同的服务,只要有实例新增或者宕机,基于长连接通讯,每个消费者均能感知到并及时更新自身缓存列表。实时调整路由群。

Consumer消费者对服务进行invoke调用时,会根据负载均衡算法,分发请求到某个provider实例,降低各个实例的负载。成熟的负载均衡算法有随机、按公约权重轮询、最少活跃调用数、一致性Hash,使用者可以根据机器、网络等情况实时分配和调整策略,灵活方便。

统一化管理平台admin

dubbo提供了可视化的管理平台dubbo-admin,使用者只要下载运行应用即可。

此平台提供了丰富的管理功能:

服务管理:有哪些服务,哪些在使用哪些已停止,对应的主机、端口、权重是多少,实时调整;

应用管理:当前有哪些应用,各自是什么角色,相互调用关系是什么,使用的负载均衡算法是什么等等。

运营监控中心

此为可选组件,对应项目为dubbo-monitor,监控SQL执行、服务调用等统计信息。和provider、Consumer一样,通过spring配置的形式,声明dubbo:monitor角色。在provider和consumer端,声明monitor地址,并定义AOP切面,收集监控信息,并定时向监控中心发送。

7.Dubbo的缺点

上面叙述了种种dubbo的优势,下面说说它的缺点。

体系结构方面

Dubbo要求将功能服务化,抽象成若干个通用的小的服务,形成分布式结构。因此往往会在最后形成大量的服务,体系会非常庞大,管理起来比较困难。但这跟它带来的种种有点相比,还是微不足道的。

安全性方面

Dubbo在使用场景方面主要针对内部的服务,由内部人员进行管理,一般很少对外部系统开放。而通常对外的服务,一般建立WebService、Rest等形式的接口,并辅助OAuth等安全协议来来处理安全。这就造成了,Dubbo在安全方面实现的功能较少,主要原则是基本上只防君子不防小人。

目前安全性层面,Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。

本文作者:兰伟敏(点融黑帮),主要从事Java后端开发,爱好电影、旅行、DOTA,目前主要负责贷款端LOANAPP系统研发。

推荐阅读更多精彩内容

  • Dubbo是什么 Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式...
    Coselding阅读 16,311评论 3 196
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 129,384评论 18 137
  • 我说:“我可以称呼您为致远吗”致远说:“当然可以!那我就称呼你为小辉了,现在我们就是兄弟了!”我说:“好,现在...
    石雨乐阅读 103评论 0 0
  • 最近不知怎的,迷上了分享做食物,就如同我喜欢待在厨房是享受做饭的过程一样,即便没有知音,依旧改变不了我的初...
    米思辰阅读 149评论 0 0
  • 努力,会让你自由,更自由的做一些事情,也让你更自由的拒绝做一些事情。 努力,会给你资本,让你有资本去赢的爱,也有资...
    馨之芬芳阅读 229评论 1 2
  • 今天加班了,感觉身体已经透支,感觉背部有种酸痛的感觉,这是一般在长时间久坐和使用鼠标的情况下才会出现的症状。忙完工...
    草千习习阅读 291评论 0 0