浅析如何使用Dubbo构建服务集成平台

Posted 2021-04-05 东航IT百分百

1.    Dubbo的介绍

1.1    分布式服务框架的演进

互联网服务和BS架构的传统企业软件相比，系统规模上产生了量级的差距。例如

·       传统BS企业内部门户只需要考虑数百人以及几千人的访问压力，而大型互联网服务有时需要考虑的是千万甚至上亿的用户；

·       传统企业管理系统管理的物料信息等，可能只有数万或数十万条记录，而一个大型B2C网站的商品SKU动辄千万，考虑到商品信息更新的历史记录，商品订单记录等数据，更是天文数字。

在这种背景下，常规的企业垂直的应用架构已经无法应对，服务式的应用架构以及分布式的服务框架势势在必行，用户亟需一个治理系统确保架构有条不紊的演进。

服务平台演进过程：

第一阶段：单一应用架构

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

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

第二阶段：垂直应用架构

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

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

第三阶段：分布式服务架构

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

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

第四阶段：弹性服务架构

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

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

1.2    Dubbo是什么

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

其核心部分包含:

远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

Dubbo的作用：

透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

2.    Dubbo的特点

2.1    Dubbo的特点

Dubbo是阿里巴巴提供的开源SOA框架，其设计原则：

• 零入侵
• 高性能
• 高可靠/适应高幵发的环境
• 模块化设计
• 从底层支持服务化

• 微内核，便于扩展

Dubbo经过了几个大版本的发展后，目前已经成熟稳定。它提供了功能强大的SOA服务治理功能，内置了可以代替负载均衡硬件的软负载，设计良好的监控模块，当然最根本的，它还是一个高性能可靠的RPC框架：

 

 图 2-1 Dubbo

Dubbo是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供

3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点，并在其他公

司也得到了广泛使用。由于其架构易于扩展，很多互联网公司还在其上构建自己的服务平

台，例如京东，当当，去哪儿等。

2.2    Dubbo的工作原理

 

 

图 2-2 Dubbo逻辑架构图

如上图所示，Dubbo逻辑架构分为Provider，Consumer，Registry，Monitor，Container5个主要的组件，其中：

1）Provider表示暴露DUBBO服务的服务提供方；

2）Consumer表示调用DUBBO远程服务的服务消费方；

3）Registry表示DUBBO服务注册与发现的注册中心；

4）Monitor表示统计DUBBO服务的调用次数和调用时间的监控中心；

5）Container表示DUBBO服务运行容器。

各种组件之间的调用关系如下：

0表示启动DUBBO服务，加载运行服务提供者，该调用在DUBBO服务初始化时完成。

1表示DUBBO服务提供者在启动时，同时向DUBBO服务注册中心提供自己的服务，该调用在DUBBO服务初始化时完成。

5表示基于DUBBO服务的监控中心的数据统计，统计DUBBO服务的消费者和提供者在后台采集服务和调用服务的次数和调用时间等信息，这些信息会将统计后的信息推送至MONITOR监控中心。

 

3.    Dubbo的架构方案

3.1    内部服务集成

Dubbo内部服务集成应用场景主要有以下几点：

1.     服务应用需要被大数据量并发的分布式访问，且不打算采用价格昂贵的硬件负载均衡方案。

2.     当服务越来越多，服务URL管理起来困难，服务调度也成了问题，可使用DUBBO的自动注册发现服务和服务治理的功能进行管理。

3.     服务应用需要及时响应，若使用WEBSERVICE等远程调用机制，会导致数据延迟，对数据实时性要求高的应用服务。

4.     应用之间错综复杂且耦合度高，应使用DUBBO进行原子服务的分离，不仅可以保证服务的原子性，还能加强服务的健壮性和可拓展性。

对于内部的服务集成，使用Dubbo的标准协议基于TCP的RPC调用非常简便，服务端自动注册到注册中心，使用方就可以自动获取到服务方信息，建立RPC通道。

 

 

图 3-1 Dubbo

3.2    系统间服务集成

DUBBO系统间服务集成应用场景主要有以下几点：

1.     同构系统之间的服务集成，可采用类似于内部系统集成的方案，服务提供方直接通过Dubbo协议注册服务，使用方通过注册中心获取服务目录进行调用

2.     异构系统之间的服务集成，可以通过在Dubbo原子服务基础上封装Dubbo服务网关，暴露成通用的HTTP/REST/WEBSERVICE协议，供异构系统调用。

3.     可自行扩展Dubbo服务网关，也可以在开源的Dubbox基础上构建。

使用Dubbox构建的蓝图：

 

 

图 3-2

4.    在Dubbo基础上构建服务集成平台的探索

Dubbo本身设计原则是无侵入，使用成本很低。不过在大型企业应用中，由于已有系统和解决方案的复杂性，仍然有不满足或契合的地方。所以还是需要在Dubbo基础上针对需求，做扩展和改造。

4.1    服务集成

4.1.1    权限管理

 

图 4-1

 

4.1.2    服务端权限控制

Dubbo的服务权限在客户端就进行了控制，所以服务端的权限控制基本上只防君子不防小人，只防止误调用。（Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。） 

 

图 4-2

如果需要真正的安全防护，可以在服务提供侧做必要的校验和控制。Dubbo的架构可以允许在调用前，插入用户自定义的逻辑，从而达到在服务端进行权限控制。

4.1.3    支持多协议、端口

Dubbo支持应用的单实例多协议和端口，但是多协议中不能有两个以上基于http的协议，原因是Dubbo的设计考虑的是分布式网络环境下的部署，这种情况下单实例一般不会出现同时支持多种http类型的协议的情况。但是在东航，由于遗留系统多以及有些项目机器资源不足，会出现一个实例同时支持Dubbo协议以及webservice，rest协议的需求。在同时配置两种以上的http类型的协议时，Dubbo会只保留一个协议，其他的会失效。

要支持这种需求，就可以扩展Dubbo的http协议，使其在多个协议并存的情况下，不会互相冲突。

4.1.4    服务质量管理

服务质量主要包括每服务每客户端的并发数和单位时间段的总调用次数。Dubbo支持对并发数的限制，对于调用总次数没有限制。另外，由于Dubbo是一个分布式的框架，并发数的限制是针对每一个Server的，不是针对每个服务的所有Server的总数。

因此，可以做这些改造：

1）扩展Dubbo服务治理系统，使其支持服务质量的相关配置：

 

图 4-3

2）Dubbo的性能监控区分不同的客户端，并在服务端根据统计分析后的数据，依据SLA配置进行流量控制

4.1.5    审计日志

Dubbo本身可提供对所有服务调用记录审计日志，只是默认实现是记录到本地文件。为方便后期的统计查询，可将其改为记录到数据库。访问量小的服务可直接插入数据库，访问量大的服务可通过日志采集系统异步导入数据库。

4.1.6    优雅停机

Dubbo已提供了优雅停机的机制，在进程中止时，会自动完成端口关闭等清理工作。

但在weblogic中部署Dubbo应用后，由于weblogic的管理机制，不是直接停止进程，而是在控制台中进行操作，会导致Dubbo的优雅停机机制失效。这样在重启服务后，会提示端口已被占用，服务无法正常启动。

通过在给应用添加的关闭监听器中，直接触发停机机制，可避免这个问题。

 

4.2    服务监控

4.2.1    服务性能监控

Dubbo已提供了一个基本的监控系统，在Dubbo的监控系统上，可做扩展：

1. 将其存储从文件改为数据库，便于查询统计

2. 扩展其查询时间段，使其支持自定时间段的统计展示

3. 根据需要修改记录的数据内容

 

 图 4-4

4.2.2    服务可用性监控

通过Dubbo内部的协议，可以侦听到服务的上下线信息，也可分析出哪些服务没有一个提供者。再根据这些数据，对服务的通用可用性进行监控告警。

业务的可用性可以针对每个服务再另外定制开发。

4.2.3    全调用链监控

分布式系统是复杂的网状结构，一个客户端发起的请求，如果可能经过了很多的环节和机器，而每一次的请求的路由也各不相同。对一个请求做全调用链的监控，首先要记录下每次请求的性能数据，并在一个调用链经过的所有路由上保持关联。

图 4-5

而借助Dubbo强大的底层Rpc框架，在通信过程中对请求的数据进行抽取封装，可以无侵入的实现全调用链的监控。

4.3    服务治理

4.3.1    对应用的服务治理

Dubbo提供了强大的服务治理功能，运维人员可以通过控制台进行服务注册，降级，路由规则，访问控制，动态配置，权重调节，负载均衡等。在此基础上可以补充扩展特殊的业务需求。

 

 图 4-6

4.3.2运行期动态服务治理

在应用正常的运行过程中，由于外部环境/接口的变化，或者服务自身的运行情况的调节，服务提供者或者监控程序可以根据业务需要，在满足一定的条件下自动下发指令，进行服务治理。

5.    Dubbo在shopping的应用案例

5.1    总体方案

在Dubbo上构建服务集成平台，把业务从服务平台中剥离出去

集中服务治理和监控

分割组合服务和原子服务，原子服务聚焦具体业务，组合服务聚焦接口封装和业务流程

 

图 5-1

5.2    架构设计

1. 以Dubbo为基础，封装原子服务，通过dubbo协议集成系统内的服务

2. 以Dubbox为基础，封装组合服务，通过rest/webservice/dubbo协议给异构系统提供服务，实现系统间以及外部系统的服务集成

3. 搭建服务注册中心，实现服务的自动注册/发现

4. 搭建服务治理中心，实现服务的管理控制

5. 搭建服务监控中心，实现服务的性能监控/可用性监控

 

图 5-2

6.    Dubbo服务集成的开发步骤

6.1    服务提供

Dubbo的内部服务集成方式很简便，采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

内容服务集成首先安装完毕ZOOKEEPER后，建立WEB项目，引入相关的JAR文件

 

图 6-1

配置WEB.XML文件

写服务接口和服务类

注册服务，新建dubbo-service.xml文件

 

 图 6-2

6.2    服务调用

首先，新建WEB或者普通JAVA工程，引入Dubbo服务注册项目中的jar文件。需要导入一个服务接口（从上个程序中导入接口的jar并且导入到此项目中。）配置web.xml文件（和上工程一样），编写调用配置文件dubbo-consumer.xml文件，内容如下：

 

图 6-3

其次，编写测试代码，内容如下：

 

图 6-4

 

-END-

本文是“东航信息部IT百分百”原创，转载需注明出处

转载须保持以上所有内容完整。

文| PSS项目组 董泽浩