基于Dubbo服务治理模式的单体架构改造

侯海平，李 龙

当数据存储的容量和速度不受约束时，各种数据中心规模呈爆炸式增长，移动互联网的加速发展又进一步推动各种基于数据的业务应用快速发展.历史上以往任何时期产生的数据、存储的数据、使用的数据都没有当今这个时代的数据规模大，数据从服务端到客户端或者从客户端到服务端都需要庞大的业务架构作为支撑，这些业务架构中最为核心的架构就是服务器架构体系，好的服务器架构可以保证业务和数据高速增长下，系统还具有良好的高并发性、高稳定性以及高扩展性.

1 传统单体架构

大多已有的服务架构都是一种单体架构，所谓单体应用是指将一个完整的Web应用程序部署在一台服务器上.在软件工程“高内聚低耦合”的思想指引下，所有单体架构Web应用程序都会采用一种分层的思想，如传统的“三层式架构”或者“多层式架构”.按照分层分职责的原则将软件结构划分为：表现层、业务层、数据层.或者再次将每个层次进一步细化分层，做到层与层之间进一步解耦.通常单体架构分层如图1所示.

图1 单体架构分层示意图

common表示项目中通用类集合，通常如字符处理、通用正则表达式等.

config表示项目中基础配置内容，如加密方式配置信息处理、解密方式配置信息等.

controller表示MVC设计模式中Controller，可以是Struts2中的Action，也可以是SpringMVC中的Controller.

dao表示数据访问的接口，是对数据访问的基本约定，与具体数据库无关，与具体数据库ORM框架无关，可以对接Hibernate框架，也可以对接MyBatis框架.

dao.impl表示选择某一种ORM框架对数据访问接口的具体实现.

dao.mapper表示ORM框架中需要映射描述文件.

entity表示业务中实体模型，也可以包括用于UI的视图层数据模型.

interceptor表示webapp中拦截器，用于实现权限控制或者其他请求的预处理.

service表示对项目业务的基本抽象，是一个接口层次.

service.impl表示业务接口的实现层.

单体架构在业务快速增长的背景下暴露出众多问题：

（1）难以适用并发请求的弹性变化［1］.请求繁忙时，需要部署更多的Web应用程序来应对业务高速的增长；业务请求空闲时，如果部署过多的服务器也会造成闲时服务器的浪费.实际的业务量不会一直处在高峰期，需要有恰当策略去应对业务的波峰和波谷.

（2）系统整体性能脆弱.如果某一业务非常耗费时间，则会导致整个服务器瘫痪，所有应用无法响应，可谓是牵一发而动全身.单体架构无法屏蔽某一业务对整体的影响，只能通过部署更多的服务器，将宕机的服务器从服务器组中剔除.

（3）架构扩展性差.业务不仅请求量会上升，而且业务本身也会发生变化.每个业务模块往往需要快速迭代，然而业务之间的隔离性较差，业务依赖度较高，一个业务的修改需要其他业务模块也随之发生变化，从开发、测试到部署都需要整体进行，大大拖慢了业务系统的迭代进度.

2 Dubbo服务治理架构

2.1 服务治理模式

大型互联网系统中，业务规模发展迅速，系统模块数量快速上升，在进行单体架构改造过程中会将业务模块拆分成一个个独立的服务组件.这些服务组件会独立部署.在构成应用平台时，他们相互之间既有逻辑上非常复杂的依赖关系，又保持相对的独立性，这种关系就要求每一个服务组件必须独立开发、独立部署、独立测试、统一授权、统一编排、统一配置，某一个服务迭代升级，同时又不能影响其他服务的正常运行，站在对其他服务角度来说是感觉不到当前服务迭代的.这一情形下就需要有一套综合的服务治理模式来应对庞大的服务组件形成的依赖关系.如截止2017年“双十一”，阿里巴巴在实际的生产环境中发布的服务数量超过23000，蚂蚁金服使用SOFA中间件治理这些服务［2-4］.这套服务治理模式必须能够解决服务注册与发现、服务监控、集群容错、负载均衡等问题.

2.2 Dubbo框架解决问题的范围

在业务快速迭代的大环境下，上述问题必须解决，激增的并发量、集群化部署、高扩展性的系统已成为业务平台需求的发展趋势，Dubbo正是在这一情形下诞生.它是一个经过阿里巴巴“双十一”考验的分布式服务架构［2-4］，实施Dubbo框架对现有架构进行改造，就能较好地解决上述问题.Dubbo框架是基于RPC（Remote Procedure Call Protocol，远程过程调用协议）通信方式的服务框架，RPC无论是从接口标准化方面还是从性能方面都有很好的表现.同时，近年来Dubbo框架又引入稳定性较好和性能表现较好的Netty和Mina作为通信层面的基础框架，大大保障了远程调用的性能.

在传统架构中引入Dubbo框架，可以解决：

（1）服务组件之间通信.服务组件可以互为Provider（提供者）和Customer（消费者），Provider向注册中心注册登记服务的地址和名称，注册中心向Customer广播Provider的地址和名称.Cus⁃tomer通过获取的地址和名称向Provider发起调用服务的请求，Provider响应请求.这一模式使集群部署成为可能.如图2所示.

图2 Dubbo框架的提供者和消费者通信方式

（2）服务组件的集群化部署与容错.集群化部署是一种业务横向扩展能力，主要应对于业务量的波峰与波谷变化，业务急速上升时，同一业务服务组件以更多服务器形式进行集群部署，而并不是让整个Web应用程序进行集群部署，大大提升了业务系统的稳定性.对于其他服务消费者来说，并不需要关心某一业务是否进行了集群部署，业务隔离性较好，这一操作方式也非常符合SOA（Service Oriented Architecture，面向服务的架构）架构要求［5-6］.如图3所示.

集群容错主要表现在其容错策略：Failover，自动切换，可设置重试次数，失败后连接其他服务器；Failfast，只发起一次，失败则立即报错；Failsafe，失败直接忽略，计入日志；Failback，失败自动恢复，定时重发；Forking，调用多个服务器，只要一个成功即可；Broadcast，对提供者服务器逐个调用，有一台出错就报错.

（3）服务组件自动化管理.Dubbo框架还提供Dubbo Admin这一服务管理平台用于开发人员和运维人员对服务进行管理和控制.通过Dubbo Admin可以清晰地看到Dubbo服务框架中正在运行的提供者和消费者，并且了解负载均衡信息，也可以通过该后台设置服务的提供者和消费者属性、路由规则及权重参数等.

2.3 Dubbo框架服务治理方面的表现

应用之间采用RPC方式通信是业务系统架构服务化的基础.架构服务化会带来很多挑战和管理问题，这就需要有一套针对大规模服务进行治理的方案.Dubbo框架就是一套比较完整的服务治理方案.Dubbo在服务治理方面具备很多优势，这些优势表现在：

（1）Dubbo框架使用服务编排、调度中心管理这些服务，即使服务越来越多，由几个模块迅速扩张为几十个服务，甚至上百个服务，服务之间有高度依赖关系也能较好地应对.

（2）每个服务需要有独立的负载均衡管理方法，服务是上线运行还是下线停止，需要服务之间相互独立，互不干扰.Dubbo框架提供了服务容器和容量评估模块实现合理扩容和减容.

俄罗斯专家表示，欧盟《机器人民事法律规则》里专设了“机器人宪章”，规定了机器人设计和研发过程中必须遵守的基本伦理原则，制定了机器人工程师道德行为守则，以及设计师的“许可”制度和用户“许可”制度。这些都是俄罗斯在立法时需要参照的范本。

（3）每个服务可以通过Dubbo框架的授权中心和服务路由模块进行服务使用者身份鉴定，确保服务调用的合法性.

（4）Dubbo包含服务监控模块，可以对服务的调用情况进行实时监控和统计，最终帮助用户掌握服务使用情况.

3 传统单体架构的Dubbo框架化改造设计

3.1 充分理解单体架构内层与层之间关系

单体架构中的包主要是为了对Web应用程序进行分层隔离，做到业务逻辑、数据读写、UI表现之间的解耦.通常一个SSH和SSM框架下的Web程序拥有如图4所示的层与层之间的关系.

图4 单体架构下层关系

步骤1：当用户发起请求时，Java Servlet容器中的Interceptor首先拦截用户请求.如果用户满足Interceptor的要求则继续转发请求给Controller.

步骤2：Controller根据业务特点调用相关的Service接口，根据Spring注入的Service实例来进行业务服务调用.

步骤2.1：表示Service接口将会选择相关的实现类来执行具体的业务逻辑.

步骤3：Service的实现类中涉及到数据的读写操作是通过调用Dao接口来完成.

步骤3.1：Spring会将Dao接口对应的具体实例注入到Service实现类中.

步骤3.2：将相关数据库操作的ORM映射关系抽取成立一个单独的层，便于数据库操作相对独立，并提供给Dao.Impl来进行调用.

步骤4：数据模型、通用方法、配置信息提供给整个应用程序.

步骤5：所有调用完成，将结果反馈给用户.

3.2 根据“职责单一”原则拆分业务包为独立项目

“职责单一”原则要求每一个类独立完成一个功能.为了进一步细粒度化业务模型单元，将业务模块进一步细分和拆解成更小的单位.将那些高频调用的业务组件、业务变更较快的业务组件独立出来.这里假定所有业务系统中都有用户中心服务组件，对于大多数系统中也都包含用户中心模块，用户中心模块通常包括用户登录、注册、认证、注销、管理等功能，以下步骤以“用户中心”模块为例.

步骤1：使用maven对拆分后的项目进行构建、安装、部署管理.所有项目都使用maven进行构建.

步骤2：拆分后的系统架构分为10个组成部分.具体如图5所示.

图5 使用Dubbo框架改造后的服务治理模型

步骤3：建立WebApp-Parent项目，maven的项目类型为pom类型.该项目作为其余9大项目的父项目存在.作用是将所有项目的依赖管理配置在此项目中，并且在此项目中对所有其他项目进行version（版本）管理.

步骤4：抽取原有common包建立WebApp-Common项目，抽取config包建立WebApp-Com⁃mon-Config项目，抽取原有Dao包下有关数据库底层辅助访问类建立WebApp-Common-Core项目，抽取Dao包建立WebApp-Dao-User（以“用户中心”模块为例），抽取Entity包建立We⁃bApp-Entity-User项目，这些项目maven项目类型为jar，将成为其他项目的依赖项.

步骤5：抽取Service包建立WebApp-Ser⁃vice-User项目和 WebApp-Service-Impl-User项目，其中WebApp-Service-User项目将成为We⁃bApp-WebPortal项目和 WebApp-Service-Im⁃pl-User项目的依赖项.WebApp-Service-User项目为服务提供者和消费者都需要的服务接口.

步骤6：抽取Controller和Interceptor包建立WebApp-Common-Web项目和 WebApp-Web⁃Portal项目，其中WebApp-Common-Web项目是WebApp-WebPortal项目的依赖项.

步骤7：最终拆分成10个独立项目.

3.3 安装注册中心，构建和部署服务

（1）安装注册中心.设置注册中心，在服务器上安装ZooKeeper项目，ZooKeeper也是Dubbo官方推荐的注册中心［7-9］.服务提供者和服务消费者都需要使用ZooKeeper进行首次通信，服务提供者向ZooKeeper注册登记服务，服务消费者向ZooKeeper订阅提供者信息.

（2）构建和部署服务.服务的部署往往需要考虑是否能够快速实现，过程是否复杂或者能否自动化，同时兼顾部署过程中能否适应正在运行的服务，不能干扰已有服务.针对这一情形，Dub⁃bo框架给出服务部署的三种做法：

①使用Servlet容器运行Dubbo服务组件.运维人员可以通过Tomcat或者Jetty等服务器程序来运行Servlet容器，然后把Dubbo服务当成一个独立的Servlet容器来运行.这种方式操作起来比较简单，但是需要分配好端口，且每一个Servlet都需要浪费更多的内存资源.

②自定义程序入口，建立main入口方法运行Spring容器，通过Spring加载Dubbo服务，解决了内存资源浪费的问题，但是由于没有使用Dubbo优雅关机等高级特性，在服务的调用上缺少一定的处理能力.

③使用Dubbo框架提供的com.alibaba.dub⁃bo.container.Main方法加载Spring容器，再由Spring框架加载服务组件.既能够较好地利用内存资源，又能够使用Dubbo提供的优秀特性.如某一服务接收到关闭指令，而同时又有服务消费者在消费该服务，则会等待该服务调用完毕后关闭.

结合上述每种做法的特点，选择第三种方式来构建和部署服务.

4 结束语

Dubbo框架已经成为服务治理框架中较为成熟的框架之一.在服务通信、服务管理、服务部署等方面都有不错的表现.

本文针对Dubbo框架特点进行分析，探讨了一种改造传统单体架构的方法和实现路径.想要提高改造的成功率，首先应充分了解当前单体架构的业务特点，理清原有业务间关系；其次要灵活运用Dubbo框架的实施策略.本文重点以“用户中心”模块为例，阐明了改造单体架构的方法和步骤.